LinkedIn password database compromised

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

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 :slight_smile: (oh and the per-brand apps that exist as well.. *sigh*).

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

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

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

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,

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.

Yes, but you're securing the account to the *client PC* there, not to
the human being; making that Portable Enough for people who use and
borrow multiple machines is nontrivial.

Cheers,
-- jra

Guess we all need implants deep in less-than-easily-operable areas to
bind us to a digitally-accessible identity. This would make for an
interesting set of user-based trust-anchoring paradigms, at least.

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

There should be a way to authenticate the same user differently depending on what device they're using and tie it all together in a central place; of course if that central place gets compromised it would be horrible..

Still, I think it would help if you use the same password on every site if your browser could encrypt or hash the password before it sends it to the website.

That way at least if the website doesn't properly store the passwords they'll be encrypted anyway =)

-Drew

Credential revocation would suddenly get more interesting. And I'm
sure there's a divorce lawyer or 3 out there who will get some creatively
evil ideas...

who would mediate/verify/validate the trust transactions, though...
thats the hard part.

Or a wizard in your browser/OS/whatever could prompt you to put in a
'special' USB key and write the identity data there, making it
portable. Or like my ssh keys, I have one on my home computer, one on
my work computer, one on my USB drive, etc... If I lose my USB key, I
can revoke the SSH key and still have access from my home computer.

And I'm sure someone would come up with the 'solution' where they
store the keys for you, but only you have the passphrase...ala
lastpass.

-A

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.

>> From: "Leo Bicknell" <bicknell@ufp.org>
> Yes, but you're securing the account to the *client PC* there, not

to

> the human being; making that Portable Enough for people who use and
> borrow multiple machines is nontrivial.

Or a wizard in your browser/OS/whatever could prompt you to put in a
'special' USB key and write the identity data there, making it
portable. Or like my ssh keys, I have one on my home computer, one on
my work computer, one on my USB drive, etc... If I lose my USB key, I
can revoke the SSH key and still have access from my home computer.

And I'm sure someone would come up with the 'solution' where they
store the keys for you, but only you have the passphrase...ala
lastpass.

-A

As far as apps go, loads of them use OAuth and have a browser step in
their setup.

So this adds precisely one step to the smartphone sync/activation
process - downloading the key pair from your PC (or if you don't have a
PC, generating one).

that covers vendor A and most vendor G devices. "what about the feature
phones?" - not an issue, no apps to speak of, noOp(). "what about
[person we want to be superior to who is always female for some
reason]?" - well, they all seem to have iPhones now, so *somebody's*
obviously handholding them through the activation procedure.

obviously vendor A would be tempted to "sync this to iCloud"...but
anyway, I repeat the call for a W3C password manager API. SSH would be
better, but a lot of the intents, actions etc are the same.

(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

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.

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.

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.