related: <a href="https://login.persona.org/" rel="nofollow">https://login.persona.org/</a><p>I will be a very happy person when / if I see a persona login page on more sites
I applaud any effort to fix the "password problem," but isn't this functionally equivalent to just using the "Forgot my password, email me a reset code" link every time you want to log in?
Then a new and huge list of security problems arises when you have to bother the user with getting a new code every time if they have the sense of closing their browser and cleaning their cookies each time they close their browser (which could be as often as whenever they leave their computer); the fact that loosing control of a single email makes you lose control to the account in every site using this system, which beats the idea since that email is most likely password protected anyway; etc, etc.<p>In a nutshell: "In most cases you won't need to do this often" is a HUGE fallacy. It depends on the security rules you work/live by. Plus, it would make it really annoying to use if on top you're using TOR.<p>Yes, passwords need to be fixed. They are weak, problematic and a security cheddar cheese. It is why we are now implementing two factor authentication. Changing the "fixed password" strategy to a "random and time limited password" strategy isn't exactly solving more issues than it raises. Again, from a security-wise stand point.<p>May be if this was implemented with something different than your email. Like, for example, a bank tokens or cell phone verifications... which, again, are part of a two factor authentication because by themselves they would be too easy to break.<p>Think about the following scenario: You use X site with this email auth system and, for example, Thunderbird. Stand up and go to the bathroom or a meeting or whatever without locking your computer. Presto! I won't even need to guess a password and get access. Of course getting access to X site would be the least of your worries in that example, but it illustrates the point I'm trying to make.
Is this any better than a link that logs you in automatically? A link would be easier and more secure. I've actually been thinking of that as a super simple login method lately, but I don't know if people would use it.<p>As a proof of concept, I couldn't actually get your site to work because by the time I understood the UI flow, it was throwing an alert saying "Error with that email address". Also, this goes to spam for me... just to let you know.
So now I have to type my email password into my friend's insecure computer every time I want to use your site? I think I'll be using your site a lot less.
Interesting concept - but what happens if you lose control of your email account (as a user)?<p>Imagine e.g. problems with your DNS (self-hosted and you forgot to renew the domain), outages of your mail provider, or the worst case (for the service provider): your outbound mail server is placed on a blacklist.<p>This way your entire user management system goes up in smoke without ANY way for you to fix it!
I built and open-sourced something like this a while ago: <a href="http://nopassword.alexsmolen.com" rel="nofollow">http://nopassword.alexsmolen.com</a><p>HN thread here: <a href="https://news.ycombinator.com/item?id=4570600" rel="nofollow">https://news.ycombinator.com/item?id=4570600</a><p>It's a great concept, but like any new authentication mechanism there's a usability and security cost due to the lack of familiarity.<p>Plenty of authentication mechanisms are "better" than passwords, but passwords are well-understood and flexible, which is a huge advantage for almost all sites.
For me, a big concern is propagation delay in the email. It sends a token that is valid for only 5 minutes, but with greylisting performed by the spam-filtering machinations in my email provider, there is a good chance I will not get that email within 5 minutes. Trying to send a second one will probably result in some kind of exponential back off penalty also.<p>For that reason alone I don't see how only using email verification as a low-friction way to log in makes sense.
Ooh, no.<p>I really don't consider email nearly reliable enough for any important logins.<p>It might work if I have a password in my password manager as a fallback, but then just using the password manager would be the way to go.<p>Edit: Actually this could work as the fallback for if I for some reason don't have access to the password manager, so I might use it but not for the intended purpose.
The big problem with something like this is that it introduces an attack vector that could compromise all of its users accounts at once and thus making it a major target for attackers (and spy angencies). I don't see any solution for this in a world where even companies with extensive security know-how like Google are successfully attacked.
For those that are interested, I got the ball rolling with email-based logins by building <a href="http://swiftlogin.com" rel="nofollow">http://swiftlogin.com</a>. I was glad to see the idea improved by Mozilla later that year and all the growth since then.
He/(she?) had more of a point if the website would have worked without having to enable javascript for the meteor domain, not even reading it now.