Mailing List Archive

On Jun 6, 2012, at 11:14 PM, Aaron C. de Bruyn wrote:

> On Wed, Jun 6, 2012 at 8:34 PM, Jimmy Hess <mysidia@gmail.com> wrote:
>> Which digital id architecture should web sites implement, and what's
>> going to make them all agree on one SSO system and move from the
>> current state to one of the possible solutions though? :)
>>
>> A TLS + Client-Side X.509 Certificate for every user.
>
> Heck no to X.509. We'd run into the same issue we have right now--a
> select group of companies charging users to prove their identity.
>

Not if enough of us get behind CACERT.

Non-profit organization providing fee certificates based on web of trust
model.

http://www.cacert.org

For any of you in the bay area and/or who encounter me in my various
travels, I am an CACERT top-level notary.

Personally, I like the SSH model and simply giving the web-site your
public key at sign-up, but, there are issues with that as well...

If your private key is compromised, how do you notify all of the web-sites
that it needs to be revoked?

Owen

On Jun 7, 2012, at 6:36 AM, Peter Kristolaitis wrote:

> On 6/7/2012 9:22 AM, James Snow wrote:
>> On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:
>>> Imaging signing up for a site by putting in your email and pasting
>>> your public key.
>> Yes! Yes! Yes!
>>
>> I've been making this exact argument for about a year. It even retains
>> the same "email a link" reset mechanism when someone needs to reset
>> their key.
>>
>> A common counter-argument is, "But ordinary Internet users won't
>> understand SSH keys." They don't need to! The idea is easily explained
>> via a lock-and-key metaphor that people already understand. The UI for
>> walking users through key creation is easily imagined.
>>
>>
>> -Snow
>
> Oh yeah, I can just imagine that "lock and key" conversation now...
>
> "Imagine if the website has a lock on it, and you tell them what key you want to use by giving them a copy."
> "But if they have a copy of my key, couldn't they use it to open all of the other locks I've set up to use it?"
> "(explain public key crypto)"
> "(drool, distraction by the latest Facebook feature)"
>

Wrong approach...

"Imagine if the website has a lock created by each user. The user creates the lock by giving the web site their "lock template". Once you give them the "lock template", only your key will open that lock."

(Lock template = public key, key = private key)

"No, the lock template won't open the other copies of the lock template. Only the key will open the lock template, but, the key will open all the lock templates. It's just like having all the locks on your house "keyed alike". I can't take the lock off the front door and use it to open the back door, neither can the lock template given to one website be used to unlock your account at another website."

> The other problem with this approach is that, as bad as trusting remote sites to do security properly is, I'm not sure that putting a "one key to rule them all" on users' machines is that much better, given the average user's penchant for installing malware on their machine because "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the time... I suspect we'd see a huge wave of malware whose sole purpose is to steal public keys (and you KNOW users won't password-protect their private keys!). Plus, now you have the problem of users not being able to login to their favourite websites when they're using a friend's computer, internet cafe, etc, unless they've remembered to bring a copy of their private key with them.

Yeah, there is that problem as well. Personally, I'd like to see someone produce what amounts to a mini-HSM such as a USB-dongle that will contain but never emit the private key, and perform one of the following functions, given the right one-time password (which could be produced either by display on the dongle, or, by a mobile app):

1. Emit public key.
2. Encrypt challenge response or other data using private key.
3. Create new keypair.

This would provide the benefits of 2-factor authentication along with the ease of the proposed SSH-key mechanism. The key wouldn't be accessible to malware and in order to exploit the key, the malware would have to convince the user to enter their one-time password and/or
would be required to beat the legitimate application to the request (in which case, the legitimate application's request would fail making the failure obvious to the user).

> I think public key auth for websites is a great idea for geeks who understand the benefits, limitations and security concerns, but I have serious doubts that it would hold up when subjected to the "idiot test".

I think that there is a lot of UI work to be done in this area, but, that it can actually be made safe and effective for lay-persons.

After all, if Blizzard can get a bunch of their players using 2-factor tokens for authentication, this can't really be that much harder.

Owen

On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong <owen@delong.com> wrote:
>> Heck no to X.509.  We'd run into the same issue we have right now--a
>> select group of companies charging users to prove their identity.
>
> Not if enough of us get behind CACERT.

Yet again, another org (free or not) that is holding my identity hostage.
Would you give cacert your SSH key and use them to log in to your
Linux servers? I'd bet most *nix admins would shout "hell no!"

So why would you make them the gateway for your online identity?

-A

On Jun 7, 2012, at 9:29 AM, Bruch, Mark wrote:

> I rarely reply to threads. However the point of interest that is missed is "Not supported anymore because Microsoft says so". So Microsoft starts putting out systems at one per year and not supporting old ones because they "Have you over a barrel"?
>
> Tell your daughter she can't get married? You haven't bought your new operating system this year, and "backward compatible" is a thing of the past?
>
> Then it is $119.00 per year on top of that (maybe)?
>
> Let's say Microsoft promised business to the PC building companies and decides that an operating system per year is only supported on new equipment? The cost to vote could be thousands per year. Only the rich can afford to vote?
>
> The point is that you have to be careful about where you go with technology and who controls it. I am sure there are people who would love to see voting as a "can you afford it" right.

Nah... They've obviated the need with superPACs and other mechanisms for purchasing the politicians we vote for much more cost effectively than purchasing the elections themselves.

Owen

>
> -----Original Message-----
> From: Aaron C. de Bruyn [mailto:aaron@heyaaron.com]
> Sent: Thursday, June 07, 2012 11:10 AM
> To: Jared Mauch
> Cc: Nanog
> Subject: Re: LinkedIn password database compromised
>
> On Thu, Jun 7, 2012 at 8:58 AM, Jared Mauch <jared@puck.nether.net> wrote:
>> I'm imagining my mother trying this, or trying to help her change it after the hard drive dies and the media in the safe deposit box doesn't read anymore.
>
> I would think it's fairly simple.
> What if she forgot her existing password? Most sites have a 'reset password' link they e-mail you.
> A browser extension 'helper' would simply generate a new key and let you reset your password. Maybe the helper could be dumbed down enough to automatically handle the password reset screen and automatically POST the new key to the reset page.
>
> I'm sure it could be done transparently enough that our mothers wouldn't need to think twice about it.
>
> Heck--the 'helper' could probably even back up your SSH key off-site sorta like LastPass does. And if your private key is actually password protected, it's slightly less useless if the off-site backup company were compromised.
>
> The only downfall is how do you get access to your e-mail account?
> (Google already calls my cell and/or home phone if I request access without using my password.)
>
> I agree there are stumbling blocks, and it wouldn't be perfect--but it seems like it would be much better than the alternative we have now.
> People using the same password on multiple sites, passwords written down, dumb website operators not salting their hashes, etc...
>
> Also, thanks for the great secondary DNS service. ;)
>
> -A
>

On Jun 7, 2012, at 10:03 AM, Randy Bush wrote:

> hi etaoin,
>
>> I still don't want single sign on. Not anywhere.
>
> i believe that 'single sign on' is a bad deal and dangerous for all, not
> just we geeks. essentially it means that the 'identiry provider' owns
> your identity. i love that they call themselves 'identity providers'
> when it is MY fracking identity and they are reselling it.
>
If single sign-on is done right, then YOU are the identity provider and YOU
own your identity. It does, however, potentially enable cross-site tracking.


Owen

I gotta agree with Aaron here. What would be my motivation to "trust" an
open and public infrastructure? With my business or personal keys?

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong<owen@delong.com> wrote:
>>> Heck no to X.509. We'd run into the same issue we have right now--a
>>> select group of companies charging users to prove their identity.
>> Not if enough of us get behind CACERT.
> Yet again, another org (free or not) that is holding my identity hostage.
> Would you give cacert your SSH key and use them to log in to your
> Linux servers? I'd bet most *nix admins would shout "hell no!"
>
> So why would you make them the gateway for your online identity?
>
> -A
>
>

On Jun 7, 2012, at 12:37 PM, Aaron C. de Bruyn wrote:

> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong <owen@delong.com> wrote:
>>> Heck no to X.509. We'd run into the same issue we have right now--a
>>> select group of companies charging users to prove their identity.
>>
>> Not if enough of us get behind CACERT.
>
> Yet again, another org (free or not) that is holding my identity hostage.
> Would you give cacert your SSH key and use them to log in to your
> Linux servers? I'd bet most *nix admins would shout "hell no!"
>
> So why would you make them the gateway for your online identity?
>
> -A

HuH?

They don't hold my identity hostage. They sign my identity. That's it.

I create the certificate and the private key. They never receive the private key.
They merely provide a mechanism by which trusted parties can verify and then
attest that I am, indeed, who I claim to be.

Would I consider using my X.509 certificate as an authentication method for
my linux servers? Not at this time for the simple reason that the combinations
of expiry and the UI complexities in doing so make it significantly less
convenient than my SSH keys.

However, if it were made to be equally convenient with SSH keys, then, I
don't see a problem with it.

Owen

A proper CA does not have your business or personal keys, they merely
sign them and attest to the fact that they actually represent you. You are
free to seek and obtain such validation from any and as many parties as
you see fit.

At no point should any CA be given your private key data. They merely
use their private key to encrypt a hash of your public key and other data
to indicate that your private key is bound to your other data.

You trust DMV/Passport Agency/etc. to validate your identity in the form
of your government issued ID credentials, right?

That doesn't give DMV/Passport Agency/etc. control over your face, but,
it does allow them to indicate to others that your face is tied to your
name, date of birth, etc.

Owen

On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:

> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys?
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong<owen@delong.com> wrote:
>>>> Heck no to X.509. We'd run into the same issue we have right now--a
>>>> select group of companies charging users to prove their identity.
>>> Not if enough of us get behind CACERT.
>> Yet again, another org (free or not) that is holding my identity hostage.
>> Would you give cacert your SSH key and use them to log in to your
>> Linux servers? I'd bet most *nix admins would shout "hell no!"
>>
>> So why would you make them the gateway for your online identity?
>>
>> -A
>>
>>

Thank you for educating without insulting. Always professional Owen.
It's appreciated.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 6/7/2012 3:18 PM, Owen DeLong wrote:
> A proper CA does not have your business or personal keys, they merely
> sign them and attest to the fact that they actually represent you. You are
> free to seek and obtain such validation from any and as many parties as
> you see fit.
>
> At no point should any CA be given your private key data. They merely
> use their private key to encrypt a hash of your public key and other data
> to indicate that your private key is bound to your other data.
>
> You trust DMV/Passport Agency/etc. to validate your identity in the form
> of your government issued ID credentials, right?
>
> That doesn't give DMV/Passport Agency/etc. control over your face, but,
> it does allow them to indicate to others that your face is tied to your
> name, date of birth, etc.
>
> Owen
>
> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:
>
>> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys?
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
>>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong<owen@delong.com> wrote:
>>>>> Heck no to X.509. We'd run into the same issue we have right now--a
>>>>> select group of companies charging users to prove their identity.
>>>> Not if enough of us get behind CACERT.
>>> Yet again, another org (free or not) that is holding my identity hostage.
>>> Would you give cacert your SSH key and use them to log in to your
>>> Linux servers? I'd bet most *nix admins would shout "hell no!"
>>>
>>> So why would you make them the gateway for your online identity?
>>>
>>> -A
>>>
>>>
>

It also allows them to sign anyone they want as someone pretending to be you, but with a different key pair.

Just like the DMV could, if it wanted to (or was ordered to) issue a drivers license with my name and DL number but an FBI agent's photo and thumbprint associated.

You'd want your logins to be at sites that only trusted CAs that you trusted to not do this... for HTTPS we're already way over that line I'm afraid.

Matthew Kaufman

(Sent from my iPhone)

On Jun 7, 2012, at 1:18 PM, Owen DeLong <owen@delong.com> wrote:

> A proper CA does not have your business or personal keys, they merely
> sign them and attest to the fact that they actually represent you. You are
> free to seek and obtain such validation from any and as many parties as
> you see fit.
>
> At no point should any CA be given your private key data. They merely
> use their private key to encrypt a hash of your public key and other data
> to indicate that your private key is bound to your other data.
>
> You trust DMV/Passport Agency/etc. to validate your identity in the form
> of your government issued ID credentials, right?
>
> That doesn't give DMV/Passport Agency/etc. control over your face, but,
> it does allow them to indicate to others that your face is tied to your
> name, date of birth, etc.
>
> Owen
>
> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:
>
>> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys?
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
>>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong<owen@delong.com> wrote:
>>>>> Heck no to X.509. We'd run into the same issue we have right now--a
>>>>> select group of companies charging users to prove their identity.
>>>> Not if enough of us get behind CACERT.
>>> Yet again, another org (free or not) that is holding my identity hostage.
>>> Would you give cacert your SSH key and use them to log in to your
>>> Linux servers? I'd bet most *nix admins would shout "hell no!"
>>>
>>> So why would you make them the gateway for your online identity?
>>>
>>> -A
>>>
>>>
>
>

Hi Randy,

Le jeudi 07 juin 2012 à 10:03 -0700, Randy Bush a écrit :
> hi etaoin,
>
> > I still don't want single sign on. Not anywhere.
>
> i believe that 'single sign on' is a bad deal and dangerous for all, not
> just we geeks. essentially it means that the 'identiry provider' owns
> your identity. i love that they call themselves 'identity providers'
> when it is MY fracking identity and they are reselling it.

I agree.

>
> the 'single sign on' i encourage for the end using human beings i
> support is 1password and its ilk. it provides the user with one sign-on
> yet strongly encourages separation of identities and strong passwords
> for sites.
>

Local repository of passwords, aggregation in a way. Right? Encrypted?
Open source?

> add to that, something such as ghostery for your browser, and you have a
> small chance of actually preserving your identity and minimizing cross-
> site tracking.
>
> randy

mh

>

On 07/06/2012, Lynda <shrdlu@deaddrop.org> wrote:
> Sorry to be the bearer of such bad tidings.

I'm a very amateur cryptologist so some of this is new to me:
"Any organization using SHA-1 without salting user passwords is
running a great risk -- much higher than they should," said Per
Thorsheim, chief information security advisor at Norwegian IT services
company EVRY. "We've seen this time and time again. This is not good
practice. Salt should be a minimum."
http://money.cnn.com/2012/06/06/technology/linkedin-password-hack/

This, however, is all too commonplace:
"We take the security of our members very seriously."
http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/

This is the only security item they have and it's mission critical right?
The issues are well understood and highly publicized.
The procedures are simple.
Taking a casual interest in security pretty much precludes mistakes here.
I'm not fooled at all.

http://press.linkedin.com/node/1192

The current system can work if applied correctly but time and again
we're seeing failure from service providers to follow the dots.
As I mentioned I'm no expert but I don't think widening the circle of
trust is the correct answer regardless of the technology. There's no
technology shortfall here.
Self signed certificates does sound great and for most purposes,
certainly in this case, fulfills all the requirements. There's no need
to verify anything about me is correct other than to tie my
authentication to my account. If I fail to meet the TOS then the plug
is easily pulled and any further activity can be dealt with as it
currently is by other means. I think there's enough risk in bringing
in a CA and so little advantage that it's wrong.

As far as moving the cryptographic responsibility from the service
provider to us - I'm all for it. They've been telling us for some time
now they'd rather not do that stuff.
I'd much rather have control and introduce something a little sleeker.
As far as users go, if they have to learn it to get on FaceSpace then
they'll learn it - that's a given.
There's no reason for it not to be optional anyway.

To all the people who've figured this out, my hat's off.

I'm very suspicious of any mention of a browser being involved in this
process though.
Shifiting some software responsibility to the client probably brings
new/different danger anyway but probably the last piece of goop that
should be involved is a browser.
That's anecdotal aversion but I'll stand by it.

> Please note that LinkedIn has weighed in with a carefully worded blog post:
>
> http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/
>
> Further details:
> 1. The leak took place on June 4
> 2. LinkedIn was using unsalted SHA-1 for their password store.
> 3. FYI, there are two lists. The second one appears to be from eHarmony.
> Unsalted MD5 used there.
> 4. The posted passwords are believed to be ones the cracker wanted help
> with, i.e., they have significantly more already cracked.
>
> Apparently phishing emails are already active in the wild based on the
> crack:
>
> http://bits.blogs.nytimes.com/2012/06/06/that-was-fast-criminals-exploit-linkedin-breach-for-phishing-attacks/
>
> In other words, if you have a LinkedIn account, expect that the password
> has been stolen. Go change your password now. If you used that password
> elsewhere, you know the routine. In addition, as has been pointed out
> elsewhere, there's no sign LI has fixed the problem. Expect that the
> password you change it to will also be compromised.
>
> :-(
>
> --
> A picture is worth 10K words -- but only those to describe
> the picture. Hardly any sets of 10K words can be adequately
> described with pictures.
>
>
>

No argument about that at all.

Owen

On Jun 7, 2012, at 2:26 PM, Matthew Kaufman wrote:

> It also allows them to sign anyone they want as someone pretending to be you, but with a different key pair.
>
> Just like the DMV could, if it wanted to (or was ordered to) issue a drivers license with my name and DL number but an FBI agent's photo and thumbprint associated.
>
> You'd want your logins to be at sites that only trusted CAs that you trusted to not do this... for HTTPS we're already way over that line I'm afraid.
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 7, 2012, at 1:18 PM, Owen DeLong <owen@delong.com> wrote:
>
>> A proper CA does not have your business or personal keys, they merely
>> sign them and attest to the fact that they actually represent you. You are
>> free to seek and obtain such validation from any and as many parties as
>> you see fit.
>>
>> At no point should any CA be given your private key data. They merely
>> use their private key to encrypt a hash of your public key and other data
>> to indicate that your private key is bound to your other data.
>>
>> You trust DMV/Passport Agency/etc. to validate your identity in the form
>> of your government issued ID credentials, right?
>>
>> That doesn't give DMV/Passport Agency/etc. control over your face, but,
>> it does allow them to indicate to others that your face is tied to your
>> name, date of birth, etc.
>>
>> Owen
>>
>> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:
>>
>>> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys?
>>>
>>> -Hammer-
>>>
>>> "I was a normal American nerd"
>>> -Jack Herer
>>>
>>>
>>>
>>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
>>>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong<owen@delong.com> wrote:
>>>>>> Heck no to X.509. We'd run into the same issue we have right now--a
>>>>>> select group of companies charging users to prove their identity.
>>>>> Not if enough of us get behind CACERT.
>>>> Yet again, another org (free or not) that is holding my identity hostage.
>>>> Would you give cacert your SSH key and use them to log in to your
>>>> Linux servers? I'd bet most *nix admins would shout "hell no!"
>>>>
>>>> So why would you make them the gateway for your online identity?
>>>>
>>>> -A
>>>>
>>>>
>>
>>

On 08/06/2012, Matthew Kaufman <matthew@matthew.at> wrote:
> It also allows them to sign anyone they want as someone pretending to be
> you, but with a different key pair.

You're exacly correct but in this case I don't think CAs are necessary
and probably detrimental so it's moot.

Currently I don't care at all if somebody joins YouTube with my name
or whatever and has a password I know nothing about. Well I do care a
little.
The point is that there's nothing sensitive about a username/password
combination for these type of accounts.
We don't care.
I'm sure I've communicated on the internet with President Obama and Johnny Cash.
If there's ever any doubt and something nefarious is going on there
are other methods.

I don't think anyone's suggesting that this is appropriate for
anything sensitive.
In short nothing changes at all other than swapping certificates for passwords.

If my bank wants to start doing it then they'll have to keep doing
what they're doing now and use other channels to verify me at
establishment, i.e. I'll have to walk into a branch and verify myself
and give them a USB stick with my certificate or whatever ...

>
> Just like the DMV could, if it wanted to (or was ordered to) issue a drivers
> license with my name and DL number but an FBI agent's photo and thumbprint
> associated.
>
> You'd want your logins to be at sites that only trusted CAs that you trusted
> to not do this... for HTTPS we're already way over that line I'm afraid.
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 7, 2012, at 1:18 PM, Owen DeLong <owen@delong.com> wrote:
>
>> A proper CA does not have your business or personal keys, they merely
>> sign them and attest to the fact that they actually represent you. You
>> are
>> free to seek and obtain such validation from any and as many parties as
>> you see fit.
>>
>> At no point should any CA be given your private key data. They merely
>> use their private key to encrypt a hash of your public key and other data
>> to indicate that your private key is bound to your other data.
>>
>> You trust DMV/Passport Agency/etc. to validate your identity in the form
>> of your government issued ID credentials, right?
>>
>> That doesn't give DMV/Passport Agency/etc. control over your face, but,
>> it does allow them to indicate to others that your face is tied to your
>> name, date of birth, etc.
>>
>> Owen
>>
>> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:
>>
>>> I gotta agree with Aaron here. What would be my motivation to "trust" an
>>> open and public infrastructure? With my business or personal keys?
>>>
>>> -Hammer-
>>>
>>> "I was a normal American nerd"
>>> -Jack Herer
>>>
>>>
>>>
>>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
>>>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong<owen@delong.com> wrote:
>>>>>> Heck no to X.509. We'd run into the same issue we have right now--a
>>>>>> select group of companies charging users to prove their identity.
>>>>> Not if enough of us get behind CACERT.
>>>> Yet again, another org (free or not) that is holding my identity
>>>> hostage.
>>>> Would you give cacert your SSH key and use them to log in to your
>>>> Linux servers? I'd bet most *nix admins would shout "hell no!"
>>>>
>>>> So why would you make them the gateway for your online identity?
>>>>
>>>> -A
>>>>
>>>>
>>
>>
>
>

>> the 'single sign on' i encourage for the end using human beings i
>> support is 1password and its ilk. it provides the user with one
>> sign-on yet strongly encourages separation of identities and strong
>> passwords for sites.
>
> Local repository of passwords, aggregation in a way. Right? Encrypted?
> Open source?

local repository good, i.e. the user owns and controls. others can not
associate the user's different identities. (again, run the ghostery
browser add-on)

encrypted good, a bit protected from loss of laptop, a 'maid attack',
etc.

open source sure would be good

randy

In message <4FD0AE52.20602@alter3d.ca>, Peter Kristolaitis writes:
> On 6/7/2012 9:22 AM, James Snow wrote:
> > On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:
> >> Imaging signing up for a site by putting in your email and pasting
> >> your public key.
> > Yes! Yes! Yes!
> >
> > I've been making this exact argument for about a year. It even retains
> > the same "email a link" reset mechanism when someone needs to reset
> > their key.
> >
> > A common counter-argument is, "But ordinary Internet users won't
> > understand SSH keys." They don't need to! The idea is easily explained
> > via a lock-and-key metaphor that people already understand. The UI for
> > walking users through key creation is easily imagined.
> >
> >
> > -Snow
>
> Oh yeah, I can just imagine that "lock and key" conversation now...
>
> "Imagine if the website has a lock on it, and you tell them what key you =
>
> want to use by giving them a copy."
> "But if they have a copy of my key, couldn't they use it to open all of=20
> the other locks I've set up to use it?"
> "(explain public key crypto)"
> "(drool, distraction by the latest Facebook feature)"

No. The correct metaphor is I have a key and a bunch of locks keyed to that
lock. I give them a lock to install which only the key I have can open.

> The other problem with this approach is that, as bad as trusting remote=20
> sites to do security properly is, I'm not sure that putting a "one key=20
> to rule them all" on users' machines is that much better, given the=20
> average user's penchant for installing malware on their machine because=20
> "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the=20
> time... I suspect we'd see a huge wave of malware whose sole purpose=20
> is to steal public keys (and you KNOW users won't password-protect their =
> private keys!).

Actually it is a big win. You now have to compromise millions of machines
to get millions of keys rather than a couple of machines to get millions
of passwords.

> Plus, now you have the problem of users not being able =
> to login to their favourite websites when they're using a friend's=20
> computer, internet cafe, etc, unless they've remembered to bring a copy=20
> of their private key with them.

That is a real issue.

> I think public key auth for websites is a great idea for geeks who=20
> understand the benefits, limitations and security concerns, but I have=20
> serious doubts that it would hold up when subjected to the "idiot test".
>
> - Pete
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

> Plus, now you have the problem of users not being able to login to
> their favourite websites when they're using a friend's computer,
> internet cafe, etc, unless they've remembered to bring a copy of their
> private key with them.

this is a feature, not a bug. you should be explaining to them why they
should never type passwords on another's keyboard, log on to anything
from an internet cafe, ...

randy

On Jun 7, 2012, at 19:24, Randy Bush wrote:

> this is a feature, not a bug. you should be explaining to them why they
> should never type passwords on another's keyboard, log on to anything
> from an internet cafe, ...

And this is where you lose the user. It doesn't matter that you're entirely right about the security risks of doing so, but real-world security is all about finding a balance with usability.

Situations where the data really does need to be secure are great for mandating public key authentication, as you point out it raises a significant technical barrier to the unskilled user preventing them from even attempting to access it from anywhere they shouldn't. That said, I doubt anyone but the most insane of security geeks are using it for their personal email. If the value to the person of being able to access their data from $random_computer exceeds the perceived risk, they'll do it if they can.

---
Sean Harlow
sean@seanharlow.info

>> this is a feature, not a bug. you should be explaining to them why
>> they should never type passwords on another's keyboard, log on to
>> anything from an internet cafe, ...
> And this is where you lose the user.

actually, not. it's like safe sex, an anology they understand. you may
be tempted over the line, but you know you may regret it for the rest of
your shortened life.

of course, having net on tablets and ip phones helps.

randy

On Thu, Jun 07, 2012 at 03:49:18PM -0700, Randy Bush wrote:
> open source sure would be good

I think it's mandatory. It's the only way we can have even modest trust
that it does what it claims to do. And...as the last week's events have
shown us...vendor-signed software sometimes isn't.

---rsk

On 6/7/12, Aaron C. de Bruyn <aaron@heyaaron.com> wrote:
>> A TLS + Client-Side X.509 Certificate for every user.
> Heck no to X.509. We'd run into the same issue we have right now--a
> select group of companies charging users to prove their identity.

The PKI infrastructure and authority validation components are not
required. Even if they were -- anyone can setup a PKI infrastructure,
the problem is trust.

Self-signed certificates are just fine for this application. The
authentication credential stored on the server for the user, can
simply be the public key of the user's certificate, and the
certificate hash.

There's no need for the TLS server to verify the client cert is
issued by a recognized authority; although it would be nice for
there to be Free X.509 certificate authorities to issue a signed TLS
cert for E-MAIL address authentication.

This would allow websites to accept user signup without a need to spam
the user with additional "Click this link here to prove that this is
actually your real e-mail address".

It should ideally be integrated with the web browser. The user
should be prompted to create their certificate by their web browser,
and given the option to self-sign an "Anonymous" certificate; use a
Free certificate authority, that will list and validate their e-mail
address.

Or an alternate CA that will validate their e-mail address and
optionally additional fields, such as a real name. Only fields
listed on a certificate need to be verified.

If a site doesn't trust the authority to issue the cert, the
connection proceeds, the site just asks the user to prove "Yes, that
really is their e-mail address"


> SSH does a good job of avoiding the pitfalls that most of those other
> products have.

SSH is vulnerable to MITM on the first connection to a new host, you
are prompted to save a host key, but noone really verifies this.
After you've saved a host key, if the host has to change keys for
legitimate reasons, such as previous host key compromised, the SSH
client refuses to connect, and the user has to manually remove
entries from their known_hosts file.

Username, password is more user-friendly than the SSH behavior, unfortunately.
Which means username/password would still be used in preference.

> Active Directory has costs associated with it.
Yes

> OpenID requires setting up your own server or using a third party.
Most options that exists require setting up your own server or using a
third party.

> Imaging signing up for a site by putting in your email and pasting
> your public key.

No... that's not convenient or user-friendly enough.
"Public what?"

There must be a browser integration where the public key is
automatically submitted (with the user's permission).

There are too many users who don't know how to use "copy and paste".

There are too many users not willing to dig into their browser's
settings to lookup their public key.


--
-JH

On 08/06/2012, at 2:09 AM, "Aaron C. de Bruyn" <aaron@heyaaron.com> wrote:
>
> I would think it's fairly simple.
> What if she forgot her existing password? Most sites have a 'reset
> password' link they e-mail you.

I especially like the ones that email back your password in clear text...

Sadly this still happens all too often.

On Fri, Jun 8, 2012 at 5:09 AM, Jimmy Hess <mysidia@gmail.com> wrote:
> The PKI infrastructure and  authority validation components are not
> required. Even if they were -- anyone  can setup a PKI infrastructure,
>  the problem is trust.

We don't need all the 'PKI' crap to do this. We already have SSL/TLS
for this purpose.
Let's face it. 99% of the sites I use don't actually verify and/or
trust who I am.

But those sites DO trust that they have my e-mail address (click here
to activate) and that I'm using the password I had when I first signed
up. So forget all PKI infrastructure. Just establish that I'm the
person who originally signed up for the account. Something as simple
as an ssh-style key exchange would be perfect. No other information
needs to be exchanged. Anonymous users could still be anonymous
(sites like slashdot allow 'anonymous' posting--or you could create an
account with a certain keypair and then throw that keypair away) and
non-anonymous users have a better method of signing in.

> This would allow websites to accept user signup without a need to spam
> the user with additional  "Click this link here to prove that this is
> actually your real e-mail address".

In the grand scheme of things, I don't think this is a huge hassle.

> Or an alternate CA that will validate their e-mail address and
> optionally additional fields, such as a real name.     Only fields
> listed on a certificate need to be verified.

...and now you need checking to figure out which CAs are anonymous or
not, combined with the original problem--a single point of failure.
One (or a handful) of providers that control access to your identity.
Would you switch to a version of SSH that requires signed
certificates--even if those certificates were free through cacert.org?

> SSH is vulnerable to MITM on the first connection to a new host, you
> are prompted to save a host key,  but noone really verifies this.

That's what the existing PKI infrastructure is for--verifying the site
you are connecting to is 'legit'. (The brokenness of that system is
an entirely different topic.)

Another thing to keep in mind is that SSH can verify key fingerprints
automatically too--you can publish them in DNS. Not infallible, but
it should be very difficult once DNS is secured. And for sites that
don't publish that info (like my podunk home machine) you can prompt
the first time to validate the fingerprint. So what. How many geeks
bypass the cert warnings in their browser almost out of habit?
(Obviously not when going to your bank--but for smaller sites.)

> After  you've saved a host key,  if the host has to change keys for
> legitimate reasons, such as previous host key compromised,   the SSH
> client refuses to connect,  and the user has to manually remove
> entries from their known_hosts file.

That could be solved by updating the DNS records or prompting the user
to update the key.

But seriously--what's going to happen if someone does an MitM on me
connecting to my bank and doing SSH auth?
The bank connection uses TLS. They'd have to forge that. Then I get
the home page and I click the 'sshauth' icon in my browser....and it
submits what? My username and does some key negotiation? What's the
MitM guy going to do? What's he going to steal? He doesn't have my
private key--nor the server's.

> Username, password  is more user-friendly than the SSH behavior, unfortunately.
> Which means username/password would still be used in preference.

So have the browser 'sshauth' plugin ask for a username and your 'ssh
passphrase' but call it a 'password'. Most users wouldn't know or
care about the difference.

>> OpenID requires setting up your own server or using a third party.
> Most options that exists require setting up your own server or using a
> third party.

The whole point of my original rant was to remove the ability of
website operators to screw up and release your password which you may
have used in multiple places. We have a simple system like that
called SSH (simple as opposed to SSL/TLS certs) that centralizes
everything on the user-side rather than the hundreds or thousands of
servers the user uses.

-A

David Walker wrote:

> Self signed certificates does sound great and for most purposes,
> certainly in this case, fulfills all the requirements. There's no need
> to verify anything about me is correct other than to tie my
> authentication to my account. If I fail to meet the TOS then the plug
> is easily pulled and any further activity can be dealt with as it
> currently is by other means. I think there's enough risk in bringing
> in a CA and so little advantage that it's wrong.
>


If LinkedIn or facebook or any large social site were to implement x509,
they would be silly not to cast themselves as the trusted root.

a) its better than self signed

b) now they are an x509 identify provider

On Wed, Jun 06, 2012 at 07:43:42PM -0700, Aaron C. de Bruyn wrote:
> Why haven't we taken this out of the hands of website operators yet?
> Why can't I use my ssh-agent to sign in to a website just like I do
> for about hundred servers, workstations, and my PCs at home?
>
> One local password used everywhere that can't be compromised through
> website stupidity...

This is the way to go.

The problem here is that x.509 is the only similar thing for browsers,
and x509 requires a ca, which makes the whole process a whole lot more
complext than the 'just give me the public half of the key you
want to use to authenticate to this service' I mean, unless
everyone trusts the same (few) CAs, which has a different set of problems.

I haven't found any way that is as simple and as portable as using
ssh that works in a web browser. I'm considering re-writing my
billing application to be libcurses based or something, and letting
users access that through ssh, too. (It would be silly, but it
might work for me; it goes along with my schtick.) This would
be somewhat suboptimal for things like bandwidth graphs, but eh.

but yeah, if someone wants to pass the hat to get an apache module
and a firefox addon written to do public key authentication over http
using ssh keys, I'd put a couple hundred bucks in the hat.