10 ms·

Web Authentication API

299 points by Jaruzel 8y ago

farleykr 8y ago
I'm a beginner in this area, but maybe someone can help me out. Would this be a replacement for something like Passport or Auth0?
- kroltan 8y ago
  Not exactly. It is an alternative to the concept of passwords in general. But it is not a complete solution to all the things covered by those services.
Ajedi32 8y ago
This is going to be _huge_ for the security of the average web user once it starts getting widespread adoption. Credential phishing, password reuse, credential stuffing, and weak passwords are all about to be a thing of the past, at least insofar as the web is concerned.
- dmortin 8y ago
  Doesn't this mean that if the authenticator is cracked then all of your accounts are revealed and become vulnerable? Compared to the situation today when if one your passwords is cracked they can't immeidately access your other accounts.
  - vorpalhex 8y ago
    It's no worse than them breaking into a password manager, and is quite a bit better since they now have to deal with full on private keys. Most passwords are vulnerable because they are easily guessed, not because somebody breaks your encrypted password store.
  - Ajedi32 8y ago
    Stealing Web Authentication keys from a hardware token is a significantly higher bar than phishing you or brute-forcing your password hash from a database leak. At the very _least_ the attacker would first have to compromise your machine with malware, at which point they could easily get access to all your password-protected accounts anyway with a simple keylogger.
    - dmortin 8y ago
      What happens if you lose your hardware token (or it gets stolen, ec.)? Is there a way for then to access your accounts?
      - gruez 8y ago
        backup/recovery codes and/or "forgot your password (authenticator)" recovery
      - StavrosK 8y ago
        Ideally (and hopefully this will be doable, as I don't see any impediments), you can have Bitcoin-wallet-style seed generation that you can back up onto a piece of paper and store it somewhere safe. I really hope my Ledger Nano S becomes WebAuthN-compatible, as it can already be used as a U2F key.
        tialaramex 8y ago
        Yes, for a device as complicated as the (~ $100) Ledger Nano S I don't see any reason they couldn't support that functionality. Most people will be using much cheaper, dumb authenticators which aren't going to have the capability to read and update the keys, they would be expected to replace their authenticator altogether, not try to clone it if there's a problem.
      - ethagnawl 8y ago
        This could introduce latency and centralization to the authentication process, but perhaps there could be a public key server/service that would allow the user to issue a revocation certificate. This scenario could also be a legitimate use case for blockchain technology.
  - tialaramex 8y ago
    The authenticators are physical property of the people they authenticate. If you're especially worried you can remove it when not using it, you can lock it in a safe, you can give it to your personal bodyguard to protect with their life. Air gapped authenticators are plausible, although they'd be awful from a usability perspective, if you're really that paranoid... Whereas all your passwords are just bits, and you have to transmit those bits to a remote party every time you authenticate. You can't keep those bits safe, only trust that everybody else is looking out for you and they're all competent. Good luck with that.
  - ajross 8y ago
    It's not a substitute for 2FA, just one of the factors. You will still need a password to authenticate new devices, etc...
tptacek 8y ago
For people confused about what this is: it's basically the de facto cross-browser standard for U2F security keys like Yubikeys.
- Ajedi32 8y ago
  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.
  - pc2g4d 8y ago
    If I'm not mistaken, the browsers themselves could act as "authenticators" and help people manage credentials in software.
    - jonny_eh 8y ago
      Exactly. Authenticate with your Google account on chrome, iCloud account on safari, or Firefox account on Firefox.
- euroclydon 8y ago
  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...
  - tscs37 8y ago
    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.
    - emlun 8y ago
tokenizerrr 8y ago
Anyone know when the Google websites will start using this? Would love to finally be able to use my Yubikey with Firefox and Google.
- svacko 8y ago
  you can partialy (password + second factor authentication) use this when using 2FA with your Google account, https://support.yubico.com/support/solutions/articles/15000006418-using-your-yubikey-with-google https://support.yubico.com/support/solutions/articles/150000...
  - tokenizerrr 8y ago
    Doesn't work with Firefox yet AFAIK. That page mentions requiring Google Chrome.
    - tscs37 8y ago
      It works with Firefox 60, Google however sometimes relies on Chrome quirks not specified in the standard which may not make it usable in Firefox. (Last I checked)
      - tokenizerrr 8y ago
        It does not, and Google does not yet even attempt to use WebAuthn. They're still using the (now legacy) U2F authentication mechanism, which firefox does not fully support. It works in some sites if you enable it in about:config, but not all. Like google.com.
        tscs37 8y ago
        Hmm, yeah, I was more aiming at "Firefox has working WebAuthn in the newest Version, Google just doesn't use it properly or at all", I should have expressed that better.
kennu 8y ago
I wonder if you could use those keys also for encrypting content?
- tialaramex 8y ago
  Not with this API. You can purchase objects which can do this AND handle say your GPG keys for encryption, but WebAuthn is deliberately narrowly scoped. Using the same key for unrelated things can result in unpleasant surprises. So it's to be avoided. If you have a crappy insecure email server that uses SSLv3 still, and uses the same key as your tightly locked down Web server with TLS 1.2 then this bites you really badly, I can use the email server to help me impersonate your web server.
- franciscop 8y ago
  It doesn't seem like it, but it does require the content to be encrypted with TLS, which implies another pair of public-private key parts and certificates.
Roritharr 8y ago
If Microsoft allows Windows Hello to be used by Firefox, Chrome etc to enable this, this would be extremly huge. Same on mobile with Google & Apple. Sadly i've got no idea how far away we are from this actually being implemented.
krupan 8y ago
How is this related to this: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ ? EDIT: found this relevant comment (I think) from yesterday's discussion: https://news.ycombinator.com/item?id=17030302 https://news.ycombinator.com/item?id=17030302
- StavrosK 8y ago
  The first sentence in TFA: > The Web Authentication API (also referred to as WebAuthn)
franciscop 8y ago
Finally! I have a design concept that I wanted to propose but never got around it which would be very similar or even the complement, but without all the security details that I do not know how to do and that this API is strong on: https://jsfiddle.net/franciscop/qj4g3rz8/ https://jsfiddle.net/franciscop/qj4g3rz8/ The browser could store several data points for each field so you can choose from a dropdown OR different user profiles so you can switch from "Francisco the freelancer" to "Francisco the open source guy" in the drop of a beat. Or per window to do both at the same time if that's your thing. But anyway, this new Web Authentication API is really, really awesome to remove passwords forever. Now we need the last one, which would be closer to my design concept to even remove the manually adding all those fields: Web Identity API.
darkhorn 8y ago
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?
- veeti 8y ago
  If the key is designed properly, no. For example, Yubikey does not store any state: https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/ https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/
- tialaramex 8y ago
  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 private key, the server can check that because of the public key it has. But in practice the key pair never actually lives inside the token - it makes the key pair during enrollment, and the "magic cookie" was actually its private key encrypted using a secret key only the token knows. So the token has no writeable storage, just ROM and a little bit of DRAM. Some tokens might have a tiny amount of flash to e.g. store a counter or a user chosen PIN to do PIN authentication instead of a one touch auth, but they aren't storing a bunch of keys, or domain names, or email addresses.
  - konschubert 8y ago
    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.
Edmond 8y ago
I proposed something similar a few years ago, glad to see it being incorporated into browsers: http://blog.codesolvent.com/2015/07/why-not-signed-password-authentication.html http://blog.codesolvent.com/2015/07/why-not-signed-password-...
miles_matthias 8y ago
Looks great for web content, but how does it support the workflow of signing up for a website on my browser and then downloading their mobile app, and signing in on the app without a password? Or is that TBD?
- tialaramex 8y ago
  If your authenticator is suitable for your mobile device, then it works with that device. If your authenticator is, say, a USB-A dongle for plugging into a PC it probably either can't be used, or is super-clumsy because it needs a big adaptor to hang off the device. They make things that do Bluetooth and USB-C though.
  - miles_matthias 8y ago
    Gotcha. Although Apple and Google will likely need to build an API for this like they did for facial/fingerprint unlock.
- jonny_eh 8y ago
  Apps can redirect you to a browser that redirects back to the app on successful login.
cornholio 8y ago
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.
marknadal 8y ago
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 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 encryption. Web Auth API does look a lot easier than Web Crypto API, but it pushes the wrong message. We've taken a lot of time to make an MIT/Zlib/Apache2 Open Source wrapper around Web Crypto API that allows better user security (better than Web Auth API), short tutorial here: https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-with-e2e-encryption-f90505b2ff8 https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi... .
- supertrope 8y ago
  Unfortunately average people are better off with a corporation holding onto their private keys. People already get annoyed when they forget their password. Telling them they have permanently lost access to their account/data because their hard disk broke or they lost their token is much worse.
- emlun 8y ago
  >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.
brianmcsweeney 8y ago
Anyone have any idea if this work is aligning with the Decentralized Identifier specification, or vise versa? https://w3c-ccg.github.io/did-spec/ https://w3c-ccg.github.io/did-spec/
danellis 8y ago
Since TLS supports client certificates, I've always wondered why browsers never added UIs that would make that useable for end users.
- n0w 8y ago
  It would be nice to have a JavaScript API that allows you to create a client certificate locally, generate a CSR, and install the signed certificate for automatic use when connecting back to the associated host?
totony 8y ago
I'd be curious to know why it chooses to have a register step, why not just use the key of the authenticator/the relying ID as a proof of identity? You would normally use a scheme like this so that websites cannot connect multiple identities together, but it seems pointless here because the pubkey will be signed with the user identity and the server will have logged your real pubkey
- deleted 8y ago
  [deleted]
- emlun 8y ago
  No, you were right at the beginning. There is no "root" or "real" pubkey. A separate keypair is generated each site, so that - like you said - identities are unlinkable. This is also a crucial part of what makes these credentials immune to phishing.
agnivade 8y ago
How costly are these devices ? Are these readily available in the market to buy ?
- emlun 8y ago
  Yubico currently sells one at $20. https://www.yubico.com/product/security-key-by-yubico/#security-key-2-pack https://www.yubico.com/product/security-key-by-yubico/#secur... There are competing U2F keys, but I don't know of any competitors that support FIDO2 yet.
xEnOnn 8y ago
So the private key will be stored a device for signing in across a few platforms. But what if I need to sign in from another device? I can't do that until I go back home and copy the key over to my mobile?

299 points by Jaruzel 8y ago

I'm a beginner in this area, but maybe someone can help me out. Would this be a replacement for something like Passport or Auth0?

kroltan 8y ago
Not exactly. It is an alternative to the concept of passwords in general. But it is not a complete solution to all the things covered by those services.

Ajedi32 8y ago

This is going to be _huge_ for the security of the average web user once it starts getting widespread adoption. Credential phishing, password reuse, credential stuffing, and weak passwords are all about to be a thing of the past, at least insofar as the web is concerned.

dmortin 8y ago
Doesn't this mean that if the authenticator is cracked then all of your accounts are revealed and become vulnerable? Compared to the situation today when if one your passwords is cracked they can't immeidately access your other accounts.
- vorpalhex 8y ago
  It's no worse than them breaking into a password manager, and is quite a bit better since they now have to deal with full on private keys. Most passwords are vulnerable because they are easily guessed, not because somebody breaks your encrypted password store.
- Ajedi32 8y ago
  Stealing Web Authentication keys from a hardware token is a significantly higher bar than phishing you or brute-forcing your password hash from a database leak. At the very _least_ the attacker would first have to compromise your machine with malware, at which point they could easily get access to all your password-protected accounts anyway with a simple keylogger.
  - dmortin 8y ago
    What happens if you lose your hardware token (or it gets stolen, ec.)? Is there a way for then to access your accounts?
    - gruez 8y ago
      backup/recovery codes and/or "forgot your password (authenticator)" recovery
    - StavrosK 8y ago
      Ideally (and hopefully this will be doable, as I don't see any impediments), you can have Bitcoin-wallet-style seed generation that you can back up onto a piece of paper and store it somewhere safe. I really hope my Ledger Nano S becomes WebAuthN-compatible, as it can already be used as a U2F key.
      - tialaramex 8y ago
        Yes, for a device as complicated as the (~ $100) Ledger Nano S I don't see any reason they couldn't support that functionality. Most people will be using much cheaper, dumb authenticators which aren't going to have the capability to read and update the keys, they would be expected to replace their authenticator altogether, not try to clone it if there's a problem.
    - ethagnawl 8y ago
      This could introduce latency and centralization to the authentication process, but perhaps there could be a public key server/service that would allow the user to issue a revocation certificate. This scenario could also be a legitimate use case for blockchain technology.
- tialaramex 8y ago
  The authenticators are physical property of the people they authenticate. If you're especially worried you can remove it when not using it, you can lock it in a safe, you can give it to your personal bodyguard to protect with their life. Air gapped authenticators are plausible, although they'd be awful from a usability perspective, if you're really that paranoid... Whereas all your passwords are just bits, and you have to transmit those bits to a remote party every time you authenticate. You can't keep those bits safe, only trust that everybody else is looking out for you and they're all competent. Good luck with that.
- ajross 8y ago
  It's not a substitute for 2FA, just one of the factors. You will still need a password to authenticate new devices, etc...

tptacek 8y ago

For people confused about what this is: it's basically the de facto cross-browser standard for U2F security keys like Yubikeys.

Ajedi32 8y ago
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.
- pc2g4d 8y ago
  If I'm not mistaken, the browsers themselves could act as "authenticators" and help people manage credentials in software.
  - jonny_eh 8y ago
    Exactly. Authenticate with your Google account on chrome, iCloud account on safari, or Firefox account on Firefox.
euroclydon 8y ago
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...
- tscs37 8y ago
  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.
  - emlun 8y ago

tokenizerrr 8y ago

Anyone know when the Google websites will start using this? Would love to finally be able to use my Yubikey with Firefox and Google.

svacko 8y ago
you can partialy (password + second factor authentication) use this when using 2FA with your Google account, https://support.yubico.com/support/solutions/articles/15000006418-using-your-yubikey-with-google https://support.yubico.com/support/solutions/articles/150000...
- tokenizerrr 8y ago
  Doesn't work with Firefox yet AFAIK. That page mentions requiring Google Chrome.
  - tscs37 8y ago
    It works with Firefox 60, Google however sometimes relies on Chrome quirks not specified in the standard which may not make it usable in Firefox. (Last I checked)
    - tokenizerrr 8y ago
      It does not, and Google does not yet even attempt to use WebAuthn. They're still using the (now legacy) U2F authentication mechanism, which firefox does not fully support. It works in some sites if you enable it in about:config, but not all. Like google.com.
      - tscs37 8y ago
        Hmm, yeah, I was more aiming at "Firefox has working WebAuthn in the newest Version, Google just doesn't use it properly or at all", I should have expressed that better.

kennu 8y ago

I wonder if you could use those keys also for encrypting content?

tialaramex 8y ago
Not with this API. You can purchase objects which can do this AND handle say your GPG keys for encryption, but WebAuthn is deliberately narrowly scoped. Using the same key for unrelated things can result in unpleasant surprises. So it's to be avoided. If you have a crappy insecure email server that uses SSLv3 still, and uses the same key as your tightly locked down Web server with TLS 1.2 then this bites you really badly, I can use the email server to help me impersonate your web server.
franciscop 8y ago
It doesn't seem like it, but it does require the content to be encrypted with TLS, which implies another pair of public-private key parts and certificates.

Roritharr 8y ago

If Microsoft allows Windows Hello to be used by Firefox, Chrome etc to enable this, this would be extremly huge. Same on mobile with Google & Apple. Sadly i've got no idea how far away we are from this actually being implemented.

krupan 8y ago

How is this related to this: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ ? EDIT: found this relevant comment (I think) from yesterday's discussion: https://news.ycombinator.com/item?id=17030302 https://news.ycombinator.com/item?id=17030302

StavrosK 8y ago
The first sentence in TFA: > The Web Authentication API (also referred to as WebAuthn)

franciscop 8y ago

Finally! I have a design concept that I wanted to propose but never got around it which would be very similar or even the complement, but without all the security details that I do not know how to do and that this API is strong on: https://jsfiddle.net/franciscop/qj4g3rz8/ https://jsfiddle.net/franciscop/qj4g3rz8/ The browser could store several data points for each field so you can choose from a dropdown OR different user profiles so you can switch from "Francisco the freelancer" to "Francisco the open source guy" in the drop of a beat. Or per window to do both at the same time if that's your thing. But anyway, this new Web Authentication API is really, really awesome to remove passwords forever. Now we need the last one, which would be closer to my design concept to even remove the manually adding all those fields: Web Identity API.

darkhorn 8y ago

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?

veeti 8y ago
If the key is designed properly, no. For example, Yubikey does not store any state: https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/ https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/
tialaramex 8y ago
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 private key, the server can check that because of the public key it has. But in practice the key pair never actually lives inside the token - it makes the key pair during enrollment, and the "magic cookie" was actually its private key encrypted using a secret key only the token knows. So the token has no writeable storage, just ROM and a little bit of DRAM. Some tokens might have a tiny amount of flash to e.g. store a counter or a user chosen PIN to do PIN authentication instead of a one touch auth, but they aren't storing a bunch of keys, or domain names, or email addresses.
- konschubert 8y ago
  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.

Edmond 8y ago

I proposed something similar a few years ago, glad to see it being incorporated into browsers: http://blog.codesolvent.com/2015/07/why-not-signed-password-authentication.html http://blog.codesolvent.com/2015/07/why-not-signed-password-...

miles_matthias 8y ago

Looks great for web content, but how does it support the workflow of signing up for a website on my browser and then downloading their mobile app, and signing in on the app without a password? Or is that TBD?

tialaramex 8y ago
If your authenticator is suitable for your mobile device, then it works with that device. If your authenticator is, say, a USB-A dongle for plugging into a PC it probably either can't be used, or is super-clumsy because it needs a big adaptor to hang off the device. They make things that do Bluetooth and USB-C though.
- miles_matthias 8y ago
  Gotcha. Although Apple and Google will likely need to build an API for this like they did for facial/fingerprint unlock.
jonny_eh 8y ago
Apps can redirect you to a browser that redirects back to the app on successful login.

cornholio 8y ago

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.

marknadal 8y ago

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 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 encryption. Web Auth API does look a lot easier than Web Crypto API, but it pushes the wrong message. We've taken a lot of time to make an MIT/Zlib/Apache2 Open Source wrapper around Web Crypto API that allows better user security (better than Web Auth API), short tutorial here: https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-with-e2e-encryption-f90505b2ff8 https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi... .

supertrope 8y ago
Unfortunately average people are better off with a corporation holding onto their private keys. People already get annoyed when they forget their password. Telling them they have permanently lost access to their account/data because their hard disk broke or they lost their token is much worse.
emlun 8y ago
>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.

brianmcsweeney 8y ago

Anyone have any idea if this work is aligning with the Decentralized Identifier specification, or vise versa? https://w3c-ccg.github.io/did-spec/ https://w3c-ccg.github.io/did-spec/

danellis 8y ago

Since TLS supports client certificates, I've always wondered why browsers never added UIs that would make that useable for end users.

n0w 8y ago
It would be nice to have a JavaScript API that allows you to create a client certificate locally, generate a CSR, and install the signed certificate for automatic use when connecting back to the associated host?

totony 8y ago

I'd be curious to know why it chooses to have a register step, why not just use the key of the authenticator/the relying ID as a proof of identity? You would normally use a scheme like this so that websites cannot connect multiple identities together, but it seems pointless here because the pubkey will be signed with the user identity and the server will have logged your real pubkey

deleted 8y ago
[deleted]
emlun 8y ago
No, you were right at the beginning. There is no "root" or "real" pubkey. A separate keypair is generated each site, so that - like you said - identities are unlinkable. This is also a crucial part of what makes these credentials immune to phishing.

agnivade 8y ago

How costly are these devices ? Are these readily available in the market to buy ?

emlun 8y ago
Yubico currently sells one at $20. https://www.yubico.com/product/security-key-by-yubico/#security-key-2-pack https://www.yubico.com/product/security-key-by-yubico/#secur... There are competing U2F keys, but I don't know of any competitors that support FIDO2 yet.

xEnOnn 8y ago

So the private key will be stored a device for signing in across a few platforms. But what if I need to sign in from another device? I can't do that until I go back home and copy the key over to my mobile?