Mailing List Archive

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