4 ms·

At my company we've been using this technique for years. Users have always hated it and after waiting a long time for people to come around, we are now transit

At my company we've been using this technique for years. Users have always hated it and after waiting a long time for people to come around, we are now transitioning back to traditional login mechanisms. The basic reasons users hated it was that a login mechanism needs to be reliable. In particular, we make business software, so if the user was ever unable to get into the system it was a big problem. While it may seem that you "always" have access to your email, or sms. Not all users (especially non-technical users) always have access to these things. Meaning, even if they have access 98% of the time, that other 2% of the time infuriates them. It was also a usability nightmare among non-technical users. Traditional login mechanisms dont necessarily mean a more usable experience, but its a pattern that everyone knows. I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it.

tngme 12y ago
This is a fair point considering the use scenario that you describe. For other website this might look very different: Think of all those small websites for which you had to create logins but that you rarely use. They are a huge risk due to people's tendency to reuse passwords across important & unimportant sites. For those smaller sites people might not even recognize this system as a traditional login: They simply come back to the site, are asked for their email address if they want to get back to their information, and shortly thereafter they have a link in their inbox to their details/comments/favorites/...
tracker1 12y ago
This really affected me the one day in the past 3 years that I forgot my phone in the morning... There was one site I had enabled 2FA (two factor authentication) on that I hadn't logged in from work yet, and it was really a pain not being able to access it. Honestly, I've been pretty happy simply using LastPass (with a really long passphrase that I haven't shared with anyone) and generating more complex passwords for sites... Just the same, not sure what the best answer is... Especially considering shared computers, portable devices and other devices which may get stolen or hacked.
- squeaky-clean 12y ago
  I've been very happy with LastPass too. I use it on my desktop and pay for the mobile app. But what I don't get is why we still need to use a password manager extension/app. Why isn't it built into the browser yet? Google already has all of my passwords saved, and synchronized online across devices for whenever I use chrome (well, the passwords I used before switching to LastPass). Why can't it automatically generate secure passwords for me just like LastPass does?
  - zackboe 12y ago
    They're working on it! Looks like it's enabled in the most recent version of Canary. http://www.chromium.org/developers/design-documents/password-generation http://www.chromium.org/developers/design-documents/password...
  - tracker1 12y ago
    I'm actually trying to unlock myself from Chrome... although it's still my goto browser, I realized I'd fallen in heavily with Chrome, and my passwords are something I can't really share with, say my Firefox, Safari, or IE instances.
    - mbreese 12y ago
      No, you're right. We have password managers built into browsers. That just doesn't work the way we'd like it to. Because of this we have the extra kludge of requiring extensions like LassPass to keep passwords safe and sync'd between browsers/devices. We know that isn't an optimal solution (but it does work...) Instead, what we really need is some kind of identity management built into the browser. We already have something similar to this in terms of private client certificates. You could setup your browser to authenticate you to supporting websites via a client certificate. The problem is, no one is going to do that... it just isn't practical from a workflow perspective. Instead, what I'd like to see is some kind of portable identity solution (similar to a certificate) where you could authenticate with your browser, then pass off public keys to websites. When you'd like to login, then the website queries the browser, and the browser either authenticates you by signing a message back to the server (with your private key). It could be quick and easy... hell, the major OS's now have KeyStores specifically available for just such a use-case. It just needs a spec for browsers and servers to be able to implement... if only. It could also be a federated system setup outside of the browser, but those are also hard to get people to use (although Mozilla has done a good job in trying). My last two jobs (research universities) both had single-sign on options for web applications to use. It was wonderful. Now we just need something that the browser itself can manage. This is a real chicken vs the egg problem, but if we could get a system like this, where we don't need passwords, life would be so much easier. Maybe someone needs to re-invent Kerberos, or at least re-brand it :)
sedachv 12y ago
> I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it. What do you think is the best alternative?
r00fus 12y ago
I also think that with Chrome/iCloud password storing features (and what's possible in iOS8 so apps can access credentials stored against an approved website), passwords become more secure. For years I attempted to get my parents to use 1Password (which I've used and promoted since v2), however, with OS/browser builtin password storage, they are doing much better at not reusing weak passwords.
michaelchisari 12y ago
I was in the beginning stages of working on an open source passwordless system like this, and this is immensely helpful to me. I plan on using this for the small things. Want to authenticate, purchase something small, and maybe never use my service again? This lets you do that. And if you want to create an actual account to do more advanced stuff, that is also an option. I think a hybrid approach is very useful for outward facing web applications.
Pxtl 12y ago
Offering both seems reasonable. Just next to the traditional "lost password" button add a login-by-email button.
kragen 12y ago
How often does a typical user use your system, and how long is the login session good for? I think I would hate such a system if it required me to check my email, say, every day or even once a week, but if it was once every month or two, I think it would be fine.

tngme 12y ago

This is a fair point considering the use scenario that you describe. For other website this might look very different: Think of all those small websites for which you had to create logins but that you rarely use. They are a huge risk due to people's tendency to reuse passwords across important & unimportant sites. For those smaller sites people might not even recognize this system as a traditional login: They simply come back to the site, are asked for their email address if they want to get back to their information, and shortly thereafter they have a link in their inbox to their details/comments/favorites/...

tracker1 12y ago

This really affected me the one day in the past 3 years that I forgot my phone in the morning... There was one site I had enabled 2FA (two factor authentication) on that I hadn't logged in from work yet, and it was really a pain not being able to access it. Honestly, I've been pretty happy simply using LastPass (with a really long passphrase that I haven't shared with anyone) and generating more complex passwords for sites... Just the same, not sure what the best answer is... Especially considering shared computers, portable devices and other devices which may get stolen or hacked.

squeaky-clean 12y ago
I've been very happy with LastPass too. I use it on my desktop and pay for the mobile app. But what I don't get is why we still need to use a password manager extension/app. Why isn't it built into the browser yet? Google already has all of my passwords saved, and synchronized online across devices for whenever I use chrome (well, the passwords I used before switching to LastPass). Why can't it automatically generate secure passwords for me just like LastPass does?
- zackboe 12y ago
  They're working on it! Looks like it's enabled in the most recent version of Canary. http://www.chromium.org/developers/design-documents/password-generation http://www.chromium.org/developers/design-documents/password...
- tracker1 12y ago
  I'm actually trying to unlock myself from Chrome... although it's still my goto browser, I realized I'd fallen in heavily with Chrome, and my passwords are something I can't really share with, say my Firefox, Safari, or IE instances.
  - mbreese 12y ago
    No, you're right. We have password managers built into browsers. That just doesn't work the way we'd like it to. Because of this we have the extra kludge of requiring extensions like LassPass to keep passwords safe and sync'd between browsers/devices. We know that isn't an optimal solution (but it does work...) Instead, what we really need is some kind of identity management built into the browser. We already have something similar to this in terms of private client certificates. You could setup your browser to authenticate you to supporting websites via a client certificate. The problem is, no one is going to do that... it just isn't practical from a workflow perspective. Instead, what I'd like to see is some kind of portable identity solution (similar to a certificate) where you could authenticate with your browser, then pass off public keys to websites. When you'd like to login, then the website queries the browser, and the browser either authenticates you by signing a message back to the server (with your private key). It could be quick and easy... hell, the major OS's now have KeyStores specifically available for just such a use-case. It just needs a spec for browsers and servers to be able to implement... if only. It could also be a federated system setup outside of the browser, but those are also hard to get people to use (although Mozilla has done a good job in trying). My last two jobs (research universities) both had single-sign on options for web applications to use. It was wonderful. Now we just need something that the browser itself can manage. This is a real chicken vs the egg problem, but if we could get a system like this, where we don't need passwords, life would be so much easier. Maybe someone needs to re-invent Kerberos, or at least re-brand it :)

sedachv 12y ago

> I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it. What do you think is the best alternative?

r00fus 12y ago

I also think that with Chrome/iCloud password storing features (and what's possible in iOS8 so apps can access credentials stored against an approved website), passwords become more secure. For years I attempted to get my parents to use 1Password (which I've used and promoted since v2), however, with OS/browser builtin password storage, they are doing much better at not reusing weak passwords.

michaelchisari 12y ago

I was in the beginning stages of working on an open source passwordless system like this, and this is immensely helpful to me. I plan on using this for the small things. Want to authenticate, purchase something small, and maybe never use my service again? This lets you do that. And if you want to create an actual account to do more advanced stuff, that is also an option. I think a hybrid approach is very useful for outward facing web applications.

Pxtl 12y ago

Offering both seems reasonable. Just next to the traditional "lost password" button add a login-by-email button.

kragen 12y ago

How often does a typical user use your system, and how long is the login session good for? I think I would hate such a system if it required me to check my email, say, every day or even once a week, but if it was once every month or two, I think it would be fine.