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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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 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.
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.
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.
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).
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.
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.
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).
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.
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.
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 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 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.
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.
I really wish mobile app developers (especially those from iOS) would look at the AccountManager on Android and actually use it. You only ever need to enter credentials once and the AccountManager will store them. Apps can ask for tokens from the AccountManager so they never get the actual password. And new apps can be installed that add themselves to the AccountManager list (eg Dropbox, LinkedIn, Skype etc do this). This is how it should work.
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)?
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).
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.
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.
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.
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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
> 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.
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
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.
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.
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].
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?
Ok, but no way to handle the case where it is comprimised? Why use the device id, why not just generate a uuid the first time the app is run? It seems like there are some issues to work out with this scheme, it may be slightly premature to declare logins dead.
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.
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.
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.
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".
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.
"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?
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.
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.
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.
127 comments
[ 2.5 ms ] story [ 166 ms ] thread- 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.
If that's the case, could it be possible to circumvent that through spoofing of the number and subsequent reception of the SMS message?
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.
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?
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.
What are some techniques for getting a unique identifier for different devices?
If anything, this post only highlights how we need more security on our mobile devices.
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.
> 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.
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.
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.
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.
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...
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.
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.
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.
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?
Unless you're talking about integrating with enterprise auth system, I see no way a login form delays a project.
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.