13 ms·

Logins are Dead, and Mobile Killed Them

163 points by harryf 14y ago

deleted 14y ago
[deleted]
schwabacher 14y ago
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
- seiji 14y ago
  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.
- harryf 14y ago
  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.
  - drivebyacct2 14y ago
    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.
    - harryf 14y ago
      We have looked at BrowserID and may use it to bring the same to the web. We'd already started before BrowserID was announced...
      - drivebyacct2 14y ago
        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.
    - Spearchucker 14y ago
      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.
moggie 14y ago
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?
- harryf 14y ago
  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-uniqueidentifier-deprecated-what-to-do-now 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.
  - andor 14y ago
    You could generate a random number, let's call it a "cookie", and hand that to the device after a successful handshake.
jps359 14y ago
"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.
- harryf 14y ago
  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.
  - jps359 14y ago
    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..
    - harryf 14y ago
      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.
  - jimg 14y ago
    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?
drivingmenuts 14y ago
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.
- harryf 14y ago
  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.
- Seldaek 14y ago
  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.
  - pdx 14y ago
    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.
    - Seldaek 14y ago
      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.
Rhymenocerus 14y ago
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.
- rimantas 14y ago
  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?
  - lotyrin 14y ago
    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).
- Seldaek 14y ago
  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.
  - arjunnarayan 14y ago
angryasian 14y ago
he must of forgot that apple is not allowing tracking through UDID and I'm really not ok with giving services my number
clickonchris 14y ago
"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?
zokier 14y ago
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).
mahyarm 14y ago
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.
peterwwillis 14y ago
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.
- jasomill 14y ago
  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.
hell0_th3r3 14y ago
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
- janl 14y ago
  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.
jroseattle 14y ago
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.
- Domenic_S 14y ago
  Isn't that like saying the datacenter or upstream provider is in between? Kind of alarmist, no?
  - jroseattle 14y ago
    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.
rogerbinns 14y ago
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. http://developer.android.com/reference/android/accounts/AccountManager.html 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)?
- mkjones 14y ago
  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).
  - rogerbinns 14y ago
    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.
  - div 14y ago
    The AppStore. It's the worst offender.
    - 14y ago
victorNicollet 14y ago
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 ?
- harryf 14y ago
  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
michaelhoffman 14y ago
> 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.
- RandallBrown 14y ago
  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
m12r 14y ago
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.
- ajanuary 14y ago
  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.
- ambrice 14y ago
  Because if you guess my PIN correctly there's not much you can do with it unless you also have my card.
- shabble 14y ago
  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 https://en.wikipedia.org/wiki/John_Shepherd-Barron [2] http://www.cl.cam.ac.uk/~jcb82/doc/BPA12-FC-banking_pin_security.pdf http://www.cl.cam.ac.uk/~jcb82/doc/BPA12-FC-banking_pin_secu...
ambrice 14y ago
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?
- harryf 14y ago
  No - done over SSL
  - ambrice 14y ago
    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.
chmike 14y ago
Avoiding the login & password authentication is a desirable feature (see http://www.mozilla.org/en-US/persona/ 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.
varx 14y ago
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.
- sshumaker 14y ago
  https
  - azinman2 14y ago
    Exactly. Username & password have the exact same situation regardless of it being user input or stored.
- vasile 14y ago
  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 :)
  - varx 14y ago
    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.
    - vasile 14y ago
drivebyacct2 14y ago
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.
- geon 14y ago
  > 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.
vegas 14y ago
Ah yes, the remarkably secure realm of mobile devices. Surely one can trust them implicitly.
jiggy2011 14y ago
"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?
logn 14y ago
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.
- samspot 14y ago
  Unless the login form falls into your lap from heaven pre-tested, I see no way it would not add time to a project.
azinman2 14y ago
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.
- sehugg 14y ago
  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.
pbreit 14y ago
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.
ilaksh 14y ago
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.
whatusername 14y ago
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/fears-over-iphone-app-security-glitch-20120703-21ez6.html http://www.theage.com.au/digital-life/consumer-security/fear...
einhverfr 14y ago
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.
KayEss 14y ago
I wrote a paper published in an IEEE journal describing this mechanism. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=5501442&contentType=Conference+Publications http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru... http://www.kirit.com/A%20simple%20password-less%20authentication%20protocol%20for%20web%20sites http://www.kirit.com/A%20simple%20password-less%20authentica...
zaroth 14y ago
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.
dools 14y ago
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 ...
- Trufa 14y ago
  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...
  - dools 14y ago
    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.
haldean 14y ago
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.
stcredzero 14y ago
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.
- regularfry 14y ago
  Yubikeys are that way --> http://yubico.com http://yubico.com
  - stcredzero 14y ago
    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?
    - regularfry 14y ago
      Because it's not self-powered? They do an NFC model too.
readme 14y ago
Blogs are dead, and Github killed them.
egrim 14y ago
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 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?

163 points by harryf 14y ago

deleted 14y ago

[deleted]

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

seiji 14y ago
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.
harryf 14y ago
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.
- drivebyacct2 14y ago
  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.
  - harryf 14y ago
    We have looked at BrowserID and may use it to bring the same to the web. We'd already started before BrowserID was announced...
    - drivebyacct2 14y ago
      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.
  - Spearchucker 14y ago
    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.

moggie 14y ago

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?

harryf 14y ago
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-uniqueidentifier-deprecated-what-to-do-now 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.
- andor 14y ago
  You could generate a random number, let's call it a "cookie", and hand that to the device after a successful handshake.

jps359 14y ago

"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.

harryf 14y ago
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.
- jps359 14y ago
  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..
  - harryf 14y ago
    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.
- jimg 14y ago
  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?

drivingmenuts 14y ago

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.

harryf 14y ago
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.
Seldaek 14y ago
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.
- pdx 14y ago
  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.
  - Seldaek 14y ago
    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.

Rhymenocerus 14y ago

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.

rimantas 14y ago
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?
- lotyrin 14y ago
  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).
Seldaek 14y ago
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.
- arjunnarayan 14y ago

angryasian 14y ago

he must of forgot that apple is not allowing tracking through UDID and I'm really not ok with giving services my number

clickonchris 14y ago

"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?

zokier 14y ago

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).

mahyarm 14y ago

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.

peterwwillis 14y ago

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.

jasomill 14y ago
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.

hell0_th3r3 14y ago

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

janl 14y ago
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.

jroseattle 14y ago

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.

Domenic_S 14y ago
Isn't that like saying the datacenter or upstream provider is in between? Kind of alarmist, no?
- jroseattle 14y ago
  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.

rogerbinns 14y ago

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. http://developer.android.com/reference/android/accounts/AccountManager.html 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)?

mkjones 14y ago
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).
- rogerbinns 14y ago
  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.
- div 14y ago
  The AppStore. It's the worst offender.
  - 14y ago

victorNicollet 14y ago

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 ?

harryf 14y ago
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

michaelhoffman 14y ago

> 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.

RandallBrown 14y ago
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

m12r 14y ago

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.

ajanuary 14y ago
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.
ambrice 14y ago
Because if you guess my PIN correctly there's not much you can do with it unless you also have my card.
shabble 14y ago
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 https://en.wikipedia.org/wiki/John_Shepherd-Barron [2] http://www.cl.cam.ac.uk/~jcb82/doc/BPA12-FC-banking_pin_security.pdf http://www.cl.cam.ac.uk/~jcb82/doc/BPA12-FC-banking_pin_secu...

ambrice 14y ago

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?

harryf 14y ago
No - done over SSL
- ambrice 14y ago
  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.

chmike 14y ago

Avoiding the login & password authentication is a desirable feature (see http://www.mozilla.org/en-US/persona/ 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.

varx 14y ago

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.

sshumaker 14y ago
https
- azinman2 14y ago
  Exactly. Username & password have the exact same situation regardless of it being user input or stored.
vasile 14y ago
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 :)
- varx 14y ago
  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.
  - vasile 14y ago

drivebyacct2 14y ago

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.

geon 14y ago
> 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.

vegas 14y ago

Ah yes, the remarkably secure realm of mobile devices. Surely one can trust them implicitly.

jiggy2011 14y ago

"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?

logn 14y ago

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.

samspot 14y ago
Unless the login form falls into your lap from heaven pre-tested, I see no way it would not add time to a project.

azinman2 14y ago

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.

sehugg 14y ago
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.

pbreit 14y ago

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.

ilaksh 14y ago

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.

whatusername 14y ago

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/fears-over-iphone-app-security-glitch-20120703-21ez6.html http://www.theage.com.au/digital-life/consumer-security/fear...

einhverfr 14y ago

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.

KayEss 14y ago

I wrote a paper published in an IEEE journal describing this mechanism. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=5501442&contentType=Conference+Publications http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru... http://www.kirit.com/A%20simple%20password-less%20authentication%20protocol%20for%20web%20sites http://www.kirit.com/A%20simple%20password-less%20authentica...

zaroth 14y ago

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.

dools 14y ago

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 ...

Trufa 14y ago
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...
- dools 14y ago
  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.

haldean 14y ago

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.

stcredzero 14y ago

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.

regularfry 14y ago
Yubikeys are that way --> http://yubico.com http://yubico.com
- stcredzero 14y ago
  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?
  - regularfry 14y ago
    Because it's not self-powered? They do an NFC model too.

readme 14y ago

Blogs are dead, and Github killed them.

egrim 14y ago

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 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?