Re: [perpass] Stopping password sniffing

["Learmonth, Iain Ross" <[e-mail]>]

> What would be ideal would be for the site to provide a site ID that can be validated using existing PKI.

combined with

>  one master key per site

does sound good. This is going to require modifications (an extension) to TLS though, which is possible but does mean developing new technology, not just new ways of leveraging existing ones. I'm not against this, just pointing it out.

> single-purpose key server

How would this key server work? Looking at X.509 key servers, they only ever seem to store the public key, which the website would already have anyway. I know with gpg-agent you can forward that to remote servers, but I've never seen anyone pulling it from somewhere.

A privacy bonus: if you have a key for each site you have an account on, you know where you have accounts and don't have old inaccessible accounts leaking information (unless you lose the keys).

Iain.

--
Iain R. Learmonth MBCS
Electronics Research Group
School of Engineering
University of Aberdeen
Kings College
Aberdeen
AB24 3UE

Tel: [phone]

The University of Aberdeen is a charity registered in Scotland No.SCO13683

________________________________________
From: Ted Lemon <[e-mail]>
Sent: 13 November 2013 16:12
To: Learmonth, Iain Ross
Subject: Re: [perpass] Stopping password sniffing

On Nov 13, 2013, at 9:56 AM, Learmonth, Iain Ross <[e-mail]> wrote:
> I was about to say signing client keys with a master key was a good idea. It would remove the need for a cloud sync as once set up, the browsers would inherit the access from the master key without the need for synchronization.
>
> Then, yes, re-use would allow for tracking across websites. So maybe not such a great idea.

Yeah, that's a flaw.

> Maybe the compromise is not a cert per service, but a cert per identity (in the loosest possible sense of the word). Maybe your social media accounts where you are you are under one, and your reddit and slashdot accounts under another, etc.

There's no particular reason not to have one key per site, other than that it's hard to define what "site" means.   This could generalize to one master key per site, so you preserve privacy but still get the nice properties of a master key versus a cloud keychain.   Of course now you need to generate keys more frequently, so that places some new pressure on the key server.

> With a smartcard, this is as easy as plugging the smartcard into the device you're using, but - another thought - would probably mean requiring multiple smartcards as I am logged into my email on about 4 different devices at a time.

I don't think the smartcard works, because your devices may not have a convenient way to connect to it other than over the network.   And in that case, why not just have a single-purpose key server?

> I'm not sure with TLS client authentication if it just tries all the personal keys it has or if the server advertises which keys would be accepted. I'm guessing it'll be the former so even if there is one key per service, the other certs would still become known to the server when authentication using them is attempted?

What would be ideal would be for the site to provide a site ID that can be validated using existing PKI.   Once the site ID has been validated, you look in your key cache for an identity that is associated with that site ID.   If you find one, you use the cert to log in.   If you don't fine one, you don't have an account on that site.