The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,115 other followers

Archive for the ‘Hashing’ Category

Password hashing on client side is insecure · Issue #44 · meteor/meteor-feature-requests · GitHub and some bcrypt notes

Posted by jpluimers on 2020/08/26

Some interesting bits from [WayBack] Password hashing on client side is insecure · Issue #44 · meteor/meteor-feature-requests · GitHub by tysonclugg:

Stop with the client side hashing – it’s security theatrics. Submit plain text passwords over TLS. The focus should be on having TLS enabled by default, and making sure the server has a sufficient amount of cryptographic work-factor during authentication to render brute-force attacks ineffective (eg: use server-side bcrypt).

Honestly, javascript password shenanigans in the browser is as dumb as backing up HOTP/TOTP secrets from your 2FA app in case you lose your phone. Hint: that changes “something you have” into “something you know”, authenticating with two things you know is single factor authentication. And yet, a group of “smart people” created an app that allows just that. Don’t be another one of those “smart people”.

If you’re still unsure about ditching client-side password hashing, have a read on what others have said:

  1. https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
  2. http://thisinterestsme.com/client-side-hashing-secure/
  3. https://security.stackexchange.com/questions/53594/why-is-client-side-hashing-of-a-password-so-uncommon
  4. https://cybergibbons.com/security-2/stop-doing-client-side-password-hashing/
  5. https://www.reddit.com/r/crypto/comments/375lor/is_client_side_hashing_of_passwords_viable_to/
    5.1. One of the comments specifically mentions SRP, but goes on to say:

You’ll probably be interested in the Secure Remote Password protocol (SRP). It uses a variant of the Diffie-Hellman key negotiation protocol to simultaneously authenticate the client with the server, the server with the client, and establish a session key for sending secrets between the client and server. It’s not very useful with web applications, because you still have to trust the encrypted channel to deliver the right version of the JavaScript to manage the communication. It could be useful for other client/server applications, where the client application can be verified and isn’t retransmitted every session.

If you’re still not convinced after reading all of the above, I’d suggest you contact a notable cryptographer for further advice. Prof. David A. Wagner might be a good choice.

Meanwhile, client side password hashing hinders upgrades to the password hashing scheme, and nothing has been done.

Hindering, not preventing. Of course you can send many hashed variants of the password from the client to the server to account for whichever legacy hash exists in the DB, but in my that weakens the system by allowing many hashes to be submitted simultaneously (or in short order) with no work factor. The result is that brute forcing an account becomes much easier.

and in [WayBack] Password hashing on client side is insecure · Issue #4363 · meteor/meteor · GitHub:

On compatibility (the reason I visited the Meteor password hashing code in the first place), upgrading to new hashing algorithms (which MUST be done from time to time) is much easier if the plaintext password is passed to the server, and transparent to the client as no new API is required to handle the case of upgrading from an old hash to a new hash. The generally accepted means of storing hashes is “$” such as “pbkdf2_sha256$15000$ZLpQISRxzhY0$fxrQcKxhkG//nHg10NrkulhvWkAqWbWeQg4QeD7c59E=
This is a PBKDF2 hash for the password “pass” which includes the number of rounds, the salt and the resultant hash ready to be verified and upgraded if required, for example by increasing the number of rounds from 150000 to 250000, or ready to be swapped to a different algorithm altogether (eg: pbkdf2_sha512).

NIST in 2017 on key derivation functions:

In June 2017, NIST issued a new revision of their digital authentication guidelines, NIST SP 800-63B-3,[12]:5.1.1.1 stating that: “Verifiers SHALL store memorized secrets [i.e. passwords] in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive.” and that “The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes.”

It looks like Argon2 is better than bcrypt and PBKDF2_SHA512. The 2017 hashing speed table:

sha1: 68.000.000.000 hash/s
sha256: 23.000.000.000 hash/s
sha512: 8.600.000.000 hash/s
sha3: 6.500.000.000 hash/s
bcrypt(5): 105.700 hash/s(for work factor 15 it’s {\displaystyle {\frac {105700}{2^{15-5}}}=103} hash/sec)
sha256crypt: 3.100.000 hash/s
And with stretching:
pbkdf2-sha1(1000 r): 26.000.000 hash/s
pbkdf2-sha256: 9.400.000 hash/s
pbkdf2-sha512: 3.400.000 hash/s

Also, one commenter mentioned that using future telling skills we expect that hash values improve 55% annually, which is exciting and scary at once. —grin 13:51, 10 October 2017 (UTC)

The cost is confirmed at [WayBack] bcrypt cost 10/12/14 brute force time? – Information Security Stack Exchange, so in 2020 it should be somewhere around the 12-14 range.

Moore’s law does not fully apply any more for single core performance, but there are other potential optimisations, and it is unclear how future hash attacks will improve, so it is better to use a mini-bench mark to calculate a good cost, see:

Delphi implementations:

Via:

Further reading:

–jeroen

Posted in Development, Hashing, Power User, Security, Software Development | Leave a Comment »

Hardening: sshd_config – How to configure the OpenSSH server | SSH.COM

Posted by jpluimers on 2020/06/05

If you want to harden your ssh server, read at least [WayBack] sshd_config – How to configure the OpenSSH server | SSH.COM.

After that use some ssh tools to check your config from the outside world. They work in a similar way as the TLS/SSL/https scans from Source: SSL Server Test (Powered by Qualys SSL Labs) or these console based scans and documentation references:

Simiarly for SSH:

Then read further on more in depth SSH topics around key management:

–jeroen

 

Posted in Encryption, Hashing, https, HTTPS/TLS security, OpenSSL, Power User, Security, testssl.sh | Leave a Comment »

OpenSSH keygen guidelines

Posted by jpluimers on 2020/05/01

Verify [WayBack] OpenSSH: Key generation before generating keys.

At the time of grabbing it was this (for the mozilla tag; use another tag if you prefer):

# RSA keys are favored over ECDSA keys when backward compatibility ''is required'',
# thus, newly generated keys are always either ED25519 or RSA (NOT ECDSA or DSA).
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

# ED25519 keys are favored over RSA keys when backward compatibility ''is not required''.
# This is only compatible with OpenSSH 6.5+ and fixed-size (256 bytes).
$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

This was not changed based on [WayBack] Key generation: pass-a and -o argument? · Issue #68 · mozilla/wikimo_content · GitHub: a discussion on the KDF rounds (-a parameter) and storage format (-o parameter).

This is slightly less strong than in [WayBack] Upgrade Your SSH Key to Ed25519 | Programming Journal, but seems to be OK when writing this in 2018.

For comparison, a similar discussion is at [WayBack] public key – How many KDF rounds for an SSH key? – Cryptography Stack Exchange.

In practice, I am not for one ssh ID per host, but I use different tags depending on where the ssh ID applies. More discussion on this is at [WayBack] privacy – Best Practice: ”separate ssh-key per host and user“ vs. ”one ssh-key for all hosts“ – Information Security Stack Exchange

Based on the above, I also learned about this password generator: [WayBack] GitHub – gdestuynder/pwgen

–jeroen

Posted in *nix, *nix-tools, Encryption, Hashing, Power User, Security, ssh/sshd | Leave a Comment »

A cheat-sheet for password crackers

Posted by jpluimers on 2018/07/30

Interesting: [WayBackA cheat-sheet for password crackers

Via: [WayBackJoe C. Hecht – Google+

–jeroen

Posted in *nix, *nix-tools, Hashing, md5, Power User, Security, SHA, SHA-256, SHA-512 | Leave a Comment »

Client-Side Password Hashing – DelphiTools

Posted by jpluimers on 2018/05/03

Interesting thought on client-side password hashing: [Archive.isClient-Side Password Hashing – DelphiTools.

I’ve ambivalent feelings on it, especially since it will expose salt and other settings to the client.

On the other hand it tremendously helps when there are transparent proxies in between. Read the article for full details; here is just one quote below.

Maybe dual hashing would be in place: once at the client to prevent plain-text to go over MITM channels, and a second hash server side with different settings like salt to prevent brute force attacks.

I need to give this more thought.

The quote:

If you are using a regular Windows and a regular browser, access to HTTPS will go through the regular certificate chain, using regular certificate authority. You also benefit from extra security layers like Public Key Pinning.

But when a custom Root CA is installed, all that goes through the window: the custom Root CA allows the corporate proxies to issue “valid” certificates for any website (even google.com and the rest), and the public key pinning features are disabled:

How does key pinning interact with local proxies and filters?

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. 

A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

All the major browsers have a similar behavior… because it is required to allow transparent proxies. And transparent proxies are the means through which the legal logging requirements are fulfilled.

So besides introducing a major MITM opportunity, this also means that there are legally-required corporate logs somewhere of all that went through HTTPS… including plain text passwords, if you did not hash them on the client-side.

These logs will have varying degrees of security when in the corporate domain… and next to none if they are ever requested by the legal system for an investigation.

–jeroen

 

Posted in Algorithms, Design Patterns, Development, Hashing, Power User, Security, Software Development | Leave a Comment »

 
%d bloggers like this: