4 ms·

Lots of security standards require passwords to have at least one digit. Lots of security standards require passwords to be changed every so often. The end res

by robtoo 15y ago

Lots of security standards require passwords to have at least one digit. Lots of security standards require passwords to be changed every so often. The end result? A user starts with the password "Seekrit1" when they join the company, then the next month they change to "Seekrit2", "Seekrit3", and so on. This is hardly what the security policy intended, so stopping that happening isn't actually a bad idea. Obviously storing a complete password history in plaintext (which would even have to be online for the consultants' plan to work) is ridiculous, but pre-calculating a bunch of hashes of similar passwords every time a new password is set would certainly be feasible. Changing passwords is usually a rare occurrence, but making this at least slightly computationally-expensive shouldn't be a problem. Of course, the more expensive the password-hashing algorithm, the fewer "similar" passwords you would reasonably be able to pre-calculate, which is an odd trade-off to have to make a call on. One thing to be wary of, though: by pre-calculating and storing a bunch of hashes of similar strings, this opens you up to (what might be called) a related plaintext attack. I have no idea if existing password hashes are specifically designed to be resistant to this, but would guess not. (edit: I didn't think this sentence through correctly. Thanks, Joachim)

brazzy 15y ago
> Lots of security standards require passwords to be changed every so often. Which is almost as idiotic as storing a complete password history in plaintext, because it pretty much guarantees that passwords either (as you note) follow a simple pattern, or if that is made impossible, are written down in an easily accessible place.
- fab13n 15y ago
  A very convenient place to store and retrieve them is under a "passwords" folder in your private mail account or your Dropbox, both of which get synchronized with your unprotected smartphone...
- wisty 15y ago
  Draconian password schemes lead to really insecure user behavior. For example, an iTunes account requires upper-case, lower-case, and a number; but it doesn't tell you that until you try "insecure" passwords. So I bet a lot of users, feeling really frustrated, just use their name (capitalized), and birthday, rather than the semi-secure password the they wanted to use (or in my case, a fairly strong pass-phrase with no numbers).
JoachimSchipper 15y ago
"Related plaintext" should not be an issue for any competent password hash (classical crypt and bcrypt are based on a block cipher, which means this should work; PBKDF2 is based on a cryptographic hash, which means this should work; etc.)
- klodolph 15y ago
  I'm not exactly sure what you're saying, but it sounds like you're saying bcrypt is reversible? It's not... it's "based on" a block encryption algorithm in the sense that it uses the encryption algorithm's key scheduling functions. Irreversibility is the intent.
  - pyre 15y ago
    It's not reversible, but block encryption should be easy to compare for similarity. If the old password is 5 blocks, and 4 of 5 blocks match the new password (in order)... I'm guessing this is what the gp was talking about. (of course block size matters, if all passwords are a single block that doesn't help)
    - mayank 15y ago
      That's why we use a fresh salt for each password. Bcrypt incorporates a fresh salt into each new hash. Your and the GP's concern in this area is not warranted.
  - JoachimSchipper 15y ago
    bcrypt isn't reversible (with respect to the password). The point is that Blowfish(key1, "message") is not at all similar to Blowfish(key2, "message"). This is called resistance to related-key attacks (look this up for a formal definition), and is an explicit design goal of every real-world block cipher. bcrypt is just Blowfish(key-derived-from-salt-and-password, "OrpheanBeholderScryDoubt"), so it inherits this property.
smackfu 15y ago
I've seen a 30 day password requirement with numeric digits circumvented simply by month + year. jun2001, jul2001, etc.
jameshart 15y ago
One option might be to store a hash of the password with all digits removed alongside the password used. Then once someone uses Seekrit1 as their password, you have the hash of Seekrit too, so if they try to use Seekrit2 later you can tell them not to. Could apply other normalization rules - remove repeated letters; force all lowercase; remove punctuation and digits. That way once someone's used Seekrit1, because you've hashed 'sekrit', they can no longer use seEeEe_kriT23...
- jat850 15y ago
  This is an interesting idea, but my very naive question would be: Even if the datastore contained only password hashes (which is good), wouldn't it be (potentially multiple) orders of magnitude easier to brute-force password attempts in the event of a large number of potential permutations to be eliminated right off the bat? Even though bruteforcing the stripped passwords wouldn't provide a full set of information, it might be a good starting point and quickly reduce the search or guessing space. Disclaimer: I have no idea if this is a practical concern, just one that comes to mind when thinking about your suggestion.
  - jameshart 15y ago
    To some extent, you're right. Bruteforcing the password becomes a case of first bruteforcing the kernel by searching the much smaller password space of lowercase letters, then once that's matched using that kernel to generate candidates by altering case, adding digits, etc. Obviously a smart search will immediately try uppercasing the first letter, and adding a 1 to the end, and in a lot of cases that's going to be right. So yes, it does reduce the strength of your encryption against bruteforce password search, by several orders of magnitude. This is where advances in hashing approaches might negate that problem for you, though - and you'd need a proper cryptographer to figure this out. If it was a plain MD5 or SHA of the normalized password, you're absolutely vulnerable to an attacker using a rainbow table of lowercase alphabet words figuring out the 'root' of the actual password; then they could use that to construct password candidates to hash and compare to the full password. But just adding a big block of salt to the normalized password though would take it out of the pure-lowercase searchspace and force you back to bruteforce searching of the (admittedly small) password space. However, multiround salted hashing strategies like bcrypt rule out rainbow tables and allow you to tune how expensive bruteforcing is, and even though the password space of the password kernel is limited, you may be able to turn bcrypt up high enough to make it unfeasible to bruteforce.... maybe?
ToastOpt 15y ago
My personal favorite is the "at least one capital". I've taken mnemonics with a large subset of the asciibet, but I can't memorize case well. So what happens? Every password begins with one capital. "Ehsiwvky" instead of "ehsiwvky", right? I enjoy the juxtaposition of following the letter of the rule, violating the intent of the rule, but nonetheless honoring the spirit of the rule.
planckscnst 15y ago
Instead of storing those pre-calculated hashes of similar strings, generate hashes on many variations of the new password and see if any match the old hash.

by robtoo 15y ago

brazzy 15y ago

> Lots of security standards require passwords to be changed every so often. Which is almost as idiotic as storing a complete password history in plaintext, because it pretty much guarantees that passwords either (as you note) follow a simple pattern, or if that is made impossible, are written down in an easily accessible place.

fab13n 15y ago
A very convenient place to store and retrieve them is under a "passwords" folder in your private mail account or your Dropbox, both of which get synchronized with your unprotected smartphone...
wisty 15y ago
Draconian password schemes lead to really insecure user behavior. For example, an iTunes account requires upper-case, lower-case, and a number; but it doesn't tell you that until you try "insecure" passwords. So I bet a lot of users, feeling really frustrated, just use their name (capitalized), and birthday, rather than the semi-secure password the they wanted to use (or in my case, a fairly strong pass-phrase with no numbers).

JoachimSchipper 15y ago

"Related plaintext" should not be an issue for any competent password hash (classical crypt and bcrypt are based on a block cipher, which means this should work; PBKDF2 is based on a cryptographic hash, which means this should work; etc.)

klodolph 15y ago
I'm not exactly sure what you're saying, but it sounds like you're saying bcrypt is reversible? It's not... it's "based on" a block encryption algorithm in the sense that it uses the encryption algorithm's key scheduling functions. Irreversibility is the intent.
- pyre 15y ago
  It's not reversible, but block encryption should be easy to compare for similarity. If the old password is 5 blocks, and 4 of 5 blocks match the new password (in order)... I'm guessing this is what the gp was talking about. (of course block size matters, if all passwords are a single block that doesn't help)
  - mayank 15y ago
    That's why we use a fresh salt for each password. Bcrypt incorporates a fresh salt into each new hash. Your and the GP's concern in this area is not warranted.
- JoachimSchipper 15y ago
  bcrypt isn't reversible (with respect to the password). The point is that Blowfish(key1, "message") is not at all similar to Blowfish(key2, "message"). This is called resistance to related-key attacks (look this up for a formal definition), and is an explicit design goal of every real-world block cipher. bcrypt is just Blowfish(key-derived-from-salt-and-password, "OrpheanBeholderScryDoubt"), so it inherits this property.

smackfu 15y ago

I've seen a 30 day password requirement with numeric digits circumvented simply by month + year. jun2001, jul2001, etc.

jameshart 15y ago

One option might be to store a hash of the password with all digits removed alongside the password used. Then once someone uses Seekrit1 as their password, you have the hash of Seekrit too, so if they try to use Seekrit2 later you can tell them not to. Could apply other normalization rules - remove repeated letters; force all lowercase; remove punctuation and digits. That way once someone's used Seekrit1, because you've hashed 'sekrit', they can no longer use seEeEe_kriT23...

jat850 15y ago
This is an interesting idea, but my very naive question would be: Even if the datastore contained only password hashes (which is good), wouldn't it be (potentially multiple) orders of magnitude easier to brute-force password attempts in the event of a large number of potential permutations to be eliminated right off the bat? Even though bruteforcing the stripped passwords wouldn't provide a full set of information, it might be a good starting point and quickly reduce the search or guessing space. Disclaimer: I have no idea if this is a practical concern, just one that comes to mind when thinking about your suggestion.
- jameshart 15y ago
  To some extent, you're right. Bruteforcing the password becomes a case of first bruteforcing the kernel by searching the much smaller password space of lowercase letters, then once that's matched using that kernel to generate candidates by altering case, adding digits, etc. Obviously a smart search will immediately try uppercasing the first letter, and adding a 1 to the end, and in a lot of cases that's going to be right. So yes, it does reduce the strength of your encryption against bruteforce password search, by several orders of magnitude. This is where advances in hashing approaches might negate that problem for you, though - and you'd need a proper cryptographer to figure this out. If it was a plain MD5 or SHA of the normalized password, you're absolutely vulnerable to an attacker using a rainbow table of lowercase alphabet words figuring out the 'root' of the actual password; then they could use that to construct password candidates to hash and compare to the full password. But just adding a big block of salt to the normalized password though would take it out of the pure-lowercase searchspace and force you back to bruteforce searching of the (admittedly small) password space. However, multiround salted hashing strategies like bcrypt rule out rainbow tables and allow you to tune how expensive bruteforcing is, and even though the password space of the password kernel is limited, you may be able to turn bcrypt up high enough to make it unfeasible to bruteforce.... maybe?

ToastOpt 15y ago

My personal favorite is the "at least one capital". I've taken mnemonics with a large subset of the asciibet, but I can't memorize case well. So what happens? Every password begins with one capital. "Ehsiwvky" instead of "ehsiwvky", right? I enjoy the juxtaposition of following the letter of the rule, violating the intent of the rule, but nonetheless honoring the spirit of the rule.

planckscnst 15y ago

Instead of storing those pre-calculated hashes of similar strings, generate hashes on many variations of the new password and see if any match the old hash.