class: big, middle # ECE 7420 / ENGI 9823: Security .title[ .lecture[Lecture 14:] .title[Secondary authentication] ] --- # Recall ### Passwords and hashing ### Password quality --- # Recall .floatright[ <img src="https://pics.me.me/create-a-new-account-spacemoses1337-password-is-being-used-by-53149196.png" width="400"/> ] ### Passwords and hashing ### Password quality -- # Today ### Authentication factors --- # Authentication factors ??? There are lots of mechanisms that we can use to try and authenticate someone, but fundamentally they all come down to one of a limited number of categories. -- ### Common formulation: -- * something you know -- * something you have -- * something you are -- ### Two-factor authentication (2FA) --- # Something you know -- ### Passwords! ??? Passwords are an example of something you know: "if you are who you say you are, you ought to know the password". However, they're hardly the only form of "something you know"! -- ### Recovery questions ??? Password recovery questions are also known as **fallback authentication questions**, **personal knowledge questions** or **secondary authentication questions**. Modern password guidance from NIST now recommends that we don't use such things, as they're effectively passwords but not protected nearly so well: > A: What's the password? > > B: I don't know the password. > > A: OK, then what's your mother's maiden name? > > B: Ummmm... Smith? > > A: Come on in! They are particularly risky [https://dl.acm.org/doi/abs/10.1145/1408664.1408667](in the age of social networking), but lots of organizations still do dumb things. Personally, if I'm required to provide answers to such questions, I choose answers that I can remember but which are not true (and therefore won't be found anywhere online). -- ### Countersigns ??? A [countersign](https://en.wikipedia.org/wiki/Countersign_(military)) is an example of a limited, non-computer-based, method of [challenge-response authentication](https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication). In such a protocol, you need to remember not just one password, but potentially several responses to give to different challenges. This provides resistance to eavesdropping attacks if each challenge/response pair can be used only once. We'll discuss cryptographic challenge-response protocols later in the course. -- ### Social authentication ??? _Social authentication_ is the expectation that, if you are who you say you are, you should know somebody else. You can imagine someone informally saying, "if you're in Term 7 computer engineering, you must know so-and-so!", but social authentication can also be done more formally, e.g., by a social network [https://link.springer.com/chapter/10.1007/978-3-642-32946-3_1](prompting you to identify faces you ought to know). --- # Something you have <img src="https://upload.wikimedia.org/wikipedia/commons/a/ae/BCRIC_Share_Certificate.jpg" width="450" align="right"/> -- ### In person: * documents * signatures * seals ??? Verifying the veracity of something you have is tricky, even when we are working in person and I hand you something. In general, [people are terrible at matching unfamiliar faces](https://blogs.scientificamerican.com/mind-guest-blog/how-hard-is-it-to-catch-a-fake-passport) to photos. People who work with documents every day can be [trained to spot fakes](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/869551/Guidance_on_examining_identity_documents_v._February_2020.pdf.pdf), but even border agencies have [experts to fall back on](https://www.sciencedirect.com/science/article/pii/S1874548218300568) for detecting high-quality forgeries. That's why it's a little bit silly to think that ordinary software developers should be trusted to [verify passports at keysigning parties](https://wiki.debian.org/Keysigning)! -- ### Remotely? ??? Given the above, how am I to verify that you have something when I'm not even in the same place as you? --- # Something you have knows... ??? In practice, when we verify "something you have", what we actually mean is "something known by something you have". -- ### A secret key? -- * symmetric-key MACs, asymmetric-key signatures (later!) ??? If you are able to produce a valid EMV cryptogram in response to a transaction at a store counter, there's a very good chance that you are in possession of a valid bank card. Manufacturers make it **very difficult** to extract secret keys from such cards. -- * HOTP ([RFC 2446](https://tools.ietf.org/html/rfc4226)): `Truncate(HMAC-SHA-1(K,C))` -- $$ h\left((k \oplus p_o) || h((k \oplus p_i) || text) \right) $$ -- * TOTP ([RFC 6238](https://tools.ietf.org/html/rfc6238)): -- `HOTP(K,T)` --- # Authentication tokens -- <img src="https://is5-ssl.mzstatic.com/image/thumb/Purple118/v4/0e/91/dc/0e91dc04-36d8-06ac-60e2-36a6e580329e/pr_source.png/300x0w.png" width="300" style="position: absolute; top: 20%; right: 4em; clip-path: inset(5% 0 70% 0);"/> ### Software -- * key stored... where? -- * security implications? ??? If your TOTP key is stored on a computer (e.g., your phone), it's important to think about the failure modes if that device is compromised or lost. If you store your TOTP key on your phone and use it to help you log in on your computer, there is a degree of independence between the two (although that may be less true if you have unencrypted mobile backups). If, however, you store your passwords in a password manager (as you should!) and also store TOTP keys in the same password manager (as some services offer), you may have an eggs-and-basket problem. -- <img src="https://www.yubico.com/wp-content/uploads/2021/05/213366-Image-HSM2-FIPS-2-1024x296.png" width="400" align="right"/> ### Hardware e.g., U2F (see [FIDO spec](https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-hid-protocol-v1.2-ps-20170411.html) and now [WebAuthn/FIDO2](https://www.w3.org/TR/webauthn-2/#sctn-intro)) --- # Something you actually have -- ### A phone... with a phone number? ??? A phone (or, more precisely, a SIM card) is **not** a great method of authenticating a user for high-value purposes. It's OK to confirm a login to a low-value account, but attackers can trick phone companies into [swapping your SIM](https://www.priv.gc.ca/en/blog/20200312) onto a device they control, often using **personal verification questions** (thus negating the "second" factor)! -- ### PUFs (Physical Uncloneable Functions)&ast; .footnote[ &ast; Pappu, Recht, Taylor, Gershenfeld, "Physical one-way functions", _Science 297 (5589)_, pp. 2026–2030, 2002. DOI: [10.1126/science.1074376](https://dx.doi.org/10.1126/science.1074376) ] -- * use microstructure (manufacturing anomalies) like fingerprints -- * unpredictable **but consistent** challenge/response pairs -- * can derive a key using a _fuzzy extractor_ --- # Something you are -- | Physical | |----------------| | fingerprint | | hand geometry | | face | | iris | | retina | --- # Biometrics | Physical | Behavioural/mixed | |----------------|-------------| | fingerprint | gait | hand geometry | typing rhythm | face | mouse patterns | iris | touch patterns | retina | voice patterns ??? Biometrics are only useful if you have a **trusted input channel** to avoid **replay attacks**. A key principle to remember: **your biometrics are not secret!** --- .floatright[ <img src="banker-scan.png" height="260"/> <img src="banker-scan-iris.png" height="260"/> <img src="tom-scan.png" height="260"/> <img src="tom-scan-iris.png" height="260"/> ] # Iris scan ### What's the problem? ??? In these images (from the BBC's production of [The Night Manager](https://www.imdb.com/title/tt1399664)), the top images show a banker taking a scan of a character's iris. Later in the series, that character (played by [Tom Hiddleston](https://www.imdb.com/name/nm1089991)) uses his iris to authorize a banking transaction related to international arms trafficking. -- * subtle but important difference (top vs bottom) ??? The problem is **not** that phone cameras lack the resolution required to do an iris scan. Rather, it's a subtle difference between the images at the top and the images at the bottom. -- * if you can't do one... ??? If you can't do the thing **at the bottom**, there's not much point doing the thing **at the top**! -- * somebody tell Samsung&ast; .footnote[ &ast; `46halbe`, [Chaos Computer Clubs breaks iris recognition system of the Samsung Galaxy S8](https://www.ccc.de/en/updates/2017/iriden), [CCC blog](https://www.ccc.de/en), 2017. ] ??? All the CCC folks needed to subvert Samsung's iris scan was a contact lens and a... Samsung printer. --- # 1.5FA ### Is your second factor really independent? Usually "something you know" plus: -- * something else you know (may add **very little** value) -- * something your computer knows (but can it be **copied**?) ??? ### Something your computer knows (or is): * cookies * fingerprints * known IPs (more **is** than **knows**) -- * something you can receive (but is it **just** you?) -- * biometric information (which may be **copied** or **replayed**) --- # Non-binary authentication -- ### Doesn't have to be "stranger" or "root" -- ### Multiple factors ??? Multiple factors can be incorporated at different times. -- ### Multiple signals ??? Multiple authentication **signals** can be incorporated that would not, on their own, be trusted to provide any assurance. For example, when I go home at the end of the day and try to use some University services from O365 (Teams, OneDriver, etc.), the fact that I've changed IP means that I'm likely to be prompted for an MFA notification. An IP address is **not enough to authenticate me**, but it can be enough to **increase the probability of a challenge**. This is also true for behavioural signals (e.g., logging in at an unusual time). -- ### Multiple levels / roles ??? Authentication shouldn't be all-or-nothing. For example, I can authenticate to a bunch of systems as the user `jon` using an SSH key, and once I'm `jon` I can escalate to `root` via `sudo` if I can prove knowledge of `jon`'s password. This means that getting to `root` is a two-step procedure: it's not possible for anyone (including an attacker) to log in directly as `root`, nor can anyone (on my systems) log in using a username and password alone. --- # Summary ### Passwords ### Guessing and entropy ### 2FA --- class: big, middle The End.