4 ms·

I wonder if this API can be coaxed into providing a method of authentication for "the other" 99% of people and use cases, without a hardware token and in a devi

I wonder if this API can be coaxed into providing a method of authentication for "the other" 99% of people and use cases, without a hardware token and in a device-independent fashion, using passwords only. That may sound contradictory or that it misses the point, but let me explain. 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. What this achieves is a login system that covers the way social login/Facebook/OAuth is used, without giving any power to a 3rd party. The password never leaves his machine and the user is not dependent on any particular hardware or keyring. So for all those "I can't trust this website with a secure password / I can't be bothered to signup" cases, you will have a strong authentication scheme that is as secure as your (salted and stretched) master password, and where you are guaranteed that a compromise on one of the sites does not spill over to the rest. Unless you choose to reuse a username, your identities will be independent and unlinkable, unlike any social login scheme, preserving privacy. The user complexity is similar to what regular people already know, usernames and passwords - you can even safely reuse a strong password. The essential difference is that you should trust only your device / browser with the password, not the site.

icebraining 8y ago
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.
- cornholio 8y ago
  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.
  - Ajedi32 8y ago
    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?
    - cornholio 8y ago
      >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.
      - Ajedi32 8y ago
        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.
homakov 8y ago
You just described https://github.com/sakurity/securelogin https://github.com/sakurity/securelogin
- cornholio 8y ago
  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.
  - homakov 8y ago
    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.
deleted 8y ago
[deleted]
StavrosK 8y ago
> 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.

icebraining 8y ago

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.

cornholio 8y ago
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.
- Ajedi32 8y ago
  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?
  - cornholio 8y ago
    >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.
    - Ajedi32 8y ago
      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.

homakov 8y ago

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

cornholio 8y ago
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.
- homakov 8y ago
  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.

deleted 8y ago

[deleted]

StavrosK 8y ago

> 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.