I never saw this go through so I'll try again with some editing including the correction of one glaring error.
--- There are a couple of issues to consider involving long passwords, or really any password. 1) There is a very real issue with such ridiculously long passwords. As I understand it, bcrypt only uses the first 72 characters. I assume that every password longer than 72 characters but with the first 72 characters being identical and with the same number of rounds and the same salt will have the same hash, but I haven't actually tested it. So there does not seem to be any advantage in using passwords longer than 72 characters. This is why I quit using really long passwords about 15 or 20 years ago. I am not sure that there is any disadvantage to using very long passwords, either. 2) Consider the possibility of hash collisions. Let P be the set of all possible 72 character passwords. Let's assume that bit 7 of each character is 0. Thus, in a 72 character password, there are 72*7=504 bits that are actually significant. The the number of all possible passwords in P is |P|=2^504. Let H be the set of all hashes created by bcrypt. If I understand correctly, |H|=2^184. Thus, f:P->H will produce, on average, 2^504/2^184 collisions for each h in H. That is, there will be, on average, 2^320 different passwords in P which map to the same hash value in H. So a password of "1111" will have approximately 2^320 other passwords that will produce the same hash. When someone runs all 2^56 possible 8 character passwords against a hashed value from a /etc/master.passwd file, they are not just testing 2^56 addresses -- they are testing 2^56*2^320=2^376 addresses. Wouldn't it be irritating to set up some password and finding out too late that it has a collision with a password such as "123456"? I do set a minimum password length using minpasswordlen in /etc/login.conf of 20 to 24 characters, depending on the server. It would be very useful if the login procedures also used minpasswordlen to limit the shortest password entered by someone attempting to log in with a password in order to eliminate the chance of there being a very short password with the same hash as the intended password. In other words, if there is a collision it would not be seen unless the password in collision was at least as long as the minimum password length set on the machine. This is why I limit ssh logins to use only public keys from everything but the most local machines. I will experiment with the 13 asterisks to see if I can still log in with S/Key from the console if needed. Eric
signature.asc
Description: OpenPGP digital signature
