The "infamous" reference generators from NIST 800-22 included linear, quadratic and cubic congruential generators only.
A potentially vulnerable implementation that may have used this document as a reference would probably have only gone up to the cubic case.
So I think it's unlikely that someone used a recurrence equation of higher degrees. But you never know.
Also, the higher the degree, the more resources the attack will require. So, we opted for a balanced cost/benefit approach.
I'm really excited to see more and more people talk about FIDO2. If you're interested about this topic, I gave a talk about it yesterday: https://news.ycombinator.com/item?id=23689606
I've been using my YubiKey 5Ci in Safari on macOS and iOS since macOS 10.15[1] and iOS 13.3[2] (which came out several months ago), and Safari supports FIDO2 + WebAuthn just fine.
My mistake was to assume that AWS saying "Your browser does not support U2F security keys." meant that Safari didn't support U2F keys. Given AWS's well-earned reputation for half-assing things I really shouldn't have trusted their assessment, but I did. My bad.
In a browser what you want is WebAuthn, U2F is an older never technically standardized hack and should not be used for new implementations.
New web sites should do WebAuthn to enable this functionality, here's a guide someone else wrote that I found helpful in talking about the moving parts to actually implement this: https://webauthn.guide/
Firefox's WebAuthn implementation isn't as complete as it would ideally be, but it does have a nice feature of asking the user whether to give out the somewhat privacy-infringing "attestation" from a FIDO2 device when it is requested by a web site. IMNSHO ordinary web sites, especially where a second factor isn't even mandatory, should not be asking for attestation and I always refuse.
Care to elaborate how attestation is privacy infringing?
As far as I understand, private attestation is a specific design goal of WebAuthN, achieved by either sharing an attestation credential with at least 100 000 instances of a given authenticator or via cryptographic means.
There have been instances of authenticator vendors getting this wrong, but I remember reading that browsers will detect it and strip any attestation response in this case.
Not everybody is comfortable that 100 000 is enough.
Is that extreme? Yes, but the upside to giving out attestation data just isn't there in most scenarios. It's like I have to step over broken glass to get a stale bagel. Yes these boots mitigate the risk from the glass very well but I don't even want a stale bagel anyway.
There are some scenarios where attestation makes sense. If you issued every one of your employees a genuine Yubico Yubikey then I guess it could make sense to insist on checking with attestation that nobody is using some homebrew device they built instead. But for general use? Even the tiny risk isn't justified, so it should be "off".
Here's someone much smarter than me proposing something you could do if you really care about the features from attestation but don't want people to give up privacy. If you insist on offering stale baked goods, here is how to clear up that glass:
Oh is that what the "anonymize this key" is? If the website requires attestation, authentication might fail, but no website should require attestation, maybe unless you explicitly got the key from them (like a bank).
Websites should absolutely be requiring attestation.
The attack scenario here is malware on your computer pretending to be a hardware authenticator (during sign-up or 2FA enrolment) but really just emulating one in software.
In this scenario bad guys are currently authenticated as you (otherwise they can't do enrolment) and can do whatever they want but, perversely, they decide what they want to do is... obtain the ability to authenticate as you later in a traceable way. I don't buy it.
If you're a James Bond villain and the plot's resolution needs to be saved for the final reel then this makes sense, you can't blow up the world 40 minutes into the story 'cos the audience knows that isn't the end. But real crooks don't want to build suspense, they're going to jump to the part where they win. Why play this long game?
"Passwordless" mode unfortunately doesn't work for me in Firefox, I implemented it on https://www.pastery.net/ but I'm not sure if I did something wrong. Chrome works fine, though.
The fact that it didn't work out-of-the-box in Ubuntu 19 (needed a udev tweak) and a failing USB port on my laptop gave me the impression that it also didn't work out-of-the-box in Ubuntu 20 (which I booted from a USB key, hence the good port was unavailable), but I just tried it using my laptop's good USB port and a hub and I can now confirm that it works out-of-the-box in Ubuntu 20.
Tried a few, doesn't seem to handle more than one key well. Worried that 1500 submissions would cause a DoS. After a few it stopped giving me results saying computations were queued.
* Why should I use a security key?
* What is it used for?
* How can I choose one ?
* What features should I look for?
We did cover FIDO2/Passkeys but also multiple other use cases.
Here are the slides if you're interested: https://tome.one/slides/amiet-pelissier-security-keys-worksh...