
Logins are Dead, and Mobile Killed Them - harryf
https://github.com/harryf/thoughts/blob/master/mobile-killed-the-login.md
======
rogerbinns
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/Acco...](http://developer.android.com/reference/android/accounts/AccountManager.html)

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

~~~
div
The AppStore. It's the worst offender.

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

~~~
untog
That's an edge case, though. Why not make it a configurable option?

~~~
bmj
This is definitely not an edge case. How many kids do you see at the grocery
store with their noses in an iPhone will their parent(s) shop?

That said, it would be nice to have the option of telling the app to cache
your credentials.

~~~
untog
Edge case was perhaps the wrong term. It certainly is not a _majority_ case.
As I said- make it an option, everyone is happy.

~~~
sirclueless
Not the person who turns on the option to make their life easier and then
complains because their kid spent $400.

~~~
untog
?! Are you suggesting that everyone should be denied the choice because some
people are unable to make informed decisions?

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

------
schwabacher
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_

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

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

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

~~~
Spearchucker
My post wasn't very clear. I'm sorry.

His problem has been solved. The way he solved it is the great user experience
I mentioned.

Bringing BrowserID into that _already solved_ scenario is no different to
bringing anything else into it - be that OpenID, ADFS, OAuth, hand-rolled...

The fact that BrowserID takes a few lines of JavaScript to implement does not
prove it's security. You're talking about consuming an identity system - I'm
talking about trusting one.

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

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

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

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

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

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

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

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

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

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

~~~
286c8cb04bda
_> If the model is based on generating a secure (in terms of entropy) token
that is then stored on the device or in the iOS cloud it's fine._

That's about a likely to happen on your phone as any given website is to have
secure password handling, eh?

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

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

------
egrim
I'd have to disagree with the post title. I think logins are _reborn_ , and
it's mobile that's resurrecting them. I'm working on a project to build a
pervasive authentication system (<http://www.toopher.com>) that finally allows
for systems to protect their user's accounts with more than just a password
but without annoying the heck out of them. Instead, why not use the location
awareness and network connectivity of smartphones to learn where you should be
when you log in from a given device and automatically provide additional
protection. I'd love feedback from the collective HN braintrust, here's how it
works: When a request is made, a website can push the details to your phone,
where they're displayed and you can grant or deny them. But instead of bugging
you every time a request is made, you can opt to remember your decision and
automatically respond to identical requests when you're in the same geographic
location. This way we only pester the user when something is out of the
ordinary (e.g.: they're in a different location, using a different computer,
etc.), and fade into the background for the majority of requests.

Since it streamlines authentication, there's no reason to limit it to just log
ins. Sites can authenticate any action they decide is critical enough to
warrant it (e.g.: a bank could authenticate requests to transfer money, etc.).
There's also potential for other scenarios like credit card transactions,
physical security, etc.

Anywho - I'd love to get feedback. Any thoughts?

------
moggie
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
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...](http://stackoverflow.com/questions/6993325/uidevice-
uniqueidentifier-deprecated-what-to-do-now) \- 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
You could generate a random number, let's call it a "cookie", and hand that to
the device after a successful handshake.

------
KayEss
I wrote a paper published in an IEEE journal describing this mechanism.

[http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...](http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=5501442&contentType=Conference+Publications)

[http://www.kirit.com/A%20simple%20password-
less%20authentica...](http://www.kirit.com/A%20simple%20password-
less%20authentication%20protocol%20for%20web%20sites)

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

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

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

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

------
stcredzero
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
Yubikeys are that way --> <http://yubico.com>

~~~
stcredzero
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
Because it's not self-powered? They do an NFC model too.

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

------
whatusername
Does this have exactly the same problem as authenticating via UDID? Ie -- when
you sell your old phone the new user can magically authenticate as you.

[http://www.theage.com.au/digital-life/consumer-
security/fear...](http://www.theage.com.au/digital-life/consumer-
security/fears-over-iphone-app-security-glitch-20120703-21ez6.html)

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

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

------
logn
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
Unless the login form falls into your lap from heaven pre-tested, I see no way
it would not add time to a project.

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

~~~
shabble
As the story goes, when John Shepherd-Barron[1] was working on the original
ATM system, he originally planned 6 digits, but reduced it to 4 because his
wife wasn't able to consistently recall a 6 digit random number.

If true (and it sounds at least plausible), then the sheer number of legacy
devices that expect a 4 digit PIN (including hardware crypto modules, which
cost an absolute fortune to design and verify)

And, of course, a numeric keypad is much smaller and easier to design around
than a full qwerty (and probably internationalises better as well)

The Cambridge Uni security group have a nice paper on PIN security in more
detail, if you're interested[2].

[1] <https://en.wikipedia.org/wiki/John_Shepherd-Barron>

[2] [http://www.cl.cam.ac.uk/~jcb82/doc/BPA12-FC-
banking_pin_secu...](http://www.cl.cam.ac.uk/~jcb82/doc/BPA12-FC-
banking_pin_security.pdf)

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

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

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

------
ambrice
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
No - done over SSL

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

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

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

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

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

------
readme
Blogs are dead, and Github killed them.

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

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

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

