Hacker News Reader

Comment by alkonaut | Hacker News Reader

Shouldn't we just stop using email/password or username/password entirely? It's already relying on the single point of failure being the users email account, because that is where you send your password reset emails. Just add a simple requirement to passwords: 1) user can't choose them and 2) they are single use. Now you don't need to store them in a database.

If an attacker controls my email account then they basically control all my other accounts too.

So how many here tend to not even try to remember passwords, and instead just always hit "forgot password" to log into a site?

Why isn't that the default? I.e. why aren't all passwords single use? I just enter my email, the site generates a secret and sends it to my email account and that's it. It might sound like a hassle - but personally I think it's less of a hassle than using a password manager (I use LastPass and their browser integration is more cumbersome than a copy & paste from inbox!)

View on HN

That was the thought behind Mozilla's BrowserID/Persona. It worked very well, but the true problem has always been adoption by vendors.

Medium did this and it is horrible. Your suggestion solves nothing as you already considered, email bring a single point of failure. So why would anyone sign into a completely different service (for most people that being signed into Google which has its own baggage) just to use an app?

1. Sending emails is not very secure

2. Delegating your authentication to a 3rd party is probably not a very good idea

3. You still need to use a password somewhere e.g. accessing your emails, it can't be mitigated all the way down

4. Increasing the importance of social media accounts / email and allowing walled gardens to act as gatekeepers to services is annoying at best and very harmful at worst if you are concerned about your data

Isn't Oauth delegating your authentication to a third party, and which is generally regarded as a good idea?

It's all about trust. If you trust the 3rd party more then it's good. That could be because the authentication provider has more resources to devote to things like intrusion detection. A separate service also isolates your credentials from the various services.

Downsides include telling that 3rd party every time you sign in and putting all your access rights in one place.

Oauth is an authorization protocol, not an authentication protocol

> 1. Sending emails is not very secure

Agreed. This is a stopgap measure until there is some agreed-upon standard for 2FA that doesn't involve email or text messages.

> 2. Delegating your authentication to a 3rd party is probably not a very good idea

Again, agree. This is of course assuming that everyone has an email provider of the gmail kind that they are both comfortable with trusting with everything and that it will always be available. That's a pretty bold assumption - but I think it's a pretty common one.

> 3. You still need to use a password somewhere e.g. accessing your emails, it can't be mitigated all the way down

It delegates the problem to a place you can trust, where you use a 2FA app or even a physical key, or at worst, a huge password of the kind you can remember ONE of, but not one per service.

> 4. Increasing the importance of social media accounts / email and allowing walled gardens to act as gatekeepers to services is annoying at best and very harmful at worst if you are concerned about your data

Yes, I realize the irony in trading the security of my data in 100 sites for storing it at google. It's a tradeoff I'm willing to do however, lacking some better solution (such as sites actually switching to using some standardized authentication method with physical tokens or similar).

Your points are all invalidated by the mere fact that everyone already uses email for authentication. What do you think the "forgot my password" link does? The GP's flow just makes it more explicit.

How is it invalidated that you need the password mechanism to access your emails? Why would you put resources into annoying your users to sign into their email accounts too every time they want to use your service? It is a very bad design imo.

Yes, password reset can be abused, but doing it all the time I would consider a security hole.

I guess the bullet points aren't the ones that are invalidated, it's the argument that sending a secret key over email to sign in is worse for security than having a password.

It's not worse, it's strictly better, as right now everyone implements both ways and an attacker only needs to break the weakest one.

Do not quite agree. Clearly having more attack surface is worse, but pushing large amounts of sensitive information through mail servers is increasing that surface as well.

How so? Any attacker can trivially push the information they're interested in right now anyway.

If many were to change to email based auth the chances of any leaked (accidentally sent, tricked into forwarding etc) email containing sensitive info would go up significantly. E.g. any mail from medium.com has a very high probability of containing login info.

Second, increased roi makes mail servers more of a target.

Passwordless.net is a NodeJS library for just this concept. It does make a lot of sense for a large majority of websites that don't need to and shouldn't track passwords long term.

Interesting idea. To take it a step further, for sites/accounts you want to reduce the chances of someone gaining access to from a single compromised device you can split the one-time password into two (or more) different parts:

    1. First half of the new one-time key goes to a pre-designated email address
    2. Second half of the key goes to a pre-designated mobile device over SMS

Both need to be entered into the sign in form before you'll be able to access the site/account. The scheme is extensible to include deeper levels of security, too, for situations where your user community is really concerned with access:

    * Email_key + SMS_key + n-digit_PIN
    * Email_key + SMS_key + Pre-paired-hardware_key
    * Email_key + SMS_key + XKCD-style-passphrase

The idea seems straight-forward enough to me that I'd be surprised if someone hasn't already written an authentication library that does something similar. It would be extra steps and a hassle, but like you, I feel that it's already a hassle to use a password manager.

Reply on news.ycombinator.com