Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Authentication API

developer.mozilla.org

Post reply on HN
Print view View original

61–70 of 76 posts

Re: Web Authentication API

#61

Post by konschubert »

tialaramex wrote: post #53
darkhorn wrote: post #34

Can you extract domain names and usernames from the U2F devices? Like if someone wants to learn what sites he is visiting and his usernames?

In practice, no, the tokens are _way_ too dumb to remember anything like that. They're using an old cryptographic trick to appear much cleverer than they really are. During enrollment they present the server with a public key, and a magic cookie, both of which it stores. In subsequent authentication, the server sends them back the cookie, and some random data, which the token then signs to prove it still knows the pr…

This is so cool.

This feels so much like cheating that I was sure it must be flawed, but I couldn't come up with any weakness.

I conviced myself that this is possible by considering the method of using a different permutation of the same key pair on each website and storing that permutation, encrypted, in a cookie.

Cryptography is awesome.

Re: Web Authentication API

#62

Post by emlun »

marknadal wrote: post #46

Sigh, I got all excited, but then discovered this is to be used with a server , which means it fundamentally propagates the idea of "fake security" (where somebody else owns your identity, not you. Check out this explainer for more info: https://gun.js.org/explainers/data/security.html ). This is bad design philosophy, I instead encourage everybody to use the native Web Crypto API to create accounts and do P2P E2EE e…

>where somebody else owns your identity, not you

Care to elaborate on how you mean WebAuthn prescribes that? The GUN explainer videos also seem to assume there's a server involved, so I don't understand what you mean is bad about that.

Re: Web Authentication API

#63

Post by tmd83 »

tscs37 wrote: post #25
euroclydon wrote: post #11

Earlier quoted context omitted.

Is this like Client Certs without the connection to the SSL cert? Oh, I guess client certs are owned and controlled by the server owner...

Sorta, Client Certs but the Client generates and authenticates them, the Server only stores the fingerprint and authenticates them on it's side. And with a better UI and flow since you don't need it to establish connection.

Lack of sleep makes it a bad time for me to read this. But if the client generates the key does it mean it's stored on the browser or something like that? It means that I will need a sync/copy procedure if I'm going to use it in another machine/browser?

Re: Web Authentication API

#64

Post by tscs37 »

tmd83 wrote: post #63
tscs37 wrote: post #25

Earlier quoted context omitted.

Sorta, Client Certs but the Client generates and authenticates them, the Server only stores the fingerprint and authenticates them on it's side. And with a better UI and flow since you don't need it to establish connection.

Lack of sleep makes it a bad time for me to read this. But if the client generates the key does it mean it's stored on the browser or something like that? It means that I will need a sync/copy procedure if I'm going to use it in another machine/browser?

Essentially yes. You'll need something like Firefox Sync or providers will have to implement a way of adding devices.

However the WebAuthn API also leaves options for password managers and other endpoints managing the actual secrets.

Re: Web Authentication API

#65

Post by [deleted] »

cornholio wrote: post #44

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…

[deleted]

Re: Web Authentication API

#66

Post by Ajedi32 »

cornholio wrote: post #52
icebraining wrote: post #47

Earlier quoted context omitted.

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…

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?

Re: Web Authentication API

#67

Post by cornholio »

Ajedi32 wrote: post #66
cornholio wrote: post #52

Earlier quoted context omitted.

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…

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.

Re: Web Authentication API

#68

Post by Ajedi32 »

cornholio wrote: post #67
Ajedi32 wrote: post #66

Earlier quoted context omitted.

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 authenticati…

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.

Re: Web Authentication API

#70

Post by jonny_eh »

pc2g4d wrote: post #36
Ajedi32 wrote: post #5

Earlier quoted context omitted.

More than that. Because it's an open standard it can be used with other types of authenticators, like password managers and platform-level security keys. There are also extensions allowing sites to prompt users for explicit authorization for a specific action. (e.g. "do you want to send $20 to xyz?") In short, this could replace passwords for web authentication entirely.

If I'm not mistaken, the browsers themselves could act as "authenticators" and help people manage credentials in software.

Exactly. Authenticate with your Google account on chrome, iCloud account on safari, or Firefox account on Firefox.
Post reply on HN