> From: Bill Bogstad [mailto:bogs...@pobox.com] > > 1. If one uses the full hostname for site identification then the > generated key pair for wiki.foo.com would be different then > for forums.foo.com. This seems like it could be annoying depending > on how a site implements site-wide logins.
A good question. I had to think about it a bit to come up with this answer: Suppose a server has multiple DNS aliases. Such as www.example.com and example.com. Clientside, how do you know what name to fold into your key generation process? You might assert "Just use whatever DNS name the user entered," but that fails, because users *expect* to be able to login to the site, regardless of whether or not they typed in "www." into their browser. You might then assert, "Just use the SSL canonical name" or "Use the server's SSL public key" but that doesn't work either - Because this year, somebody might be operating their https server with a cert for "www.example.com,example.com" and next year, they might be operating with "*.example.com" or some other variation, which is still valid for SSL. And of course, the server's public key is prone to change from year to year. It means the client can *neither* trust the DNS name to remain consistent, nor the SSL canonical name. There's only one thing to do. The server must make a representation to the client, say, the CBCryptHostName. There might be some concern about allowing the server to make a representation of its own identity. What if Joe Schmoe operates a server, and sets his CBCryptHostName to "twitter.com"? If you attempt to login there, you'll be attempting to login to twitter.com. But all you're giving Joe Schmoe is your public key. He still cannot impersonate you at twitter.com. Althesame, let's not be brazen and stupid about it - Even if it *is* actually safe to let the server specify their own CBCryptHostName, I'd like to see the client validate this against the SSL canonical name. That way, whether you browse to https://twitter.com or https://www.twitter.com, the server will then unconditionally serve you the CBCryptHostName "www.twitter.com", which you then compare with the SSL canonical name. Regardless if the SSL cname is "www.twitter.com,twitter.com" or "*.twitter.com" or any other valid combination, you're good to go because you have a standardized uniform string you can use in your key generation process. > 2. If one uses a suffix instead (say foo.com), then if an attacker > convinces someone to login to trojan.foo.com after managing to pollute > their DNS lookup (or manage some other man in the middle type attack), > then they can capture the user's credentials for the whole site. That's not true - Even if an attacker *does* trick you into a login attempt, using "twitter.com" and your username, the only thing you expose to the attacker is your public key. They still cannot impersonate you anywhere. > 3. If users re-use password between sites that use your system and > those that send to/store credentials on the server, then > passwords stolen from those sites can be used to authenticate to your > site. Since one of the advantages of this system is that users can > remember just a few passwords, this is annoying. At a minimum, you > will need to educate users to use a new password for those sites that > use this new system. I'm doubtful though that typical users verify > this correctly and would expect plenty of trojan sites which will > claim to do so in order to capture user credentials. Not sure how to > police this. This is correct. CBCrypt is ultimately password based authentication, in which the passwords are never communicated. If your password is already compromised, it doesn't protect you any longer. But it *should* reduce the incidence of passwords being compromised. I can name a few preventable recent high profile cases (nevermind low profile incidences that we didn't hear about in the news). _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
