> From: David Lang [mailto:da...@lang.hm] > > but what if they use different certs for the different servers?
Like I said. Match the pattern. So if you have a server with cert "foo.example.com,example.com" and another server with cert "bar.example.com,example.com" and another with "whiz.example.com,example.com" then the common denominator of them all is "example.com" and that would have to be the CBCryptHostName to authenticate to a shared backend database. No Problem. > http://www.passwordmaker.org/ Here's why that's not similar: If instead of sending your password to a site, you send a hash of your password, then the hash has essentially become your password. Anybody who compromises the server will be able to impersonate you, by sending your hash. PasswordMaker uses the URL that you logged into. So you'll have a problem if you first login to https://twitter.com and later https://www.twitter.com because the URL is different. They're also using bad crypto. Because they're not introducing a workfactor. Even if you send a hash of your password, your weakpoint is your password. An attacker who finds your hash can brute force guess all the possible passwords until they find one that produces your hash, and voila, they know your password. This is actually a very practical attack, which has been demonstrated over and over, and led to the invention of bcrypt, scrypt, and pbkdf2. > all that someone would need to > do is to compromise one of the CAs that they depend on (you don't think > that you > are going to be able to run THE CA for everyone to use to authenticate do > you?) If your biggest fear is "Don't trust root CA's," then we're on the same page - because the present state of the world is such that not only do you trust the root CA's, but based on that trust, you're willing to send your password over the encrypted channel. It is only the latter half of that statement that I'm interested in addressing. > If you plan is compatible with existing sites, then it's still better than the > current status quo, but my other concerns then apply. Worst case, there exists a server which has absolutely no support for CBCrypt. Then CBCrypt would behave similarly to PasswordMaker you linked above, but without the bad crypto. It is absolutely possible for the client to perform the workfactor and generate the public/private keypair, and use a hash of the public key as the password. In which case, we have accomplished everything PasswordMaker has set out to accomplish, with the same drawback - that it's dependent on the server's URL. One minimal step away from there: It should be trivial for the server to have a field, to send the CBCryptHostName to the client, and eliminate the URL problem. But to truly support the asymmetric authentication, a little bit of code will have to be added to the server. _______________________________________________ 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/
