4 ms·
> At this point everything of value is lost. With FIDO2 this is not the case—since FIDO2 uses public key signatures with a secret key stored on the authenticat
by bkettle 3y ago
> At this point everything of value is lost.
With FIDO2 this is not the case—since FIDO2 uses public key signatures with a secret key stored on the authenticator, a keylogger would not lead to the long-term account compromise that it would with just password-based authentication. An attacker with control of a user’s PC may be able to learn a session cookie, but once that cookie expires the attacker will no longer be able to log in.
- leetbulb 3y agoIn many cases, a typical cookie / session expiration time is enough time to heavily compromise an account / product / org.
- bkettle 3y agoMaybe once we replace passwords with FIDO2 more widely and people no longer have to remember and enter their password every time they manually authenticate, we can shorten up session timeouts. Or, as GitHub does, we can require explicit authentication for sensitive actions. But yes, agreed—there’s not much FIDO2 can do to help when authentication isn’t required.
- leetbulb 3y agoAgreed. </3 passwords. Excellent work by the way. This stuff is super intriguing.
- deleted 3y ago[deleted]
- benlivengood 3y agoI wonder what account recovery is going to look like with FIDO2. "I lost my hardware passkey" buttons that email/text a magic link to enroll a new device? How many sites will allow adding a second device? How many will allow adding a second device without validating control of the original one?
- dwaite 3y agoUsually you have to upgrade all the links in the chain to get noticeably stronger security. Authentication by secure hardware-backed cryptography is great, but you need to make sure the user agent and execution environment don't allow for exfiltration of sessions. You might want to use time-of-flight calculations on geopositioned IP address information to make sure they aren't exfiltrated as well, but... You have to make sure you don't focus on exfiltration too much, since the attacker could use code injection to misuse resources local to the user. That will obviously break a lot of your anomaly detection. So you probably want to work on securing the user agent to prevent code injection, such as requiring a particular browser and configuring it to only allow a list of vetted web extensions, using CSP and sub resource integrity for web pages, having a policy of installing OS and browser updates nearly immediately, and so on. ...but again, you probably don't want to spend that much time strengthening all the walls without planning what to do when attackers manage to figure out a way in, such as using an unknown zero-day. Reducing the damage an attacker can do is possibly a better investment, but that touches on the entire business process. To your question, requiring the highest levels of strong authentication is an inefficient focus if the recovery process is an email into a third-party system. You can register multiple authenticators to reduce the need to go through recovery, (but then you have to worry about attackers registering new ones during a compromise, or the end-user having processes to keep them all safe). For recovery, you may use an equivalently strong mechanism like strong in-person identity verification (e.g. you have to walk to the IT desk and prove who you are to register a new security key fob onto your account).