"It is very important to force users to add non alphanumerical characters and a few capital letters in the password IF security is very important for your application. "
Not it's not. What's important is that users pick a password randomly from a large pool. For example, there's nothing wrong with a long password all in lowercase if the characters are picked randomly (see, for example, how Google 2-factor authentication handles application specific passwords).
"But guess what? This morning I discovered that actually the algorithm PBKDF1 described into RFC2898 does exactly what I proposed."
Actually PBKDF1 has been deprecated since 2000 and replaced by PBKDF2 which doesn't use SHA1 (it uses HMAC-SHA1 instead). And PBKDF1 is a key derivation function, it's not designed to be slow (as is, for example, bcrypt).
PBKDF1 is a key derivation function, it's not designed to be slow (as is, for example, bcrypt)
No that's actually one of the purposes of a KDF:
http://tools.ietf.org/html/rfc2898#page-84.2 Iteration Count
An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.
What's wrong with long password with all lowercase characters which are not picked randomly? Apart from someone looking at you typing, why would "fuwaiunviohugihyeurpqwjiosnxjcewiorhewuioahfdsfeaw" be worse than "i like unicorns in the morning and hedgehogs in the evening"?
There's nothing really wrong with that as long as it's not predictable in some way. For example, if you knew that all my passwords were song lyrics in lowercase then you could attack my passwords using list of all the world's song lyrics (which would be much smaller than all random lowercase strings of length X).
If you come up with something you can remember that's long and unlikely someone else can guess the search space for then you'll be ok.
In a sense. But it's a principle of cryptography that you assume the attacker knows all your schemes / algorithms, and only the random bits are secret.
If those become common enough, then you have reduced your symbols from 50 (your first example) to 11 (your second) where five ("in the and in the") are typical joining words. We can imagine password crackers can just combine the words in the dictionary just like they currently combine letters and give a higher priority to looking for combinations of conjunctions. The random letters make these approaches a lot more difficult.
It depends what you mean by "random" in this case. Things that would not be random include all-lowercase passwords drawn from personal things such as your name, kid's names, etc - things that can be guessed/found through research.
The long passphrase sentence you posted that happens to be all lower-case letters is seemingly random though.
Sure, but I suspect the 16 chars requirement is too much. It is simpler for users to remember $t33.llar10 then a 16 chars password IMHO in most cases. If you make it hard to accept for users they'll end with the same small world repeated N times.
Here we are entering in the field of the "user component" as well. It is pretty hard...
You're making the fallacy of assuming whats easy for you is easy for everyone else. As the xkcd comic pointed out, which is easier to remember? "x1.Tlm98" or "trix are for kids!"
If you try to remember your password, you've done something horribly wrong. 99% of my passwords come straight out of pwgen, and I immediately have my browser remember them so I don't have to.
Those of us with the right kind of memory system (patterned numbers and letters go straight to long-term until no longer needed, can't remember the fancy Latin word for it) have no problem memorizing any kind of password, as long as it is not both extra-long and extra-meaningless. Of course, I'm also the kind of person that doesn't trust password managers.
Having the ability to memorize passwords helps, since you obviously have to memorize at least a couple of passwords (such as those for your personal system). I'd just argue that when you have dozens of sites you use (which you hopefully use different passwords on), you shouldn't try to memorize passwords for them all, just generate passwords and have your browser remember them.
Comments
"It is very important to force users to add non alphanumerical characters and a few capital letters in the password IF security is very important for your application. "
Not it's not. What's important is that users pick a password randomly from a large pool. For example, there's nothing wrong with a long password all in lowercase if the characters are picked randomly (see, for example, how Google 2-factor authentication handles application specific passwords).
"But guess what? This morning I discovered that actually the algorithm PBKDF1 described into RFC2898 does exactly what I proposed."
Actually PBKDF1 has been deprecated since 2000 and replaced by PBKDF2 which doesn't use SHA1 (it uses HMAC-SHA1 instead). And PBKDF1 is a key derivation function, it's not designed to be slow (as is, for example, bcrypt).
Nevertheless, you could iterate SHA1 if you wish.
PBKDF1 is a key derivation function, it's not designed to be slow (as is, for example, bcrypt)
No that's actually one of the purposes of a KDF:
http://tools.ietf.org/html/rfc2898#page-8 4.2 Iteration Count An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.
What's wrong with long password with all lowercase characters which are not picked randomly? Apart from someone looking at you typing, why would "fuwaiunviohugihyeurpqwjiosnxjcewiorhewuioahfdsfeaw" be worse than "i like unicorns in the morning and hedgehogs in the evening"?
There's nothing really wrong with that as long as it's not predictable in some way. For example, if you knew that all my passwords were song lyrics in lowercase then you could attack my passwords using list of all the world's song lyrics (which would be much smaller than all random lowercase strings of length X).
If you come up with something you can remember that's long and unlikely someone else can guess the search space for then you'll be ok.
If I knew your passwords were all song lyrics, that's already a failure of security.
In a sense. But it's a principle of cryptography that you assume the attacker knows all your schemes / algorithms, and only the random bits are secret.
Your scheme can be a few more random bits, selecting from a finite number of "schemes".
Yes.
If those become common enough, then you have reduced your symbols from 50 (your first example) to 11 (your second) where five ("in the and in the") are typical joining words. We can imagine password crackers can just combine the words in the dictionary just like they currently combine letters and give a higher priority to looking for combinations of conjunctions. The random letters make these approaches a lot more difficult.
It depends what you mean by "random" in this case. Things that would not be random include all-lowercase passwords drawn from personal things such as your name, kid's names, etc - things that can be guessed/found through research.
The long passphrase sentence you posted that happens to be all lower-case letters is seemingly random though.
Sure, but I suspect the 16 chars requirement is too much. It is simpler for users to remember $t33.llar10 then a 16 chars password IMHO in most cases. If you make it hard to accept for users they'll end with the same small world repeated N times.
Here we are entering in the field of the "user component" as well. It is pretty hard...
You're making the fallacy of assuming whats easy for you is easy for everyone else. As the xkcd comic pointed out, which is easier to remember? "x1.Tlm98" or "trix are for kids!"
If you try to remember your password, you've done something horribly wrong. 99% of my passwords come straight out of pwgen, and I immediately have my browser remember them so I don't have to.
Those of us with the right kind of memory system (patterned numbers and letters go straight to long-term until no longer needed, can't remember the fancy Latin word for it) have no problem memorizing any kind of password, as long as it is not both extra-long and extra-meaningless. Of course, I'm also the kind of person that doesn't trust password managers.
Having the ability to memorize passwords helps, since you obviously have to memorize at least a couple of passwords (such as those for your personal system). I'd just argue that when you have dozens of sites you use (which you hopefully use different passwords on), you shouldn't try to memorize passwords for them all, just generate passwords and have your browser remember them.