On Wed, 30 Apr 2014, Edward Ned Harvey (lopser) wrote:
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.
Any security improvement that starts with "if all the websites implement my
authentication mechanism" is doomed to failure. You just aren't going to get
everyone to change like that.
David Lang
_______________________________________________
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/
