3 ms·

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 i

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
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).
- amjo324 11y ago
  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.
uremog 11y ago
At the very least, storing any indication of entropy will tell you which passwords are more likely to be the worst.

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

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

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

uremog 11y ago

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