Logins are Dead, and Mobile Killed Them
github.com
github.com
http://developer.android.com/reference/android/accounts/Acco...
iOS drives me nuts. There was an old joke dialog years ago "Windows has detected that you r mouse moved. You must reboot for this change to take effect." The contemporary version seems to be "iOS has detected you want to do something. You must enter a password (yet again) for this to happen." I can't understand why people are ok with this - your password should be long and hard to type and hence virtually impossible to enter on a mobile device.
You can always tell the iOS apps that were ported to Android because they have their own UI for asking for your account information instead of using the system. They also almost universally believe you only have one of a kind of account - eg only one Google account. Who doesn't have multiple ones these days (school, work, personal etc)?
That said, it would be nice to have the option of telling the app to cache your credentials.
A short appstore PIN could solve this much more easily.
Now, an SD card with a certificate plus face recognition might be ok ;-)
But for biometrics, keep in mind that biometric systems are currently seen as the most subject to false positives of any authentication system out there with the possible exception of improperly maintained and insufficiently strong passwords.
If I had a child I'd want to be able to let them use my phone but only in a special mode that allowed access to a limited number of whitelisted websites & apps.
http://www.schneier.com/blog/archives/2012/07/all-or-nothing... http://cups.cs.cmu.edu/soups/2012/proceedings/a2_Hayashi.pdf
But: yes.
I'd like my phone to offer a few different "shells" of access:
- Emergency calls.
- "Share" or "play" mode. Selected photos or apps.
- "Mobile" -- ready access to stuff I need, but not distractions (the "Car Panel" on some Android phones is somewhat like this, but I'd appreciate if it didn't encourage use while driving).
- "Full" complete and potentially immersive access.
The iPad browser is a trainwreck in this regard. Not only doesn't it support LastPass or 1Password. It also utterly fails to remember passwords that were painfully entered manually.
For most sites it simply doesn't recognize the login at all. On some sites it works intermittently, often forgetting the password for no reason or the auto-fill not working reliably.
And don't get me started on HTTP-Auth. You can save those sites (by making a bookmark) but you get a phishing warning every single time you access it.
I have pretty much abandoned the iPad for browsing for this reason. The only time I fire it up is to lookup a movie on rotten tomatoes.
I'm still bitter this device was pitched to me as "the internet in your hands". It's not up to the task. Not even close.
(I agree that the default behavior sucks)
The vast majority of Google account holders only have one account, you and the average HN user are atypical.
as google apps for business and schools becomes more and more popular, this becomes more and more wrong. Tons of non-technical people have a personal gmail account and a school/work one.
I love this article about an ecommerce site and requiring people to register: http://www.uie.com/articles/three_hund_million_button/
Note one statistic: Later, we did an analysis of the retailer's database, only to discover 45% of all customers had multiple registrations in the system, some as many as 10.
That puts the order of magnitude of people having more than one account around half. That of course doesn't mean that people have multiple Google accounts, just multiple accounts but Google is becoming increasingly pervasive being the email provider for companies, universities, organisations etc.
Its purpose is to allow the system-wide SyncManager to manage syncing data to/from a web service in the background. But if your goal is just to store user credentials somewhere, it's not necessarily the right place to do so, which is why I imagine some apps choose not to use it.
As an example the Github app that came out the other did things right and installs itself with AccountManager. That means any app can now authenticate against Github without needing its own code.
I will admit that it isn't trivial to add your own stuff to AccountManager, but the important part is that it only has to be coded by that provider once (Github in the above example) not by every single app that wants to use it.
Exactly as you should. It's frustrating when I have to make up a new username and password just to try out some service where the ill effects would be small if someone gained access to the account.
It's only supposed to take "a few seconds," but then I have to pick a new username because the one I used was already taken. That one too. Type in the CAPTCHA again. Also that one. Oh, and the password doesn't have enough numbers and uppercase letters (we could have told you our unnecessary restrictions in advance but we didn't). Type in the CAPTCHA again. Now the new password is too long. Now I have to make up a security answer (no, I'm not going to use the same info I give to my bank). Type in the CAPTCHA again. No, you got the CAPTCHA wrong, try again, and also enter your new password again. Now I have to log into my password manager to store all this stuff. And we're done! Oh no, now I have to wait to get an e-mail to confirm my address. Still waiting...
It's at the point where I often just bounce when someone wants me to make up a new password.
- you want users to be able to use the service from multiple devices
- (relatedly) you want users to be able to get a new phone without loosing their account
- you want to collect an email address or other information about users before allowing them to use the service
edited for formatting
> - you want to collect an email address or other information about users before allowing them to use the service
That's correct. Actually our process begins with a signup form where the email and phone number is provided. It's actually our sales that complete this form but it could probably be done on the web. But an E-Mail is pre-requisite - that was I was alluding to with the whole "What would Steve do?" section.
> - you want users to be able to use the service from multiple devices
This we handle. We've already created a customer record (based on the E-Mail) and we allow the activation message to be re-used by multiple devices so it's just a many to one relationship.
> - (relatedly) you want users to be able to get a new phone without loosing their account
This we're in the process of solving via the iCloud - not there yet though so we have to support customers manually and Android and others still to be figured out.
Unfortunately, you're also missing out on the federated and vastly potentially more secure nature of BrowserID in the rush to say that you've "done away with logins" which at the heart of it, isn't true.
I think the federated nature and options in security along with the eventual UserAgent integration has the potential to give users and integrators a really fast, easy UX. More than OpenID ever did, certainly.
a). Isn't doing security for security's sake, and
b). He's giving his users a great experience.
BrowserID is new tech. Even if that adds any value it's not been field tested. I'm not sure whether he considered it or not, but I can tell you I wouldn't. At least not until someone's thrown some sizeable stones at it, and that doesn't make it fall over.
All of that said and done, I think there are better options out there - specifically something that supports services (active requestor profile) and not just the browser (passive). Something like Windows Azure Active Directory, for example, which has a proven pedigree, connects with anything, and above all follows the laws of identity.
"He's giving his users a great experience". It's almost like you're trying to be ironic.
Your comment seems borderline FUD on BrowserID, especially to smush it between "Easy to use" and "Azure AD". BrowserID is built on an older protocol and is pretty straight forward PKI. It's not hard to implement right now. At all. In fact it's a snippet of JavaScript and you're done, outside of server side validation if you want session management.
edit: For the downvoters, please note that Azure AD is less than 24 hours old. Besides the fact that it integrates into existing AD systems and really has no place at all in solving the problem being discussed in this thread. Whatsoever.
His problem has been solved. The way he solved it is the great user experience I mentioned.
Bringing BrowserID into that already solved scenario is no different to bringing anything else into it - be that OpenID, ADFS, OAuth, hand-rolled...
The fact that BrowserID takes a few lines of JavaScript to implement does not prove it's security. You're talking about consuming an identity system - I'm talking about trusting one.
Right, that exact same user experience flow is replicable with BrowserID except that it has all of the other features and optional security mechanisms I mentioned...
I wasn't saying his system + BrowserID, I was saying he could move to BrowserID and keep the same flow with all the benefits.
>The fact that BrowserID takes a few lines of JavaScript to implement does not prove it's security
No, the existing underlying protocol and very straight-forward and completely standard PKI does though. The irony is that BrowserID at the most basic invocation already has all of the security embodied by the solution outlined here... except it has another layer of backing and can also feature additional-factor authentication. It's basically only possible to get more secure via the use of BrowserID.
No offense, but this conversation would be more interesting if you knew the difference between what they're currently doing, how BrowserID works and what things like Azure AD offer.
Any identity system should ideally be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
Neither BrowserID nor WAAD are justifiable parties.
My question relates to BrowserID regardless of the value to local.ch.
So, similarly, no offence, but saying "PKI" and "protocol" does not provide assurance. Does the BrowserID PKI implementation provide non-repudiation? Is it used to detect spoofing, tampering, to make a big secret a little secret? Does it in fact implement the protocol as specified?
I'm not saying it doesn't. I'm suggesting that until it's proven itself, BrowserID doesn't get my trust.
Since typing a user identification and password is not convenient with touch screen devices, we should obviously use method adapted to such types of interface. A combination of taps and slides on a changing interactive pattern could do the job. The service needs only to allow using both methods to authenticate.
A javascript widget with a commonly accepted method would be great to have.
Sending credential by mail and making their use implicit from a particular browser seems unsafe.
This is only because of the gigantic backwards step the entire industry has taken towards touch screens. Pro tip: if you can't send me an email without coming off like a gibbering idiot, the device should not be used in a professional context (I think this is possibly the original impetus for putting "Sent from my iPhone" at the bottom of every email - not for marketing purposes but so that everyone didn't immediately lose their jobs and/or clients as soon as they started using one).
I just bought a Motorola Pro+ after 6 months of tyranny at the hands of a Samsung Galaxy SII and I'm so happy I could cry. It's like a Nokia e63 running Android. Sheer bliss ... apart from the fact that it randomy reboots :(
There's always something, though ...
I do admit that on a hurry I have left behind a few wrong auto-corrections but it's not like I never made a typo on a computer keyboard. I definitely would not call it a "gigantic backwards step" but I may be wrong...
Aside from that (and this is purely anecdotal) I spend a reasonable amount of my time de-autocorrecting typos sent to me by people using auto-correct on their phones.
I also found in my time using a touchscreen keyboard (and, during that time I was not using auto-correct specifically because I wanted to train myself to be able to work without it for reasons mentioned previously) the lack of physical feedback and the fact that there was only one "mode" of touch (either touching or not touching) where as with a physical keyboard you have not touching, touching and actively pressing meant that I would continually make the same mistakes over and over and over, where as within a day or so of using a new physical keyboard I've adapted to it and my error rates drop significantly.
We have a similar-ish solution for a product we are building (empiric.al), except we don't even have the text/email. We server-side generate the device id & challenge when you connect the first time. That way the user is instantly in the app without any sign up.
Linking devices then becomes a secondary issue (similarly over email/sms, or optionally oauth) rather than a primary. Yes it is easier to abuse the system generating many empty sign ups, but it's just one of many ways people can abuse you. You still need something checking for abuse regardless.
Still, you could give the user the option to defer creating user/pass until later with the understanding that their account is temporary until then.
> And we chose Facebook / Twitter / OAuth right? Nope. It's a shitty position to be in when you have this large, deaf middle-man between you and your customers. Period.
Isn't the user's mobile carrier in between? While it may look less restrictive at the moment, I wouldn't be surprised in the least if (insert-your-carrier-here) changed policies on their network that restricted sending the information you need.
It's better than the FB/T/Y/G/etc. dependency, but only as a form of the UI. I think you still have a dependency there, and that dependency could be more volatile than meets the eye.
Carriers are definitely concerned with the bits being passed around.
I now need to pretend to be your phone, instead of pretending to be you, but that's not such a leap, security wise.
If some library becomes common and used by multiple sites, now you're even worse off, because now, you have the same "password" on multiple sites, and you are relying on each site salting this "password" for your security. Since you now no longer have the option of using different passwords on different sites, your security is now completely out of your hands and you are at the mercy of each person using this "mobile authentication library" to properly salt before saving it into their database.
That's about a likely to happen on your phone as any given website is to have secure password handling, eh?
How does this work for accessing the site on the computer? How do you get the same powers? I'm just wondering how one uses the service across more than one device.
If anything, this post only highlights how we need more security on our mobile devices.
Since it streamlines authentication, there's no reason to limit it to just log ins. Sites can authenticate any action they decide is critical enough to warrant it (e.g.: a bank could authenticate requests to transfer money, etc.). There's also potential for other scenarios like credit card transactions, physical security, etc.
Anywho - I'd love to get feedback. Any thoughts?
If that's the case, could it be possible to circumvent that through spoofing of the number and subsequent reception of the SMS message?
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...
http://www.kirit.com/A%20simple%20password-less%20authentica...
i.e. I'm sniffing traffic at a local coffee shop, or I find out your 'unique' phone ID through a malicious app. Once I have that, I spoof my phone to be yours and suddenly I'm logged in as you.
Does it just use an easily obtained device id though? so could a potentially malicious app that the user installs also grab the device ID and then forward it?
Even if an app 'saves' a username/password combo, (I hope at least) it does it in a secure way, where other apps can't access the saved info.
If all this system does is use a device id, its still not as secure. The article didn't mention whether or not it did this, but it would be better if, in addition to a device id, the app also randomly generated a key and stored it in a place that other apps couldn't access it. If it used that in addition to the device id for authentication, it would at least be as secure as other apps that 'remember' your username/password.
Currently the work I have done in this area has been one of two two approaches:
1) The app stores the information and maybe sends it to the user in an email. Copy and paste into a text field in the ERP app, or
2) A traditional username/password login.
In these areas I don't see a better approach. Sometimes even invoices may be entered. You really need to know who is doing it.
What are some techniques for getting a unique identifier for different devices?
How about a device that would just live on your real-world keychain, which would communicate with the website through a central registry? If you have it, it does a two-factor authentication behind the scenes with any website that has the feature that you've enabled it for.
It would have to be someone like Amazon, Apple, or Google to implement this.
If you have come up with some innovation that you believe is so simple that you are amazed the entire industry has ignored it, there is probably something glaring insecure about it but you simply don't understand security well enough to see it.
Apart from that doesn't stuff like lastpass basically solve this problem?
Also what if I want to login to several accounts from the same phone?
http://www.theage.com.au/digital-life/consumer-security/fear...
I find it humorous how many people seem oblivious to the fact that there's MANY people who find Apple uninspiring, especially since they often seem to be years behind those who are actually innovating. Unless you're trying to innovate new ways of marketing to narcissists and overpricing electronics.
Of course, Apple managed to realize them, polish them and place them in the hands of consumers and developers and thereby create viable markets based around the ideas (even for competitors), and while that's definitely a feat of engineering and marketing, many people (myself included) simply don't care about that part.
The only part I care about is that it's driving money towards tech such that there are R&D resources for developing new products (at the level of ARM chip designs or battery tech) that might make new kinds of products viable (from an engineering, not consumer marketing standpoint).
I for one use "What would Jesus do?" as a saying sometimes, and I don't need to be religious to do so. Similarly you need not be an Apple fanboy to get the reference. Move on.
The underlying assumption behind WWJD is that Jesus is a deity or exemplar of some sort, and that his example serves as adequate precedent to predispose us towards his point of view. For those who do not accept those axioms, it's irrelevant, just as if you said "well would my crazy cousin Max do?", or "what would Mohammed do?"
Those examples are often times important (such as the classic "what would my mom do?"). But they have to be properly motivated. Just as the mom example can be gendered and unfair, unstated assumptions that elevate certain groups (Christians/Apple-users in the running examples above) are also annoying and tedious.
Steve Jobs is not the exemplar of all things good in tech. There's a difference between listening to the words of a great man (Steve Jobs once said...) and deifying him into an archetype and extrapolating based on that myth (what would Steve Jobs do). The former is often relevant, the latter almost never is.
Unless you're talking about integrating with enterprise auth system, I see no way a login form delays a project.
PS: I have always wondered why PINS from debit card are 4 digits, and some random consumer product will ask you for a crazy complex password with at least 8 characters.
If true (and it sounds at least plausible), then the sheer number of legacy devices that expect a 4 digit PIN (including hardware crypto modules, which cost an absolute fortune to design and verify)
And, of course, a numeric keypad is much smaller and easier to design around than a full qwerty (and probably internationalises better as well)
The Cambridge Uni security group have a nice paper on PIN security in more detail, if you're interested[2].
[1] https://en.wikipedia.org/wiki/John_Shepherd-Barron
[2] http://www.cl.cam.ac.uk/~jcb82/doc/BPA12-FC-banking_pin_secu...
I get that a lot of people think that the web is becoming obsolete or whatever, but I think they are wrong. Yes, its nice to have a native look and feel or certain native features, but its not nice to have to make four different versions of the same application implemented in different platforms. That just doesn't make sense.
The web as a platform seems to have obvious advantages, but there is some stuff missing that makes it fall short of native applications. I think that doesn't have to be the case.
I think that 1) web browser teams have to work even harder to make the web as platform a reality, taking notice of a few particular problems, and 2) native application developers should stop being so enthusiastic about reinventing the wheel with multiple implementations.
As far as the problems that web browser teams need to be more aware of:
* HTML5 (mobile) applications need to install and launch just as easily as native applications. The current efforts to enable this go just far enough to fool a lot of people into thinking that their HTML5 application is "just like" a native app, when it isn't. They need an installer that is just as easy as mobile, a listing in an app store, and a launch button on a home page or app listing page.
* HTML5 (mobile) applications need to have the same API/device features available.
Maybe its just an impossible dream. Maybe technology will never make sense or stop being so wasteful and re-inventy as long as it is being driven by people in this 'culture'. Because I guess people want to waste time and money reimplementing the wheel or an app.
I guess that's the part about technology that I will never really be comfortable with, the part where it intersects with people and their 'values' and 'decision making'.
The other impediment, aside from individuals and values etc., is just the fact that there is a strong 'economic' incentive to ensure that the web as platform does not become truly compatible and match native platforms in terms of capability. Native platform (OS) vendors have to assume that could very possibly lead to significant drops in sales.
I think that this is the central challenge that human society has in regards to all sorts of technology, not just information technology: how to build systems that have leading edge capability and are compatible while at the same time allowing for localization, specialization, free evolution, robustness and diverse approaches to common problems.
I think that eventually we will agree on some common semantic models that are above the programming language/platform/hardware/engineering level, externally describe our systems and implement lower levels based on those terms. Of course we also need a technology and process to mediate the collaborative and competitive evolution of these higher-level knowledgebases.
As I mentioned in my other comment, just use BrowserID. It's federated, it's in the hands of the user, and it can be vastly more secure than this can be (and it prevents everyone from having to implement this system if they just support it).
---
The other cool idea plays off of what Google tried a while back. You could open a browser session on a new computer to login to Google and it presented a QR code. If you scanned it from a logged in Google Account Android phone, it would automatically unlock your browser session. No passwords needed, just a proof-of-(identity/trust) solution.
Shouldn't the token be saved with the backup?
> if I want to login from multiple devices
The technique should work well with multiple devices too.
i never log in to my bank, broker, or anything else i deem worthy of security from my phone. i never used any of the apps from the banks or the brokers, which is good, because many of them were eventually found to have numerous obvious security flaws
maybe one day the phone will be the default trusted access portal, but thats a long way off, and i am waiting for all of you to help expose the flaws with your own personal data before i take the plunge
> Of course there's a whole bunch of cases I'm happily ignoring, like banking apps, the App Store and pretty much anything with money changing hands.