
Reddit Was Hacked - ddingus
https://np.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/
======
mariust
Hmm, so... SMS is not that good, why not try this
[https://www.typingdna.com/](https://www.typingdna.com/) ( I am not working /
affiliate with them)

------
breakingcups
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.

[1]:
[https://np.reddit.com/r/announcements/comments/93qnm5/we_had...](https://np.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/e3f8kqa/)

[2]:
[https://np.reddit.com/r/announcements/comments/93qnm5/we_had...](https://np.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/e3fkvtq/)

------
jwilk
Duplicate of:
[https://news.ycombinator.com/item?id=17664301](https://news.ycombinator.com/item?id=17664301)

~~~
ddingus
Thanks. I just did not see that one.

------
modells
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.

Never trust external, unsecured data.

—-

HTH

~~~
zamadatix
> 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.

~~~
paulddraper
You could hash the password again on the server, preserving the property that
getting database info doesn't compromise logins.

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.

