Hacker News Reader

> The password can be used to locally decrypt a secret key that is stored on the server at registration time, and that is retrieved based on the username provided.

I'm not sure I understand the advantage here. You're still dependent on a password.

> you will have a strong authentication scheme that is as secure as your (salted and stretched) master password

So, as secure as we have now.

> where you are guaranteed that a compromise on one of the sites does not spill over to the rest

Why not? If I use the same password for all sites, the attacker can just use that password to authenticate to all other sites (by decrypting all the other secret keys with it).

> Unless you choose to reuse a username, your identities will be independent and unlinkable

They're independent and unlinkable with passwords now, too. The only improvement is that your password doesn't go over the wire, which, admittedly, is a moderate improvement.

Seems like in that scheme anyone can retrieve the encrypted secret without authentication (just by knowing the username), and then try to brute-force it at will.

In a real world implementation this can be easily avoided by breaking the retrieval query into a challenge-response like:

  retrieve_salt(username)
  retrieve_keyfile(username, encrypt(streched_password, salt, server_name))

So the offline, parallel crack turns into an online, serial and rate-limited bruteforce. The salt and password derived shared secret are established at account setup time and after any password change, which the browser must support too.

This still has some imperfections related to replay susceptibility, but my point isn't to design a protocol, rather the principle of a thing that could make social login obsolete and stone-age.

So now the server needs to store a copy of your stretched master password? How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct?

Why not just use public key authentication, like the Web Authentication standard already does?

>How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct?

By comparing it to the static value stored at account setup time. The server trusts your shared secret just like it trusts your public key - establishing the identity of a public key is a different problem with various solutions, CAs, WoT, directory servers etc. The idea here is to move from plain authentication (user/password) to a public key system without carrying the key material around, but deriving it when needed from your password.

So the server stores a copy of your encrypted keyfile, salt, and the result of `encrypt(streched_password, salt, server_name)`?

That's better, but still allows malicious sites (or anyone who compromises the database of a site you have an account on) to brute force your master password offline. Slightly better than reusing passwords since there's no danger of sites using a weak hash algorithm or storing your password in plaintext, but still not great.

IMO if you _really_ don't want to carry the key material around (which _does_ necessarily reduce security btw, as you're going from "something you have" + "something you know" to just "something you know", which is easier to steal and inherently susceptible to brute force), then it'd be much simpler to just derive a private key from `(user password, site id)` and use that with WebAuthn.

You just described https://github.com/sakurity/securelogin

It's an interesting project, although the blockchain incarnation seems to go in a different direction, more akin to social login.

While I congratulate you for your efforts, I can't really see the point of implementing this outside of the browser as anything more than a proof of concept. The whole idea is to replace the trust in a web service with the trust into the user agent, I would approach this as specification/standardization work, not something you whip up an electron app for.

The Failsafe work is fascinating, I just discovered it thanks to your link and I'm digging in.

Thanks, the blockchain part is recent and isn't relevant. Otherwise it's super simple idea: strong derivation based on something anyone can remember (username + pw) + website origin = strong non-reusable credentials w/o hardware.

It's definitely would be more successful being part of the browser, but Web Auth API is too slow to move so I went out to make a PoC instead. In the end: I hate electron apps now :) Also I now know what kind of effort is needed to change the auth space... I don't believe it will happen short term :/ It's too hard and too little incentive to change things.

The only perk of being outside the browser is being able to auth regular desktop apps like Spotify or Btc wallets. But yes, 99% are web apps so seamless in-browser login would make more sense.