Logins are Dead, and Mobile Killed Them(github.com)
github.com
Logins are Dead, and Mobile Killed Them
https://github.com/harryf/thoughts/blob/master/mobile-killed-the-login.md
36 comments
Not sure if you're actually an Android developer but I just ran into this issue while working on an app: AccountManager isn't really meant to be used as a standalone password store, it needs to be hooked into a SyncAdapter & ContentProvider in order to function properly. (http://stackoverflow.com/a/8614699/188197)
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.
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.
I am an Android developer amongst others. Note that the SyncAdapater/ContentProvider etc don't actually gave to do anything. And more to the point the writing of that code is the problem of whoever is providing the service.
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.
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.
What are some cases where you've been asked for a password in an iOS app? I've only ever seen this for initial login with like facebook or instagram, and when updating apps (very annoying, I agree).
Does the browser count?
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.
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.
By default auto-fill is off on the ipad, did you try turning it on for names and passwords?
(I agree that the default behavior sucks)
(I agree that the default behavior sucks)
The AppStore. It's the worst offender.
The good thing about the AppStore password timing out after 15 minutes is that you can hand your child the ipad/iphone/etc. and not get a surprise $5,000 itunes bill.
That's an edge case, though. Why not make it a configurable option?
Holy not an edge case Batman! That is most definitely a very common reason to timeout the password...
Oh my god that is so not an edge case.
This is definitely not an edge case. How many kids do you see at the grocery store with their noses in an iPhone will their parent(s) shop?
That said, it would be nice to have the option of telling the app to cache your credentials.
That said, it would be nice to have the option of telling the app to cache your credentials.
Edge case was perhaps the wrong term. It certainly is not a majority case. As I said- make it an option, everyone is happy.
Not the person who turns on the option to make their life easier and then complains because their kid spent $400.
?! Are you suggesting that everyone should be denied the choice because some people are unable to make informed decisions?
This is confusing authentication and authorization. Is this phone legitimately tied to this Apple ID? Yes. Is the owner of the account authorized to make such a purchase? No.
A short appstore PIN could solve this much more easily.
A short appstore PIN could solve this much more easily.
I'm not so sure having _yet another_ PIN for users to remember would be a good idea. And besides, a short PIN would be far easier to deduce by looking over a person's shoulder.
It is a configurable option (Settings -> General -> Restrictions)
Yeah, it's configurable between "Demand my password again if 15 minutes has passed" and "Demand my password again immediately." You can tell you're going in the wrong direction when you first have to "enable restrictions" hoping to relax the restriction. I take it you've never actually tried to configure this option.
How about using fingerprint scanner for authentication? Or face recognition using front-facing camera? It's 2012 after all.
The Samsung Galaxy S3 has face recognition. It can be unlocked using a photo of the user. Google Images search, point cam at laptop, bingo you're in.
They "fixed" this in JellyBean.
too many false positives.
Now, an SD card with a certificate plus face recognition might be ok ;-)
Now, an SD card with a certificate plus face recognition might be ok ;-)
Why an SD card? The phone itself is already a portable device you control.
It depends on the app but at least in the areas I work (business apps relating to tracking money) I wouldn't assume that device authentication is sufficient.
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.
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.
Only problem I have with AppStore is that it requires my password for free downloads. Paid download? Hell yes, require my password if I haven't typed it in for 15 minutes.
I have kids. I'm happy they _always_ ask for a password... Free apps can be malicious e.g giving away location to parties unknown. But still you're right - this could be an option users can decide.
This is part of a deeper problem with most mobile OSes.
I might give my phone to somebody so they can make a quick call or look something up online.
However, I don't really want them being able to dig through my history or be automatically logged into my email etc.
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.
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.
Schneier today:
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.
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.
There are currently a few projects ongoing with enabling VMs on smartphones. The way it was thought is that you would put your corporate stuff on a protected VM that would have no external app install, and the rest (games, social networks...) would be on the "fun" VM. That way, the company data would be better protected.
This isn't a popular sentiment but the way I solve this is not to let anyone borrow or touch my devices.
iOS 6 removes the needs to enter passwords for app updates. finally.
I haven't lied if I say it's one of the sweetest things I've found in iOS 6.
How about each Google app I install? Or any app that has Dropbox integration? Or Trello. Pretty much every app is an island and doesn't know that you have already entered your username and password numerous times in other apps.
iOS 6 addresses this (system account management) for FB and Twitter.
The vast majority of Google account holders only have one account, you and the average HN user are atypical.
The vast majority of Google account holders only have one account, you and the average HN user are atypical.
>The vast majority of Google account holders only have one account
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.
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.
And more do not.
Over time people are far more likely to accumulate more accounts. The longer someone has been on the net the more accounts they are likely to have. Making life difficult for this group of people doesn't seem sensible.
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.
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.
What kind of half-assed excuse is that for not implementing a good feature that's proven to work?
But they don't address it for Dropbox, Skype or random other services out there.
> 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.
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.
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.
I have some sort of default login credentials I'll use to sign up for stuff just to try it out. If those don't work for whatever reason (screen name taken, password not complex enough) I'll usually stop signing up
There are a few reasons logins are still needed for most apps:
- 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 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
Changing your order as it makes it easier to answer...
> - 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.
> - 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.
So you halfway implemented BrowserID. In it's current incarnation (well, originally, now it's more traditional with a password), you can create an account with an email address and login via the link sent to you in email.
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.
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.
Actually I think he did the right thing. He:
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.
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.
I literally spit coffee out on my desk that you recommended Windows Azure Active Directory for this type of scenario.
"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.
"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.
My post wasn't very clear. I'm sorry.
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.
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.
>His problem has been solved. The way he solved it is the great user experience I mentioned.
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.
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.
None taken, I understand the difference quite well.
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.
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.
We have looked at BrowserID and may use it to bring the same to the web. We'd already started before BrowserID was announced...
Cool! I'm looking at building a server to be an identity provider and wiring it up to a really simple smtp server, imap client (for pulling from gmail) and imap server to make a really stupid simple email client that provides identity services with a variety of options for security. Multifactor auth with a variety of choices in factors : SMS, phone call, OTP, time based codes, PKI, etc.
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.
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.
Quoth the article: We send you a link by SMS or E-Mail containing a link comprised of an activation code. Tapping on the link results in our app being launched in "activation mode". The app then "phones home" passing back the activation code and some unique identifier for the device. That's it.
Avoiding the login & password authentication is a desirable feature (see http://www.mozilla.org/en-US/persona/) but a user authentication is still required at some point : unlock the secret key, use browser on public access devices, etc.
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.
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.
smartphones are not good devices for accurate typing
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 ...
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 really have almost no spelling mistakes with my iPhone and I generally touch the wrong key, I have found the auto-correct feature awesome! Am I alone here? I actually had much more typos on a BB since it was "trusting" all my inputs (though this could be solved, haven't seen it yet - not that it doesn't exist).
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...
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...
The article is talking about passwords which makes auto-correct useless, but I also do a lot of stuff over SSH (SQL queries, UNIX commands, basic vim editing) and the ability to do so allows me to be farther away from my desk even on days when I'm responsible for tech support and diagnosing problems with our products/servers so accurate typing is very critical to me personally.
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.
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.
While remembering usernames and passwords suck, so does having to wait for a text/email and going through another hoop. Any kind of friction in a sign up process is undesirable.
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.
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.
Saving the auth info is then the problem. It's not so bad on iOS, because you have the Keychain that persists across uninstalls and get backed up. Android is a bit trickier -- there's no comprehensive way to preserve information across uninstalls (except BackupManager, which requires a Google login).
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.
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.
To be more accurate, mobile apps delegated the 'login' to a primary login service, such as your phone number, email, facebook account, device ids and so on. Nobody wants to remember 50 logins for the 50 apps they've downloaded just to try them out.
I like the sentiment of reducing user friction, but one statement sticks out to me:
> 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.
> 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.
Isn't that like saying the datacenter or upstream provider is in between? Kind of alarmist, no?
Not really -- most datacenters or upstream providers aren't really engaged or interested in the data your application uses (outside of illegal activities.)
Carriers are definitely concerned with the bits being passed around.
Carriers are definitely concerned with the bits being passed around.
Until phones are surgically attached or implanted at birth, they are not secure enough to serve as a login device. It is way too easy for someone to forget their phone or for someone else to steal the phone.
In light of recent password leaks events, I feel much safer leaving my phone on the table than giving my password to any of the major websites. Also this point was addressed in the original article.
Why? You still have a password. You now have a password you don't know, that's entered on your behalf by querying some aspect of your phone, but it's still a password in a database that can be compromised if the database is compromised.
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.
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.
I don't think this is necessarily a problem. If the model is based on generating a secure (in terms of entropy) token that is then stored on the device or in the iOS cloud it's fine. Every app using that lib has its own token even for the same device.
> If the model is based on generating a secure (in terms of entropy) token that is then stored on the device or in the iOS cloud it's fine.
That's about a likely to happen on your phone as any given website is to have secure password handling, eh?
That's about a likely to happen on your phone as any given website is to have secure password handling, eh?
Isn't that a problem with phone-based email and apps already? For example, how many people have their email set to ask for a password each and every time and who has the facebook app set to ask for a password each launch? If I had someone's mobile phone, I could easily use the "forgot password" link on most web services and then just pull up the email client.
On the other hand, if I forget my phone somewhere or it's stolen, I'll probably know within hours, if not minutes. If someone steals my password, who knows how or when I'll find out.
Agreed. But for many cases you don't need something that secure like when you're posting pictures of cats. And many web based logins are not providing a great deal of security either - this approach may actually be an improvement as it makes identity theft via brute forcing redundant.
"We're now able to identify you so we can enable your "super powers" in the form of functionality that normal users of our app don't have access to."
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.
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.
Well we began this one "mobile first" so we haven't actually solved this one yet. But... the activation message contains a link to a web based landing page - from there we currently launch the app but depending on the client, we could also launch a webpage. Our current thinking is to give you a "single use" session - once the session expires, you need to go back to the activation message. Not optimal but we want our customers to focus on the apps.
yeah - but what happens if you have 2 IOS devices and want to access the same "account" info on both? how do you grant access to the second device?
The solution you have in mind sounds terribly inconvenient, but I can understand wanting to keep the focus on the app.
What would this mean for accessing your service with and iPad or a tablet? I really feel like a traditional log-in system might be better in this case..
For the iPad it's no problem - we have a universal app but you're right - it's not a pretty approach and we have quite a few customers asking. Mostly it's the "desktop bound" ones that want it e.g. the receptionist at the dentist.
Isn't this.... pointless? I already log in once on my device, click 'save password', and I never type it in again. So "removing the login" is a solution for a problem that doesn't exist.
If anything, this post only highlights how we need more security on our mobile devices.
If anything, this post only highlights how we need more security on our mobile devices.
We also need more convenience, though, especially for low-security things like discussion forums and blog comments where the choice is often between a lousy password and a lousy password reset scheme. Your solution only works well with a convenient (no extra steps beyond "save my password") and ubiquitous (works with all major platforms, browsers, and applications) password synchronization system.
I'd have to disagree with the post title. I think logins are reborn, and it's mobile that's resurrecting them. I'm working on a project to build a pervasive authentication system (http://www.toopher.com) that finally allows for systems to protect their user's accounts with more than just a password but without annoying the heck out of them. Instead, why not use the location awareness and network connectivity of smartphones to learn where you should be when you log in from a given device and automatically provide additional protection. I'd love feedback from the collective HN braintrust, here's how it works: When a request is made, a website can push the details to your phone, where they're displayed and you can grant or deny them. But instead of bugging you every time a request is made, you can opt to remember your decision and automatically respond to identical requests when you're in the same geographic location. This way we only pester the user when something is out of the ordinary (e.g.: they're in a different location, using a different computer, etc.), and fade into the background for the majority of requests.
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?
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?
How exactly do you identify the device? By phone number?
If that's the case, could it be possible to circumvent that through spoofing of the number and subsequent reception of the SMS message?
If that's the case, could it be possible to circumvent that through spoofing of the number and subsequent reception of the SMS message?
We began with using the device ID but of course we've had to change given that's deprecated - http://stackoverflow.com/questions/6993325/uidevice-uniqueid... - iOS6 seems to have perfect answers here - we're not interested in IDs you can share between apps - this is for our app only.
You could generate a random number, let's call it a "cookie", and hand that to the device after a successful handshake.
I wrote a paper published in an IEEE journal describing this mechanism.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...
http://www.kirit.com/A%20simple%20password-less%20authentica...
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...
http://www.kirit.com/A%20simple%20password-less%20authentica...
So... how does this protect against a replay attack?
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.
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.
The login system suggested should be used via HTTPS where you have to do more than just sniffing the traffic. Also, as the author mentioned, we don't do e-banking or stuff that involves $$$. Just keep it simple :)
Yeah, now that I think about it, username/password combos pose the same risk as this when it comes to sniffing.
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.
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.
Again, the article stresses the "good enough security" . However, udid itself can be sniffed and read by other apps, so it's not good to rely only on it but in a combination with some kind of a "salt".
Now the more interesting case I think has to do with mobile in ERP. These are often shared devices (for example portable data terminals of one sort or another, some of which are even phones too), and even when they aren't, you need some assurance that it's not a kid playing with the device.
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.
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.
"The app then "phones home" passing back the activation code and some unique identifier for the device. That's it."
What are some techniques for getting a unique identifier for different devices?
What are some techniques for getting a unique identifier for different devices?
What if two-factor fobs were actually secure, really cheap, and required nearly zero user intervention?
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.
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.
Yubikeys are that way --> http://yubico.com
Not really. Why do I have to take it out of my pocket and plug it into the machine? Why can't it just get on my home WiFi network?
Because it's not self-powered? They do an NFC model too.
"Custom" security/authentication solutions always scare the shit out of me.
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?
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?
[deleted]
Does this have exactly the same problem as authenticating via UDID? Ie -- when you sell your old phone the new user can magically authenticate as you.
http://www.theage.com.au/digital-life/consumer-security/fear...
http://www.theage.com.au/digital-life/consumer-security/fear...
What would Steve do?
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.
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.
Way to turn a decent post in an Apple vs. World religious war.
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.
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.
To be fair, if you invoked a "What would Jesus do?" people would be apt to get testy.
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.
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.
So before iPhone came out pretty much every smarthpone looked just like it?
And befor iPad came out Samsung, HTC, HP, RIM, Amazon had their tablet computers business going full-steam?
And do you mind to compare prices of iPhone and Samsung Galaxy S, iPad and Samsung Galaxy Tab and explain how are they overpriced?
Or is it just inconceivable to you that Apple does indeed make damn good products for the price that is on par with competition?
I personally don't find any of their products to be very interesting or inspiring. The ideas were all in the ether already as far as I cared about them.
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).
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).
Regarding login forms: "Engineers and product managers hate them because you have to build lots of sucky forms which are never quite are as usuable as they should be and lead to missed deadlines."
Unless you're talking about integrating with enterprise auth system, I see no way a login form delays a project.
Unless you're talking about integrating with enterprise auth system, I see no way a login form delays a project.
Unless the login form falls into your lap from heaven pre-tested, I see no way it would not add time to a project.
love the idea, but logins are not dead, you just piggy backed on device/passcode combination instead of email/password combination.
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.
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.
As the story goes, when John Shepherd-Barron[1] was working on the original ATM system, he originally planned 6 digits, but reduced it to 4 because his wife wasn't able to consistently recall a 6 digit random number.
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...
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...
Because if you guess my PIN correctly there's not much you can do with it unless you also have my card.
I think 4 digit pins are so prevalent because they're easy to remember. As they get longer and harder to remember, people are more likely to write them down etc.
Great article, but one minor nitpick; I have a hard time believing that Apple's policy of only allowing personal email addresses isn't just to maximize profits. I imagine they require a personal email address so that everyone in an organization has to pay the $100 developer fee.
I'm quite a newbie as far as mobile web apps go, so forgive me for asking... is there a way to use your cell phone unique device identifier to log in on a web application ? Or does this article deal only with native mobile applications ?
As far as I know, it's not possible - passing a device ID tithe browser would be a privacy disaster. You could use something like PhoneGap if you want to develop your app in HTML5 while having access to native APIs
The headline is kind of silly. Logins are far from dead, even on mobile. In fact, I find that I'm logging in more than ever on mobile (mostly thanks to updating iOS apps). But I think I understand where the author is coming from.
Are these ids in plaintext in network requests? What if someone at Starbucks snoops my request? What if someone steals/guesses my id while I still have the same device, how do I do the equivalent of resetting my password?
I agree on that mobile phones are good authentication method. Not exactly in the way TFA describes, but eg how Google QR code authentication worked (sadly it was discontinued for some reason).
Let's call this what it is. You are storing a session id on the device, and your sessions never expire. There's nothing wrong with sessions that never expire, if that's what you want.
Ah yes, the remarkably secure realm of mobile devices. Surely one can trust them implicitly.
he must of forgot that apple is not allowing tracking through UDID and I'm really not ok with giving services my number
Blogs are dead, and Github killed them.
This makes sense. Why can't we have something similar for web applications? Maybe browsers could add a new API to enable it? They definitely could.
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.
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.
So if I want to login from multiple devices, or if I drop my device in a lake and create a new one... I still have to "relogin" via a link sent to my email.
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.
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.
> if I drop my device in a lake
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.
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.
the phone is the last device i trust to be secure
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
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
That’s why the article states:
> 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.
> 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.
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)?