Reconsider salted hashing construction

[Scott]

https://github.com/fedspendingtransparency/data-act-broker-backend/blob/development/dataactbroker/handlers/userHandler.py#L294-L310

It's a well-known fact that bcrypt will silently truncate after 72 characters. Appending a "salt" to the user's password before passing to bcrypt (which is, itself, a salted password hashing algorithm and uses a 128-bit salt derived from a CSPRNG) doesn't buy you any security.

To verify this:

1. Create two new users (Alice and Bob).
2. Set their password to the letter A repeated 72 times.
3. Without updating the hashes, swap their salts in the backend storage.
4. Logins will still succeed.

If you're looking to add a level of security beyond what bcrypt offers, you have a few ways you can go:

• Use Argon2i or yescrypt.
• Pre-hash passwords with SHA-384, taking care not to pass a raw binary string to bcrypt (it truncates on NUL bytes). If your hashing interface returns raw bytes, base64 encode the hash before passing to bcrypt.

[Becky Sweger]

Thanks for rightfully pointing out that we’re double salting our passwords. We’re in the process of mitigating this by moving to a single sign-on system (based on the Central Authentication Service provided by max.gov). Unfortunately, their source is not open, but we believe that shifting to their system (which includes optional 2-factor authentication) will be more secure in the long-term.

Again, thanks for taking the time to weigh in—we appreciate it!