Mailing List Archive

On Wed, Jun 6, 2012 at 9:33 PM, Lynda <shrdlu@deaddrop.org> wrote:
> Sorry to be the bearer of such bad tidings. Please note that I'm doing a
> quick copy/paste from a notification I received. I've edited it a bit.
>
> 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.

Raising the issue of why Linkedin hasn't adopted the latest security
wrinkles from 1978. ( http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps
)

> 3. FYI, there are two lists. The second one appears to be from eHarmony.
> Unsalted MD5 used there.

Ditto. Normally I would complain about the use of MD5, but what's the point.

Regards
Marshall

> 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.
>
>

On Wed, Jun 6, 2012 at 7:19 PM, Marshall Eubanks
<marshall.eubanks@gmail.com> wrote:
> On Wed, Jun 6, 2012 at 9:33 PM, Lynda <shrdlu@deaddrop.org> wrote:
>> 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.

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...

-A

On 6/6/12, Aaron C. de Bruyn <aaron@heyaaron.com> wrote:
[snip]
> One local password used everywhere that can't be compromised through
> website stupidity...

One local password is an excellent idea of course.
"Remote servers directly handling user created credentials" should be appended
to the list of the worst ideas in computer security.

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.
BrowserID
OpenID
Active Directory Federation Services

OASIS SAML / STS + WS-Trust
Shibboleth SSO
CoSign SSO
Facebook Connect
Novell Access Manager
Windows Live ID

[.insert a thousand of the other slightly more obscure Multi-website
Single-Login systems]
....

--
-JH

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.

> [.insert a thousand of the other  slightly more obscure Multi-website
> Single-Login systems]

SSH does a good job of avoiding the pitfalls that most of those other
products have.
Active Directory has costs associated with it.
OpenID requires setting up your own server or using a third party.
Facebook and Google have their own auth systems, but quite a few
people are worried about how much they track you.
And the only time I use a Windows Live account is when I set one up
for a client who needs access to their volume licensing site.

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

No third party verifying and certifying who you are like with SSL
certs and charging you for the privilege (plain 'ol username/password
logins don't give you any verification either--linkedin has no clue
who I really am) just a key exchange from the user and server proving
that you've both seen each other before.

-A

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

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)"

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.

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".

- Pete

In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn 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.

Why?

A user providing the public half of a self-signed certificate is
exactly the same as the user providing the public half of a
self-generated SSH key.

The fact that you can have a trust chain may be useful in some
cases. For instance, I'm not at all opposed to the idea of the
government having a way to issue me a signed certificate that I
then use to access government services, like submitting my tax
return online, renewing my drivers license, or maybe even e-voting.

The X.509 certificates have an added bonus that they can be used
to secure the transport layer, something that your ssh-key-for-login
proposal can't do.

This is all a UI problem. If Windows/OSX or Safari/Firefox/Chrome
prompted users to create or import a "user certificate" when first
run, and provided a one-click way to provide it to a form when signing
up there would be a lot more incentive to use that method. Today pretty
much the only place you see certificates for users is Enterprises with
Microsoft's certificate tools because of the UI problem.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

On Jun 7, 2012, at 9:58 AM, Leo Bicknell wrote:

> In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn 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.
>
...
> For instance, I'm not at all opposed to the idea of the
> government having a way to issue me a signed certificate that I
> then use to access government services, like submitting my tax
> return online, renewing my drivers license, or maybe even e-voting.



All in favor of paying $119/year to vote, please raise your hands.

http://www.verisign.com/dod-interoperability/

On 07/06/12 6:36 AM, Peter Kristolaitis wrote:
> 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.

I've run into this problem with setting up accounts on aps on my
smartphone. A secure password that is relatively easy to type on a
regular keyboard becomes a PITA to type on a smartphone. There are a
number of sites I simply don't use on my phone because the hassle of
setting up each site's ap is greater than the benefit I get from
accessing it via the phone.

jc

On Thu, Jun 7, 2012 at 6:36 AM, Peter Kristolaitis <alter3d@alter3d.ca> 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:
>>>
> "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)"

You'd run into the same issue explaining how MD5, SHA1, salting,
etc... works to 'protect' their password.
Users don't care.
If putty were to pop up its password box when my mother signed in to
her computer and then I said something like "Don't worry, you won't
need to enter passwords while you surf the 'net now." and maybe showed
her the chrome extension icon thingy to click when she wants to paste
her 'password' (public key) into a new site, she'd be fine with it.

> 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...

And how does our current system of usernames and passwords avoid
malware that logs keystrokes?

> 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.

Yep--that's the one big problem I can see with this 'solution' that I
don't have an answer for yet.
It would be difficult to get users to carry around a USB key or a
smartcard, or whatever to get them signed in while away from their
home computer.

-A

True,

Back in 1998-1999 timeline, there was an ongoing project to have the US
Postal service issue X.509 certificates at a nominal fee. The fact that even
the most rural areas have access to a post office made a lot of sense. After
the 2000 election, the project was cancelled because "private business" can
handle it better.



----
Matthew Huff  | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139


> -----Original Message-----
> From: jeff murphy [mailto:jcmurphy@jeffmurphy.org]
> Sent: Thursday, June 07, 2012 10:06 AM
> To: Nanog
> Subject: Re: LinkedIn password database compromised
>
>
> On Jun 7, 2012, at 9:58 AM, Leo Bicknell wrote:
>
> > In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron
> C. de Bruyn 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.
> >
> ...
> > For instance, I'm not at all opposed to the idea of the government
> > having a way to issue me a signed certificate that I then use to
> > access government services, like submitting my tax return online,
> > renewing my drivers license, or maybe even e-voting.
>
>
>
> All in favor of paying $119/year to vote, please raise your hands.
>
> http://www.verisign.com/dod-interoperability/

On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote:

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

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.

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 Thu, Jun 7, 2012 at 11:58 AM, Jared Mauch <jared@puck.nether.net> wrote:
>
> On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote:
>
>> Imaging signing up for a site by putting in your email and pasting
>> your public key.
>>
>
> 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.

Or having to deal with family tech support, along the lines of

"You said you pasted it exactly."

"But I did. I've spent hours trying to watch that movie. I don't know
why it isn't working."

"But you {added a period at the end / didn't include the line wrap /
added a space at the beginning / etc}"

"Oh. Does that matter"

For more joy, imagine debugging such issues over the phone. At least I
can say that my Mother (God rest her soul) would never
have indulged in such foolery. She would have just called the company
to send a technician in to send the email for her.

Regards
Marshall

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.

-----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 6/7/2012 8:58 AM, Jared Mauch wrote:
>
> On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote:
>
>> Imaging signing up for a site by putting in your email and pasting
>> your public key.

> 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.

There are other issues than not being familiar with technology, and they
specifically affect those of us who have grown older, and lost certain
dexterity that used to be innate. There are passwords and pass phrases I
used to have committed to muscle memory. I never even had to think about
them. I've had to spend literally hours trying to type in a PGP pass
phrase that used to be something I could type without thinking.

There is no one size fits all solution to this. I'm still very annoyed
with a company that has only now moved to a password solution that
should have been in place in 2005. I still don't want single sign on.
Not anywhere. I've been around for a very long time, and I'm fine with
technical complexity for me, but do not expect the standard 16 year old
text messaging addict to be able to handle some of the solutions I've
seen suggested, much less most people my age.

Things are so complex now that people on nanog-l forget the average
level of expertise among their peer groups is simply not replicated in
the outside world. Jokes about needing a teenager to reprogram your VCR
are a thing of the past. I used to be in the business of forecasting the
future (among other things), and any security solution that is more
difficult than knowing not to use the same password for your bank that
you do for Facebook is doomed to fail.

{P.S. Ditto on thanks for backup DNS.}

--
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.

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.

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.

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

On Thu, Jun 7, 2012 at 1:03 PM, Randy Bush <randy@psg.com> 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.

so... now that this can is open, has anyone looked at:
<http://www.oneid.com/>

they seem to have some interesting options for better authentication.

> 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.

the oneid people would say: "it is still a shared secret"

-chris

> so... now that this can is open, has anyone looked at:
> <http://www.oneid.com/>

yep. yet another bucket of identity slime wanting to resell my
identity.

randy

The problem:
- Modern internet users must have lots of different login/passwords around
the internet. Most of then in easy-to-break poorly-patched poorly-managed
servers, like linkedin.

The solution:
- Reduce the number of authentication. Allow anonymous posting in more
sites.

Imagine this. I post something on the blog "yadaydayda". I give my email
and nothing else. The blog software sends me a email to confirm the post.
I click on it, and the post is published.

The real problem is that nowdays everybody and his dog want a password, and
a password is expensive for the user. The internet need more anonymous
ways to publish content.


--
--
ℱin del ℳensaje.

On Thu, Jun 7, 2012 at 1:14 PM, Randy Bush <randy@psg.com> wrote:
>> so... now that this can is open, has anyone looked at:
>>   <http://www.oneid.com/>
>
> yep.  yet another bucket of identity slime wanting to resell my
> identity.

maybe? they don't seem to want to be the 'identity provider' directly
though, or rather they point out that your corporation could be your
identity provider (or anyone else you might trust) they simply sell
the enabling software/tech.

On Thu, Jun 7, 2012 at 1:30 PM, Tei <oscar.vives@gmail.com> wrote:
> The problem:
> - Modern internet users must have lots of different login/passwords around
> the internet.  Most of then in easy-to-break poorly-patched poorly-managed
> servers,  like linkedin.
>
> The solution:
> -  Reduce the number of authentication.  Allow anonymous posting in more
> sites.
>
> Imagine this.   I post something on the blog  "yadaydayda". I give my email
> and nothing else.   The blog software sends me a email to confirm the post.
> I click on it, and the post is published.
>
> The real problem is that nowdays everybody and his dog want a password, and
> a password is expensive for the user.  The internet need more anonymous
> ways to publish content.

Maybe so, but anonymous entries on linkedin seems like a zen koan,
beyond the powers of my simple mind.

Regards
Marshall

>
>
> --
> --
> ℱin del ℳensaje.

>>> so... now that this can is open, has anyone looked at:
>>>   <http://www.oneid.com/>
>>
>> yep.  yet another bucket of identity slime wanting to resell my
>> identity.
>
> maybe? they don't seem to want to be the 'identity provider' directly
> though, or rather they point out that your corporation could be your
> identity provider (or anyone else you might trust) they simply sell
> the enabling software/tech.

so they provide tools to indentity resellers. the folk their software
enables are still *reselling* MY identity.

my point is that it is MY identity. there are tools, such as 1password,
which enable me to control MY identity and yet have the effect of single
sign-on.

and i believe it is important that mom and pop retain control of their
identities.

randy

On Thu, 07 Jun 2012 13:33:59 -0400, Marshall Eubanks said:

> Maybe so, but anonymous entries on linkedin seems like a zen koan,
> beyond the powers of my simple mind.

There's a distinction between anonymous and pseudonymous. I'm
certainly not the former, but to all but maybe a dozen or two NANOG'ers, I'm
pretty much the latter - somebody who always posts from the same
identity, but they've never actually personally verified the identity.

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.

On 6/8/12 7:22 PM, Luke S. Crawford wrote:
> I haven't found any way that is as simple and as portable as using
> ssh that works in a web browser.

The Enigform Firefox Add-on (plus mod_openpgp on Apache httpd) seems
similar:

http://wordpress.org/extend/plugins/wp-enigform-authentication/

> Enigform is a Firefox Add-On which uses OpenPGP to digitally sign
> outgoing HTTP requests and Securely login to remote web sites, as long
> as the remote web server is Enigform-compliant.

-Phil

Hi Everyone,

I thought that i would share an IEEE article about LinkenIn and eHarmony.

http://spectrum.ieee.org/riskfactor/telecom/security/linkedin-and-eharmony-hacked-8-million-passwords-taken/?utm_source=computerwise&utm_medium=email&utm_campaign=061312


-Grant

On Wed, Jun 13, 2012 at 1:05 PM, Phil Pishioneri <pgp+nanog@psu.edu> wrote:

> On 6/8/12 7:22 PM, Luke S. Crawford wrote:
>
>> I haven't found any way that is as simple and as portable as using
>> ssh that works in a web browser.
>>
>
> The Enigform Firefox Add-on (plus mod_openpgp on Apache httpd) seems
> similar:
>
> http://wordpress.org/extend/**plugins/wp-enigform-**authentication/<http://wordpress.org/extend/plugins/wp-enigform-authentication/>
>
> Enigform is a Firefox Add-On which uses OpenPGP to digitally sign
>> outgoing HTTP requests and Securely login to remote web sites, as long
>> as the remote web server is Enigform-compliant.
>>
>
> -Phil
>
>

I normally don't respond and just sit back leeching knowledge, however
this incident with LinkedIn & eHarmony strikes close to home. Not just
because my password was in this list of dumped LinkedIn accounts, but
the fact that this incident struck virtually every business professional
and corporation across the world. Please bare with me while I ramble a
few thoughts...

The real problem with authentication falls on "trust". You either have
to trust the website is storing the data securely or some other party
will verify you are who you really are. Just as in the example of the
DMV. If you think about your daily life you have put your entire life
on display for the world. You trust the DMV with your drivers license
information, address, social security number, heck they are even asking
for email now. If your active or prior military you have given that
same information, plus DNA and fingerprints. Think about how much
information about you and your habits occur from simply using "rewards"
cards, or "gas points". You, meaning users, give up your identity
everyday and with little regard, but when it comes to a website or
tracking you across websites we throw our hands up and scream "stop".

Please don't get me wrong, I am a HUGE fan boy of privacy and protection
of data, but responsibility ultimately falls back on the user. Those
users who do not know any better are still at fault, but it is our job
to educate them in better methods of protection.

So the question falls back on how can we make things better?

The fact that we must trust people outside ourselves is key. We need to
explain the importance of things such as KeePass (http://keepass.info/),
and pass-phases, rather than words. Below is an example, my password
which was leaked during the LinkedIn dump, but till I started using this
as an example the likelihood of the hash being cracking it was VERY
slim. Use this as an example of how to select a password for websites
and how even if the hashes are dumped the likelihood of cracking it is slim.

Password: !p3ngu1n_Pow3r!
SHA1 Hash: b34e3de2528855f02cf9ed04c217a15c61b35657
LinkedIn Hash: 00000de2528855f02cf9ed04c217a15c61b35657

To crack this pass-phase using the following systems it would take the
the associated amount of time:

$180,000 cracker it would take roughly 2 decades, 7 years to complete
the crack
$900 cracker it would take 3 centuries, 3 decades to complete the crack
Average graphics card it would take 15 centuries to complete the crack
Average desktop computer would take 795 centuries to complete the crack

Now what does this mean in the schema of things. You cannot trust any
website, third party identity verification, one time password, etc. You
can only trust yourself in creating a password that even if dumped will
make it nearly impossible to crack. Use some form of nomenclature to
identify a website separate from the base pass-phrase, thus giving you
individual "passwords" and in turn if one site gets dumped the others
remain safe.

Practicality is more along the lines of what the solution is. It is not
practical to develop an pub/priv solution because of the user
themselves, it is however practical to educate everyone we meet,
preaching to them how to make simple changes can increase their
protection ten fold.

A similar question though comes from "Website xyz.com was just dumped,
how do I know if my password was in this group?". Just from previous
experience, organizations release the warning stating they had a breach,
but it normally takes a good bit of time, as seen with LinkedIn, for
them to release who was part of this dump. If they ever really do,
sometimes it becomes a blanket "We were breached please change your
password." story. If a website you have been using is breached then I
revert back to the original statement saying that the issue becomes
trust. In the early days of LinkedIn websites claiming to check your
password against the database dump were popping up left and right. Is
it truly wise to jump to these sites and put your password, which
potentially will take decades to crack, into a website that claims to
check it without storing that password anywhere. I know there are sites
which were created by companies and individuals with outstanding
reputations, however it was outside my control and thus not trusted. I
decided to write a small, very simple, Python script that will run on
your local machine and allow you to check your password against the dump
of hashes. Right now it only does the LinkedIn dumps, but my goal is to
do any dump all you have to do is point it to the file. I also then
decided to take a little longer on the next release and learn to code in
a GUI for users who may not be a techie. I will continue to work on the
GUI release, but if you want to get that release email me and I'll make
sure you are aware of its release.

Until then I hope this helps those who may not feel comfortable about
checking a password against a website and trusting that website doesn't
store your password.

http://www.armoredpackets.com/hashcheck_a_small_piece_of_mind

I also hope that my explanation about how trust is the real issue, and
that ultimately you can't trust any site nor any method. That by making
simple, yet effective, changes in how you create and use passwords will
protect you long enough to safely change the passwords/pass-phrases for
all your sites.

Back to leeching knowledge :-)

Keep up the great conversations!

- Robert Miller
(arch3angel)

On 6/13/12 3:54 PM, Grant Ridder wrote:
> Hi Everyone,
>
> I thought that i would share an IEEE article about LinkenIn and eHarmony.
>
> http://spectrum.ieee.org/riskfactor/telecom/security/linkedin-and-eharmony-hacked-8-million-passwords-taken/?utm_source=computerwise&utm_medium=email&utm_campaign=061312
>
>
> -Grant
>
> On Wed, Jun 13, 2012 at 1:05 PM, Phil Pishioneri <pgp+nanog@psu.edu> wrote:
>
>> On 6/8/12 7:22 PM, Luke S. Crawford wrote:
>>
>>> I haven't found any way that is as simple and as portable as using
>>> ssh that works in a web browser.
>>>
>> The Enigform Firefox Add-on (plus mod_openpgp on Apache httpd) seems
>> similar:
>>
>> http://wordpress.org/extend/**plugins/wp-enigform-**authentication/<http://wordpress.org/extend/plugins/wp-enigform-authentication/>
>>
>> Enigform is a Firefox Add-On which uses OpenPGP to digitally sign
>>> outgoing HTTP requests and Securely login to remote web sites, as long
>>> as the remote web server is Enigform-compliant.
>>>
>> -Phil
>>
>>

In a message written on Wed, Jun 20, 2012 at 03:30:58PM -0400, AP NANOG wrote:
> So the question falls back on how can we make things better?

Dump passwords.

The tech community went through this back in oh, 1990-1993 when
folks were sniffing passwords with tcpdump and sysadmins were using
Telnet. SSH was developed, and the problem was effectively solved.

If you want to give me access to your box, I send you my public
key. In the clear. It doesn't matter if the hacker has it or not.
When I want to log in I authenticate with my private key, and I'm
in.

The leaks stop immediately. There's almost no value in a database of
public keys, heck if you want one go download a PGP keyring now. I can
use the same "password" (key) for every web site on the planet, web
sites no longer need to enforce dumb rules (one letter, one number, one
character your fingers can't type easily, minimum 273 characters).

SSL certificates could be used this way today.

SSH keys could be used this way today.

PGP keys could be used this way today.

What's missing? A pretty UI for the users. Apple, Mozilla, W3C,
Microsoft IE developers and so on need to get their butts in gear
and make a pretty UI to create personal key material, send the
public key as part of a sign up form, import a key, and so on.

There is no way to make passwords "secure". We've spent 20 years
trying, simply to fail in more spectacular ways each time. Death to
traditional passwords, they have no place in a modern world.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

Hi,

Leo Bicknell wrote:

[public key cryptography]
>
> What's missing? A pretty UI for the users. Apple, Mozilla, W3C,
Microsoft IE developers and so on need to get their butts in gear and make a
pretty UI to create personal key material, send the public key as part of a
sign up form, import a key, and so on.

Key management: doing it right is hard and probably beyond most end users.

Regards,

Leo

>> What's missing?  A pretty UI for the users.  Apple, Mozilla, W3C,

perhaps this is a good starting point:
http://gpg4usb.cpunk.de/
GPLv3, lightweight, portable, compatibility with GNU/Linux and Windows

Exactly!

Passwords = Fail

All we can do is make it as difficult as possible for them to crack it
until the developers decide to make pretty eye candy.

- Robert Miller
(arch3angel)

On 6/20/12 3:43 PM, Leo Bicknell wrote:
> In a message written on Wed, Jun 20, 2012 at 03:30:58PM -0400, AP NANOG wrote:
>> So the question falls back on how can we make things better?
> Dump passwords.
>
> The tech community went through this back in oh, 1990-1993 when
> folks were sniffing passwords with tcpdump and sysadmins were using
> Telnet. SSH was developed, and the problem was effectively solved.
>
> If you want to give me access to your box, I send you my public
> key. In the clear. It doesn't matter if the hacker has it or not.
> When I want to log in I authenticate with my private key, and I'm
> in.
>
> The leaks stop immediately. There's almost no value in a database of
> public keys, heck if you want one go download a PGP keyring now. I can
> use the same "password" (key) for every web site on the planet, web
> sites no longer need to enforce dumb rules (one letter, one number, one
> character your fingers can't type easily, minimum 273 characters).
>
> SSL certificates could be used this way today.
>
> SSH keys could be used this way today.
>
> PGP keys could be used this way today.
>
> What's missing? A pretty UI for the users. Apple, Mozilla, W3C,
> Microsoft IE developers and so on need to get their butts in gear
> and make a pretty UI to create personal key material, send the
> public key as part of a sign up form, import a key, and so on.
>
> There is no way to make passwords "secure". We've spent 20 years
> trying, simply to fail in more spectacular ways each time. Death to
> traditional passwords, they have no place in a modern world.
>

In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda wrote:
> Key management: doing it right is hard and probably beyond most end users.

I could not be in more violent disagreement.

First time a user goes to sign up on a web page, the browser should
detect it wants a key uploaded and do a simple wizard.

- Would you like to create an online identity for logging into web
sites? Yes, No, Import

User says yes, it creates a key, asking for an e-mail address to
identify it. Import to drag it in from some other program/format,
No and you can't sign up.

Browser now says "would you like to sign up for website 'foobar.com'",
and if the user says "yes" it submits their public key including the
e-mail they are going to use to log on. User doesn't even fill out
a form at all.

Web site still does the usual e-mail the user, click this link to verify
you want to sign up thing.

User goes back to web site later, browser detects "auth needed" and
"public key foo" accepted, presents the cert, and the user is logged in.

Notice that these steps _remove_ the user filling out forms to sign up
for simple web sites, and filling out forms to log in. Anyone who's
used cert-based auth at work is already familiar, the web site
"magically" knows you. This is MUCH more user friendly.

So the big magic here is the user has to click on "yes" to create a key
and type in an e-mail once. That's it. There's no web of trust. No
identity verification (a-la ssl). I'm talking a very SSH like system,
but with more polish.

Users would find it much more convenient and wonder why we ever used
passwords, I think...

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

(Fight of the Leos...)

bicknell@ufp.org (Leo Bicknell) wrote:

> Users would find it much more convenient and wonder why we ever used
> passwords, I think...

Yeah cool. Shame I have three accounts on peerindb.com alone...

On 6/20/2012 2:39 PM, Leo Bicknell wrote:
> Users would find it much more convenient and wonder why we ever used
> passwords, I think...

Yes. Those users who have a single computer with a single browser. For
anyone with a computer *and* a smartphone, however, there's a huge
missing piece. And it gets exponentially worse as the number of devices
multiplies.

Matthew Kaufman

On Wed, Jun 20, 2012 at 2:44 PM, Elmar K. Bins <elmi@4ever.de> wrote:
> (Fight of the Leos...)
>
> bicknell@ufp.org (Leo Bicknell) wrote:
>
>> Users would find it much more convenient and wonder why we ever used
>> passwords, I think...
>
> Yeah cool. Shame I have three accounts on peerindb.com alone...

You're right. Multiple accounts is unpossible in every way except
prompting for usernames and passwords in the way we do it now.
The whole ssh-having-multiple-identities thing is a concept that could
never be applied in the browser in any sort of user-friendly way.
</sarcasm>

-A

On Jun 20, 2012, at 5:54 PM, Matthew Kaufman wrote:

> On 6/20/2012 2:39 PM, Leo Bicknell wrote:
>> Users would find it much more convenient and wonder why we ever used passwords, I think...
>
> Yes. Those users who have a single computer with a single browser. For anyone with a computer *and* a smartphone, however, there's a huge missing piece. And it gets exponentially worse as the number of devices multiplies.

Not including the "app culture" that results in things like the Hilton (for example) app being just a bookmark into their mobile website. That does not make it a fully fledged application. I could have used my web browser to get to the same place and flow better as well :) (oh and the per-brand apps that exist as well.. *sigh*).

Not sure how to import my crypto key into those :)

- Jared

In a message written on Wed, Jun 20, 2012 at 03:05:17PM -0700, Aaron C. de Bruyn wrote:
> You're right. Multiple accounts is unpossible in every way except
> prompting for usernames and passwords in the way we do it now.
> The whole ssh-having-multiple-identities thing is a concept that could
> never be applied in the browser in any sort of user-friendly way.
> </sarcasm>

Aw come on guys, that's really not hard, and code is already in the
browsers to do it.

If you have SSL client certs and go to a web site which accepts
multiple domains you get a prompt, "Would you like to use identity
A or identity B." Power users could create more than one identity
(just like more than one SSH key). Browsers could even generate
them behind the scenes for the user "create new account at foo.com"
tells the browser to generate "bicknell@foo.com" and submit it. If
I want another a quick trip to the menu creates "superman@foo.com"
and saves it. When I go to log back in the web site would say "send
me your @foo.com" signed info.

Seriously, not that hard to do and make seemless for the user; it's all
UI work, and a very small amount of protocol (HTTP header probably)
update.

In a message written on Wed, Jun 20, 2012 at 02:54:10PM -0700, Matthew Kaufman wrote:
> Yes. Those users who have a single computer with a single browser. For
> anyone with a computer *and* a smartphone, however, there's a huge
> missing piece. And it gets exponentially worse as the number of devices
> multiplies.

Yeah, and no one has that problem with a password.

Ok, that was overly snarky. However people have the same issue
with passwords today. iCloud to sync them. Dropbox and 1Password.
GoodNet. Syncing certs is no worse than syncing passwords.

None of you have hit on the actual down side. You can't (easily) log in
from your friends computer, or a computer at the library due to lack of
key material. I can think of at least four or five solutions, but
that's the only "hard" problem here.

This has always failed in the past because SSL certs have been tied to
_Identity_ (show me your drivers license to get one). SSH keys are NOT,
you create them at will, which is why they work. You could basically
coopt SSL client certs to do this with nearly zero code provided people
were willing to give up on the identity part of X.509, which is
basically worthless anyway.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

On Wed, 20 Jun 2012 14:39:14 -0700, Leo Bicknell said:
> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda wrote:
> > Key management: doing it right is hard and probably beyond most end users.
>
> I could not be in more violent disagreement.

I have to agree with Leo on this one. Key management *is* hard - especially
the part about doing secure key management in a world where Vint Cerf
says there's 140M pwned boxes. It's all nice and sugary and GUI-fied and
pretty and Joe Sixpack can do it - till his computer becomes part of the 140M
and then he's *really* screwed.

In a message written on Wed, Jun 20, 2012 at 06:37:50PM -0400, valdis.kletnieks@vt.edu wrote:
> I have to agree with Leo on this one. Key management *is* hard - especially
> the part about doing secure key management in a world where Vint Cerf
> says there's 140M pwned boxes. It's all nice and sugary and GUI-fied and
> pretty and Joe Sixpack can do it - till his computer becomes part of the 140M
> and then he's *really* screwed.

I'm glad you agree with me. :)

That's no different than today. Today Joe Sixpack keeps all his
passwords in his browsers cache. When his computer becomes part of the
botnet the bot owner downloads that file, and also starts a keylogger to
get more passwords from him.

In the world I propose when his computer becomes part of the botnet
they will download the private key material, same as before.

My proposal neither helps, nor hurts, the problem of Joe Sixpack's
machine being broken into is orthoganal and not addressed. It needs to
be, but not by what I am proposing.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

leo,

what is the real difference between my having holding the private half
of an asymmetric key and my holding a good passphrase for some site?
that the passphrase is symmetric?

> First time a user goes to sign up on a web page, the browser should
> detect it wants a key uploaded and do a simple wizard.
> - Would you like to create an online identity for logging into web
> sites? Yes, No, Import

s/onto web sites/this web site/ let's not make cross-site tracking any
easier than it is today.

randy

In a message written on Thu, Jun 21, 2012 at 08:02:58AM +0900, Randy Bush wrote:
> what is the real difference between my having holding the private half
> of an asymmetric key and my holding a good passphrase for some site?
> that the passphrase is symmetric?

The fact that it is symmetric leads to the problem.

The big drawback is that today you have to provide the secret to
the web site to verify it. It doesn't matter if the secret is
transfered in the clear (e.g. http) or encrypted (e.g. https), they
have it in their RAM, or on their disk, and so on. Today we _trust_
sites to get rid of that secret as fast as possible, by doing things
like storing a one way hash and then zeroing the memory.

But what we see time and time again is sites are lazy. The secret
is stored in the clear. The secret is hashed, but with a bad hash
and no salt. Even if they are "good guys" and use SHA-256 with a nice
salt, if a hacker hacks into their server they can intercept the secret
during processing.

With a cryptographic solution the web site would say something like:

"Hi, it's 8:59PM, transaction ID 1234, cookie ABCD, I am foo.com, who are you."

Your computer would (unknown to you) would use foo.com to figure out
that bicknell@foo.com (or superman@foo.com) was your login, do some
math, and sign a response with your private key that says:

"Hi, I'm bicknell@foo.com, I agree it's 8:59 PM, transaction 1234,
cookie ABCD."

Even if the attacker had fully compromised the server end they get
nothing. There's no reply attack. No shared secret they can use to log
into another web site. Zero value.

> s/onto web sites/this web site/ let's not make cross-site tracking any
> easier than it is today.

Yep. Don't get me wrong, there's an RFC or two here, a few pages of
code in web servers and browsers. I am not asserting this is a trival
change that could be made by one guy in a few minutes. However, I am
suggesting this is an easy change that could be implemented in weeks not
months.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

> The fact that it is symmetric leads to the problem.
>
> Even if the attacker had fully compromised the server end they get
> nothing. There's no reply attack. No shared secret they can use to log
> into another web site. Zero value.

with per-site passphrases there is no cross-site threat. there is
replay, as you point out.

would be interested to hear smb on this.

> Yep. Don't get me wrong, there's an RFC or two here, a few pages of
> code in web servers and browsers. I am not asserting this is a trival
> change that could be made by one guy in a few minutes. However, I am
> suggesting this is an easy change that could be implemented in weeks
> not months.

did you say RFC in the same sentence as weeks? but i definitely agree
that we should be able to do better than we are now.

randy

Anonymity on the Internet is a feature, because a lot of the world
netcitizens come from countries where saying this or that is a crime,
and can get you in trouble.
Any asymetric cryptography solution that remove anonymity is a bad
thing. Making censorship easier on the internet is making it worse.

What could do some good, is to discredit some bad practices, and
propose alternate better practices.
This is hard, and part of it is because some people good practices is
other people good practices. We can't start this yet, because we
don't agree on these good practices.

Theres something weird with passwords length, on most websites you
are allowed to type a 80 or 120 characters long name. But if you try
that with your password, you find a problem. Somehow VARCHAR(120) is
unfeasible for passwords, but ok for first_name,second_name.
Is even more weird wen people are storing hashs. The length of a md5
don't change if I choose very long passwords, so why are people
limiting password length?

Other weird limitations that "must go", is the idea that you can't use
"special characters". The expresion "special characters" is a red flag
itself. Most passwords sould allow UTF-8, and allow anything that
UTF-8 allow.

Forcing people to mix uppercase and lowercase.. I understand where
this come from. It enhance the password strength. A what price? Making
passwords a random mix of letter and numbers make then hard to
remember and make life miserable for everyone. Practices to make
passwords stronger may be pushing people to write password down, or
reuse passwords.

--
ℱin del ℳensaje.

On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote:

(on the use of public/private keys)

> The leaks stop immediately. There's almost no value in a database of
> public keys, heck if you want one go download a PGP keyring now.

It's a nice thought, but it won't work. There are two large-scale
security problems which prevent it from working:

1. Fully-compromised/hijacked/botted/zombied systems. Pick your term,
but any estimate of this population under 100M should be laughed out
of the room. Plausible estimates are now in the 200M to 300M range.
Any private key present on any of those is accessible to The Bad Guys
whenever they can trouble themselves to grab it. (Just as they're
already, quite obviously, grabbing passwords en masse.)

2. Pre-compromised-at-the-factory smartphones and similar. There's
no reason why these can't be preloaded with spyware similar to CarrierIQ
and directed to upload all newly-created private keys to a central
collection point. This can be done, therefore it will be done, and when
some security researcher discovers it, the usual excuses and justifications
will be made by the designated spokesliars for the companies involved...
which will of course keep right on doing it, albeit perhaps with more
subterfuge.

Problem #1 has been extant for ten years and no (meaningful) progress
whatsoever has been made on solving it.

Problem #2 is newer, but I'm willing to bet that it will also last
at least a decade and that it will get worse, since there are
substantial economic incentives to make it so.

---rsk

Tei <oscar.vives@gmail.com> wrote:

> Anonymity on the Internet is a feature, because a lot of the world
> netcitizens come from countries where saying this or that is a crime,
> and can get you in trouble.

Note that you need to make a distinction between pseudonymity and
anonymity. In most online situations anonymity is not useful, because you
want a service to be able to identify you as the same person when you go
away and come back later. You want the service to attach a pseudonym to
you, and you want to be in control of whether this pseudonym is linked to
your identities at other services or in the real world.

Whether you authenticate your pseudonym with a password or a cryptographic
key is immaterial, provided the key store supports unlinked identities -
i.e. it must not require you to use the same key for everything. A good
key store makes it easier to decouple your identities at different
services than remembering N different username + password pairs.

Tony.
--
f.anthony.n.finch <dot@dotat.at> http://dotat.at/
North Portland, Plymouth: Cyclonic, becoming westerly 5 to 7, occasionally
gale 8. Rough. Rain or showers. Good, occasionally poor.

I have two concerns with this thought, while at the same time intrigued
by it.

How will this prevent man in the middle attacks, either at the users
location, the server location, or even on the compromised server itself
where the attacker is just gathering data. This is the same concerns we
face now.

Second is regarding the example just made with "bicknell@foo.com" and
superman@foo.com. Does this not require the end user to have virtually
endless number of email addresses if this method would be implemented
across all authenticated websites, compounded by numerous devices
(iPads, Smartphones, personal laptop, work laptop, etc..)

Again I think this conversation is on the right track, but ultimately a
form of two factor authentication method such as pub/priv, Wikid, etc..
is needed.

On 6/20/12 6:28 PM, Leo Bicknell wrote:
> In a message written on Wed, Jun 20, 2012 at 03:05:17PM -0700, Aaron C. de Bruyn wrote:
>> You're right. Multiple accounts is unpossible in every way except
>> prompting for usernames and passwords in the way we do it now.
>> The whole ssh-having-multiple-identities thing is a concept that could
>> never be applied in the browser in any sort of user-friendly way.
>> </sarcasm>
> Aw come on guys, that's really not hard, and code is already in the
> browsers to do it.
>
> If you have SSL client certs and go to a web site which accepts
> multiple domains you get a prompt, "Would you like to use identity
> A or identity B." Power users could create more than one identity
> (just like more than one SSH key). Browsers could even generate
> them behind the scenes for the user "create new account at foo.com"
> tells the browser to generate "bicknell@foo.com" and submit it. If
> I want another a quick trip to the menu creates "superman@foo.com"
> and saves it. When I go to log back in the web site would say "send
> me your @foo.com" signed info.
>
> Seriously, not that hard to do and make seemless for the user; it's all
> UI work, and a very small amount of protocol (HTTP header probably)
> update.
>
> In a message written on Wed, Jun 20, 2012 at 02:54:10PM -0700, Matthew Kaufman wrote:
>> Yes. Those users who have a single computer with a single browser. For
>> anyone with a computer *and* a smartphone, however, there's a huge
>> missing piece. And it gets exponentially worse as the number of devices
>> multiplies.
> Yeah, and no one has that problem with a password.
>
> Ok, that was overly snarky. However people have the same issue
> with passwords today. iCloud to sync them. Dropbox and 1Password.
> GoodNet. Syncing certs is no worse than syncing passwords.
>
> None of you have hit on the actual down side. You can't (easily) log in
> from your friends computer, or a computer at the library due to lack of
> key material. I can think of at least four or five solutions, but
> that's the only "hard" problem here.
>
> This has always failed in the past because SSL certs have been tied to
> _Identity_ (show me your drivers license to get one). SSH keys are NOT,
> you create them at will, which is why they work. You could basically
> coopt SSL client certs to do this with nearly zero code provided people
> were willing to give up on the identity part of X.509, which is
> basically worthless anyway.
>

If anyone have a really good idea how to fix this mess, It will be a
good idea to contact with Jeff Atwood (of codehorror.com and
stackoverflow.com fame). He and other people is working on a new
internet approach to discussions. Think forums 2.0. If this new pet
rock succeed, could change how the world use, eerrh... forums. We
could hit two problems with the same rock.



--
--
ℱin del ℳensaje.

I want to start by saing, there are lots of different security problems
with accessing a "cloud service". Several folks have already brought up
issues like compromised user machines or actually verifing identity.

One of the problems in this space I think is that people keep looking
for a silver bullet that magically solves all the problems. It doesn't
exist. We need a series of technologies that work with each other.

In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wrote:
> How will this prevent man in the middle attacks, either at the users
> location, the server location, or even on the compromised server itself
> where the attacker is just gathering data. This is the same concerns we
> face now.

There is a sign up problem. You could sign up with a MTM web site,
which then signs you up with the real web site.

There are a number of solutions, you can try and prevent the MTM attack
with something like DNSSEC, and/or verify the identity of the web site with
something like X.509 certificates verified by a trusted party. The
first relationship could exchange public keys in both directions, making
the attack a sign-up attack only, once the relationship is established
its public key in both directions and if done right impervious to a MTM
attack.

Note that plenty of corporations "hijack" HTTPS today, so MTM attacks
are very real and work should be done in this space.

> Second is regarding the example just made with "bicknell@foo.com" and
> superman@foo.com. Does this not require the end user to have virtually
> endless number of email addresses if this method would be implemented
> across all authenticated websites, compounded by numerous devices
> (iPads, Smartphones, personal laptop, work laptop, etc..)

Not at all. Web sites can make the same restrictions they make
today. Many may accept my "bicknell@ufp.org" key and let me us
that as my login. A site like gmail or hotmail may force me to use
something like bicknell@gmail.com, because it actually is an e-mail,
but it could also give me the option of using an identifier of my
choice.

While I think use of e-mails is good for confirmation purposes, a
semi-anonymous web site that requires no verification could allow
a signup with "bob" or other unqualified identifier.

It's just another name space. The browser is going to cache a mapping
from web site, or domain, to identifier, quite similar to what it does
today...

Today:
www.facebook.com, login: bob, password: secret

Tomorrow:
www.facebook.com, key: bob, key-public: ..., key-private: ...


--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

While I am not disagreeing with your statements, nor do I believe they
will work. What I am doing is playing devils advocate. I am hoping to
stir all of our gray matter for ideas, maybe something said here may end
up being the fix.

However, which thread do we want to continue this conversation in?

"LinkedIn password database compromised"

or

"How to fix authentication (was LinkedIn)"

:-)

- Robert Miller
(arch3angel)

On 6/21/12 11:05 AM, Leo Bicknell wrote:
> I want to start by saing, there are lots of different security problems
> with accessing a "cloud service". Several folks have already brought up
> issues like compromised user machines or actually verifing identity.
>
> One of the problems in this space I think is that people keep looking
> for a silver bullet that magically solves all the problems. It doesn't
> exist. We need a series of technologies that work with each other.
>
> In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wrote:
>> How will this prevent man in the middle attacks, either at the users
>> location, the server location, or even on the compromised server itself
>> where the attacker is just gathering data. This is the same concerns we
>> face now.
> There is a sign up problem. You could sign up with a MTM web site,
> which then signs you up with the real web site.
>
> There are a number of solutions, you can try and prevent the MTM attack
> with something like DNSSEC, and/or verify the identity of the web site with
> something like X.509 certificates verified by a trusted party. The
> first relationship could exchange public keys in both directions, making
> the attack a sign-up attack only, once the relationship is established
> its public key in both directions and if done right impervious to a MTM
> attack.
>
> Note that plenty of corporations "hijack" HTTPS today, so MTM attacks
> are very real and work should be done in this space.
>
>> Second is regarding the example just made with "bicknell@foo.com" and
>> superman@foo.com. Does this not require the end user to have virtually
>> endless number of email addresses if this method would be implemented
>> across all authenticated websites, compounded by numerous devices
>> (iPads, Smartphones, personal laptop, work laptop, etc..)
> Not at all. Web sites can make the same restrictions they make
> today. Many may accept my "bicknell@ufp.org" key and let me us
> that as my login. A site like gmail or hotmail may force me to use
> something like bicknell@gmail.com, because it actually is an e-mail,
> but it could also give me the option of using an identifier of my
> choice.
>
> While I think use of e-mails is good for confirmation purposes, a
> semi-anonymous web site that requires no verification could allow
> a signup with "bob" or other unqualified identifier.
>
> It's just another name space. The browser is going to cache a mapping
> from web site, or domain, to identifier, quite similar to what it does
> today...
>
> Today:
> www.facebook.com, login: bob, password: secret
>
> Tomorrow:
> www.facebook.com, key: bob, key-public: ..., key-private: ...
>
>

On Thu, Jun 21, 2012 at 12:56 PM, Rich Kulawiec <rsk@gsp.org> wrote:
> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote:
>
> (on the use of public/private keys)
>
>> The leaks stop immediately.  There's almost no value in a database of
>> public keys, heck if you want one go download a PGP keyring now.
>
> It's a nice thought, but it won't work.   There are two large-scale
> security problems which prevent it from working:
>
> 1. Fully-compromised/hijacked/botted/zombied systems.  Pick your term,
> but any estimate of this population under 100M should be laughed out
> of the room.  Plausible estimates are now in the 200M to 300M range.
> Any private key present on any of those is accessible to The Bad Guys
> whenever they can trouble themselves to grab it.  (Just as they're
> already, quite obviously, grabbing passwords en masse.)
>
> 2. Pre-compromised-at-the-factory smartphones and similar.  There's
> no reason why these can't be preloaded with spyware similar to CarrierIQ
> and directed to upload all newly-created private keys to a central
> collection point.  This can be done, therefore it will be done, and when
> some security researcher discovers it, the usual excuses and justifications
> will be made by the designated spokesliars for the companies involved...
> which will of course keep right on doing it, albeit perhaps with more
> subterfuge.
>
> Problem #1 has been extant for ten years and no (meaningful) progress
> whatsoever has been made on solving it.
>
> Problem #2 is newer, but I'm willing to bet that it will also last
> at least a decade and that it will get worse, since there are
> substantial economic incentives to make it so.

In both cases, the evildoers may only gain access to a
passphrase-protected private key. That doesn't help if the private
key is generated on a compromised system, but it helps if the system
is compromised after the private keys are generated, or if the private
key is generated elsewhere and loaded onto the compromised system.
And it doesn't help if the passphrase is easily guessed.

Cheers,
Dave Hart

----- Original Message -----
> From: "Tei" <oscar.vives@gmail.com>

> If anyone have a really good idea how to fix this mess, It will be a
> good idea to contact with Jeff Atwood (of codehorror.com and
> stackoverflow.com fame). He and other people is working on a new
> internet approach to discussions. Think forums 2.0. If this new pet
> rock succeed, could change how the world use, eerrh... forums. We
> could hit two problems with the same rock.

Those who do not understand Usenet are condemned to reinvent it. Poorly.
-- after henry@utzoo

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

On Thu, Jun 21, 2012 at 08:33:47AM +0900, Randy Bush wrote:
> would be interested to hear smb on this.

+1. I've been reading and thinking about:

http://www.ietf.org/id/draft-bellovin-hpw-01.txt

for quite some time, and I recommend that others interested in
this topic do the same.

---rsk

Rich Kulawiec <rsk@gsp.org> wrote:
>
> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote:
>
> (on the use of public/private keys)
>
> > The leaks stop immediately. There's almost no value in a database of
> > public keys, heck if you want one go download a PGP keyring now.
>
> It's a nice thought, but it won't work. There are two large-scale
> security problems which prevent it from working:
>
> 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term,
> but any estimate of this population under 100M should be laughed out
> of the room. Plausible estimates are now in the 200M to 300M range.
> Any private key present on any of those is accessible to The Bad Guys
> whenever they can trouble themselves to grab it. (Just as they're
> already, quite obviously, grabbing passwords en masse.)

The proverbial 'so what' applies?

IF the end-user system is compromised, it *doesn't*matter* what kind of
security is used, THAT USER is compromised.

However, there is a _MASSIVE_ difference with respect to a 'server-side'
compromise. One break-in, on *one* machine, can expose tens of millions,
(if not hundreds of millions) of user credentials.

>
> 2. Pre-compromised-at-the-factory smartphones and similar. There's
> no reason why these can't be preloaded with spyware similar to CarrierIQ
> and directed to upload all newly-created private keys to a central
> collection point.
>
> Problem #1 has been extant for ten years and no (meaningful) progress
> whatsoever has been made on solving it.

'male bovine excrement' applies to this strawman argument.

Leo made no claim of describing a FUSSP (final ultimate solution to stolen
passwords). What he did describe was a methodology that could be fairly
easily implemented in the real world, =and= which effectively eliminates
the risk of _server-side_ compromise of a master 'password-equivalent' list.

Leo's proposal _does_ effectively address the risk of server-side compromise.
If implemented, it would effectively eliminate "more than half" of the

Still playing devils advocate here, but does this still not resolve the
human factor of "Implementation"?

--

- Robert Miller
(arch3angel)

On 6/22/12 7:43 AM, Robert Bonomi wrote:
> Rich Kulawiec <rsk@gsp.org> wrote:
>> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote:
>>
>> (on the use of public/private keys)
>>
>>> The leaks stop immediately. There's almost no value in a database of
>>> public keys, heck if you want one go download a PGP keyring now.
>> It's a nice thought, but it won't work. There are two large-scale
>> security problems which prevent it from working:
>>
>> 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term,
>> but any estimate of this population under 100M should be laughed out
>> of the room. Plausible estimates are now in the 200M to 300M range.
>> Any private key present on any of those is accessible to The Bad Guys
>> whenever they can trouble themselves to grab it. (Just as they're
>> already, quite obviously, grabbing passwords en masse.)
> The proverbial 'so what' applies?
>
> IF the end-user system is compromised, it *doesn't*matter* what kind of
> security is used, THAT USER is compromised.
>
> However, there is a _MASSIVE_ difference with respect to a 'server-side'
> compromise. One break-in, on *one* machine, can expose tens of millions,
> (if not hundreds of millions) of user credentials.
>
>> 2. Pre-compromised-at-the-factory smartphones and similar. There's
>> no reason why these can't be preloaded with spyware similar to CarrierIQ
>> and directed to upload all newly-created private keys to a central
>> collection point.
>>
>> Problem #1 has been extant for ten years and no (meaningful) progress
>> whatsoever has been made on solving it.
> 'male bovine excrement' applies to this strawman argument.
>
> Leo made no claim of describing a FUSSP (final ultimate solution to stolen
> passwords). What he did describe was a methodology that could be fairly
> easily implemented in the real world, =and= which effectively eliminates
> the risk of _server-side_ compromise of a master 'password-equivalent' list.
>
> Leo's proposal _does_ effectively address the risk of server-side compromise.
> If implemented, it would effectively eliminate "more than half" of the

Leo,

This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.

Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.

If it does not use self-generated unsigned keys, it will never fly.

---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org


> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell@ufp.org]
> Sent: Wednesday, 20 June, 2012 15:39
> To: nanog@nanog.org
> Subject: Re: LinkedIn password database compromised
>
> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda
> wrote:
> > Key management: doing it right is hard and probably beyond most end users.
>
> I could not be in more violent disagreement.
>
> First time a user goes to sign up on a web page, the browser should
> detect it wants a key uploaded and do a simple wizard.
>
> - Would you like to create an online identity for logging into web
> sites? Yes, No, Import
>
> User says yes, it creates a key, asking for an e-mail address to
> identify it. Import to drag it in from some other program/format,
> No and you can't sign up.
>
> Browser now says "would you like to sign up for website 'foobar.com'",
> and if the user says "yes" it submits their public key including the
> e-mail they are going to use to log on. User doesn't even fill out
> a form at all.
>
> Web site still does the usual e-mail the user, click this link to verify
> you want to sign up thing.
>
> User goes back to web site later, browser detects "auth needed" and
> "public key foo" accepted, presents the cert, and the user is logged in.
>
> Notice that these steps _remove_ the user filling out forms to sign up
> for simple web sites, and filling out forms to log in. Anyone who's
> used cert-based auth at work is already familiar, the web site
> "magically" knows you. This is MUCH more user friendly.
>
> So the big magic here is the user has to click on "yes" to create a key
> and type in an e-mail once. That's it. There's no web of trust. No
> identity verification (a-la ssl). I'm talking a very SSH like system,
> but with more polish.
>
> Users would find it much more convenient and wonder why we ever used
> passwords, I think...
>
> --
> Leo Bicknell - bicknell@ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/

> 2. Pre-compromised-at-the-factory smartphones and similar. There's
> no reason why these can't be preloaded with spyware similar to CarrierIQ
> and directed to upload all newly-created private keys to a central
> collection point. This can be done, therefore it will be done, and when
> some security researcher discovers it, the usual excuses and justifications
> will be made by the designated spokesliars for the companies involved...
> which will of course keep right on doing it, albeit perhaps with more
> subterfuge.

> Problem #2 is newer, but I'm willing to bet that it will also last
> at least a decade and that it will get worse, since there are
> substantial economic incentives to make it so.

This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different.

---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org

On 06/23/2012 05:52 PM, Keith Medcalf wrote:
> Leo,
>
> This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback).

What is their leverage to extort? A web site just needs to make the
client and server end agree on a scheme, and they control both ends.
They can't force me to use their scheme any more than they can force
me to not use Basic and use their scheme instead. Keep in mind that
asymmetric keys do not imply certification, and asymmetric keys are
cheap and plentiful -- as in a modest amount of CPU time these days.

Mike

> You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.
>
> Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.
>
> If it does not use self-generated unsigned keys, it will never fly.
>
> ---
> () ascii ribbon campaign against html e-mail
> /\ www.asciiribbon.org
>
>
>> -----Original Message-----
>> From: Leo Bicknell [mailto:bicknell@ufp.org]
>> Sent: Wednesday, 20 June, 2012 15:39
>> To: nanog@nanog.org
>> Subject: Re: LinkedIn password database compromised
>>
>> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda
>> wrote:
>>> Key management: doing it right is hard and probably beyond most end users.
>> I could not be in more violent disagreement.
>>
>> First time a user goes to sign up on a web page, the browser should
>> detect it wants a key uploaded and do a simple wizard.
>>
>> - Would you like to create an online identity for logging into web
>> sites? Yes, No, Import
>>
>> User says yes, it creates a key, asking for an e-mail address to
>> identify it. Import to drag it in from some other program/format,
>> No and you can't sign up.
>>
>> Browser now says "would you like to sign up for website 'foobar.com'",
>> and if the user says "yes" it submits their public key including the
>> e-mail they are going to use to log on. User doesn't even fill out
>> a form at all.
>>
>> Web site still does the usual e-mail the user, click this link to verify
>> you want to sign up thing.
>>
>> User goes back to web site later, browser detects "auth needed" and
>> "public key foo" accepted, presents the cert, and the user is logged in.
>>
>> Notice that these steps _remove_ the user filling out forms to sign up
>> for simple web sites, and filling out forms to log in. Anyone who's
>> used cert-based auth at work is already familiar, the web site
>> "magically" knows you. This is MUCH more user friendly.
>>
>> So the big magic here is the user has to click on "yes" to create a key
>> and type in an e-mail once. That's it. There's no web of trust. No
>> identity verification (a-la ssl). I'm talking a very SSH like system,
>> but with more polish.
>>
>> Users would find it much more convenient and wonder why we ever used
>> passwords, I think...
>>
>> --
>> Leo Bicknell - bicknell@ufp.org - CCIE 3440
>> PGP keys at http://www.ufp.org/~bicknell/
>
>