5 ms·

This incident report glosses over the depth of what access was given to focus on the user data that was compromised... but it sure seems like they got pretty de

This incident report glosses over the depth of what access was given to focus on the user data that was compromised... but it sure seems like they got pretty deep: * A complete copy of an old database backup containing user data from launch in 2005 through May 2007 including: -usernames, -salted/hashed passwords, -e-mails, -all content including private messages * Reddit source code * Internal logs * configuration files * other employee workspace files [?]

bredren 8y ago
This is a serious breach and I'd suggest "gloss over" does not characterize Reddit's statement appropriately. Given how the report is structured, it seems like the amount of leaked data is purposefully being hidden behind red herring info about SMS 2FA that is not important to users who want to know where they stand. When this DB is leaked, there should be more than enough weak passwords to both pwn and dox many, many reddit users. Do we know the encryption scheme reddit used to encrypt their password database involved in the leak? Also, how is it that Reddit gained a head of security 2.5 months ago? Who was in charge of this prior to that date?
- Deimorz 8y ago
  > Do we know the encryption scheme reddit used to encrypt their password database involved in the leak? At the time of this backup, it would have been SHA1. Here's the relevant hashing code: https://github.com/reddit-archive/reddit/blob/4778b17e939e119417cc5ec25b82c4e9a65621b2/r2/r2/models/account.py#L244-L248 https://github.com/reddit-archive/reddit/blob/4778b17e939e11... Edit: reddit's confirmed this here: https://www.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/e3f8og0/ https://www.reddit.com/r/announcements/comments/93qnm5/we_ha...
  - bredren 8y ago
    While not unexpected, it is very bad for these users. This salt will do nothing to stop a cracking effort. A system with pairs of GTX 960 and GTX 1060 cards can easily check 12 billion hashes a second. This database is hosed.
  - zokier 8y ago
    randstr has this goldnugget of a comment: """If reallyrandom = False, generates a random alphanumeric string (base-36 compatible) of length len. If reallyrandom, add uppercase and punctuation (which we'll call 'base-93' for the sake of argument) and suitable for use as salt.""" https://github.com/reddit-archive/reddit/blob/4778b17e939e119417cc5ec25b82c4e9a65621b2/r2/r2/lib/utils/utils.py#L41 https://github.com/reddit-archive/reddit/blob/4778b17e939e11... The function has specifically a flag for use as salt, but the hashing code does not actually use it. Whoops. Of course the loss here is not really that significant (~4bits of entropy), but I find it still bit funny.
    - zokier 8y ago
      Picking on the code bit more while we are at it, random.choice that randstr uses is of course not backed by CSPRNG so its not ideal for salts. Although I would be shocked if attackers would be able to exploit that in any way. Kinda interesting is how they decided on specifically 3 characters for salt, which seems really low. Its not like the characters cost anything, why not 30 characters instead?
- JoblessWonder 8y ago
  I used "gloss over" because I wanted to give them the benefit of the doubt. I can see an argument that 99.9% of the users are going to just care about what user information was stolen. However, the fact that private messages were stolen is... I mean, it is just mind boggling to me. There has to be so much shit in there.
peterwwillis 8y ago
> other employee workspace files If "workspace files" meant "home directory", that's the big holy shit moment. People keep all kinds of stupid shit in home directories. SSH keys. Browser profiles. E-mail cache. Private keys for TLS certificates. Logs. Logs with secrets. Literally anything that's supposedly secret and used to run things. Put user home directories on an NFS mount and I can basically own your whole company.
- zakk 8y ago
  > People keep all kinds of stupid shit in home directories. SSH keys. Are you implying that it's stupid to keep SSH keys in one's home dir?
  - peterwwillis 8y ago
    If unencrypted, yes. Ideally your home dir is encrypted [so that only the user can unlock and use it]. (The truly paranoid will keep their private keys on an encrypted thumbdrive and remove it from the machine after authenticating the key into their keychain) But most of the time when I see network home directories in a company, it's just flat files on an NFS or CIFS share, which is bonkers.
    - whyever 8y ago
      > The truly paranoid will keep their private keys on an encrypted thumbdrive and remove it from the machine after authenticating the key into their keychain Does not necessarily help when the machine is compromised. Using one key per machine and storing it in the corresponding home directory seems safer to me.
      - peterwwillis 8y ago
        If you compromise the machine, you can attack anything on that machine. If the keys are in the home dir on the network, you can attack the network. If the keys are in the home dir on unencrypted local disk, you can attack the disk. If the keys are in a user namespace, you can attack the user namespace (which includes processes and mounts). If the keys are in a thumbdrive and in a keyring, you can only attack two things: 1) the user namespace, 2) the thumbdrive's mounted contents while it is inserted _and unlocked_. This limits the scope of attacks. When the keys in the keyring expire ("-t life" option to ssh-agent), you can't even attack that.

bredren 8y ago

This is a serious breach and I'd suggest "gloss over" does not characterize Reddit's statement appropriately. Given how the report is structured, it seems like the amount of leaked data is purposefully being hidden behind red herring info about SMS 2FA that is not important to users who want to know where they stand. When this DB is leaked, there should be more than enough weak passwords to both pwn and dox many, many reddit users. Do we know the encryption scheme reddit used to encrypt their password database involved in the leak? Also, how is it that Reddit gained a head of security 2.5 months ago? Who was in charge of this prior to that date?

Deimorz 8y ago
> Do we know the encryption scheme reddit used to encrypt their password database involved in the leak? At the time of this backup, it would have been SHA1. Here's the relevant hashing code: https://github.com/reddit-archive/reddit/blob/4778b17e939e119417cc5ec25b82c4e9a65621b2/r2/r2/models/account.py#L244-L248 https://github.com/reddit-archive/reddit/blob/4778b17e939e11... Edit: reddit's confirmed this here: https://www.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/e3f8og0/ https://www.reddit.com/r/announcements/comments/93qnm5/we_ha...
- bredren 8y ago
  While not unexpected, it is very bad for these users. This salt will do nothing to stop a cracking effort. A system with pairs of GTX 960 and GTX 1060 cards can easily check 12 billion hashes a second. This database is hosed.
- zokier 8y ago
  randstr has this goldnugget of a comment: """If reallyrandom = False, generates a random alphanumeric string (base-36 compatible) of length len. If reallyrandom, add uppercase and punctuation (which we'll call 'base-93' for the sake of argument) and suitable for use as salt.""" https://github.com/reddit-archive/reddit/blob/4778b17e939e119417cc5ec25b82c4e9a65621b2/r2/r2/lib/utils/utils.py#L41 https://github.com/reddit-archive/reddit/blob/4778b17e939e11... The function has specifically a flag for use as salt, but the hashing code does not actually use it. Whoops. Of course the loss here is not really that significant (~4bits of entropy), but I find it still bit funny.
  - zokier 8y ago
    Picking on the code bit more while we are at it, random.choice that randstr uses is of course not backed by CSPRNG so its not ideal for salts. Although I would be shocked if attackers would be able to exploit that in any way. Kinda interesting is how they decided on specifically 3 characters for salt, which seems really low. Its not like the characters cost anything, why not 30 characters instead?
JoblessWonder 8y ago
I used "gloss over" because I wanted to give them the benefit of the doubt. I can see an argument that 99.9% of the users are going to just care about what user information was stolen. However, the fact that private messages were stolen is... I mean, it is just mind boggling to me. There has to be so much shit in there.

peterwwillis 8y ago

> other employee workspace files If "workspace files" meant "home directory", that's the big holy shit moment. People keep all kinds of stupid shit in home directories. SSH keys. Browser profiles. E-mail cache. Private keys for TLS certificates. Logs. Logs with secrets. Literally anything that's supposedly secret and used to run things. Put user home directories on an NFS mount and I can basically own your whole company.

zakk 8y ago
> People keep all kinds of stupid shit in home directories. SSH keys. Are you implying that it's stupid to keep SSH keys in one's home dir?
- peterwwillis 8y ago
  If unencrypted, yes. Ideally your home dir is encrypted [so that only the user can unlock and use it]. (The truly paranoid will keep their private keys on an encrypted thumbdrive and remove it from the machine after authenticating the key into their keychain) But most of the time when I see network home directories in a company, it's just flat files on an NFS or CIFS share, which is bonkers.
  - whyever 8y ago
    > The truly paranoid will keep their private keys on an encrypted thumbdrive and remove it from the machine after authenticating the key into their keychain Does not necessarily help when the machine is compromised. Using one key per machine and storing it in the corresponding home directory seems safer to me.
    - peterwwillis 8y ago
      If you compromise the machine, you can attack anything on that machine. If the keys are in the home dir on the network, you can attack the network. If the keys are in the home dir on unencrypted local disk, you can attack the disk. If the keys are in a user namespace, you can attack the user namespace (which includes processes and mounts). If the keys are in a thumbdrive and in a keyring, you can only attack two things: 1) the user namespace, 2) the thumbdrive's mounted contents while it is inserted _and unlocked_. This limits the scope of attacks. When the keys in the keyring expire ("-t life" option to ssh-agent), you can't even attack that.