On Tue, 25 Mar 2014, Edward Ned Harvey (lopser) wrote:
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.
It's not just that, it's the case where a company has multiple resources for you
to access (forums, support, mail) that legitimately live on different servers
but share an identity.
Mozilla came out with a similar approach several years ago as a browser plugin,
including a website that you could use from machines that didn't have the plugin
installed (kiosks)
anyone know why that faded away?
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.
huh, how did public keys get involved here?
I thought you took the site, userid, and local password and generated a password
to pass to the site. Using public keys somehow would require that the site be
changed to use the public keys?
and if you aren't modifying all the websites in the world, then the sites still
require reusable passwords, and if someone can capture that password, they can
impersonate you.
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).
I don't see how it prevents your passwords from being compromised. I do see how
it prevents the compromise of a password on one site from being a compromise of
passwords on other sites.
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/
