The official announcement post makes use of the phrase "salted and hashed passwords" but omits the fact that it was probably SHA1 with a three-byte salt.
A Reddit admin does confirm in a later comment that it was SHA1 that was used [1].
This information regarding the salt was only available because Reddit was open sourced for a while and the oldest commit (from 2008) still uses that hashing scheme. [2]
Let this be yet another reminder that SMS 2FA is not secure.
totp 2fa attack surface varies based on the trustworthiness of many factors between the server and the client... adding SMS seems to not add much when the client could store a totp and generate an OTP challenge locally.
Some standard, obvious (or not so) best-practices, based on defense-in-depth and security effort based on impact risk:
Hash passwords using a real pbkdf like argon2 in JS or native code client-side, using sensible mem-/cpu-/gpu-fpga-/asic-hard params, because passwords should never go over the wire in any form.
Use nonces where available.
Fixed-time compare hashes server-side, with exponential back-off.
2FA tokens should be stored server-side encrypted, only decrypted when needed to generate a challenge code and then securely erased, where available.
Prefer TOTP to SMS 2FA.
Lock down admin access to all production boxes to a dedicated private vlan or physical net behind ssh/vpn bastion (jump box) which has per-user ssh keyed logins.
Use gpg user-based, single packet authorization secure port knocking to allow access to ssh / vpn through bastion. Paranoia around admin access isn’t paranoid enough since a compromise would cost much time and money in many unforseen ways.
No root passwords, ssh keys only. If absolutely required, store N-keyed using something like vault.
Don’t give too many people access they don’t need, but also don’t micromanage.
No shared accounts or ssh keys for people; service accounts for unattended services only.
Audit and disable/remove creds/privs not being used.
Ssh/gpg/tls private keys must be stored securely.
Lock-down, audit, transparent proxy, SPI, scrub nearly all external ports/data.
> Hash passwords using a real pbkdf like argon2 in JS or native code client-side, using sensible mem-/cpu-/gpu-fpga-/asic-hard params, because passwords should never go over the wire in any form.
Please explain.
Does this meaning haahing the password on the client and then hashing the hash again on the server?
> Hash passwords using a real pbkdf like argon2 in JS or native code client-side, using sensible mem-/cpu-/gpu-fpga-/asic-hard params, because passwords should never go over the wire in any form.
If you're sending the hash on behalf of the password... doesn't that just turn the hash into password? In either case if you get the info that's all you need to send to the server for auth.
9 comments
[ 2.9 ms ] story [ 32.6 ms ] threadA Reddit admin does confirm in a later comment that it was SHA1 that was used [1].
This information regarding the salt was only available because Reddit was open sourced for a while and the oldest commit (from 2008) still uses that hashing scheme. [2]
Let this be yet another reminder that SMS 2FA is not secure.
[1]: https://np.reddit.com/r/announcements/comments/93qnm5/we_had...
[2]: https://np.reddit.com/r/announcements/comments/93qnm5/we_had...
Some standard, obvious (or not so) best-practices, based on defense-in-depth and security effort based on impact risk:
Hash passwords using a real pbkdf like argon2 in JS or native code client-side, using sensible mem-/cpu-/gpu-fpga-/asic-hard params, because passwords should never go over the wire in any form.
Use nonces where available.
Fixed-time compare hashes server-side, with exponential back-off.
2FA tokens should be stored server-side encrypted, only decrypted when needed to generate a challenge code and then securely erased, where available.
Prefer TOTP to SMS 2FA.
Lock down admin access to all production boxes to a dedicated private vlan or physical net behind ssh/vpn bastion (jump box) which has per-user ssh keyed logins.
Use gpg user-based, single packet authorization secure port knocking to allow access to ssh / vpn through bastion. Paranoia around admin access isn’t paranoid enough since a compromise would cost much time and money in many unforseen ways.
No root passwords, ssh keys only. If absolutely required, store N-keyed using something like vault.
Don’t give too many people access they don’t need, but also don’t micromanage.
No shared accounts or ssh keys for people; service accounts for unattended services only.
Audit and disable/remove creds/privs not being used.
Ssh/gpg/tls private keys must be stored securely.
Lock-down, audit, transparent proxy, SPI, scrub nearly all external ports/data.
Never trust external, unsecured data.
—-
HTH
Please explain.
Does this meaning haahing the password on the client and then hashing the hash again on the server?
If you're sending the hash on behalf of the password... doesn't that just turn the hash into password? In either case if you get the info that's all you need to send to the server for auth.
But you would also have added property that the password is never processed at all server-side.
IDK if that latter item is actually significant.