Hacker News Reader

Comment by jordanpg | Hacker News Reader

The cynic in me observes that although this post is couched in the language of an improved UX, what it also does is absolves Mozilla from keeping any (hashed) passwords stored in their databases. Only tokens with a very short shelf-life.

(Hashed) Password storage is moved to a third-party database (the email provider). Presumably the client "remember me" links are meaningless by themselves.

View on HN

Of course - and thats fantastic! There's one less place that people will trust with a shared password.

A very large percentage of users reuse the same password on multiple sites. If you do that, a security breach in any site will leave your password exposed on all sites. And if you're anything like me, you have an account on all sorts of tiny sites.

You really can't trust the security of any startup thats less than 2 years old, or less than 5 people. Most software engineers don't know infosec well enough to implement a proper password database and protect it. Most startups are only 'secure' because they're such small threat targets that they don't have much value in attacking. However, if those small targets store username and passwords that get reused on lots of websites, everybody loses.

If the 'reset password' link sends an email, users have to trust their email security anyway. If I have access to your email, I can reset your facebook, twitter, etc passwords then delete the password reset link & notification from your email account. Google is going to do a better job at password security than a 3 month old startup with 1 engineer.

Absolving mozilla (or anyone else) from keeping passwords improves security.

I don't know if I'd call this "fantastic". It simply relocates the attack. Ostensibly, the thing that is improving security is having a stronger password elsewhere rather than those recycled ones that you mentioned, but this is not guaranteed and, I suspect, not the case in most instances. It's really like using an email account as a password manager.

You get sent an OTP that expires after half an hour. So in order to attack someone, you need to gain access to your victim's e-mail account beforehand. Which is quite hard if if the victim has MFA activated.

If you gain access to your victim's e-mail account, even if you find any passwords in there, you cannot use any of them because they are not working anymore.

So it's not only a stronger, non-recycled password. It's:

1. an OTP

2. that expires very soon

3. that cannot be recycled

4. in a place that's likely to be well-protected

EDIT: 5. that place (#4) is in widespread use

This is beyond a "password manager" which barely covers #3 (it incentivizes not to recycle) – and maybe #4, if you're careful.

Almost all services have a "forgot password" link that will send a reset to your email account.

The solution in this article isn't really "relocating" the attack... more like removing additional attack vectors and limiting it to the email vector (which already exists right now, anyway).

The authentication providers are more than just email (the article mentions phone and SMS tbd).

I'm not sure what you're saying here:

> (Hashed) Password storage is moved to a third-party database (the email provider)

There is no hashed password? It's just a challenge response using an alternative path.

My assumption is that a "login key" is essentially a large piece of data that would be prohibitively inconvenient to use outside of an email account, text, etc. Analogous to a large session cookie without an expiration date.

In contrast, a password is designed to be used from any login point.

In this regime, unless the optional password is used, there is no hashed password stored on Mozilla's servers. Only a copy of the hash of the "login key" is stored, so the attack surface is considerably shrunk if you are attacking Webmaker users.

More technical details here from the post:

https://chrisdecairos.ca/one-time-passwords-pt-2/

I'm not totally clear about what the different between a "login key" (short-lived, pronounceable) and whatever is contained in these semi-permanent login email links (~1 year, presumably non-pronounceable).

The login key is in the article in the example screenshot[1]: 'hopping-smiles'.

[1]: http://notebook.ideapublic.org/wp-content/uploads/sites/5/20...

The onus on protecting the users password is now on the email provider, since they aren't going to have this kind of system

No the onus is still on the user. How does the onus move to the channel provider?

I don't see a difference in this and 'Reset your password' links in emails that are common place. They are basically the same premise, without the password.

Reply on news.ycombinator.com