Travis wrote: > Agreed. > > Let's assume that users tend to pick the password "password" when > given a choice. > > Now adversaries try the most common password, namely "password", first. > > Security conscious admins ban the word "password" as a password. > Yes, this does reduce the keyspace a tiny bit. > > Do adversaries generally stop trying the password "password"? > Not generally.
Of course, but this is to catch people who do not follow proper security protocols. It's not designed to catch someone who actually chooses the password "password" using some valid password-generating method. To make this analogy apply, you would have to argue that an automated password generator that selects 8 random letters or numbers should specifically test its output for the string 'password' and try again if it just happens to get it by pure chance. > For every security-conscious admin or user, there are 99 who are not. > > For every cutting-edge security expert, there are 99 bottom-feeders > who will only get this information years later. > > I still hear of people trying to tftp /etc/passwd. > > I think that people will still be trying to brute-force their way in > with these keys for ten years. > > I would ban the use of these keys to gain entry to anything, much like > security-conscious admins ban easily-guessed passwords. Of course, but not because security-conscious users might happen to choose these keys by pure chance. You would ban them because someone might use software that has the bug to generate their keys. > Only the key space here is much, much larger than typical 8-character > passwords, so this loss will be unnoticeable. And that is the reason why you would *NOT* add a 'password' detector to your random password generator, which is essentially what was suggested here. > I personally don't like the idea of generating keys that people will > try, or using a weak/known key with small probability, but in this > case I think it's so small that simply scanning for and banning such > keys is good enough. Right, but you do that in case someone uses a broken RNG to generate them. > I was hoping someone would release a tool to search for them in the > authorized_keys files on any OS (e.g. my OpenBSD box), but AFAIK, > nobody has. > > I certainly don't want a kluge to the RNG... Exactly. You can't fix what isn't broken. By the way, while I disagree with most of the arguments made, I am not saying that I disagree with their conclusion. Here's how I would make the argument: 1) Broken code is going to be out there. We are going to see broken keys used for access, authentication, and signing. 2) We don't want to accept a signature from a broken key. We don't want to allow someone to access our machine with a compromised key. 3) So we probably will really want a blacklist of these keys, and we'll probably need to check every foreign key against this blacklist before we trust it forever. 4) If we have a list of keys we refuse to trust, we should probably make sure we don't generate keys we don't trust. (Though the probability is so, so low that I would argue that's what needed to ensure this is nothing.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
