Hacker News Reader

Comment by wiremine | Hacker News Reader

While this feels similar to a password reset process, it is different:

a. you're sending the auth credentials every single time a user wants to login. If email was secure, that might be fine, but it's not.

b. On a password reset, you typically require a user to actually reset their credentials, and then allow them to continue. In this case, if someone accidentally forwards the email, or enters the wrong email address, the recipient automatically gets access to the account, no questions asked.

It is an interesting concept, though. I don't really know if I like it yet, but it's nice to see people trying to work on this problem.

View on HN

Account recovery emails should probably use one time tokens, meaning that after you click on the link once, the link becomes invalidated. This would largely solve the issue with point b.

Not only one time tokens, but with limited life-span. So after a while the token expires and is useless. This is a must for such a scheme.

Both of these, plus a differentiator between 'current' and 'new' token requests - without that, it's an easy way to log people out of sites by simply knowing their email address. To the point about not always having access to email, it's a pretty simple denial of service vector.

Can you clarify, what you mean by "differentiator between current and new token requests"? Currently I don't exactly know which attack form you mean and how it could be prevented by such a "differentiator".

(an example would be nice)

In general email is more protected than other passwords: people understand that they need to protect their email.

Without other tools (e.g. PGP) email is not a secure communication medium. Any email can be intercepted from any server or router it passes through between sender and recipient. This weakness has nothing to do with compromising the password of the recipients' accounts, it's a fundamental flaw in the design of email.

That's no longer true. Most end user access to email is over a secure channel (https/imap with tls). While SMTP between most servers uses TLS as well.

The problem is we don't know if the message was sent over secure channels or not. I suppose the password less scheme could refuse to work with SMTP servers that don't encrypt the traffic.

This does in no way prevent those servers from reading and/or altering your message. Hint: if your provider checks your email for viruses, it must be able to decrypt them.

b.) wouldn't make a difference if the account is compromised

It would in cases where there wasn't an _intentional_ attack. If I accidentally sent a log in email to my Mom, and she clicked it, odds are she wouldn't know what was going on: there is no challenge screen asking for a new password. She's just see my account.

Reply on news.ycombinator.com