6 ms·

The Death of the Login

50 points by rp_yogat 12y ago

s_kilk 12y ago
> The primary use cases for requiring a login are customization, multi-device sync and being able to reach out to the user. And security, which is kind of a big deal if you have data the user would prefer be kept in their own secure space.
- connerbryan 12y ago
  Agreed. I think it's important to keep in mind the context of your application when considering implementing a system like OP mentions. Although, it would interesting to provide the user a choice between a password/"secure" login and a device/"anonymous" login (with the option to later switch).
  - rp_yogat 12y ago
    yes, definitely. for an app like ours, where its not mission critical or the user is not communicating and contributing with/to the community, anonymous works 90% of the time.
  - nothrabannosir 12y ago
    One caveat to the cookie-to-password switch: I am very good at saying, "Tomorrow." "Yeah, yeah, I'll do that tomorrow." Tomorrow comes and goes, I or a friend clear my history, whoops! Session lost. At that point I am easily discouraged enough to stop using it. E.g.: this happened to me with Khan Academy. I had watched so many videos on that cookie-only session, by the time it disappeared I'd long forgotten which ones I'd seen. Feeling a little discouraged, I thought, Okay, I'll get back to Khan tomorrow. Tomorrow never came. If more people are like that, that could be a good reason not to allow cookie-only sessions for too long. Or am I the only one?
- rp_yogat 12y ago
  yes, updating the article. sort of glossed over that!thank s_killk
  - currysausage 12y ago
    So, you wrote an article about "The Death of the Login" before even looking up "Login" on Wikipedia?
ezegolub 12y ago
So, in this scenario, losing the device (phone, tablet, computer) will mean losing access to the account right? It is coupled to device ID or some cookie right?
- rp_yogat 12y ago
  I am going to add an addendum about this which I will do now. On the app we are developing, the app installation has a unique id. Every once in a while, all of the "history" is stored in a secure fashion back on the server. So a device migration can be done. I must admit, losing a device is trickier because you wouldnt which id to use to restore on a new device. Let me think about this a bit
  - nkohari 12y ago
    Have you considered adding logins? :) But seriously, this is literally the problem that logins were designed to solve. With a login, you are defining an external concept of "user" that is distinct from the device. Available security factors are: something you are, something you possess, something you know. Right now, you're using something you possess (the device). The problem is, if I lose the device, I've lost my security credential, and no longer "own" my account. To fix this, you could collect an email, and when installing your app, you could prompt the user if they want to use an existing account or create another. But then, you probably want to add some security in the form of a password... and then you've created a login.
  - sg47 12y ago
    Unrelated but the link to the app in your biography has a typo in it.
  - jasonlotito 12y ago
    > I must admit, losing a device is trickier because you wouldnt which id to use to restore on a new device. This will happen. It will happen all the time. And when it does, people will be disappointed. People will stop using your app because they lost everything. I've seen this happen. This system can work if the data is not important. But the nature of apps that store data or have a concept of "your data is stored" needs to account for cases where the original device is no longer accessible/usable. > So a device migration can be done. Relying on device migration is foolish. It will fail. And I will blame your app for losing my data.
et1337 12y ago
I'm a big fan of the "email-only" login. Type your email address, hit login, switch to your email app, click the link, and you're logged in forever. If you don't have a password manager, it's probably what you do most of the time anyway via the forgotten password interface.
- rp_yogat 12y ago
  agree! HN has this and i love it
  - mattmanser 12y ago
    No it doesn't. It has a standard username/password/forgotten email me setup. What et1337 means is that you never even create a password, you literally login by putting just your email in, switching to your email, and clicking the link provided. Given that most sites require you to do this when you first create an account to prove you own the email anyway, what was the point of having a password?
    - gear54rus 12y ago
      For cases when you want to trust this computer for logging you into X, but not into your email (compromised it lets anyone use anything that is yours), obviously.
- shillster 12y ago
  Passing tokens around via email isn't very secure. Its not like email is encrypted.
  - username223 12y ago
    Right, but an expiring, single-use link that will send a second email saying "someone from X place just logged in, so contact us if this wasn't you" is still good enough in most cases. To see that, ask which sites will send you a password reset mail when you forget your password. My bank certainly won't -- I have to talk to a person -- but most others do, making their passwords useless.
daigoba66 12y ago
Everything in the article until the topic of "Multi-device support" is really just talking about how locally installed software has worked long before the Internet and SaaS. If I buy and install a piece of software like Photoshop (pre-Adobe subscription Photoshop), I don't have to login to use it. It "remembers" my settings and customizations simply by storing them in a file on my computer. There's nothing stopping an app on my phone or tablet from doing the same. When talking about "Multi-device support" we're really talking about device synchronization. You could consider a web browser/web app as a "device" for the purposes of this discussion. Since most devices can't do peer-to-peer synchronization, we often rely on the software vendor to provide centralized services. This requires identification and security which is typically implemented with username/password credentials.
mbesto 12y ago
> Multi-device support is when users are using your app on multiple devices...For most apps, this is really an over-rated feature. Uhh, it's not? What happens when a user upgrades their phone? Or loses it? Since the OP has basically admitted they'll fall back on logins at some point, I think they're going to have a much harder time explaining to users that they need to add an email address later in the process (or worse, try to retrieve someone's data when it's too late). On the other hand, it is interesting to think that maybe there is a decent strategy here, where you gracefully migrate an app user without a login (high conversion) into identifiable user (lower conversion).
- Eyas 12y ago
  Agreed. What the poster doesn't seem to realize in the analysis on multiple device users is that the use case is not only about using multiple devices concurrently, but transferring from one device to another.
codingdave 12y ago
"The primary use cases for requiring a login are customization, multi-device sync and being able to reach out to the user." No, the primary use case for a login is when you need to actually authenticate to be authorized to access secure data.
- Heewg9 12y ago
  Exactly.
- Someone1234 12y ago
  That cannot be right, that explanation doesn't contain enough buzzwords and web-2.0 nonsense. Almost sounds very 1980s... But really, does anyone else find that quote eye-rollingly tech-hipsterish?
  - username223 12y ago
    I've been desensitized enough that it doesn't seem that bad. At least he wrote "reach out" rather than "initiate the onboarding funnel."
    - warfangle 12y ago
      I prefer the term 'lead gavage'
  - neeleshs 12y ago
    While I do not agree with the premise of the quote, I don't find "customization" and "multi-device synch" tech-hipsterish - its exactly what happens with many phone app/webapp combinations.
- randomdata 12y ago
  Wouldn't that technically fall under customization? i.e. The customization of available data.
  - barrkel 12y ago
brandonwamboldt 12y ago
I'm not sure if it's just me, but I'm getting tired of the blog post formula: > The Death of XYZ that is actually not really going anywhere for most people The death of login, gamers, angular, react, PHP, etc, etc.
- Karunamon 12y ago
  It's the current fad. A few years ago, it was "Why I quit my job, and why you should too". Then it was "Why $social_network sucks, and why you should leave". Every now and then, you see "Why X sucks, and why you should stop using it (alternatively: X considered harmful)". Now it's "The death of X"
  - l0c0b0x 12y ago
    Not just that, but "The death of X" (title)... then blablabla, then conclusion: "This really isn't the death of x". :\
aytekin 12y ago
We have this on JotForm. You can use JotForm fully without creating an account. I think it is important to give people freedom to roam your product freely before making a decision to create an account.
skorecky 12y ago
"Does this mean the login is dead? Of course not." Ugh.
EugeneOZ 12y ago
the "login" has even more lives than cat.
andrewmutz 12y ago
"Been a few days since you have come back to the app? You get a nice welcome back notification." Do any users actually like these sorts of notifications? It's clear to me why application authors use them, but do users really like this stuff? It is notifications like this that make it so that whenever an app asks for permission notify these days, I say no.
- mavrc 12y ago
  I was thinking this as well. I wonder, there must be statistics that show that annoying your users gets results, or they wouldn't be used so frequently.
pionar 12y ago
This piece is the least thought-out piece I've seen either on Medium or HN in a while. Why all the upvotes?
pvsub 12y ago
All my devices and apps seem to cache logins, so for the login is dead (missing) until I need to change devices (and then there is the cloud-backup)

50 points by rp_yogat 12y ago

> The primary use cases for requiring a login are customization, multi-device sync and being able to reach out to the user. And security, which is kind of a big deal if you have data the user would prefer be kept in their own secure space.

connerbryan 12y ago
Agreed. I think it's important to keep in mind the context of your application when considering implementing a system like OP mentions. Although, it would interesting to provide the user a choice between a password/"secure" login and a device/"anonymous" login (with the option to later switch).
- rp_yogat 12y ago
  yes, definitely. for an app like ours, where its not mission critical or the user is not communicating and contributing with/to the community, anonymous works 90% of the time.
- nothrabannosir 12y ago
  One caveat to the cookie-to-password switch: I am very good at saying, "Tomorrow." "Yeah, yeah, I'll do that tomorrow." Tomorrow comes and goes, I or a friend clear my history, whoops! Session lost. At that point I am easily discouraged enough to stop using it. E.g.: this happened to me with Khan Academy. I had watched so many videos on that cookie-only session, by the time it disappeared I'd long forgotten which ones I'd seen. Feeling a little discouraged, I thought, Okay, I'll get back to Khan tomorrow. Tomorrow never came. If more people are like that, that could be a good reason not to allow cookie-only sessions for too long. Or am I the only one?
rp_yogat 12y ago
yes, updating the article. sort of glossed over that!thank s_killk
- currysausage 12y ago
  So, you wrote an article about "The Death of the Login" before even looking up "Login" on Wikipedia?

ezegolub 12y ago

So, in this scenario, losing the device (phone, tablet, computer) will mean losing access to the account right? It is coupled to device ID or some cookie right?

rp_yogat 12y ago
I am going to add an addendum about this which I will do now. On the app we are developing, the app installation has a unique id. Every once in a while, all of the "history" is stored in a secure fashion back on the server. So a device migration can be done. I must admit, losing a device is trickier because you wouldnt which id to use to restore on a new device. Let me think about this a bit
- nkohari 12y ago
  Have you considered adding logins? :) But seriously, this is literally the problem that logins were designed to solve. With a login, you are defining an external concept of "user" that is distinct from the device. Available security factors are: something you are, something you possess, something you know. Right now, you're using something you possess (the device). The problem is, if I lose the device, I've lost my security credential, and no longer "own" my account. To fix this, you could collect an email, and when installing your app, you could prompt the user if they want to use an existing account or create another. But then, you probably want to add some security in the form of a password... and then you've created a login.
- sg47 12y ago
  Unrelated but the link to the app in your biography has a typo in it.
- jasonlotito 12y ago
  > I must admit, losing a device is trickier because you wouldnt which id to use to restore on a new device. This will happen. It will happen all the time. And when it does, people will be disappointed. People will stop using your app because they lost everything. I've seen this happen. This system can work if the data is not important. But the nature of apps that store data or have a concept of "your data is stored" needs to account for cases where the original device is no longer accessible/usable. > So a device migration can be done. Relying on device migration is foolish. It will fail. And I will blame your app for losing my data.

et1337 12y ago

I'm a big fan of the "email-only" login. Type your email address, hit login, switch to your email app, click the link, and you're logged in forever. If you don't have a password manager, it's probably what you do most of the time anyway via the forgotten password interface.

rp_yogat 12y ago
agree! HN has this and i love it
- mattmanser 12y ago
  No it doesn't. It has a standard username/password/forgotten email me setup. What et1337 means is that you never even create a password, you literally login by putting just your email in, switching to your email, and clicking the link provided. Given that most sites require you to do this when you first create an account to prove you own the email anyway, what was the point of having a password?
  - gear54rus 12y ago
    For cases when you want to trust this computer for logging you into X, but not into your email (compromised it lets anyone use anything that is yours), obviously.
shillster 12y ago
Passing tokens around via email isn't very secure. Its not like email is encrypted.
- username223 12y ago
  Right, but an expiring, single-use link that will send a second email saying "someone from X place just logged in, so contact us if this wasn't you" is still good enough in most cases. To see that, ask which sites will send you a password reset mail when you forget your password. My bank certainly won't -- I have to talk to a person -- but most others do, making their passwords useless.

daigoba66 12y ago

Everything in the article until the topic of "Multi-device support" is really just talking about how locally installed software has worked long before the Internet and SaaS. If I buy and install a piece of software like Photoshop (pre-Adobe subscription Photoshop), I don't have to login to use it. It "remembers" my settings and customizations simply by storing them in a file on my computer. There's nothing stopping an app on my phone or tablet from doing the same. When talking about "Multi-device support" we're really talking about device synchronization. You could consider a web browser/web app as a "device" for the purposes of this discussion. Since most devices can't do peer-to-peer synchronization, we often rely on the software vendor to provide centralized services. This requires identification and security which is typically implemented with username/password credentials.

mbesto 12y ago

> Multi-device support is when users are using your app on multiple devices...For most apps, this is really an over-rated feature. Uhh, it's not? What happens when a user upgrades their phone? Or loses it? Since the OP has basically admitted they'll fall back on logins at some point, I think they're going to have a much harder time explaining to users that they need to add an email address later in the process (or worse, try to retrieve someone's data when it's too late). On the other hand, it is interesting to think that maybe there is a decent strategy here, where you gracefully migrate an app user without a login (high conversion) into identifiable user (lower conversion).

Eyas 12y ago
Agreed. What the poster doesn't seem to realize in the analysis on multiple device users is that the use case is not only about using multiple devices concurrently, but transferring from one device to another.

codingdave 12y ago

"The primary use cases for requiring a login are customization, multi-device sync and being able to reach out to the user." No, the primary use case for a login is when you need to actually authenticate to be authorized to access secure data.

Heewg9 12y ago
Exactly.
Someone1234 12y ago
That cannot be right, that explanation doesn't contain enough buzzwords and web-2.0 nonsense. Almost sounds very 1980s... But really, does anyone else find that quote eye-rollingly tech-hipsterish?
- username223 12y ago
  I've been desensitized enough that it doesn't seem that bad. At least he wrote "reach out" rather than "initiate the onboarding funnel."
  - warfangle 12y ago
    I prefer the term 'lead gavage'
- neeleshs 12y ago
  While I do not agree with the premise of the quote, I don't find "customization" and "multi-device synch" tech-hipsterish - its exactly what happens with many phone app/webapp combinations.
randomdata 12y ago
Wouldn't that technically fall under customization? i.e. The customization of available data.
- barrkel 12y ago

brandonwamboldt 12y ago

I'm not sure if it's just me, but I'm getting tired of the blog post formula: > The Death of XYZ that is actually not really going anywhere for most people The death of login, gamers, angular, react, PHP, etc, etc.

Karunamon 12y ago
It's the current fad. A few years ago, it was "Why I quit my job, and why you should too". Then it was "Why $social_network sucks, and why you should leave". Every now and then, you see "Why X sucks, and why you should stop using it (alternatively: X considered harmful)". Now it's "The death of X"
- l0c0b0x 12y ago
  Not just that, but "The death of X" (title)... then blablabla, then conclusion: "This really isn't the death of x". :\

aytekin 12y ago

We have this on JotForm. You can use JotForm fully without creating an account. I think it is important to give people freedom to roam your product freely before making a decision to create an account.

skorecky 12y ago

"Does this mean the login is dead? Of course not." Ugh.

EugeneOZ 12y ago

the "login" has even more lives than cat.

andrewmutz 12y ago

"Been a few days since you have come back to the app? You get a nice welcome back notification." Do any users actually like these sorts of notifications? It's clear to me why application authors use them, but do users really like this stuff? It is notifications like this that make it so that whenever an app asks for permission notify these days, I say no.

mavrc 12y ago
I was thinking this as well. I wonder, there must be statistics that show that annoying your users gets results, or they wouldn't be used so frequently.

pionar 12y ago

This piece is the least thought-out piece I've seen either on Medium or HN in a while. Why all the upvotes?

pvsub 12y ago

All my devices and apps seem to cache logins, so for the login is dead (missing) until I need to change devices (and then there is the cloud-backup)