- commit
- daeba706811b307dd7d5f86a81bf8280a3a357e7
- parent
- cca81deb3b9eb935f066d4ebf224e63c2f9710a4
- Author
- Tobias Bengfort <tobias.bengfort@posteo.de>
- Date
- 2023-10-04 22:18
post on mfa
Diffstat
| A | _content/posts/2023-09-28-mfa/index.md | 262 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | _content/posts/2023-09-28-mfa/index.yml | 3 | +++ |
2 files changed, 265 insertions, 0 deletions
diff --git a/_content/posts/2023-09-28-mfa/index.md b/_content/posts/2023-09-28-mfa/index.md
@@ -0,0 +1,262 @@
-1 1 Multi factor authentication (MFA) is gaining steam. The ecosystem is evolving
-1 2 and laws such as
-1 3 [NIS-2](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555)
-1 4 start making it a legal requirement. At the same time the ecosystem is becoming
-1 5 so diverse that two people working on the topic might work with completely
-1 6 different terminology and software.
-1 7
-1 8 Time for me to take a step back and get an overview. I will try not to do the
-1 9 old "passwords are bad and MFA is better" dance. I will still do the
-1 10 comparison, but only skim the boring parts and quickly move on to the
-1 11 (hopefully) more interesting details.
-1 12
-1 13 # Passwords
-1 14
-1 15 Passwords have been used for authentication for a long time, even though they have many issues:
-1 16
-1 17 - Humans pick passwords that are easy to guess
-1 18 - Humans easily forget their passwords, so they keep them on sticky notes on their screen
-1 19 - Passwords are typed in, so they can be extracted by keyloggers
-1 20 - Passwords are sent over the wire, so they can be extracted if there is insufficient transport encryption
-1 21 - Passwords are sent to servers, so the server operators can get access to your other accounts if you reuse passwords (or type in the wrong password)
-1 22 - Passwords are stored on the server, so they can be extracted from database leaks if they are not sufficiently hashed and salted
-1 23
-1 24 In short: Passwords are in too many places.
-1 25
-1 26 # Two Factor Authentication (2FA)
-1 27
-1 28 Now, replacing passwords all at once didn't seem realistic. Also, all the
-1 29 alternatives we had available came with issues of their own. So instead of
-1 30 replacing passwords, we started adding other authentication mechanisms on top.
-1 31
-1 32 # One-Time Passwords
-1 33
-1 34 A very common approach to two factor authentication is to send one-time
-1 35 passwords over a side channel such as
-1 36 [email](https://notes.xoxco.com/post/27999787765/is-it-time-for-password-less-login),
-1 37 SMS, or some proprietary smartphone app. These side channels are often insecure
-1 38 though.
-1 39
-1 40 A better approach is to use [Time-Based One-Time Passwords
-1 41 (TOTP)](https://www.rfc-editor.org/rfc/rfc6238): A one-time password is
-1 42 generated based on the current time and a pre-shared symmetric secret. The
-1 43 secret is commonly transferred via QR codes. The main downsides here are that
-1 44 the secret cannot be hashed on the server and that phishing is possible.
-1 45
-1 46 # Something you own
-1 47
-1 48 Many people say that the two factors in "two factor authentication" are
-1 49 knowledge and possession. Sometimes they also add biometrics ("something you
-1 50 are"). I don't buy that. Computer science is built on the idea that everything
-1 51 is data. All these factors will eventually collapse into bits, aka
-1 52 "something you know".
-1 53
-1 54 A common implementation of possession is that websites store a long lived
-1 55 cookie on a device. This device is now "trusted". Logging in from an untrusted
-1 56 device is then blocked or at least a warning is sent to the user. This process
-1 57 of course needs to be bootstrapped somehow.
-1 58
-1 59 This simple cookie-based implementation assumes that session cookies are
-1 60 short-lived and trust cookies are long-lived. Users who never log out do not
-1 61 get any benefits. And users who regularly delete all cookies get confusing
-1 62 warnings ("login from new device"). So I am not a fan.
-1 63
-1 64 More involved implementations use something like a trusted platform module
-1 65 (TPM) where a secret is stored but can never be extracted. This way knowledge
-1 66 of the secret is replaced by possession of the TPM. This is an interesting
-1 67 theoretical idea, but I am not 100% convinced that this actually works in
-1 68 practice.
-1 69
-1 70 # Multi Factor Authentication (MFA)
-1 71
-1 72 My impression is that the term "2FA" is slowly being displaced by "MFA". The
-1 73 "multi" is not so much about "two or more factors", but more about a move to a
-1 74 more open understanding of authentication. Since we started thinking about 2FA,
-1 75 the ecosystem has evolved and we are slowly ready to leave passwords behind.
-1 76 The discussion is no longer just about amending passwords with a second factor,
-1 77 but about finding new and better ways to do authentication in general.
-1 78
-1 79 This also means that we are in a time of change, kinda post-password. We
-1 80 already know that passwords are a thing of the past, but we have not yet
-1 81 settled on a new approach.
-1 82
-1 83 # Single Sign-On (SSO)
-1 84
-1 85 Let's shift gears for a moment and think about SSO.
-1 86
-1 87 With SSO we get a third party: You (via your *client*) want to log in to a
-1 88 website (*relying party*), but the actual authentication is done by an
-1 89 *identity provider*. This has two implications:
-1 90
-1 91 - Everything is centralized to a single login, so you can concentrate on
-1 92 making that really secure, e.g. by picking a more complex password or some
-1 93 elaborate MFA scheme.
-1 94
-1 95 - The communication between the relying party and the identity provider is
-1 96 completely automated, so it can use more complicated but stronger
-1 97 mechanisms (long random passwords, challenge-response, asymmetric
-1 98 cryptography, …).
-1 99
-1 100 # Local Identity Providers
-1 101
-1 102 Password managers can be seen as local identity providers. By being local, the
-1 103 authentication doesn't need to involve the network, which significantly reduces
-1 104 the attack surface.
-1 105
-1 106 They deliver on the first aspect (a single place that can be really secure) but
-1 107 not on the second (a password is still sent to the relying party). Their main
-1 108 benefit is that they are fully backwards compatible with existing websites.
-1 109
-1 110 Your SSH keys also act as local identity providers. Compared to password
-1 111 managers, they use a much better protocol to communicate with the relying
-1 112 party.
-1 113
-1 114 # WebAuthn / FIDO2
-1 115
-1 116 [WebAuthn](https://www.w3.org/TR/webauthn/) is a new JavaScript interface. Even
-1 117 though it is often talked about in the context of MFA, I believe it is more
-1 118 productive to understand it as local SSO with *authenticators* as local
-1 119 identity providers.
-1 120
-1 121 It was created by the [Fast IDentity Online (FIDO)
-1 122 Alliance](https://fidoalliance.org/). The commonly used term "FIDO2" is (as far
-1 123 as I understand) not a specific standard, but an umbrella term for "WebAuthn
-1 124 and related stuff".
-1 125
-1 126 I finally got around to read the WebAuthn spec and I was a bit shocked. You
-1 127 want your security related specs to be clear and specific. WebAuthn is not
-1 128 that. Let me illustrate that with a quote:
-1 129
-1 130 > A Client-side discoverable Public Key Credential Source, or Discoverable
-1 131 > Credential for short, is a public key credential source that is
-1 132 > ***discoverable*** and usable in authentication ceremonies where the Relying
-1 133 > Party does not provide any credential IDs, i.e., the Relying Party invokes
-1 134 > `navigator.credentials.get()` with an ***empty*** `allowCredentials`
-1 135 > argument. This means that the Relying Party does not necessarily need to
-1 136 > first identify the user.
-1 137 >
-1 138 > — <https://www.w3.org/TR/webauthn/#client-side-discoverable-credential>
-1 139
-1 140 I will get to discoverable credentials later, but suffice to say that I did not
-1 141 understand them from reading this paragraph. (It is actually even worse because
-1 142 they changed the wording mid-way, so all the interfaces use the term "resident
-1 143 keys" instead.)
-1 144
-1 145 Looking past the overly complex jargon, there is a lot of good stuff there. I
-1 146 will skip over most of it because many posts have already been written about
-1 147 that. I will only say that it is a lot like SSH in that it uses public key
-1 148 cryptography to communicate between the authenticator and the relying party and
-1 149 that it has some other benefits (e.g. use of TPMs) that even put it ahead of
-1 150 SSH in terms of security.
-1 151
-1 152 # Client-side MFA
-1 153
-1 154 So far we have discussed that WebAuthn is a form of local SSO. It can be used
-1 155 as a building block for MFA either by using it as one of several factors on the
-1 156 relying party, or by requiring user verification on the authenticator. Let's
-1 157 look at the latter option.
-1 158
-1 159 The relying party can select whether user verification should be discouraged,
-1 160 preferred, or required. It is preferred by default. Discouraged user
-1 161 verification is useful to avoid redundant verification if the relying party has
-1 162 already asked for a password. (Redundant user verification could become a real
-1 163 usability issue as we add MFA in more and more places.)
-1 164
-1 165 Required user verification is only useful if the relying party can trust the
-1 166 authenticator. There is a a certificate based
-1 167 ["attestation"](https://developers.yubico.com/WebAuthn/Concepts/Securing_WebAuthn_with_Attestation.html)
-1 168 system for that, but a relying part must jump through some additional hoops to
-1 169 use it. You if you are a relying part and absolutely deend on user
-1 170 verification, make sure to check attestation.
-1 171
-1 172 Apart from user verification, authenticators can also check user presence.
-1 173 However, relying parties have no control over that and it is always required.
-1 174 That means that authentication without user interaction is not possible.
-1 175
-1 176 How user verification is implemented depends on the authenticator. Another
-1 177 benefit of using a local identity provider is that it has access to a wide
-1 178 range of sensors. Currently we see passwords (or PINs), but also facial
-1 179 recognition or fingerprints.
-1 180
-1 181 Of course, authenticators can also decrease security in favor of convenience,
-1 182 e.g. by syncing credentials across devices.
-1 183
-1 184 # Moving beyond passwords
-1 185
-1 186 As explained in the beginning, the goal is to get rid of passwords completely.
-1 187 The buzzword a year ago was "passwordless", the current iteration is "passkey".
-1 188 Those are just marketing terms that represent more less clearly defined
-1 189 configurations of the technologies described so far.
-1 190
-1 191 Maybe a more interesting development is to also skip usernames. This is where
-1 192 we come back to discoverable credentials:
-1 193
-1 194 Many authenticators have limited storage capacity, so they mainly keep a single
-1 195 secret. The private keys are encrypted using that secret and stored with the
-1 196 relying party. Now if I want to log in, I have to send my username so the
-1 197 relying party can pass the correct encrypted key. It could also send me all the
-1 198 keys, but that is neither secure nor practical.
-1 199
-1 200 If, on the other hand, the key is stored on the authenticator, all that is not
-1 201 necessary. The relying party would send a challenge, my authenticator would
-1 202 use the local key to generate a reply, and I would be logged in.
-1 203
-1 204 (With this explanation, maybe go back and see if you can understand the
-1 205 paragraph I quoted above.)
-1 206
-1 207 Now, this comes with some usability bumps. For one, the relying party would
-1 208 have to know that my authenticator supports discoverable credentials and
-1 209 provide a legacy login otherwise. I guess that is the main reason why we hardly
-1 210 see this in the wild. The other issue is that having multiple accounts at
-1 211 the same relying party becomes a bit more involved. Either I have different
-1 212 authenticators, or the authenticator allows me to pick one, or the relying
-1 213 party receives all keys and asks me which one to use.
-1 214
-1 215 # Recovery
-1 216
-1 217 Before ending this post, we also have to look into some potential issue. The
-1 218 first one is recovery.
-1 219
-1 220 There are many ways to loose access to your account. Something you know may be
-1 221 forgotten, something you own may be stolen or just break, and even your
-1 222 fingerprints can be lost (e.g. by losing a finger).
-1 223
-1 224 The common way to tackle this issue, in the terminology we established so far,
-1 225 is to require `n` factors, but provide more than `n` factors.
-1 226
-1 227 The most common version of this is that you can send a "reset password" link to
-1 228 your email account. The two factors here are a password and access to an email
-1 229 account. It is tempting to think of this as a completely separate recovery
-1 230 flow. But in practice this just means that either factor is sufficient. And the
-1 231 security of your account depends on the weakest one.
-1 232
-1 233 With multi factor authentication, the most common issue is that recovery
-1 234 collapses into a single factor, e.g. it is possible to reset all factors using
-1 235 the same side channel or recovery keys are stored in the same password manager
-1 236 as the password. If that is the case, you are not doing MFA and not gaining any
-1 237 security. So make sure that your recovery options are solid!
-1 238
-1 239 # Account enumeration attacks
-1 240
-1 241 When we are thinking about password-less approaches we also have to consider
-1 242 some attacks that have been solved for passwords a long time ago.
-1 243
-1 244 Early on in my career I learned that I should display the same warning on a
-1 245 failed login attempt regardless of whether the username exists or not. This is
-1 246 so that attackers cannot find out whether a specific user has an account.
-1 247
-1 248 In WebAuthn (and if not using discoverable credentials) the relying party will
-1 249 usually respond with a set of keys for a given username. How can we avoid
-1 250 enumeration in that case? The
-1 251 [spec](https://www.w3.org/TR/webauthn/#sctn-username-enumeration) recommends
-1 252 creating a fake key in that case, but that sounds like there could be all kinds
-1 253 of footguns.
-1 254
-1 255 # Conclusion
-1 256
-1 257 After reading and hearing a lot about MFA, I had to structure all that
-1 258 information. I believe the idea to think of WebAuthn as local SSO can be
-1 259 productive.
-1 260
-1 261 Even though MFA has come a long way, it is still to soon to say what kind of
-1 262 authentication we will settle on.
diff --git a/_content/posts/2023-09-28-mfa/index.yml b/_content/posts/2023-09-28-mfa/index.yml
@@ -0,0 +1,3 @@ -1 1 title: On WebAuthn, MFA, and local SSO -1 2 date: 2023-09-28 -1 3 tags: [security, code]