1. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year.[1] That's a long time to go without reauthenticating a client!
2. Authentication is or should be a much more common event than recovering a lost password, and now that's totally dependent on your email provider. One concern is latency.. a minute can feel like an hour while waiting to log in to your account to do something urgent. But also worrisome is provider downtime, spam filters, etc. all can block you from accessing your accounts.
Of course the way they "deal" with #2 is by just trying to avoid authenticating you very often (#1), which is not a generally-applicably awesome security practice. Might be ok in some cases but I wouldn't classify that as an overall "better" way to sign in.
I think a better way to solve this is at the browser/OS level with built-in password generation and management. And that's actually a third drawback to this approach.. it's incompatible with password managers.
> a better way to solve this is at the browser/OS level with built-in password generation and management
I agree. It is also the only method that can guarantee backward compatibility with the millions of existing websites that are not going to move to a different auth method anytime soon.
KeePass, LastPass, et al. have done a tremendous amount of work to make the experience as seamless as possible, but there are still a lot of rough edges because every website has different policies. If most websites agreed to accept strong passwords of a standard format (e.g. 32-byte string of ASCII printable characters), we could finish the automation and just treat passwords like any other key that websites exchange with us all the time.
About a year ago, I proposed that we should come up with a standard login API for websites to adopt, in order to improve the password manager UX [1]. There was quite a bit of discussion, but unfortunately the world seems to be much more interested in getting rid of passwords altogether, no matter how unrealistic it might be. Well, can't blame them, it's always more fun to create something new than to fix something that already exists.
I feel like we're missing the elephant in the room.
The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work.
This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons.
But the real authentication happens when you enter your password to access your email.
Therefore, when I read:
> I think a better way to solve this is at the browser/OS level with built-in password generation and management.
All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?
We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is.
Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one).
Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules).
From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system.
So, is it really a better way to solve this? Not currently.
For your #1: For sites with low security demands that will be Ok. GMail already does it. When I enter GMail it always gets me logged in by an cookie and that lasts for a month or so, only after that period, I have to enter my pw again. Of course, when you do some security relevant changes (like changing passwors ;) ... just kidding ... changing eMail adress), a reauthentication is needed.
I don't think that this scheme is for any site ... banking sites just want to be more secure... but it is very much better, than setting pw="123" on all websites, you don't care to much.
The long log-in duration doesn't really bother me in and of itself. No-one uses my computer without my permission, and no-one uses my browser, period (I create new accounts for people).
If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.
I like the idea. The downside is of course having to switch between the site and your email.
One could bridge that gap by adding two headers to the authentication emails - one containing the URL where the sign in request originated, and one with the sign in URL that must be visited.
A browser extension could then check your emails, and if an incoming mail matches the sign-in page of the current tab, log you in directly.
Bingo! Automating email-based authentication would indeed be pretty cool. In fact, extend this concept a little further, and you will realize that email itself is the ultimate platform to build programmatic exchange of information between persons and services. I wrote an essay about all the possibilities this would open: http://blog.zorinaq.com/?e=76
I implemented this style of login in the app I'm currently building. I don't think its necessarily appropriate everywhere; the reason I decided to use it is that its the type of service you very rarely log into. For things like that, a large portion of logins are (anecdotally) going to end up going through the forgot password flow anyway.
I will admit that not being responsible for storing passwords was one of the reasons I used it. I'm by no means a security expert; one less thing I can screw up seems like a major plus.
I've done the same thing in a few prototype-style apps I've built too. Not only do you not need to store passwords, but you can just ignore a whole area of UX.
Enter email to signup -> link gets emailed.
Enter email to login -> link gets emailed.
I use JWT for this and it really makes it easy to get started on the part of the project that matters... and sometimes (not always) I think it's probably going to be fine to leave it this way.
A modern password manager (e.g. 1Password) seems like a way more natural solution that this. Not to mention that many services do not use smtpd+ssl/tls.
I disagree with this. I see services like 1Password as a bandaid for the tech savvy population. They are solving the password problem well, but only if you seek out the tool and understand the need for the tool. Approaches like the author's here solves the password problem for the majority of the population - the non-tech savvy population.
To your second point. Yes, this is true. But this is improving [1]. I'd add that forgot password functionality carries the same risk, and I'd add that the more likely chance of your password being 'discovered' is by brute force or a website hack storing passwords in plain text - rather than intercepting email.
I agree. I use KeePassX with both keyfile and passphrase. Keyfile is always offline and database is on Dropbox for syncing purposes. If I want to use it on Android, I manually move the keyfile and access database off the cloud. I create 25 characters long passphrase for each website. Works way better than single sign on. No one can every deny me service or close my account.
I really like this, I was thinking the other day when I used a site that I rarely use, and went through the whole 'forgot resend reenter' password thing that just that could be the 'standard' way of dealing with low impact sites and wouldn't force a password to be generated. It does imply the mail path is workable but that seems pretty common these days.
It's clever but I wouldn't use it. First the user experience of going from one channel (web) to another (email) isn't very natural but the second and biggest reason is that it turns an email account into a central authority to access my other accounts from.
Some say email is already like that but it isn't with services using two factor authentication.
I don't think there is an easy and intuitive way to get rid of passwords without involving some sort of physical component that stays on yourself.
What is your workflow that this would be any more difficult? The first time you sign up for a service you almost always have to do this anyway for confirmation. If you then select the "Remember me" path, your primary computer is whitelisted and you don't have to do the round-trip.
Due to "Forgot my password" workflows email is already a central authority. If you have two factor auth set up for your email account then you're already pretty well protected and having each and every service use a different two-factor method provides diminishing returns in security.
The funny thing about this proposal is that it is exactly the way my non-technical family members use every service. They don't bother with passwords they just use reset links every time. They don't have to remember anything and it's a common workflow.
You don't have to do that. Persona is pluggable, and what looks like your email address isn't, really. For example, I made a third-party authentication platform that you can use to authenticate, instead of your email provider: https://www.persowna.net/
Sure, 2-factor auth (by its very nature) prevents sign-in from a single source, but 2FA is an additional layer of security on top of passwords, NOT a reason why email isn't already a central way to bypass password security.
To put it another way: This article describes logging in to a service via an email sent to your account. Every major service already has this in-place via the use of the "forgot password" link; if I have access to your email account, I can already log into any service which sends a reset link to your inbox.
2-factor auth is great as an additional layer of security on top of either this method or the traditional password method, so why not just remove the additional vulnerability of permitting logins via passwords stored everywhere else on the internet, too?
I remember this idea from a while back, and I still think it's not going to work. It's too cumbersome to have to access your email every time you want to log into something. I love the creativity of the solution, but I just don't think it's workable on a large scale.
Now that we all have push email in our smartphones, it's not nearly as cumbersome. I already need to pull out my phone every time I want to access a Google app, having 2FA enabled.
This is still nothing more than a password...it's essentially just a password that is emailed to you. I've never understood why we can't instead authenticate ourselves to our browser or device, and get people out of the habit of authenticating to individual websites. This would eliminate phishing and greatly enhance security. Touch ID is a big step in this direction, but still can't be used for websites.
When authenticating, the browser could just send the user's public key, and if a user with that key is in the system, it replies with a session key encrypted with the user's public key. If browser companies would get their act together, we wouldn't have as many authentication issues as we do today.
It is possible to use public key authentication with most modern browsers (not sure exactly which browsers support this). However, it's true that browsers currently don't provide any method to authenticate the user with the browser itself. (Although you could argue whether or not this is necessary since the user has presumably already authenticated with the machine running the browser.)
The biggest problem is that the user experience is pretty terrible for generating and managing the certificates used for authentication. There's also the fact that the certificates are stored by the browser with no obvious mechanism to log in from another machine.
This essentially mimics my login flow to every site I only use occasionally (e.g. twitter) and therefore can never remember the password for:
1. Go to login
2. Forget password - click reset password
3. Go to email, find reset password email
4. Login.
I wouldn't really mind if this became more common. I don't trust password managers (and access the internet from so many different devices that the only common thing they share between them is that I can access my webmail client or email on my phone.)
LastPass was considered secure on HN in the past, has this changed? Or is there a reason you don't like it? Not attacking, just curious about my own security.
The cynic in me observes that although this post is couched in the language of an improved UX, what it also does is absolves Mozilla from keeping any (hashed) passwords stored in their databases. Only tokens with a very short shelf-life.
(Hashed) Password storage is moved to a third-party database (the email provider). Presumably the client "remember me" links are meaningless by themselves.
Of course - and thats fantastic! There's one less place that people will trust with a shared password.
A very large percentage of users reuse the same password on multiple sites. If you do that, a security breach in any site will leave your password exposed on all sites. And if you're anything like me, you have an account on all sorts of tiny sites.
You really can't trust the security of any startup thats less than 2 years old, or less than 5 people. Most software engineers don't know infosec well enough to implement a proper password database and protect it. Most startups are only 'secure' because they're such small threat targets that they don't have much value in attacking. However, if those small targets store username and passwords that get reused on lots of websites, everybody loses.
If the 'reset password' link sends an email, users have to trust their email security anyway. If I have access to your email, I can reset your facebook, twitter, etc passwords then delete the password reset link & notification from your email account. Google is going to do a better job at password security than a 3 month old startup with 1 engineer.
Absolving mozilla (or anyone else) from keeping passwords improves security.
In mobile the sign up flow can even be more streamlined using deep linking:
1. User enters email address.
2. Opens email client and click the link.
3. Link contain app specific schema myapp://login?token=cold_fish etc.
4. App opens and verifies the token with the server.
5. User is logged in.
User has to enter only email address as opposed to email + password (and sometime password confirmation)
Then only needs to click a link in email client to sign up.
Isn't email transferred in plain text? This is not very secure in my mind. Granted, nowadays a lot of service lets you reset your password through email, but that is only a one time thing. Now the whole system is dependent on someone not introspecting the packets flowing in the Internet.
That's historically true but TLS is now really common on both servers and clients. In fact most major email clients I've seen show a warning if the server only supports plain text.
Thunderbird shows a large modal "WARNING! Server mail.myhost.com does not use encryption" dialog.
I too would "like to see [this approach] used and pushed further by other designers and developers."
I'm one of those who have been trying to do so. I created an open source approach called Handshake.js that is re-usable for developers. [1]
I presented this topic to a good crowd at JS.LA [2].
At the current time, I'm finding developers still hesitant to jump into the approach. Passwords are familiar and there are many developer tools/libraries to quickly setup the defacto username/password approach to authentication.
It uses the same idea as in the post, ie the "lost password flow for login", but with XMPP. The latter gives you much higher flexibility in that it actually is thought out as a programmable protocol. You try to login, the server sends a token to any of your connected clients via a bot message, you just repeat it to the bot and you're then granted access.
Playing with NetBSD the other day, and bored, I created an SSH key for the first time and was amazed that I had not been using this for forever. I think keys could replace passwords, or at least, cookie based logins.
Client-authentication has actually been supported in SSL for a long time [1]. Unfortunately, there seems to be little interest in using that form of authentication in browsers. A big part of that is probably making a compelling user interface and teaching users how it works.
What's funny is that we're basically doing a very similar thing at my startup, PricePlow (https://www.priceplow.com), and it was actually inspired by discussion earlier here at Hacker News.
It works very well for our purposes. We don't need crazy security because we store no important personal information -- just product preferences. It's insanely easy on the users.
I guess I should get back to blogging about my entrepreneurial lessons learned, as this has been one of many of them....
So instead of directly logging in using the ID provider like FB/Google/Microsoft, which are also the email providers, you send an email to those accounts and ask user to take one extra step of checking and clicking the link. It seems to be inefficient. A much better solution should be for the devices to support accounts natively and integrate authentication directly into the platform.
The idea seems to be that you only have to do this once, then you remain authenticated for every service that integrates with this authentication service. You don't have to remember another password or place trust in a new service not to mishandle it.
This seems like a solution that completely replaces the need for every website to manage their own user signups, which is something you still need to do even if you integrate with Google/Facebook/etc. because not everyone has an account with those and signing up for one is less trivial than having a sign-in link sent to your email.
How is this any materially different than the "I always forget my password and I always use the forgot password link"? I guess you don't have to pick a new password each time? But you could just rapidly type in gibberish and achieve nearly the same effect, no real password, login via email.
The biggest reason for me to pass on implementing an approach like this is what I THINK is the actual most common use case for a typical user when logging into a site at which they are a regular:
They're doing so for the nth time, and on the (or a) device they usually use, and thus their browser (or other password manager) has already got their password remembered and thus it is pre-filled in.
Having to click back and forth between email every time you log in seems way clunky relative to that, which for me is something above 90% of the instances I log in to some web application.
Couple that smoothness with picking a non-reused, strong password for a web application (which password managers make actually practical) and the friction in the user login experience seems to have little if any upside.
In the email, you can click "Sign in & remember me". I guess that sets a cookie in your browser, so next time you come back, you'll still be logged in (until the cookie expires).
[+] [-] abalone|11 years ago|reply
1. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year.[1] That's a long time to go without reauthenticating a client!
2. Authentication is or should be a much more common event than recovering a lost password, and now that's totally dependent on your email provider. One concern is latency.. a minute can feel like an hour while waiting to log in to your account to do something urgent. But also worrisome is provider downtime, spam filters, etc. all can block you from accessing your accounts.
Of course the way they "deal" with #2 is by just trying to avoid authenticating you very often (#1), which is not a generally-applicably awesome security practice. Might be ok in some cases but I wouldn't classify that as an overall "better" way to sign in.
I think a better way to solve this is at the browser/OS level with built-in password generation and management. And that's actually a third drawback to this approach.. it's incompatible with password managers.
[1] https://chrisdecairos.ca/one-time-passwords-pt-2/
[+] [-] kijin|11 years ago|reply
I agree. It is also the only method that can guarantee backward compatibility with the millions of existing websites that are not going to move to a different auth method anytime soon.
KeePass, LastPass, et al. have done a tremendous amount of work to make the experience as seamless as possible, but there are still a lot of rough edges because every website has different policies. If most websites agreed to accept strong passwords of a standard format (e.g. 32-byte string of ASCII printable characters), we could finish the automation and just treat passwords like any other key that websites exchange with us all the time.
About a year ago, I proposed that we should come up with a standard login API for websites to adopt, in order to improve the password manager UX [1]. There was quite a bit of discussion, but unfortunately the world seems to be much more interested in getting rid of passwords altogether, no matter how unrealistic it might be. Well, can't blame them, it's always more fun to create something new than to fix something that already exists.
[1] https://news.ycombinator.com/item?id=5743057
[+] [-] espadrine|11 years ago|reply
The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work.
This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons.
But the real authentication happens when you enter your password to access your email.
Therefore, when I read:
> I think a better way to solve this is at the browser/OS level with built-in password generation and management.
All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?
We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is.
Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one).
Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules).
From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system.
So, is it really a better way to solve this? Not currently.
[+] [-] asdfaoeu|11 years ago|reply
For a lot of sites I use with low frequency my login procedure is basically just reset password, and login with new password.
[+] [-] PythonicAlpha|11 years ago|reply
I don't think that this scheme is for any site ... banking sites just want to be more secure... but it is very much better, than setting pw="123" on all websites, you don't care to much.
BTW: I also described a similar idea some time ago in a blog post: http://strategieneu.blogspot.de/2014/06/email-only-registrat...
After I wrote it, that such ideas where discussed at HN even some time ago.
[+] [-] wtbob|11 years ago|reply
If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.
[+] [-] janfoeh|11 years ago|reply
One could bridge that gap by adding two headers to the authentication emails - one containing the URL where the sign in request originated, and one with the sign in URL that must be visited.
A browser extension could then check your emails, and if an incoming mail matches the sign-in page of the current tab, log you in directly.
[+] [-] mrb|11 years ago|reply
[+] [-] thedufer|11 years ago|reply
I will admit that not being responsible for storing passwords was one of the reasons I used it. I'm by no means a security expert; one less thing I can screw up seems like a major plus.
[+] [-] thenduks|11 years ago|reply
Enter email to signup -> link gets emailed. Enter email to login -> link gets emailed.
I use JWT for this and it really makes it easy to get started on the part of the project that matters... and sometimes (not always) I think it's probably going to be fine to leave it this way.
[+] [-] atmosx|11 years ago|reply
[+] [-] scottmotte|11 years ago|reply
To your second point. Yes, this is true. But this is improving [1]. I'd add that forgot password functionality carries the same risk, and I'd add that the more likely chance of your password being 'discovered' is by brute force or a website hack storing passwords in plain text - rather than intercepting email.
[1] https://sendgrid.com/blog/sendgrid-and-the-future-of-email-s... (I work at SendGrid)
[+] [-] donniezazen|11 years ago|reply
[+] [-] ChuckMcM|11 years ago|reply
[+] [-] BinaryIdiot|11 years ago|reply
Some say email is already like that but it isn't with services using two factor authentication.
I don't think there is an easy and intuitive way to get rid of passwords without involving some sort of physical component that stays on yourself.
[+] [-] iandanforth|11 years ago|reply
Due to "Forgot my password" workflows email is already a central authority. If you have two factor auth set up for your email account then you're already pretty well protected and having each and every service use a different two-factor method provides diminishing returns in security.
The funny thing about this proposal is that it is exactly the way my non-technical family members use every service. They don't bother with passwords they just use reset links every time. They don't have to remember anything and it's a common workflow.
[+] [-] StavrosK|11 years ago|reply
[+] [-] wilkystyle|11 years ago|reply
To put it another way: This article describes logging in to a service via an email sent to your account. Every major service already has this in-place via the use of the "forgot password" link; if I have access to your email account, I can already log into any service which sends a reset link to your inbox.
2-factor auth is great as an additional layer of security on top of either this method or the traditional password method, so why not just remove the additional vulnerability of permitting logins via passwords stored everywhere else on the internet, too?
[+] [-] soneca|11 years ago|reply
Why not one of these on a thin enough tag to stick on your phone? Sounds like a very good solution for me.
(1) http://en.wikipedia.org/wiki/Security_token#Disconnected_tok...
[+] [-] pmichaud|11 years ago|reply
[+] [-] esolyt|11 years ago|reply
That is not the case. It will remember you every time you come back. You just never set a password when registering.
[+] [-] ricardobeat|11 years ago|reply
[+] [-] downandout|11 years ago|reply
When authenticating, the browser could just send the user's public key, and if a user with that key is in the system, it replies with a session key encrypted with the user's public key. If browser companies would get their act together, we wouldn't have as many authentication issues as we do today.
[+] [-] michaelmior|11 years ago|reply
The biggest problem is that the user experience is pretty terrible for generating and managing the certificates used for authentication. There's also the fact that the certificates are stored by the browser with no obvious mechanism to log in from another machine.
[+] [-] awendt|11 years ago|reply
No, it's an OTP. And that's so much more than a password...
[+] [-] sarahj|11 years ago|reply
1. Go to login
2. Forget password - click reset password
3. Go to email, find reset password email
4. Login.
I wouldn't really mind if this became more common. I don't trust password managers (and access the internet from so many different devices that the only common thing they share between them is that I can access my webmail client or email on my phone.)
[+] [-] Lost_BiomedE|11 years ago|reply
[+] [-] jordanpg|11 years ago|reply
(Hashed) Password storage is moved to a third-party database (the email provider). Presumably the client "remember me" links are meaningless by themselves.
[+] [-] josephg|11 years ago|reply
A very large percentage of users reuse the same password on multiple sites. If you do that, a security breach in any site will leave your password exposed on all sites. And if you're anything like me, you have an account on all sorts of tiny sites.
You really can't trust the security of any startup thats less than 2 years old, or less than 5 people. Most software engineers don't know infosec well enough to implement a proper password database and protect it. Most startups are only 'secure' because they're such small threat targets that they don't have much value in attacking. However, if those small targets store username and passwords that get reused on lots of websites, everybody loses.
If the 'reset password' link sends an email, users have to trust their email security anyway. If I have access to your email, I can reset your facebook, twitter, etc passwords then delete the password reset link & notification from your email account. Google is going to do a better job at password security than a 3 month old startup with 1 engineer.
Absolving mozilla (or anyone else) from keeping passwords improves security.
[+] [-] dekz|11 years ago|reply
I'm not sure what you're saying here:
> (Hashed) Password storage is moved to a third-party database (the email provider)
There is no hashed password? It's just a challenge response using an alternative path.
[+] [-] mderazon|11 years ago|reply
In mobile the sign up flow can even be more streamlined using deep linking:
1. User enters email address.
2. Opens email client and click the link.
3. Link contain app specific schema myapp://login?token=cold_fish etc.
4. App opens and verifies the token with the server.
5. User is logged in.
User has to enter only email address as opposed to email + password (and sometime password confirmation) Then only needs to click a link in email client to sign up.
[+] [-] netheril96|11 years ago|reply
[+] [-] AReallyGoodName|11 years ago|reply
Thunderbird shows a large modal "WARNING! Server mail.myhost.com does not use encryption" dialog.
[+] [-] scottmotte|11 years ago|reply
I'm one of those who have been trying to do so. I created an open source approach called Handshake.js that is re-usable for developers. [1]
I presented this topic to a good crowd at JS.LA [2].
At the current time, I'm finding developers still hesitant to jump into the approach. Passwords are familiar and there are many developer tools/libraries to quickly setup the defacto username/password approach to authentication.
[1] https://sendgrid.com/blog/lets-deprecate-password-email-auth... [2] https://vimeo.com/90883185
[+] [-] rakoo|11 years ago|reply
https://github.com/rakoo/xauth
It uses the same idea as in the post, ie the "lost password flow for login", but with XMPP. The latter gives you much higher flexibility in that it actually is thought out as a programmable protocol. You try to login, the server sends a token to any of your connected clients via a bot message, you just repeat it to the bot and you're then granted access.
I feel there is high potential here, and there even is an official XEP (http://www.xmpp.org/extensions/xep-0070.html) for this.
[+] [-] RexRollman|11 years ago|reply
[+] [-] bajsejohannes|11 years ago|reply
[1] https://en.wikipedia.org/wiki/Transport_Layer_Security#Clien...
[+] [-] MicroBerto|11 years ago|reply
It works very well for our purposes. We don't need crazy security because we store no important personal information -- just product preferences. It's insanely easy on the users.
I guess I should get back to blogging about my entrepreneurial lessons learned, as this has been one of many of them....
[+] [-] thesumofall|11 years ago|reply
[+] [-] harigov|11 years ago|reply
[+] [-] hmsimha|11 years ago|reply
This seems like a solution that completely replaces the need for every website to manage their own user signups, which is something you still need to do even if you integrate with Google/Facebook/etc. because not everyone has an account with those and signing up for one is less trivial than having a sign-in link sent to your email.
[+] [-] codinghorror|11 years ago|reply
[+] [-] esolyt|11 years ago|reply
Besides, I don't think they are claiming to be innovative. I think they just point out there is a redundant step which we can remove from the process.
[+] [-] jplarson|11 years ago|reply
They're doing so for the nth time, and on the (or a) device they usually use, and thus their browser (or other password manager) has already got their password remembered and thus it is pre-filled in.
Having to click back and forth between email every time you log in seems way clunky relative to that, which for me is something above 90% of the instances I log in to some web application.
Couple that smoothness with picking a non-reused, strong password for a web application (which password managers make actually practical) and the friction in the user login experience seems to have little if any upside.
[+] [-] troymc|11 years ago|reply