Props to Hetzner for having this properly integrated with the option for multiple (at least three in my case) hardware keys.
For whatever reason, quite often you can only register a single device (looking at you AWS Root account). The only way around this is by setting up your backup keys with the same OTP private key and use the Yubico Authenticator app to generate the TOTP.
> quite often you can only register a single device (looking at you AWS Root account).
For WebAuthn (and thus FIDO devices) this comes up regularly on HN. It's just AWS. It may feel like it's "everywhere", because it's your Amazon Web Services account, the credentials you use with DynamoDB, the thing you need for your EC2 VMs, the Cloud Computing stuff, your S3 buckets... oh right, yeah, that's all actually just AWS isn't it.
It's still a bug, but it's specifically a bug in Amazon's implementation, there is no wider ecosystem problem here.
My telecom provider Vodafone doesn't support it, neither do any of my banks. My favourite crypto exchange; only a single key. The list goes on. There is still a lot of ground to cover.
I agree with your overall point that most of the big services do this correctly, but I do think we'll see more services that do this wrong as webauthn gains greater adoption. Developers are lazy and supporting multiple keys is more work than supporting a single key.
Just yesterday I discovered that Thinkst (Canary Tokens) only lets you register a single webauthn token. Thinkst is a company that makes security products! I'm expecting to see this more as adoption picks up.
I don't really understand the context in which "Thinkst only lets you register a single webauthn token". Poking around I see some free services (for which I don't need or want any credentials so WebAuthn is irrelevant) and marketing, presumably there's something else here but I don't know what it is.
As to the larger point, as well as explicitly telling you to support multiple tokens, WebAuthn is designed in a way that makes the "one single token" implementation pretty unergonomic, which you'd hope would cause anybody who isn't just copy-pasting to think "Huh, I wonder why I need a list of exactly one item here, and this other array with exactly one thing in it, and I have this database table with a column I never use for anything. What a strange design unless... oh right, yeah, we are explicitly required to support multiple tokens".
For example, the tokens have a mandatory ID for each enrolment. It's huge (larger than a UUID)! If you're never allowing multiple enrolments it might seem tempting to just forget the ID. There's only one per user, so it's not a problem right? Nope, now nothing works. Cryptographically this now can't work because the ID - while yes it's an identifier and you can totally use it as a PRIMARY KEY in your database or whatever - is also critical to the cryptographic underpinning and so if you've lost it now you can't do WebAuthn.
It is of course possible to get it wrong, not really any way around that, but I don't think it's often going to happen by mistake rather than policy.
> Poking around I see some free services (for which I don't need or want any credentials so WebAuthn is irrelevant) and marketing, presumably there's something else here but I don't know what it is.
To your larger point, I hope you are right. But I know I've worked with people in the past that given the task to add support to webauthn would (a) not bother to understand it more than the minimum copy paste examples from stack overflow or from a webauthn library and (b) would feel like adding a new SQL table to store store these would be "a lot more work" and "the jira ticket didn't say we needed to support more than one per user."
IIRC, Twitter, Google, Dropbox and Facebook also don't allow to enroll multiple Yubikeys (ETA: Looks like I'm a bit outdated).
In general, most platforms don't really account for the scenario "my 2nd factor got stolen/robbed/destroyed/lost" beyond also offering a phone app and printed recovery records - and the end result is that a house fire, flood or storm scenario locks out users permanently.
It looks like Firefox might be finally taking this seriously -- I've been tracking the open item for touch ID support which is also lacking and they upgraded the priority a few days ago.
Oh wow I was literally just looking at that ticket a few days ago when I was trying to figure out if there was a way to get Firefox to use Touch ID. I must have missed seeing them up the priority by just a few hours!
I'm very glad to see there's interest in getting that working because I was strongly considering switching browsers to get that feature
So, User Presence and User Verification are distinct things in FIDO and thus WebAuthn.
User Presence refers to determining that a human wants the authentication, often through some simple button or contact switch. This defuses a remarkable array of potential attacks, but obviously it isn't actually authenticating very much since a two year old and your grandmother can both press a button.
User Verification refers to confirming this is the same human who owns the device. For a cheap FIDO device this might involve a PIN (not actually numeric, the difference from a password is that it's local, the PIN is not going to a remote web site, it's just proving to the device "I'm really your owner") while Yubico also makes devices that use a fingerprint, and I believe Apple sells products which use facial ID.
The UV flow is significantly extra work for the browser, especially for PIN where now the browser needs to pop up a PIN entry window securely. In contrast UP is not work for the browser, in fact, many cheaper FIDO devices UP isn't even optional, if you say "I don't want UP" the device ignores you and just demands somebody press the button anyway.
The authentication credentials you use to log in somewhere actually include signed bitflags from the FIDO device saying whether UP or UV occurred. So there is no way to fake this, if I didn't provide the PIN, my Yubico Security Key 2 will not sign the UV bitflag, and so a remote site knows it might just be a toddler pushing the button. Which is still fine as a second factor of course.
I've had to implement WebAuthn support once and it was a mess. Basically every browser and OS combination works slightly differently, so I ended having to do a bunch of changes to get at least somewhat decent UX. And Windows machines act completely differently depending on whether or not your computer has Windows Hello setup. And no one seems to have any idea on how Resident Keys should be managed, so if you ever register one, it just kinda exists from here until the end of time unless you know that one neat trick on how to get rid of one.
That's weird. I implemented it a year ago and it basically works perfectly on all the browsers I use. I can enroll a Yubikey on my desktop, and then hold it up to my iPhone to log in. (Of course, I also enrolled FaceID on the phone.)
My one complaint is that enrollments don't sync between my iPhone and my iPad. Had to enroll my face twice.
Your face unlocks a certificate in the TPM (or Apple equivalent), and each device has unique certificates, so it's expected that you have to enroll for each device. The YubiKey has its own certificate, which is why it can be used everywhere without having to enroll it multiple times.
I believe there is a plan to support syncing private keys [0] (that you can turn on via the developer tab in Safari) announced at WWDC 2021 [1] and discussed in this blog post from Hanko [2]. But I have not heard any more about it in the last 10 months.
Such a technology looks to me like an attractive nuisance. It's the Bearer Bonds of security technology - benefits to legitimate users are minor, yet the costs from all the illegitimate uses accrue to everybody all the time.
Don't get me wrong, it would be very useful (well, the Apple version not to me directly since I don't have an Apple device) but I think the security penalty is too high in practice.
Yeah, I don't see this as a big security disaster. I sync my SSH keys between machines manually. That increases the exposure risk, but not as much as using the same password on every site. Mobile devices have pretty good security (option to auto-wipe after using the wrong lock screen passcode a certain number of times). Desktop security is pretty bad (straightforward to steal the Windows Hello keys on some installs), but the rootkit that steals your WebAuthn keys will also just steal your Google session cookies or whatever.
What was inconsistent between browsers/OSes? I've implemented webauthn support and didn't have to do anything special to make it work in all browsers I've tested with.
Registration UX/flow, JavaScript APIs, and removing Resident Keys at least.
Windows computers with Windows Hello activated basically completely ignore hardware-based WebAuthn devices unless you specify that you want to register a cross-platform device. So the same piece of registration code will act differently if you're using Chrome on macOS, where you will be asked if you want to register a platform authenticator (Touch ID) or if you want to register a cross-platform authenticator (Yubikey), and Chrome on Windows, where you will basically be automatically defaulted to platform authenticator (Windows Hello) unless you abort the Windows Hello registration, in which case it will switch over to a cross-platform registration. You basically need to set authenticator attachment to either "platform" or "cross-platform" to get consistent experience across macOS and Windows.
And Safari for example requires user gestures for navigator.credentials.get(), so if you were thinking of redirecting users to a /login/verify/ page where it will automatically prompt for a WebAuthn verification, you actually need Safari users to click on a button on that page. On other browsers, you can basically just pop up the WebAuthn prompt automatically on page load.
And removing Resident Keys is another pain point. On Windows you basically need to do it via the command-line, whereas on macOS you need to go to "Clear browsing data" and then select "Passwords and other sign-in data" in order to get rid of them. So on Windows, they make it basically impossible for the regular user, and on macOS, they make it so easy that users might accidentally do it if they don't realise that the internal password manager and the stored Resident Keys are wiped the same way. Can't remember how it worked for Firefox, but I'm sure it will be at least slightly different (or didn't work at all, Firefox was painful).
I also can't remember off the top of my head if Firefox even supported fingerprint-backed authenticator devices on macOS. On Windows it might, since I think everything there goes through Windows Hello.
> And Safari for example requires user gestures for navigator.credentials.get(), so if you were thinking of redirecting users to a /login/verify/ page where it will automatically prompt for a WebAuthn verification, you actually need Safari users to click on a button on that page. On other browsers, you can basically just pop up the WebAuthn prompt automatically on page load.
This is something that is being changed in the standard that user action will be required. Safari just implemented it first.
The problem is that without prompting things like FaceID on the iPhone are so fast that you may get logged in without knowing if there is no user action required.
I really really like WebAuthn, I hope it can catch on. I've made a Django library to enable easy usernameless/passwordless WebAuthn-based authentication for Django:
You can see a demo on www.pastery.net, it's very nifty. Now that browser support is good, I will probably try to improve the library a bit to make the UX a bit better, but I really hope WebAuthn becomes commonplace.
> Resident Key / Discoverable Credential - The browser supports WebAuthn credentials stored on the authenticator. These credentials can be read to identify the user account without the user manually providing them.
Microsoft does it. It's hidden behind one click in the UX, but if you click "Sign in options" on the screen where it asks you for a username to sign into e.g. Outlook, one of the options is to sign in with a WebAuthn credential. Here, Microsoft invokes the WebAuthN API in "discoverable credential" mode (with empty allowCredentials) - if you have multiple online accounts connected to your Windows account, Windows will ask you which of the accounts you want to use and then provide both userid and assertion for that account.
you basically just have to create a new 'browser flow' and enable this one in the realm you wish to authenticate with. It wasn't really possible to add multiple keys to the user the last time i configured it -- but according to the docs, that seems to be resolved so it probably is worth another look.
Sadly I haven’t managed to find a way to make keycloak prefer security keys for 2FA over TOTP. I always get the TOTP prompt first, then have to click "try another way" and select security key.
It depends on the order that the user registered their 2FA, since they are ordered (and an admin can move factors up/down in the admin interface).
If you move the WebAuthN devices above the TOTP, Keycloak will first ask for the WebAuthN key with a button to switch back to another method (TOTP). It's slightly annoying.
@stavros, not sure if OSS is a requirement, but my current employer is in the same space.
It is not open source, but there is a gratis/free as in beer edition that you can download and use commercially (for certain usage: https://fusionauth.io/license-faq#3 ).
It's pretty great, but you should be aware that the LTS version is called red hat single sign on (rh sso), and the keycloak itself updates every few months.
It's usually not a deal breaker, but you should be aware if you're going to evaluate it for work
The passwordless WebAuthn UX is much nicer than everything except, maybe, passwords plus an unsupervised auto-fill rule, which is also a great way to get your passwords stolen (if the auto-fill rule ever malfunctions your passwords get automatically given to somebody else). Yet it delivers much better security.
Notably still no web standards for end to end encryption. We can crytopgraphically authenticate our identity with cloudservers, but the web has no way to cryptographically secure our data.
Nitrokey at least understood how biased & half assed this lopsided half-assed standardizing is. Made a first ignored apaa at doing better. Yubico doesnt seem to notice or care, they're happy pushing better ways to uniquely identify ourselves.
The way you're using "end to end encryption" is confusing: many applications of TLS are end-to-end, since they involve a user communicating with a server (rather than a server brokering communications between multiple users).
It doesn't make a lot of sense to standardize E2EE outside of a specific use case, since the "end" is subject to semantic squabbling. That being said, there's an IETF working group (do they count as a web standards group?) actively developing a standard E2EE messaging protocol[1].
A thing running on my computer should be able to communicate on a way no intermediary can decrypt with your computer.
This is not nearly so fuzzy as you imply. Signal gets it. Plenty of online systems can advertise & do end to end encryption. Your softened down incorrect definition is a mis-example: end to server to end is not e2e encryption.
Security keys should be useful on the web for end encryption. They are not. There is nothing to debate about this situation, itcs well defined & clear. The web is missing a huge gap.
Signal is a chat app (a very good one!), not a generic application layer like HTTP. When we're talking about the breadth of the services available on the web, there are plenty of contexts in which TLS is an E2E scheme. Not every use of TLS is E2E, but I didn't claim that.
I dont know what case you are trying to make? Should we not create cryptographic storage on the web? Is that not ok? Do you think there's anything that would keep us from using secure keys for encrypting storage? Is there some barrier you perceieve to why the web couldnt make use of such a capability?
I have no clue why you are building a case out for the web being something special & different & weird & hard to expect basic common sense secure cryptography from. Nitrokey had a pretty basic simple sensible early draft spec. Having some storage & a key that alone cam decrypt it seems trivially obvious. Not sure what kind of smoke you are attempting to blow on this idea.
TLS has absolutely nothing to do with this. The idea of e2e messaging usually is that you could send the message over untrusted links just fine. The other party could validate & decrypt it. Discussion on TLS seems wildly off topic/tangenti to the kind of e2e storage that messaging apps do, and that secure end to end storage entails.
Edit: to your credit, the MLS link you have above is indeed relevant.
A lot of very wrong immoral & silent downvoters: you are degrading the web & attacking society. Explain your downvotes & leave somrthing contestable & arguable. Why all the cheapass anti-security dowvotes? Why sign up to degrade security like this? What the frag?
I downvoted because your posts are vague complaints containing little details, and when people engage in good faith you respond with scorn because those poor idiots haven't understood you properly. I'd argue this is because you haven't explained your point very well. And this kind of attitude is specifically the type of thing that's not appreciated on HN.
I suspect many people are down voting your tone. Regardless of the merit of your arguments, and I make no claim about them, incivility and petulance will always undermine them.
> Notably still no web standards for end to end encryption
TLS is end to end encryption.
Maybe you are wanting something like Noise[0]? It's already a standard in many respects and nacl's crypto_box[1] stuff also exists.
Why should it be a "web standard"? Browsers are already stupidly complicated(arguably as complicated as operating systems). I'd argue they don't need more complexity.
> Nitrokey at least understood how biased & half assed this lopsided half-assed standardizing is
Well webauthn is specific to one thing only. It doesn't want to get into all the other things, there are good solutions for almost all of that stuff already.
> Yubico doesnt seem to notice or care, they're happy pushing better ways to uniquely identify ourselves.
For E2E encryption, you have to uniquely prove your identity or it's pointless. Thankfully webauthn just specifies the crypto part and doesn't mandate personal identification.
this feels like yet more inordinately & vastly incorrect obvious hogwash. how is tls end to end? it's literally you to your immediate service: it will never ever be end to end by definition. could it be any more obvious? why does such an obviously irrelevamt non-sequitor keep showing up? if the server you are talking with can decrypt it, it means it's not a secure channel. definitional, inarguable, basic.
how can are all the replies so wrong? what is this conspiracy against reason? what definition of e2e encryption are you using, when i communicate with my friend, and how does it accomodate this twisted ass warped "google can so read my messages" flagrantly incorrect viciously wrong misinformation view that merely having singleink tls security that you & other dude argue for? why is everyone so up on being immoral & misleading & wrong here about end-to-end encryptiom?
it secures a connection. but data going from party to party traverses multiple parties. end to end encryption, by definition, is not encryption between you & the service: it's between you & the other party.
intensely fantastically stupidly wrong & insistent argumentation keeps happening. i keep getting downvoted, ya'll keep making wrong posts with way off base claims. so sad. hopeless universe. again, folks lole nitrokey saw exactly this weakness, this inability for current web crypto standards tk ever help secure user data from the services they connected to, something tls cannot ever help with. but ya'll keep focusing.on the tiniestost irrelevant hop of data, keep insisting one leg of encrytion is equal to end to end. no.
Sorry, it's you misunderstanding. TLS doesn't require that it's a client to a server, TLS doesn't care, TLS says this connection from A <-> B is secure, that's it. 99% of deployed TLS is client to server, but it doesn't have to be. TLS IS however limited to 1 connection A <-> B.
I think what you are trying to talk about is: You want A to talk THROUGH B to get to C and have the connection secure between A and C. This is generally a terrible idea, if you can at all avoid it, but sadly for many reasons, we can't. And you are right TLS can't do this. Noise totally does this, which I linked to in my first comment.
So We are just talking about different meanings behind E2E. E2E == End To End, i.e. both ends are secure from eavesdroppers, TLS 100% fits this bill, as each end of the connection is secure. You seem to imply E2E is ONLY defined as encryption through some other connection, i.e. A <-> B <-> C, where B can't inspect/understand the contents.
It's important to know that, even with E2E as you seem to be defining it, there is still a LOT of data leakage, B knows that A is talking to C, they maybe can't uniquely identify who A and C are directly, but they probably can indirectly. There is 100% a reason that NSA and friends care a lot about metadata and learn a ton from it. Hence why P2P (i.e. talk directly to the person you want to talk to, nothing in the middle) is way better from a security perspective, less metadata to exploit.
If the Internet was better, Signal wouldn't have to use Noise and shunt traffic through their servers, and we could just use TLS directly between you and I for instance.
Anyways, I hope this helps further your education and you learned something.
It still is wildly off target from what I see as a core weakness with the web, which is that security keys cant be used to help a client create secure data. We can only authenticate ourselves with keys, not protect ourselves. The server we are talking to has more favor than us.
Introducing the term e2e was a mistake, & mislead everything. TLS isnt really a factor. It was frustrating being so very very far off course from the relevant problem. But I certainly didnt handle this drift well at all & was frustrated at being so off topic from such a vital & core web weakness.
WebAuthn is about presenting credentials to the server from the security key. The server gets to check our private keys, but the end client (the page) doesn't have any validation or tools at it's own disposal.
NitroKey & myself want the web to have a standard way to encrypt & secure data, ideally that allows for security keys to help do (sign) the encryption. https://github.com/Nitrokey/nitrokey-webcrypt
> WebAuthn is about presenting credentials to the server from the security key. The server gets to check our private keys, but the end client (the page) doesn't have any validation or tools at it's own disposal.
Clients get to check the servers TLS certs & DNS entries for proof that they are who they say they are.
> NitroKey & myself want the web to have a standard way to encrypt & secure data, ideally that allows for security keys to help do (sign) the encryption. https://github.com/Nitrokey/nitrokey-webcrypt
OH, so you want a way for the server to encrypt data just for a given client, that they can't read. This doesn't really make a ton of sense. The server has to have the plaintext version to encrypt, which means they have the data un-encrypted before they encrypt it for you. Hence you MUST trust the server with your plaintext data. Since you have to trust them anyway, this doesn't really buy you much. But sure, fine whatever. If people want to play with that, it's fine. Not hugely practical though.
> OH, so you want a way for the server to encrypt data just for a given client, that they can't read.
No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem.
Please, make this pain stop. Why does this thread never go anywhere clear & always goes to misinformation?
I really don't think Nitrokey made everything crystal clear, but it's far far less confusing than where we are right now after this brand new vast massive tragic & sorrowful retrogression in the discussion, so,
> While FIDO is supported by web browsers, using Nitrokey as a secure key store for email and (arbitrary) data encryption requires native software. Therefore email encryption in webmail has not been possible with the Nitrokey until now. At the same time strong end-to-end encryption in web applications all share the same challenge: To store users' private keys securely and conveniently. Therefore secure end-to-end encryption usually requires native software as well (e.g. instant messenger app) or – less secure – store the user keys password-encrypted on servers. Nitrokey aims to solve these issues by developing a way to use Nitrokey with web applications.
100% of my premise is that we should not need to always trust the server we connect to. We should be able to secure data on the client, in a way the server cannot access. Because we should not have to trust all data we access to the servers we connect to. It cannot be more basic & simple than that. But this voice & this perspective has been run off the site by confusion & bedlam that obfuscates & distracts from this simple point. I am so sorry.
> No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem.
This is 100% a solved problem already, I have no idea why you are having such a hard time with this.
See PGP/GPG and friends, age[1], magic wormhole[2], etc. Not to mention Noise[0], which I've already mentioned many times, as a protocol that does this. Even MS Exchange supports this for email(S/MIME, OME, etc). Webmail could implement PGP or S/MIME or something similar(and some do last I checked).
> MLS capabilities
Look up Macaroons(for the web) and capability based security. This is also a solved problem.
> 100% of my premise is that we should not need to always trust the server we connect to.
Essentially you are trying to achieve the un-achievable, for various definitions of security and trust, it's just not possible. In the modern web, servers can run arbitrary code on your device AND run arbitrary 3rd party programs on your device, with you having little to no say about it. This isn't limited to the Web, it just makes it ridiculously over the top. Web security is mostly an illusion, it's not going to change anytime soon(arguably never).
Anyways, there is basically zero demand for any of this stuff, and no incentive for companies or organizations to care. We know how to make secure operating systems and software, but nobody bothers.
For whatever reason, quite often you can only register a single device (looking at you AWS Root account). The only way around this is by setting up your backup keys with the same OTP private key and use the Yubico Authenticator app to generate the TOTP.