- commit
- 88c03504ad923851023e2d0b2908ce5fec3d9a4f
- parent
- 43624c0386c08ec1269c9077f0865dc45e45acff
- Author
- Tobias Bengfort <tobias.bengfort@posteo.de>
- Date
- 2023-10-19 05:49
rework mfa post basd on feedback
Diffstat
| M | _content/posts/2023-09-28-mfa/index.md | 58 | +++++++++++++++++++++++++++++----------------------------- |
1 files changed, 29 insertions, 29 deletions
diff --git a/_content/posts/2023-09-28-mfa/index.md b/_content/posts/2023-09-28-mfa/index.md
@@ -40,8 +40,10 @@ though. 40 40 A better approach is to use [Time-Based One-Time Passwords 41 41 (TOTP)](https://www.rfc-editor.org/rfc/rfc6238): A one-time password is 42 42 generated based on the current time and a pre-shared symmetric secret. The43 -1 secret is commonly transferred via QR codes. The main downsides here are that44 -1 the secret cannot be hashed on the server and that phishing is possible.-1 43 secret is commonly transferred via QR codes. The main downsides here is that -1 44 phishing is easy: Attackers can just call users and say "I need you to verify -1 45 your identity by telling me the current code" and they are in. Also, the -1 46 symmetric secrets cannot be hashed on the server. 45 47 46 48 # Something you own 47 49 @@ -62,10 +64,11 @@ get any benefits. And users who regularly delete all cookies get confusing 62 64 warnings ("login from new device"). So I am not a fan. 63 65 64 66 More involved implementations use something like a trusted platform module65 -1 (TPM) where a secret is stored but can never be extracted. This way knowledge66 -1 of the secret is replaced by possession of the TPM. This is an interesting67 -1 theoretical idea, but as far as I know, real-world TPMs are not perfect. Still,68 -1 they pose a considerable obstacle for attackers.-1 67 (TPM) where a secret is stored but can never be extracted. Knowledge of the -1 68 secret is replaced by possession of the TPM. As far as I know, real-world TPMs -1 69 are not perfect. I fear we might get into trouble if our crypto protocols start -1 70 to depend on TPMs. Instead, we should think of them as obstacles. They make -1 71 attacks harder, but don't give any guarantees. 69 72 70 73 # Multi Factor Authentication (MFA) 71 74 @@ -99,13 +102,13 @@ website (*relying party*), but the actual authentication is done by an 99 102 100 103 # Local Identity Providers 101 104102 -1 Password managers can be seen as local identity providers. By being local, the103 -1 authentication doesn't need to involve the network, which significantly reduces104 -1 the attack surface.-1 105 If the identity provider is running on your devce, the authentication doesn't -1 106 need to involve the network, which significantly reduces the attack surface. 105 107106 -1 They deliver on the first aspect (a single place that can be really secure) but107 -1 not on the second (a password is still sent to the relying party). Their main108 -1 benefit is that they are fully backwards compatible with existing websites.-1 108 One example of this idea are password managers. They deliver on the first -1 109 aspect (a single place that can be really secure) but not on the second (a -1 110 password is still sent to the relying party). Their main benefit is that they -1 111 are fully backwards compatible with existing websites. 109 112 110 113 Your SSH keys also act as local identity providers. Compared to password 111 114 managers, they use a much better protocol to communicate with the relying @@ -115,8 +118,8 @@ party. 115 118 116 119 [WebAuthn](https://www.w3.org/TR/webauthn/) is a new JavaScript interface. Even 117 120 though it is often talked about in the context of MFA, I believe it is more118 -1 productive to understand it as local SSO with *authenticators* as local119 -1 identity providers.-1 121 productive to understand it as a way to authenticate against a special kind of -1 122 local identity providers called "authenticators". 120 123 121 124 It was created by the [Fast IDentity Online (FIDO) 122 125 Alliance](https://fidoalliance.org/). The commonly used term "FIDO2" is (as far @@ -152,9 +155,14 @@ SSH in terms of security. 152 155 # Client-side MFA 153 156 154 157 So far we have discussed that WebAuthn is a form of local SSO. It can be used155 -1 as a building block for MFA either by using it as one of several factors on the156 -1 relying party, or by requiring user verification on the authenticator. Let's157 -1 look at the latter option.-1 158 as a building block for MFA either by using it as one of several authenticaion -1 159 steps on the relying party, or by requiring user verification on the -1 160 authenticator. Let's look at the latter option. -1 161 -1 162 How user verification is implemented depends on the authenticator. Another -1 163 benefit of using a local identity provider is that it has access to a wide -1 164 range of sensors, so apart from passwords (or PINs), we also see facial -1 165 recognition or fingerprints. 158 166 159 167 The relying party can select whether user verification should be discouraged, 160 168 preferred, or required. It is preferred by default. Discouraged user @@ -166,21 +174,13 @@ Required user verification is only useful if the relying party can trust the 166 174 authenticator. There is a a certificate based 167 175 ["attestation"](https://developers.yubico.com/WebAuthn/Concepts/Securing_WebAuthn_with_Attestation.html) 168 176 system for that, but a relying part must jump through some additional hoops to169 -1 use it. You if you are a relying part and absolutely deend on user-1 177 use it. If you are a relying part and absolutely depend on user 170 178 verification, make sure to check attestation. 171 179 172 180 Apart from user verification, authenticators can also check user presence. 173 181 However, relying parties have no control over that and it is always required. 174 182 That means that authentication without user interaction is not possible. 175 183176 -1 How user verification is implemented depends on the authenticator. Another177 -1 benefit of using a local identity provider is that it has access to a wide178 -1 range of sensors. Currently we see passwords (or PINs), but also facial179 -1 recognition or fingerprints.180 -1181 -1 Of course, authenticators can also decrease security in favor of convenience,182 -1 e.g. by syncing credentials across devices.183 -1184 184 # Moving beyond passwords 185 185 186 186 As explained in the beginning, the goal is to get rid of passwords completely. @@ -208,7 +208,7 @@ Now, this comes with some usability bumps. For one, the relying party would 208 208 have to know that my authenticator supports discoverable credentials and 209 209 provide a legacy login otherwise. I guess that is the main reason why we hardly 210 210 see this in the wild. The other issue is that having multiple accounts at211 -1 the same relying party becomes a bit more involved. Either I have different-1 211 the same relying party becomes a bit more complicated. Either I have different 212 212 authenticators, or the authenticator allows me to pick one, or the relying 213 213 party receives all keys and asks me which one to use. 214 214 @@ -217,7 +217,7 @@ party receives all keys and asks me which one to use. 217 217 Before ending this post, we also have to look into some potential issue. The 218 218 first one is recovery. 219 219220 -1 There are many ways to loose access to your account. Something you know may be-1 220 There are many ways to lose access to your account. Something you know may be 221 221 forgotten, something you own may be stolen or just break, and even your 222 222 fingerprints can be lost (e.g. by losing a finger). 223 223 @@ -258,5 +258,5 @@ After reading and hearing a lot about MFA, I had to structure all that 258 258 information. I believe the idea to think of WebAuthn as local SSO can be 259 259 productive. 260 260261 -1 Even though MFA has come a long way, it is still to soon to say what kind of-1 261 Even though MFA has come a long way, it is still too soon to say what kind of 262 262 authentication we will settle on.