On Wed, 30 Apr 2014, Edward Ned Harvey (lopser) wrote:
From: David Lang [mailto:da...@lang.hm]
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.
Get an SSL cert that is valid for "foo.company.com,bar.company.com,biz.company.com" or
just "*.company.com"
Set the CBCryptHostName the same on all these servers, as long as it matches
the SSL pattern match, and it's the same on all the servers (which don't need
to have the same DNS names) then you're good to go.
but what if they use different certs for the different servers?
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)
Haven't heard of that...
I don't know if this is the one I was thinking of, or just one that works the
same way..
http://www.passwordmaker.org/
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.
Nope - it seems you missed the point. From the combined public and private
info (servername, port, username, password) is deterministically derived, a
keypair. Anyone who knows the user's password is able to regenerate the
keypair, so the user is able to go from computer to computer without carrying
anything. User is able to be authenticated, without sending his/her password
to the server.
but the server doesn't know that the user is doing all of this, the server
thinks you are using a standard reusable password. It's just something that is
done on your end.
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.
Point taken. If you reuse your password somewhere that doesn't adequately
protect your password, then nothing can be done to protect you.
But all these sites that were compromised by heartbleed - would not have
exposed my password, if I had never sent them my password. That's kind of the
point. Even when the server gets compromised, the user's secret is still
secret.
This is where I disagree. With heartbleed, any single site could be compromised
just as easily, the only difference is that the password they got would not get
them into any other site.
I don't see how it prevents your passwords from being compromised.
Pretend you're a server. I tell you my username is eharvey, and I tell you my
public key. You're able to authenticate my identity, because I'm able say
something that could only be said, with knowledge of my private key. Now
suppose you get compromised. Suppose I even login to you while you're
compromised. The most I'll ever send you is the public key.
But to do this, every server has to switch to public key authentication, and all
work in the same way.
This just isn't going to happen. And if it did, 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 this is your plan, then I can ignore it.
If you plan is compatible with existing sites, then it's still better than the
current status quo, but my other concerns then apply.
David Lang
The only weakness is, as you've mentioned, that if I reuse my password at
unprotected sites, then successful attacks against those sites could expose my
password and the attackers could impersonate me at your site. At some point,
it's impossible to protect lazy users. This will *also* not offer you
adequate protection, if your password is "password" or "55555"
_______________________________________________
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/
