A Tale of Security Gone Wrong | Hacker News Reader

A Tale of Security Gone Wrong

gavinmiller.io

37 pointsvinnyglennon13 comments

Out of curiosity, what would be the problem with say rounding the entropy to one significant digit, and storing that? The main downside I can think of is that it would help attackers avoid wasting time on passwords that are difficult to crack, and focus on the easy ones instead. But then again, if the whole point of the feature is to avoid allowing easy passwords in the first place, could it be worth it?

The easy passwords (for today) were already filtered out. The idea was to future-proof it by recording how hard they were. Rounding to, say, whole numbers still leaks information, but a bit less. So now everything from [13.5,14.5) map to 14, that's still smaller than [0,+inf]. You could use some sort of hidden value mapping them to grades that aren't obviously mappings of entropy (like A, B, C, D). It indicates that there's something about them, but without seeing a table mapping [10,12] -> C you don't know exactly what. That's still a point for data to leak, though, should the mapping be discovered (encoded elsewhere in your database or somewhere in your code).

Your solution of mapping to a grading system A,B,C,D; or terrible, crap, better, best was mentioned in another thread about this article. It's a common thought, however it's incorrect because you're still leaking substantial information about passwords. By storing entropy of any kind: whole number, graded, > threshold, etc you are weakening your password hash. This is completely unnecessary where better solutions exist: TFA

You've repeated what I wrote and I'm not sure why. I was responding to the original comment asking if rounding or similar could work and said that it still leaked data. Which is what you've written here in response to me.

It still tells you way too much about candidate passwords. Even if you're only targeting the fuzzed entropy. It also eliminates your need for rainbow tables since it calculates that hashed value without any salt added (or maybe it does, but you can still target users with 'weaker' passwords to begin with).

Bcrypt has built-in salts to prevent rainbow (i.e. lookup) table attacks. More to the point, modern password cracking doesn't usually involve the use of rainbow tables anyway. GPU speed has improved at such a rate that it's actually more practical to just compute all possible hashes from plaintexts (in a word list) to find a match rather than performing a lookup against a rainbow table that might have to be terabytes in size to be useful.

Essentially, if you ever find yourself having to think about manually creating and incorporating salts into your password hashing mechanism, it's a telltale sign that you are using an unsuitable password hashing algorithm to begin with. Instead, you should almost always be using bcrypt, scrypt or PBKDF2 as per current best practice.

At the very least, storing any indication of entropy will tell you which passwords are more likely to be the worst.

There was a question on Information Security (Stackexchange) about a year ago which was exactly adressing this issue:

https://security.stackexchange.com/questions/92512/how-much-...

This was a follow up of a more general and well received question (How critical is it to keep your password length secret?), where some of the answers imho are a really worth reading:

https://security.stackexchange.com/questions/92233/how-criti...

Since links to Github search results are hip on HN recently: https://github.com/search?q=zxcvbn-ruby&type=Code

>>If you don’t think about security on a regular basis, this probably looks normal.

Can someone help me understand if this is an assumption or a status quo?

Then, what does storing this information gain you from an app owner perspective?

It looks like an assumption, and a poor one at that. I'm certainly no security expert, and the danger here is almost absurdly obvious.

That said - the article addresses the claimed advantage of storing the value:

"The rationale was that as technology progressed and password cracking became easier, users could be contacted to update their password."

"The rationale was that as technology progressed and password cracking became easier, users could be contacted to update their password."

I would argue that this a misguided motivation for storing the password entropy. Bcrypt is purposefully designed to combat the problem of more efficient brute-forcing due to future GPU/CPU speed improvements by incorporating a 'work factor'. At any time, application owners can specifically increase the work factor and the hashing process will be intentionally slowed further. In this way, the future reversibility of the password hashes can be reduced without requiring that users update their passwords.

It's an assumption on my part, and anecdotally a correct one. Having included this entropy example in a number of talks and asking the audience what's wrong, the majority of the technical audience did not know, nor did they have an appropriate guess.

Reply on news.ycombinator.com