Hacker News Reader

Comment by mattlong | Hacker News Reader

> In some cases, we may require you to change your password. (For example, if it’s commonly used or hasn’t been changed in a long time)

This is ambiguous...by "commonly used" do they mean 1) I'm logging in with my password frequently or 2) my password itself is a commonly used password? I'm assuming (and praying!) they mean the former since the latter would mean they're storing my password in plaintext.

UPDATE: Dropbox doesn't store in plaintext. I was incorrect to assume these were the only two possibilities. Confer child comments.

View on HN

It's quite obvious from context that it's the latter. However, there is zero implication that they are storing passwords in plaintext. There are several ways to implement such a feature.

First, the password could be checked on login when it is sent in plaintext but not stored. Second, they could run an offline dictionary attack against the hashed password database.

Given they state that some accounts were compromised by stolen passwords from "other websites," it would make sense to run some sort of dictionary attack using lists from those sites.

It wouldn't, necessarily -- I thought about this a little, and there are ways to identify commonly used passwords without storing them in plain text.

They could check passwords on login (before salting/hashing) against a blacklist of 'commonly used passwords'. This is probably the most secure method, as it only implies that users passwords are not on the blacklist, but does not imply plain text storage or unsalted hashes.

If they were not salting their hashes, then they could query their database for hashes that match the hashed version of commonly used passwords. Similar to the blacklist above, but implies that the passwords are stored unsalted, which is sad.

Dropboxer here. We do not store passwords in plaintext, or unsalted. End sentence. :)

How do you store them?

I believe the implication is that they are stored hashed and salted.

There are many different ways to salt and hash, some more secure than others (bcrypt and DES crypt() being two examples with vastly different levels of security).

With regards to security, I'd rather not read into subtext. Hopefully they can provide a definitive answer.

They wouldn't have to store your password in plaintext to determine that. They could just hash commonly used passwords and compare the hashes to yours.

If the number of salts used in the system is equal to the number of users, this could be expensive.

They will just check your password against a list of 'bad' passwords when you log in. No need to brute force the stored hash.

Obviously that would work, but not if you're using Challenge-response authentication. In general, I don't think people bother with now that when using https.

A little bit of googling makes it seem like auth tokens are not sent it plaintext over HTTPS but are authenticated using challenge response – http://forums.dropbox.com/topic.php?id=47952 The WWW site may differ.

Assuming they use straight up salted sha256, my five year old core2 laptop does at least 10,000 per second, per core. They could check every user for the top 10k passwords for a few hundred bucks of EC2 time.

Why do you assume that?

Reply on news.ycombinator.com