Logins without logins.
openideas.ideon.co
openideas.ideon.co
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.
We'll get one in time; it just won't be as quick as we would like.
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.
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.
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.
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.
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.
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.
But I doubt this would decrease conversion rate at all.
So I would also be doubtful that it's a problem.
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 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.
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'.
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.
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'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.
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.
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.
You wouldn't use any secure websites if you truly believed this!
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!
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>".
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.
[0] http://bu.mp/
Maybe NFC/BTLE could make this feasible?
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?.
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.
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.
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.
No thanks.
Also, http://xkcd.com/927/
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.
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
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.