We are in 2011 after all, so seeing an error message that a password is too long is… well embarasing.
So, given that passwords shouldn’t or should I say must not be saved in a way that enables anyone (even administrators) to retrieve the plaintext version of a password, we’re talking about some sort of hashing. Whether hashing algorithm it is MD5 (avoid) os SHA1 (and in order to avoid precomputed hashes of passwords (known also as rainbow tables) you should use salting techniques with hashing algorithms), the length of a calculated hash does not depend on the length of the plain text password.
So, why is the length of the password limited to 16 characters? Beats me.
Of course, I recommend developers to use bcrypt instead of SHA or MD5. Bcrypt is very slow (compared to SHA or MD5), which is a good property to have for checking passwords — you don’t want to have a super-fast hashing/crypting algorithm thus effectively preventing brute force attacks.
Hmm, the reasoning for use bcrypt (it’s first time I hear of it) doesn’t seem good to me.
1) what if you want to allow RPC style calls to your system, then outside system have to authenticate and you are intentionally slowing it down, it is better to build in some kind of logic that every failed attempt slows down next attempt
2) bcrypt is maybe slow by today standards, but Moore’s low still apply
3) maybe will someone derive order of magnitude faster implementation of bcrypt tomorrow
Other than that limiting password length is odd at least.
Petar,
authenticating RPC-style calls is a different matter. You can do it in the same way as web apps work though — by establishing a session beforehand and just passing session token to the methods. Or, you can cache credential checks on the backend for that matter. The point is that you need the right tool for the right job.
As for bcrypt’s slowness with regards to todays standards — let’s say it is much slower than MD5. It’s slowness also dependes on the “number of rounds” that you configure (you can have different number of rounds per password, if you wish – more rounds, more secure (and slower). The slowness of bcrypt is not due to poor implementation but rather due to the mathematics involved in it. Different approaches, using CUDA for calculations etc. might make computation faster — but most probably faster for other calculations (and algorithms) as well.
There was a very good article by Thomas Ptacek, and this Stackoverflow page is also informative. You might consider scrypt if you really want to protect against parallel attacks on password hashes.
The point being, don’t use MD5, and don’t, for the love of [insert your Diety], limit password length.
Peter, and be sure to read the comments in Thomas’ article. They are also very informative (albeit numerous).