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. 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-lin... 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 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-lin...
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
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
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
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
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/
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.
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
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 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 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 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
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: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.
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 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.
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 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
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
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
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 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 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
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
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
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
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
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 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
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:
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.
-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:
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
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/
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 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 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/
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.
----- 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
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 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, 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/
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/
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.
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.
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.
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
----- Original Message -----
From: "Leo Bicknell" <bicknell@ufp.org>
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.
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 -- 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
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. On Wed, Jun 20, 2012 at 7:26 PM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Leo Bicknell" <bicknell@ufp.org>
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.
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 -- 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
-- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
On Wed, 20 Jun 2012 19:31:40 -0400, Kyle Creyts said:
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.
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. On Wed, Jun 20, 2012 at 7:46 PM, <valdis.kletnieks@vt.edu> wrote:
On Wed, 20 Jun 2012 19:31:40 -0400, Kyle Creyts said:
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.
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...
-- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
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 -----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Wednesday, June 20, 2012 7:27 PM To: NANOG Subject: How to fix authentication (was LinkedIn) ----- Original Message -----
From: "Leo Bicknell" <bicknell@ufp.org>
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.
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 -- 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 Wed, Jun 20, 2012 at 4:26 PM, Jay Ashworth <jra@baylink.com> wrote:
From: "Leo Bicknell" <bicknell@ufp.org> Yes, but you're securing the account to the *client PC* there, not to
----- Original Message ----- 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
On Thursday 21 Jun 2012 04:16:22 Aaron C. de Bruyn wrote:
On Wed, Jun 20, 2012 at 4:26 PM, Jay Ashworth <jra@baylink.com> wrote:
From: "Leo Bicknell" <bicknell@ufp.org> Yes, but you're securing the account to the *client PC* there, not to
----- Original Message ----- 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.
I still believe that the final solution should be some sort of two factor, something you know (i.e. a passphrase) and something you have (i.e. key / token / something which has been verified). Up till recently RSA was a good platform, but was not very effective for smartphone use. If there is no two factor methodology, which changes, being deployed then man in the middle will still work. So will compromising systems and even compromised servers. What if, and I am brainstorming here, what if there was a hardware device which plugged in via USB. It was programed (i.e verified) in person, such as a key signing party. The serial number of the hardware device was all that is stored in the "verified" database with say a generic email created at that time with the domain of the verifying group. For example, your serial number is 12345, so the email would be generated as 12345@foo.com. This device is hardware encrypted, and stores your password (priv key) in a one way encryption. Then when you go to a website they can ask if you are verified by foo.com. The users selects yes, then the website pulls the public key at that time. Then asks you for your pin, password, pass-phrase, whatever, and at that time the users clicks a pretty eye candy button in the browser which looks for the USB device with the serial number from the database. Once found it then starts a secure tunnel such as VPN (can be anything just using it as a methodology), and no data is transmitted until the tunnel and DNSSEC has been established. Once established you can surf the site as normal. All these connections and tunnels being setup by the browser using two factor authentication. What you know being the public key with verification from foo.com, which was also verified in person with the foo.com email. What you have which is the hardware token, again serial number verified and encrypted. Combined to give you access and the browser does most the work. Couple things I see as issues off the bat are: Cost of USB device Security controls over manufacturing In person verification, will require many locations and volunteers - Still involves the Human Factor of error or misuse Education of the users who are techie Browser security Browser plugin & functionality Change time limit and process (i.e. must be regenerated after x months) Complete Revocation of the token and notification to all websites using foo.com verification Again I am just throwing an idea out there to see what others think, maybe pieces of everyone's idea may result in an effective solution :-) Along the lines of iCloud, or any cloud based service. I am by no means a fan of cloud services in any shape or form. The risks are WAY to great to out weigh the benefits. If someone has a good argument for "secure" cloud services I am open to hearing those, but that's an entirely different email thread :-) - Robert Miller (arch3angel) On 6/21/12 8:23 AM, Alexander Harrowell wrote:
On Thursday 21 Jun 2012 04:16:22 Aaron C. de Bruyn wrote:
From: "Leo Bicknell" <bicknell@ufp.org> Yes, but you're securing the account to the *client PC* there, not to
----- Original Message ----- 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
On Wed, Jun 20, 2012 at 4:26 PM, Jay Ashworth <jra@baylink.com> wrote: 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 Jun 21, 2012, at 12:15 PM, AP NANOG wrote:
What if, and I am brainstorming here, what if there was a hardware device which plugged in via USB. It was programed (i.e verified) in person, such as a key signing party. The serial number of the hardware device was all that is stored in the "verified" database with say a generic email created at that time with the domain of the verifying group. For example, your serial number is 12345, so the email would be generated as 12345@foo.com. This device is hardware encrypted, and stores your password (priv key) in a one way encryption. Then when you go to a website they can ask if you are verified by foo.com. The users selects yes, then the website pulls the public key at that time. Then asks you for your pin, password, pass-phrase, whatever, and at that time the users clicks a pretty eye candy button in the browser which looks for the USB device with the serial number from the database. Once found it then starts a secure tunnel such as VPN (can be anything just using it as a methodology), and no data is transmitted until the tunnel and DNSSEC has been established. Once established you can surf the site as normal. All these connections and tunnels being setup by the browser using two factor authentication. What you know being the public key with verification from foo.com, which was also verified in person with the foo.com email. What you have which is the hardware token, again serial number verified and encrypted. Combined to give you access and the browser does most the work.
That's basically the Yubikey. It uses a shared key, but since you're relying on a trusted third party anyway it's fine if they keep the key. When a Yubikey is manufactured the factory default key is stored in Yubico's public auth service database along with the serial number. Anyone on the internet can then ask the service "was this OTP in fact generated by serial number X?" If you don't trust Yubico's service you can program your own key into it and run your own verification service. The mechanics are different but I think the trust model is the same -- users get USB tokens identified only by serial number, and a third party service vouches that a signature/OTP was generated by a particular serial number. -Ben
On Thu, Jun 21, 2012 at 10:48 PM, Randy Bush <randy@psg.com> wrote:
That's basically the Yubikey. It uses a shared key, but since you're relying on a trusted third party anyway
there are no trustable third parties
note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another' -chris
I used the example I did based on YubiKey, I own one and use it on a
regular basis. The real issue I am trying to make is the fact that even
in the scenario I placed forward it still requires trust. Trust of a
person or trust of a company. This reminds me of a quote:
Only two things are infinite, the universe and
human stupidity, and I'm not sure about the former.
- Albert Einstein
By no means am I saying any of us, or the majority of the world is
stupid or uneducated. However, the inherent nature behind trust is just
that, relying on some sort of other party is the weak link here. It
only takes a single person who has a bad day, or just wants to slack off
for that day, to create a vulnerability in any password, key,
encryption, or authentication process hundreds if not thousands of
people work so hard to solve.
While I used YubiKey as my original example, and use it on a regular
basis, it still has its downfalls. It cannot be used with Active Sync,
so ultimately you can not use it for your Active Directory log in
because of a small thing called Exchange. There have been other areas
were YubiKey has failed but not by it's design, but by the design of the
application itself.
How can any of our solutions over come the human factor?
--
- Robert Miller
(arch3angel)
On 6/21/12 10:53 PM, Christopher Morrow wrote:
> On Thu, Jun 21, 2012 at 10:48 PM, Randy Bush <randy@psg.com> wrote:
>>> That's basically the Yubikey. It uses a shared key, but since you're
>>> relying on a trusted third party anyway
>> there are no trustable third parties
> note that yubico has models of auth that include:
> 1) using a third party
> 2) making your own party
> 3) HOTP on token
> 4) NFC
>
> they are a good company, trying to do the right thing(s)... They also
> don't necessarily want you to be stuck in the 'get your answer from
> another'
>
> -chris
In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush wrote:
there are no trustable third parties
With a lot of transactions the second party isn't trustable, and sometimes the first party isn't as well. :) In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher Morrow wrote:
note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC
they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another'
Requirements of hardware or a third party are fine for the corporate world, or sites that make enough money or have enough risk to invest in security, like a bank. Requiring hardware for a site like Facebook or Twitter is right out. Does not scale, can't ship to the guy in Pakistan or McMurdo who wants to sign up. Trusting a third party becomes too expensive, and too big of a business risk. There are levels of security here. I don't expect Facebook to take the same security steps as my bank to move my money around. One size does not fit all. Making it so a hacker can't get 10 million login credentials at once is a quantum leap forward even if doing so doesn't improve security in any other way. The perfect is the enemy of the good. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
I would suggest that multiple models be pursued (since each appears to have a champion) and that the market/drafting process will resolve the issue of which is better (which is okay by me: widespread adoption of any of the proposed models would advance the state of the norm; progress beats the snot out of stagnation in my book) My earlier replies were reprehensible. This is not a thread that should just be laughed off. Real progress may be occurring here, and at the least, good knowledge and discussion is accumulating in a way which may serve as a resource for the curious or concerned. On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell@ufp.org> wrote:
In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush wrote:
there are no trustable third parties
With a lot of transactions the second party isn't trustable, and sometimes the first party isn't as well. :)
In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher Morrow wrote:
note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC
they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another'
Requirements of hardware or a third party are fine for the corporate world, or sites that make enough money or have enough risk to invest in security, like a bank.
Requiring hardware for a site like Facebook or Twitter is right out. Does not scale, can't ship to the guy in Pakistan or McMurdo who wants to sign up. Trusting a third party becomes too expensive, and too big of a business risk.
There are levels of security here. I don't expect Facebook to take the same security steps as my bank to move my money around. One size does not fit all. Making it so a hacker can't get 10 million login credentials at once is a quantum leap forward even if doing so doesn't improve security in any other way.
The perfect is the enemy of the good.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Kyle, I may be mistaken here, but I don't believe anyone is truly laughing the matter off. There may have been some remarks about second or third parties, but the fact does remain these are the areas which current concerns still lay. -- Robert Miller (arch3angel) On 6/24/12 1:02 AM, Kyle Creyts wrote:
I would suggest that multiple models be pursued (since each appears to have a champion) and that the market/drafting process will resolve the issue of which is better (which is okay by me: widespread adoption of any of the proposed models would advance the state of the norm; progress beats the snot out of stagnation in my book)
My earlier replies were reprehensible. This is not a thread that should just be laughed off. Real progress may be occurring here, and at the least, good knowledge and discussion is accumulating in a way which may serve as a resource for the curious or concerned. On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell@ufp.org> wrote:
In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush wrote:
there are no trustable third parties With a lot of transactions the second party isn't trustable, and sometimes the first party isn't as well. :)
In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher Morrow wrote:
note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC
they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another' Requirements of hardware or a third party are fine for the corporate world, or sites that make enough money or have enough risk to invest in security, like a bank.
Requiring hardware for a site like Facebook or Twitter is right out. Does not scale, can't ship to the guy in Pakistan or McMurdo who wants to sign up. Trusting a third party becomes too expensive, and too big of a business risk.
There are levels of security here. I don't expect Facebook to take the same security steps as my bank to move my money around. One size does not fit all. Making it so a hacker can't get 10 million login credentials at once is a quantum leap forward even if doing so doesn't improve security in any other way.
The perfect is the enemy of the good.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
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
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
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
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 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-lin...
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.
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
participants (43)
-
-Hammer- -
Aaron C. de Bruyn -
Alexander Harrowell -
AP NANOG -
Ben Jencks -
Bruch, Mark -
Christopher Morrow -
Dave Hart -
David Walker -
Drew Weaver -
Elmar K. Bins -
Grant Ridder -
James Snow -
Jared Mauch -
Jay Ashworth -
Jay Mitchell -
JC Dill -
jeff murphy -
Jimmy Hess -
Joe Maimon -
Keith Medcalf -
Kyle Creyts -
Leo Bicknell -
Leo Vegoda -
Luke S. Crawford -
Lynda -
Mark Andrews -
Marshall Eubanks -
Matthew Huff -
Matthew Kaufman -
Michael Hallgren -
Michael Thomas -
Owen DeLong -
Pedro -
Peter Kristolaitis -
Phil Pishioneri -
Randy Bush -
Rich Kulawiec -
Robert Bonomi -
Sean Harlow -
Tei -
Tony Finch -
valdis.kletnieks＠vt.edu