81–90 of 154 posts
sqrl
What Brian_K_White is referring to is SQRL by Steve Gibson from GRC. https://en.wikipedia.org/wiki/SQRL.
Its an alternative simpler secure protocol that has been in development for a few years that is frequently discussed on the Security Now podcast.
I don't want to let the password go. It gives me the freedom to rightfully access my service if I just know the secret, without any entanglent to some app, device, or other account.
Almost there; now we just need some cross-platform implementations with synced credentials, and support from a couple major sites. Ideally some password managers will step in and implement support, and Google will add support to their own login flow as a primary authentication factor.
Use case: I create an account using using a Yubikey on my desktop, then want to access that account from my mobile phone using a fingerprint. How does the website know I'm the same person?
Keybase has a nifty personal web-of-trust for this stuff, but (A) that ties you to a single strong identity and (B) you can't really use that identity outside of their services.
Does anyone else find these informal specifications difficult to digest? The informative appendices link to papers on TPM and the like but it's hard to find a formal description of the protocol, or at least the sensitive parts, that could be independently validated or verified. Has there been any work to formally verify/validate the design of this protocol that I'm not seeing?
Having worked with a few different standards before, I was pleasantly surprised by how easy to understand and ergonomic (https://github.com/google/mundane/blob/master/DESIGN.md) the WebAuthn spec was.
I don't want to let the password go. It gives me the freedom to rightfully access my service if I just know the secret, without any entanglent to some app, device, or other account.
Passwords will continue to exist. But it has a lot of flaws, so it's nice have alternatives.
So what happens if you lose one of those USB devices? Can you use multiple USB devices on the same site?
OK, so here are the options I've seen people deploy for 2FA: 1. Force users to register two U2F tokens. Google's 'advanced protection' requires this. 2. Have users print out one-time-use recovery codes and put them somewhere safe. This is what Google does without 'advanced protection'. 3. Require the user to provide a cell phone number, thus offloading the problem to cell phone companies, introducing all the insecuri…
For something like #5, let's hope the other website's auth isn't on the same key too :)
Earlier quoted context omitted.
In addition to being able to add multiple devices, there are recovery scenarios that would ostensibly fall outside of the scope of WebAuthn. A service using WebAuthn could give you a set of one time use high-entropy codes that can be printed and stored in a safe location. When you use those code to gain access to an account for which you have lost your token(s), you would of course get an e-mail letting you know that…
webauthn has to solve the problem, or the problem will still exist and will stop mass adoption.
Earlier quoted context omitted.
Passwords will continue to exist. But it has a lot of flaws, so it's nice have alternatives.
Is there a solution for the fact that all of your accounts will be secured by the same "source"? Isn't this almost close to using the same password on every site? I realize a physical secret is better than a password, but if someone gets their hand on your little FIDO device, do they instantly get access to all your accounts?
Using a security token is more like a password manager with random passwords everywhere than that (the attacker needs to get access to your password manager to get access to your accounts; it's not enough for someone to hack a single site you use), but more secure because it's generally not copyable and the attacker needs physical access to use it. (A virus on your computer can't clone your security token, even if it's plugged in.)
sqrl
You're being downvoted because the comment isn't really adding anything to the discussion because its so short. What Brian_K_White is referring to is SQRL by Steve Gibson from GRC. https://en.wikipedia.org/wiki/SQRL . Its an alternative simpler secure protocol that has been in development for a few years that is frequently discussed on the Security Now podcast.