| That is exactly the point. The author is proposing we replace one thing with another which doesn't fix the problem. There'll just be some other vulnerability with a passwordless approach we'll have to work around. I don't see the point to be honest. Passwords aren't what make web applications and services insecure, nor are they any more of a risk than say sending a user a temporary code to enter to login. I am taking him somewhat literally because the author and the sensationalist title saying passwords are obsolete. As you pointed out yourself, passwords are not obsolete because how else are we going to login to our email to get our temporary passcodes (if sent to our email)? Any solution which pitches itself like: well you would use it for everything except for the one thing you most likely would care about protecting over everything else, your email. My argument against this approach is it doesn't solve the problem. Those generated passcodes are being stored somewhere on the server-side, correct? How is what the author proposing any different to that of a securely hashed password? Replace hashed password with hashed temporary code and you get the same results: they're both passwords when you view this proposed solution on a technical level. To quote a few parts of the article: Passwords are obsolete because of email and SMS. Specifically, the ability to send an email or SMS to users reliably and quickly. In theory, we’ve had that ability for a long time. Sending our a passcode via SMS which the author seems to be a fan of costs money. Unless you're the likes of Google, Facebook or Twitter, implementing a solution that costs real money on an already tight-budgeted service is most likely at the bottom of your priority list, if you have thousands of users logging in daily, that's a lot of cash being spent, even if an SMS is cents on the dollar. Why would I implement a solution that is for people too lazy to use a password manager or use strong passwords for the various web services they use? Adding in functionality that requires use of a third party service also doesn't sit well with me. I have to trust that Twilio or whomever is sending out these SMS's have a secure service that isn't going to allow the wrong people to get passcodes sent from the website because of some API flaw nobody has discovered yet (or heartbleed like attack). But the recent Heartbleed bug highlights the fact that hacking password reset flows for convenience is not good enough. We need to convince websites to stop using passwords altogether. As I pointed out, this temporary passcode approach isn't truly passwordless. A hash is being generated on the server side, stored in a database awaiting a user to login. The difference being the server is generating the passcode for you and you're trusting that passcode is secure enough. |