Hacker News Reader

Comment by JoblessWonder | Hacker News Reader

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 [?]

View on HN

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

> 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?

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.

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

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.

> 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

While the more secure organisations disable USB in the OS / BIOS and glue the ports shut to prevent anyone using them, to prevent against data loss by employee.

Source: worked in two different organisations that literally glued the USB ports shut.

The truly paranoid will implement an SSH CA that will sign the key's cert for a limited length of time, using u2f or similar to authenticate the user at the time of signing.

Not OP but it is inevitable, if unfortunate, that SSH keys go in most peoples' home folders

If it's anywhere other than on your personal machine, yes. OP was referring to NFS home directories (or otherwise home directories on servers), which I think is likely the only feasible vector to access people's "workspace files" in bulk without hacking every employee's machine individually.

Your SSH key should only exist on your desktop/laptop, never on a server. Use ssh-agent (and agent forwarding, when needed), which was designed for this.

The best approach is to use yubikeys and pkcs11 along with your ssh-agent so the private key never exists on disk at all, but at the very least, using vanilla ssh-agent is an imperative.

And if corporate policy demands all personal files live on the network and corporate computer policy sets the home directory there? This is common in enterprise.

So like, /Users/ken on my mac is an NFS mount? That's horrifying.

Yes, such enterprises are stuck in the 1980s and deserve what they get.

(Also, "personal files" shouldn't mean SSH private keys in any stretch of the definition.)

Unfortunately, ssh-agent does not have a way to discriminate against which remote is requesting authorization. So if you have dozens of keys and the correct key isn't among the first to be presented, then the remote server is likely to kick you for too many authorization attempts.

You can use ssh_config to limit which agent keys are offered to which remotes. https://superuser.com/questions/272465/using-multiple-ssh-pu...

Yes, but configuring that for hundreds of remotes is infeasible.

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?

> 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/4778b17e939e11...

Edit: reddit's confirmed this here: https://www.reddit.com/r/announcements/comments/93qnm5/we_ha...

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.

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

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?

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.

Reply on news.ycombinator.com