[sadfnjksdf]

Woah, hold on.

> sort of like two-factor authentication without the two-factor?

If you don't have 2-factor, which most sites don't, then it is 1-factor. This is replacing that 1-factor with another 1-factor.

> So how do I login to my email account for example if I need to login first to my email and get the temporary password? It's a chicken and egg problem.

You are taking him too literally. While he did say it could replace passwords, he obviously didn't mean email auth. Email auth would probably still require a password. Since many have their email password saved, they may not usually have to enter that anyway, most of the time.

> Somewhat flawed idea in theory, even more horrible in practice. I hope this doesn't become a real thing. I will refuse to use any site that implements this flawed passwordless solution.

You've not presented any valid argument against it. Why is it flawed? If it is horrible in practice then why do many companies use SMS as secondary auth (for the "2" in 2-factor)?

[DigitalSea]

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.

[anaphor]

>why do many companies use SMS as secondary auth (for the "2" in 2-factor)?

Because they don't know about TOTP or HOTP, and they instead decided to use a terribly insecure protocol as the basis for user authentication? The onus is on you to prove SMS is better than a shared secret + a nonce.

[sadfnjksdf]

Ok, valid point- to clarify, when I said 2-factor SMS, I was assuming a 30-second TOTP like Google's.

If you don't use TOTP, someone can login to your account just by knowing the password which they can use from almost anywhere. If you were to only use TOTP, they'd need your phone. To me them stealing your phone is tougher than stealing or guessing your password.

[mantrax4]

The problem is that getting email or SMS and having to type that code in every time, then deleting that email/SMS, manually is less convenient that using a password manager.

You can have an "authentication email manager" just like password managers, but then what have we solved exactly? Nothing.

Except that emails, when used as mass-authentication device, will become an even more attractive target to hackers. In most cases accounts are exploited namely via their email password recovery, not via their password.

Email/SMS are an ok layer when used as a second factor, but on their own, they are less secure than a strong password. While logins are HTTPS, email is plain text, so is SMS.

Heartbleed is an exception. Dropping passwords over Heartbleed is precisely the same type of overreaction we had after 9/11 when suddenly flying became a nightmare (and still is).

The proper reaction here is: Heartbleed is fixed, and we better put some resources towards vetting and fixing OpenSSL so this doesn't happen again.

No need to build towers of nonsense that assume it'll be Heartbleed every week now for the next 20 years.

[DanBC]

Dropping passwords because of heartbleed is an over reaction. But passwords are hopessly outdated.

People need secure cryptographic hardware tokens (something they have) with a passphrase (something they know).

[mantrax4]

You're underestimating the work that's been done in secure password managers in the last few years.

Check the whitepaper Apple published regarding their iCloud Keychain mechanism.

It generates secure passwords, locks them with a passphrase, but also makes them available on all your devices, not just one (which, if it breaks, you're locked out of all your services).

Using hardware for tokens is secure and simple, but it shows a severe lack of imagination. I only see hardware tokens as useful for very high security logins, like bank accounts, where the apparent inconvenience is at least justified.