
A Tale of Security Gone Wrong - vinnyglennon
http://gavinmiller.io/2016/a-tale-of-security-gone-wrong/
======
oconnor663
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?

~~~
Jtsummers
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).

~~~
gavingmiller
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

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

------
schlowmo
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-...](https://security.stackexchange.com/questions/92512/how-much-does-
knowing-the-zxcvbn-password-strength-help-an-attacker)

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...](https://security.stackexchange.com/questions/92233/how-critical-is-
it-to-keep-your-password-length-secret)

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

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

~~~
wyattpeak
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."

~~~
amjo324
_" 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.

