Logins without logins.(openideas.ideon.co)
openideas.ideon.co
Logins without logins.
http://openideas.ideon.co/2012/logins-without-logins
75 comments
Better: https://login.persona.org/
OK, so they've changed BrowserID to Mozilla Persona. How reassuring, I don't recall being notified of such a change.
They all agree on HTTP...
We'll get one in time; it just won't be as quick as we would like.
We'll get one in time; it just won't be as quick as we would like.
Mike Hanson's article, "LIFDing the web" [0] outlines a really interesting way to prototype and introduce new browser features. Highly recommended.
[0]: http://www.open-mike.org/entry/lifding-the-web
[0]: http://www.open-mike.org/entry/lifding-the-web
To play devil's advocate, smart phone based solutions exclude a huge portion of Internet-connected users. This includes users on computers without smartphones and users on smartphones without computers.
As a result, this design inherently segments out the login to only the upper tier of affluent users. Depending on your application, this is either a huge win or a huge barrier. All about your context. If this fits your target user based awesome. Eventually, though, a normal email-password solution may be needed if you grow your market out to the more general public.
Still, a promising idea. Just go in with your eyes open to the tradeoffs.
As a result, this design inherently segments out the login to only the upper tier of affluent users. Depending on your application, this is either a huge win or a huge barrier. All about your context. If this fits your target user based awesome. Eventually, though, a normal email-password solution may be needed if you grow your market out to the more general public.
Still, a promising idea. Just go in with your eyes open to the tradeoffs.
The need for an extra device to take a picture of the screen could be eliminated by simulating it with screen-capturing software.
That'd be less secure than a completely separate device with your authentication data on it, but no less secure than current-generation password managers as far as I can tell.
That'd be less secure than a completely separate device with your authentication data on it, but no less secure than current-generation password managers as far as I can tell.
At that point, exactly which of "something you know", "something you are", or "something you have" are you authenticating against? I am quite sure an attacker can get access to "a computer", somewhere, upon which he can claim to be me, at which point you will serve him a bar code which he will confirm does indeed correspond to the account he is trying to hack.
Even the whole "use a cell phone for auth" is not really a good idea. It at least sort of qualifies as "something you have", but a great deal of the identity that you "have" isn't in the physical hardware, but in the cloud and the connection the device has to the cell network, which as "something you have" goes is pretty low-grade security.
Even the whole "use a cell phone for auth" is not really a good idea. It at least sort of qualifies as "something you have", but a great deal of the identity that you "have" isn't in the physical hardware, but in the cloud and the connection the device has to the cell network, which as "something you have" goes is pretty low-grade security.
"Something you have"- the computer that you are on. You would only store your authentication information on one machine running the virtualized camera auth system, just as it would be stored on your otherwise-separate smartphone. An attacker would not just have to get access to "a computer"- they'd have to get access to the computer that can authenticate as you. This is little different from requiring an attacker to get access to the smartphone that can authenticate as you.
If you have a key on the system you are on, just use it. Your complicated system of barcodes and virtual scanners adds nothing but complication to what was already a secure system. Or the system wasn't secure, and you can't use the insecure system to validate the security of the insecure system.
You and thedufer aren't doing this right. You see one objection, then bend the system to meet it, then see another objection, then rewrite the system to meet that, then so on, never considering the whole picture. You can't do security that way. You have to do it holistically. The whole system that you come up with has to be simultaneously secure against everything, and also needs to be the best possible solution. If you're looping a design around trying to solve one problem at a time (and not necessarily all that well) you've already lost.
You and thedufer aren't doing this right. You see one objection, then bend the system to meet it, then see another objection, then rewrite the system to meet that, then so on, never considering the whole picture. You can't do security that way. You have to do it holistically. The whole system that you come up with has to be simultaneously secure against everything, and also needs to be the best possible solution. If you're looping a design around trying to solve one problem at a time (and not necessarily all that well) you've already lost.
Its "something you have" - your private key. Someone would have actually get access to files on your device (or the physical device itself) to beat the system.
Rube Goldberg would be proud!
We implemented and used this approach exactly for login and a few other things at Clover. People we observed using it were mostly confused. We switched to "enter your phone number and we'll text you a on-time code", where the phone number became the unique identifier for the user. Worked much better.
Unless your users have unlimited text message plans, pay-per-login seems like an unreasonable burden. How does Clover deal with users who have limited text messages?
Users with the Clover app installed gets a push notification instead of a text message. Tapping it takes you to a screen which asks if you want to log in to the site. Tapping yes logs you in (the site long-polls in this case)
Clover sends a text with a code to the visitor not the other way around.
In the US, that still counts against your limits.
But I doubt this would decrease conversion rate at all.
But I doubt this would decrease conversion rate at all.
I would -suspect- that US users are already desensitised to that and have suitable limits set up, and I'm not aware of anywhere else that happens.
So I would also be doubtful that it's a problem.
So I would also be doubtful that it's a problem.
Canada too, and it is an issue. Most people don't have suitable limits set up, nor are they desensitized to it. They just do what they can to avoid unsolicited texts. Not to mention SMS-as-authentication blows for a number of other reasons, not the least of which is you have to be connected to a cell network to receive them. Not WiFi, but the actual cell network.
You have a deactivated phone or phone out of the network you would like to use to authenticate? Too bad, not only do you need a phone that can receive an SMS, you also need an active phone plan.
Unfortunately the only way to do this well is to cover all your bases. A great example is Blizzard, who offers an authenticator app for your phone, an SMS program for those who don't have smartphones, and a custom built authenticator device for everyone else.
It's expensive, but anything less will cut out a large portion of potential users. Hence why we still just use a username and password. Much like democracy is to politics, user/pass is the worst form of authentication except for all the others.
You have a deactivated phone or phone out of the network you would like to use to authenticate? Too bad, not only do you need a phone that can receive an SMS, you also need an active phone plan.
Unfortunately the only way to do this well is to cover all your bases. A great example is Blizzard, who offers an authenticator app for your phone, an SMS program for those who don't have smartphones, and a custom built authenticator device for everyone else.
It's expensive, but anything less will cut out a large portion of potential users. Hence why we still just use a username and password. Much like democracy is to politics, user/pass is the worst form of authentication except for all the others.
right i did not know that, thanks for clearing that up.
Carriers typically charge rates for both sending and receiving text messages.
I think that might just be in the USA, or at least we don't have this in the UK. It seems to me quite cheeky to charge the recipient also; you wouldn't charge someone to receive a letter.
Especially since you have no means to refuse the delivery of a text message other than telling your operator to stop delivering messages for you entirely. I have never really understood the rationale behind the US model of charging for received texts.
> I have never really understood the rationale behind the US model of charging for received texts.
Vendor charges customer because they can and customer is powerless. What about that don't you understand?
More seriously - I think it traces back to the fact that in the US you pay airtime for both incoming and outgoing calls, including "free" (1-800) numbers; The reason for this was that originally:
a) mobile calls were really expensive b) there were no number range or pattern allocated for mobile phone numbers (thus, when you call a number, you generally don't know if it is landline, mobile, virtual or which operator it is (or ever was)).
So caller-to-mobile pays the same (they don't know they are calling mobile), and recipient-on-mobile pays the rest. And since everyone was used to that, the operators extended that to text as well.
Vendor charges customer because they can and customer is powerless. What about that don't you understand?
More seriously - I think it traces back to the fact that in the US you pay airtime for both incoming and outgoing calls, including "free" (1-800) numbers; The reason for this was that originally:
a) mobile calls were really expensive b) there were no number range or pattern allocated for mobile phone numbers (thus, when you call a number, you generally don't know if it is landline, mobile, virtual or which operator it is (or ever was)).
So caller-to-mobile pays the same (they don't know they are calling mobile), and recipient-on-mobile pays the rest. And since everyone was used to that, the operators extended that to text as well.
Yes, this is in the USA. And yes, it is quite cheeky. It is exactly like charging someone to receive a letter, whether they want it or not, and do so based entirely on the fact that it made it to their mailbox. It's ridiculous.
The U.S. mobile market really needs a shake-up if you've got to pay for what you receive even if you haven't asked for it.
Yes, it really rubs salt in the wound when you get a spam text and then realize that cost me money.
Indeed it does. My understanding of the standing of mobile carriers in the legal system leaves me to think this shake-up is not so easily accomplished. From texting to tethering, we're charged to use every feature our phones include if the carriers can delimit some kind of usage of it (even though the actual usage is not different from, say, merely using our data plans).
UK/France/Spain and most european countries have got good deals. Under 40$ a month for all unlimited, and many MVNO offer 4 cent/minute or text and a fixed ~20cent per call rate, pay as you go (data is very cheap, too). Inbound texts or calls are of course free (except when abroad).
Roaming is currently around 9ct/mb in the european union if you manage to get the right deal, or by law 80ct/mb which isn't _that_ good.
Roaming is currently around 9ct/mb in the european union if you manage to get the right deal, or by law 80ct/mb which isn't _that_ good.
[deleted]
The barrier to password-less logins is not technology. It's user adoption.
You can create all the protocols and tech stacks that implement public-key crypto, but getting everyone to use it over passwords is the problem - not the technology.
A browser-based solution has the most chance at being adopted, so you should focus your efforts on supporting Mozilla Persona and other browser-based logins. We'll start to get there as soon as people realize the solution has to be browser-based.
You can create all the protocols and tech stacks that implement public-key crypto, but getting everyone to use it over passwords is the problem - not the technology.
A browser-based solution has the most chance at being adopted, so you should focus your efforts on supporting Mozilla Persona and other browser-based logins. We'll start to get there as soon as people realize the solution has to be browser-based.
[deleted]
[deleted]
Google already did this (in part), it was called 'Sesame' and allowed you to log in to your Google account (on a desktop browser) by scanning a on-screen QR code with your phone.
However it was apparently just an experiment, and unfortunately has been shut down.
For a bit more info: http://www.webpronews.com/open-sesame-googles-newest-securit...
Or just search for 'Google Sesame'.
However it was apparently just an experiment, and unfortunately has been shut down.
For a bit more info: http://www.webpronews.com/open-sesame-googles-newest-securit...
Or just search for 'Google Sesame'.
I just noticed that it's no longer available after I wanted to post a link to it here. Does anyone know what happened to it?
The URL pointed to this text after it was shut down:
Hi there – thanks for your interest in our phone-based login experiment. While we have concluded this particular experiment, we constantly experiment with new and more secure authentication mechanisms.
Stay tuned for something even better!
Dirk Balfanz, Google Security Team.
Hi there – thanks for your interest in our phone-based login experiment. While we have concluded this particular experiment, we constantly experiment with new and more secure authentication mechanisms.
Stay tuned for something even better!
Dirk Balfanz, Google Security Team.
I think this idea is something that many people are dreaming/afraid of. I see myself among the former. Just like using a finger-print, an iris scan, face-recognition, the ability to readily identify users is something I dream of. It would reduce the friction in many cases.
Just imagine you don't have to carry around all your loyalty cards, the tailor at your store immediately knows your size, you fill out a standard form very easily.
It's one of these things IMO that would create much joy and convenience in the world. People however rightfully criticize the possibility of abuse here. Indeed, having ready access to identity is something not easily to digest to many that love the anonymity of the Internet. Many open initiatives like OpenID have not seen the coverage needed to make such a system happen on a broad basis, Facebook Connect is probably the closest solution. Mozilla BrowserID is the next ambitious project that tries to tackle this space, however I question whether one could ever design an identity system, or whether it just "happens" like Facebook and Twitter showed.
Just imagine you don't have to carry around all your loyalty cards, the tailor at your store immediately knows your size, you fill out a standard form very easily.
It's one of these things IMO that would create much joy and convenience in the world. People however rightfully criticize the possibility of abuse here. Indeed, having ready access to identity is something not easily to digest to many that love the anonymity of the Internet. Many open initiatives like OpenID have not seen the coverage needed to make such a system happen on a broad basis, Facebook Connect is probably the closest solution. Mozilla BrowserID is the next ambitious project that tries to tackle this space, however I question whether one could ever design an identity system, or whether it just "happens" like Facebook and Twitter showed.
> I question whether one could ever design an identity system, or whether it just "happens"
I'm with you. We're trying to get over most of that in Persona by using email address as identifiers, which most people already view as proxies for identities (home, school, work, etc), but time will tell whether or not that belief pans out.
On the other hand, designing authentication systems seems completely tractable. To that end, Mozilla already relies heavily on Persona, so it will continue to exist and work for authentication even if external traction is slow.
I'm with you. We're trying to get over most of that in Persona by using email address as identifiers, which most people already view as proxies for identities (home, school, work, etc), but time will tell whether or not that belief pans out.
On the other hand, designing authentication systems seems completely tractable. To that end, Mozilla already relies heavily on Persona, so it will continue to exist and work for authentication even if external traction is slow.
I know Persona allows a user to attach multiple email addresses to their Persona identity, but can a user log into a third party service with any of those email addresses and get their same third party account? Alternately, can a user create separate accounts on a third party service that are associated with different email addresses of the single Persona identify?
Persona tries to support the notion of one address == one identity, so the only information you transmit to a site when logging in is "my email address is [email protected], and here's the proof."
To help people manage identities, the Persona UI does allow you to pre-load a bunch of your addresses, but the connections there are never revealed to outside parties. In the future, that information will be managed completely locally in your browser if it has native support for Persona.
To help people manage identities, the Persona UI does allow you to pre-load a bunch of your addresses, but the connections there are never revealed to outside parties. In the future, that information will be managed completely locally in your browser if it has native support for Persona.
You see articles like this quite regularly and they always don't quite solve the problem. Most solutions rely on computers keeping a secret, usually a hash on the server, or a private key in the browser.
Due to the possibility of poor client side security the private key approach is a none-starter as malware could get hold of it. You could password protect the key, but in that case you would need to prompt the user regularly to avoid the key being held in memory. In that case you might as well just hash the password, and generate session cookies.
Due to the possibility of poor server side security the hashed password option is also problematic. We have to trust that the website will use the right algorithm.
Any solution must avoid the need for computers to keep secrets. That is difficult.
Due to the possibility of poor client side security the private key approach is a none-starter as malware could get hold of it. You could password protect the key, but in that case you would need to prompt the user regularly to avoid the key being held in memory. In that case you might as well just hash the password, and generate session cookies.
Due to the possibility of poor server side security the hashed password option is also problematic. We have to trust that the website will use the right algorithm.
Any solution must avoid the need for computers to keep secrets. That is difficult.
A valid point but we all know there is and can never be any true security as long as the programmers of systems are human. This approach is definitely useful but not always. I wouldn't want my email account protected by it but we all have some accounts where convenience is more valuable than security and others where security is preferable to convenience. Since we'll never have a perfect system the trick is to know when to use each technique.
> poor server side security
You wouldn't use any secure websites if you truly believed this!
You wouldn't use any secure websites if you truly believed this!
Why are we inventing new authentication methods? Client certificates would be perfect, but browsers must provide an automatic way to generate key pairs.
How would one authenticate from two different devices? Moving certificates around has plenty of issues.
DON'T MOVE CERTIFICATES.
You need another way of authenticating someone as well, whether it by SMS, biometrics or passwords.
Client-side certificates can be used as one-part of two-factor authentication or on their own depending on the level of security needed.
Oh, and btw, DON'T MOVE CERTIFICATES!
You need another way of authenticating someone as well, whether it by SMS, biometrics or passwords.
Client-side certificates can be used as one-part of two-factor authentication or on their own depending on the level of security needed.
Oh, and btw, DON'T MOVE CERTIFICATES!
You could have the certificate follow the device, rather than the user.
If the certificate is device-bound, then how do you authenticate from another device?
Well, duh. I don't like all the "login optimization" work that's been done lately. A user name and a password have always served me well. On non-sensitive sites cookies have enabled me to automatically log in whilst the cookies are stored on the computer which is - of course - protected against outside abuse.
I know people are seeing this whole login thing as a UX issue but I don't think so. All solutions so far are just exchanging the user/pass combination stored in your head with identifying some device like a smartphone.
I won't go away from the classic setup until we get key based login using biometric data as a passphrase. Signing up automatically transfers your public key and login is reduced to a "please swipe your finger over <insert input device here>".
I know people are seeing this whole login thing as a UX issue but I don't think so. All solutions so far are just exchanging the user/pass combination stored in your head with identifying some device like a smartphone.
I won't go away from the classic setup until we get key based login using biometric data as a passphrase. Signing up automatically transfers your public key and login is reduced to a "please swipe your finger over <insert input device here>".
I really like the idea but I wonder if the additional effort required will limit adoption. It's much easier for me to tap my fingers on a keyboard than it is to get out my phone, unlock it, open an app, and focus it on the computer screen. Yeah I know I sound really lazy, but I think this makes a difference in general adoption.
This reminds me of using NFC for payment. Swiping a credit card is still a lot easier than getting out my phone, opening an app, holding it up to merchant's NFC scanner, and clicking to confirm.
Both are awesome ideas because they have other benefits (not having to remember a password for this, not having to carry around a credit card for NFC), but the UX needs to be tweaked so that the effort is <= current methods.
This reminds me of using NFC for payment. Swiping a credit card is still a lot easier than getting out my phone, opening an app, holding it up to merchant's NFC scanner, and clicking to confirm.
Both are awesome ideas because they have other benefits (not having to remember a password for this, not having to carry around a credit card for NFC), but the UX needs to be tweaked so that the effort is <= current methods.
Bump (the iPhone app startup) has a photo uploader where you can bump your phone against the keyboard.[0] I think that could work here.
[0] http://bu.mp/
[0] http://bu.mp/
The greatest issue with this is that a phone + QR reader is not always-on. You have to 1) turn on 2) unlock 3) type phone's password 4) open app 5) then read code. At this point you could already have typed your username+password a dozen times.
Maybe NFC/BTLE could make this feasible?
Maybe NFC/BTLE could make this feasible?
WIP at https://github.com/tianshuo/mobile-2d-barcode-login Note that this kind of login is already live and default for Chinese popular online chat - wechat(微信). The working url is wx.qq.com and you will need to login using the Wechat mobile client. The feature is to bind a computer keyboard with the mobile phone so typing is a whole lot easier. The strength of this idea is not logging in, but online payment, remote controlling of TVs, interaction using mobile phone with outdoor ads, binding keyboards to mobile phones, etc.
I had a similar idea, for an "auth box" that would could be hosted by a third party or ran at home on the end of a consumer connection.
Whenver you log in or sign up to a site, a request is made to this device which can authenticate the user and return the result to the site.
A big drawback to this scheme is that stealing the box could become profitable. It would also require a more mature network than we have now.
Passwords are crap and key management is hard, who really wants to do 2 factor auth every time they want to log into gmail?.
Whenver you log in or sign up to a site, a request is made to this device which can authenticate the user and return the result to the site.
A big drawback to this scheme is that stealing the box could become profitable. It would also require a more mature network than we have now.
Passwords are crap and key management is hard, who really wants to do 2 factor auth every time they want to log into gmail?.
An existing implementation of that are Smart Cards. They contain a Public-Private key pair, and they will actually perform the crypto themselves (when plugged into a reader), so the private key never leaves the card.
Here in Portugal our new ID cards (Citizen Card) are already smart cards, so we can log in to e.g. our IRS using it, at least with browsers which support PKCS#11, like Firefox.
Here in Portugal our new ID cards (Citizen Card) are already smart cards, so we can log in to e.g. our IRS using it, at least with browsers which support PKCS#11, like Firefox.
What happens if you lose the ID card?.
You need to ask for a new one, with its own key pair (and the old one will be revoked).
As for a possible attacker that found your card:
The card has a PIN and locks out after three failed tries. After locking out, you can only unlock it by going to an IRS office where they authenticate you using photo/fingerprint/etc and then using their machine and inserting an unblocking code that only you have. If you don't know the code, you need to ask for a new card.
As for a possible attacker that found your card:
The card has a PIN and locks out after three failed tries. After locking out, you can only unlock it by going to an IRS office where they authenticate you using photo/fingerprint/etc and then using their machine and inserting an unblocking code that only you have. If you don't know the code, you need to ask for a new card.
Can't do this for at least two reasons.
1. If your phone is dead you can't login. 2 factor auth can authorize a login such that secondary authentication via phone is not always needed, reducing this problem significantly.
2. It invites those wanting to break into your account to attempt to auth so much that you either get a ton of texts or it stops trying to text you at some point, effectively keeping you from being able to login.
It is a nice idea, but it doesn't work.
1. If your phone is dead you can't login. 2 factor auth can authorize a login such that secondary authentication via phone is not always needed, reducing this problem significantly.
2. It invites those wanting to break into your account to attempt to auth so much that you either get a ton of texts or it stops trying to text you at some point, effectively keeping you from being able to login.
It is a nice idea, but it doesn't work.
"You visit a site on your computer and point your camera phone at the barcode next to the login form."
No thanks.
No thanks.
This authentication method is implemented pretty well by https://nomopass.com/ (SaaS) and https://tiqr.org/ (Open Source)
This should be implemented on a strict as-needed basis, trying to come up with a solution when there's no immediate problem makes no sense to me.
Also, http://xkcd.com/927/
Also, http://xkcd.com/927/
Passwords are a glaring problem that really need a solution. Most people use the same password over and over, make their password too simple, don't remember their password, hate password requirements, etc etc. Passwords are a huge pain in the butt and a common security achilles heal. I think the worst is when I go to a site I rarely visit, so thus forgot my password for that site, and so try a handful of my "standard" passwords and all fail because this particular site requires at least 3 symbols in the password.
My personal solution has been to use 1Password. And it does help quite a bit. But I also got a license for my fiancee and she hates it. She doesn't get it at all.
If someone can truly and effectively solve the password problem, then they have my money.
My personal solution has been to use 1Password. And it does help quite a bit. But I also got a license for my fiancee and she hates it. She doesn't get it at all.
If someone can truly and effectively solve the password problem, then they have my money.
> If someone can truly and effectively solve the password problem, then they have my money.
Mozilla is working on one take on this (Persona), but it's a long, slow slog to develop a good API and get traction with developers, identity providers, and browsers. We'll gladly take your pull requests over your money :) https://github.com/mozilla/browserid
Mozilla is working on one take on this (Persona), but it's a long, slow slog to develop a good API and get traction with developers, identity providers, and browsers. We'll gladly take your pull requests over your money :) https://github.com/mozilla/browserid
They have your money as a developer or as a user?
It would be nice if every browser installation came with a unique fingerprint, like a public ssh key that you could give to sites as a form of two-factor authentication.
I've not dug into how its implemented, but logging into airdroid via the qr code is a pleasure, and on the surface similar to what's being described here.
So in essence your keychain is in your phone but your trick allows you to use it to log in on other devices?
The solution is already available at https://rublon.com
The signup process was interesting. Download the app, enter some personal info, scan the QR code on their site. Cool.
After logging in I got bogged down in trying to understand their stupid point system. Invite blah,blah,blah and get so many points so you can 'unlock' a website to log into. Huh?
Worse, it kept composing a self promoting tweet each time I logged into Twitter which required me to click on a small x to close it. Lame.
Great idea. Decent start at getting me to sign up. Not so great at converting me to use it full time.
After logging in I got bogged down in trying to understand their stupid point system. Invite blah,blah,blah and get so many points so you can 'unlock' a website to log into. Huh?
Worse, it kept composing a self promoting tweet each time I logged into Twitter which required me to click on a small x to close it. Lame.
Great idea. Decent start at getting me to sign up. Not so great at converting me to use it full time.
Hi Kord! Thank you for your interest in Rublon. We have removed the self promoting tweet window from appearing (it would appear 10 times and then go away). This also concerns the sharing windows that appear after logging in to a Google service or Facebook.
Yeah, they seem to strive for quick user base growth. Probably to show nice hockey stick on Dublin Web Summit ;) But I agree that it could be done in a more friendly way.
What happens if you lose your phone?
Even worse, how am I going to explain this login system to my parents, or even my non-technical friends?
It's like OpenID login a while back. "Enter a URL to log in" was wasn't quite as easy to understand as developers thought.
This needs to be baked-in to the browser. Unfortunately, because we have loads of different browser vendors, I don't think we'll ever see a decent solution.