3 ms·

A Tale of Security Gone Wrong

37 points by vinnyglennon 11y ago

konceptz 11y ago
>>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 11y ago
  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 11y ago
    "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.
- gavingmiller 11y ago
  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.
oconnor663 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
- mjevans 11y ago
daveloyall 11y ago
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
schlowmo 11y ago
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-does-knowing-the-zxcvbn-password-strength-help-an-attacker 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-critical-is-it-to-keep-your-password-length-secret https://security.stackexchange.com/questions/92233/how-criti...

37 points by vinnyglennon 11y ago

>>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 11y ago
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 11y ago
  "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.
gavingmiller 11y ago
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.

oconnor663 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.
mjevans 11y ago

daveloyall 11y ago

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

schlowmo 11y ago

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-does-knowing-the-zxcvbn-password-strength-help-an-attacker 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-critical-is-it-to-keep-your-password-length-secret https://security.stackexchange.com/questions/92233/how-criti...