class: big, middle # ECE 7420 / ENGI 9823: Security .title[ .lecture[Lecture 28:] .title[Web authentication] ] --- class: big <img src="web-login.png" class="centered" width="800"/> --- # Web authentication ### Authentication factors ### TLS client certificates ### OAuth ### Cookies ### Authentication signals --- # Authentication factors ### Recall: -- * something you _know_ -- * something you _have_ -- * or just something else you know? * something your computer knows? -- * something you _are_ -- (which can be copied!) --- # Passwords -- ### Benefits ??? Passwords, for all of their limitations, aren't 100% bad. They are used so extensively for some sensible reasons (as well as a few poor reasons, like intertia or a lack of knowledge of alternatives on the part of software developers). -- ### Problems -- ### Strategies ??? The risks of password usage can be mitigated through sound password management strategies. What are some things that every password-verifying system ought to do? --- # TLS client certificates ### Remember TLS? -- ### What do CAs do? ??? CAs mostly vouch for **the identity of servers**, confirming that a particular public key **has been demonstrated to be owned by some well-known identity**. If that public key is used to **sign some Diffie-Hellman parameters**, we can have some assurance that **we're not talking to a middleperson**. There are also some problems with CAs (as we've seen), but the risks associated with rogue CAs are lower than they used to be. --- # TLS client certificates .floatright[ <img src="https://cdn2.auth0.com/docs/media/articles/connector/client-certs/connector-client-cert-choose.png" alt="Selecting a TLS client certificate"/> .caption[Source: <a href="https://auth0.com/docs/connector/client-certificates">auth0.com</a> ] ] ### Remember TLS? ### What do CAs do? ### Can also give _clients_ certificates ??? CAs mostly vouch for **the identity of servers**, confirming that a particular public key **has been demonstrated to be owned by some well-known identity**. If that public key is used to **sign some Diffie-Hellman parameters**, we can have some assurance that **we're not talking to a middleperson**. There are also some problems with CAs (as we've seen), but the risks associated with rogue CAs are lower than they used to be. CAs don't _only_ issue server certificates, however. We've already seen **code signing certificates**, but they can also issue client certificates! This allows both the server _and_ the client to identify themselves when setting up a TLS connection. -- * _mutual_ authentication ??? This form of mutual authentication, based on **public-key signatures**, is much stronger than **password-based authentication**. It also has the benefit (and the cost!) of preventing users from **selecting their own passwords**. -- * a few challenges... --- # Client certificate issues -- .floatright[ <a href="https://docs.microsoft.com/en-us/azure/includes/media/vpn-gateway-certificates-install-mac-client-cert-include/addcert.png"> <img src="https://docs.microsoft.com/en-us/azure/includes/media/vpn-gateway-certificates-install-mac-client-cert-include/addcert.png" alt="Adding a client certificate to macOS"/> </a> .caption[Source: <a href="https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-how-to-vpn-client-install-azure-cert">Microsoft</a> ] ] ### User experience -- * unusual ??? It's very unusual to be prompted for a TLS client certificate. In fact, it's even unusual to see a browser-native password prompt rather than an HTML form: <img src="password-prompt.png" width="300"/> -- * pre-interaction ??? One reason for this is that it doesn't give the user a chance to see the website that they're logging into. When you visit ecorp.com, they don't want you to see a generic browser prompt, they want you to see the eCorp logo and feel warm fuzzies about their brand. This is true of HTTP `Basic-Auth` authentication, and it's also true of TLS client certificate authentication. -- ### TLS termination and trust -- * why believes what? why? ??? It's very typical to have TLS connections terminated by one host which acts as a proxy for internal hosts. In that case, the internal host has **no cryptographic assurance of identity**: it just has to **take the TLS terminator's word** for the user's identity. --- # Client certificate issues .floatright[ <img src="http://www.browserauth.net/_/rsrc/1472873495513/tls-client-authentication/datacenter.png" width="400" alt="TLS termination in the datacenter"/> .caption[Source: browserauth.net] ] ### User experience * unusual action * pre-interaction privacy ### TLS termination and trust * why believes what? why? ??? It's very unusual to be prompted for a TLS client certificate. In fact, it's even unusual to see a browser-native password prompt rather than an HTML form: <img src="password-prompt.png" width="300"/> One reason for this is that it doesn't give the user a chance to see the website that they're logging into. When you visit ecorp.com, they don't want you to see a generic browser prompt, they want you to see the eCorp logo and feel warm fuzzies about their brand. This is true of HTTP `Basic-Auth` authentication, and it's also true of TLS client certificate authentication. It's very typical to have TLS connections terminated by one host which acts as a proxy for internal hosts. In that case, the internal host has **no cryptographic assurance of identity**: it just has to **take the TLS terminator's word** for the user's identity. -- #### Useful in _certain_ circumstances -- (corporate, end-to-end M2M...) ??? That said, client cert authentication _can_ be useful when you can expect users to be trained to expect the prompts and respond appropriately. This can be true in corporate settings, and it's definitely true in M2M environments (where "training" is also known as "programming"). --- # OAuth <img src="oauth-buttons.png" align="right" width="350"/> -- ### RFC ~~5849~~ 6749 -- ### Several parties: -- * user -- * application developer -- * authentication provider -- #### _Mutual distrust_ --- # OAuth2 protocol ### Rather... flexible -- > OAuth 2.0 provides a rich authorization framework with well-defined security > properties. However, as a rich and highly extensible framework with many > optional components, on its own, this specification is likely to produce a > **wide range of non-interoperable implementations**. -- Also see: [OAuth 2.0 and the Road to Hell](https://web.archive.org/web/20130325140509/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell) -- ### OAuth in practice --- # OAuth setup > this specification leaves a few required components partially or fully > undefined (e.g., client registration, authorization server capabilities, > endpoint discovery) -- ### Client registration -- ### Application setup -- * register application with auth provider -- : ID and **secret** --- # Login request .centered[ <img src="oauth-flow/redirect.svg" width="500" alt="A website redirects a user to an auth server"/> ] --- # Auth redirection .centered[ <img src="oauth-flow/auth.svg" width="900" alt="A website redirects a user to an auth server"/> ] --- # Authorization code .centered[ <img src="oauth-flow/auth-token.svg" width="600" alt="A website redirects a user to an auth server"/> ] --- # Access token .centered[ <img src="oauth-flow/full-protocol.svg" width="600" alt="A website redirects a user to an auth server"/> ] --- # More OAuth details ### Omitted some details: -- * authorization _grant_ types (client credentials, etc.) ??? The typical grant type is the _Authorization Code Grant_, described in [&sect;4.1 of RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1). However, other grant types (e.g., _Implicit Grant_, which doesn't cause a back-end communication between the Client and the Authorization Server involving a Client secret hidden from the user) are also possible. -- * access _scope_ ??? An OAuth _scope_ has syntax defined by the RFC (space-separated strings) with only minimal semantics (additive composition, order doesn't matter). Further semantics (i.e., what each scope means) are defined by the authorization server. For example, [here are GitHub's scopes](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). -- ### Can read RFC 6749, _but:_ ## Note the definition of "client" carefully! ??? As per [&sect;1.1 of RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-1.1), the "client" doesn't refer to the end user: the user is the "resource owner". Instead, the "client" is an application that makes requests. This is typically the user's "user agent" (browser), but it can be another application, like a mail client. --- # Cookies -- ### Session cookies -- * crypto? -- * _sidejacking_ ??? _Sidejacking_ refers to the the practice of sniffing authentication cookies over a plain-text connection and then using them to impersonate a user. This was a dangerous attack back in the dark days of the early 2010s, when it was common for even large websites to do authentication over HTTPS but then allow regular browing over HTTP. More and more, however, sites are using HTTPS all the time, preventing this kind of attack. -- ### Login cookies -- * crypto? -- * "Remember me on this computer" --- # Authentication signals ### Many _fallible_ ways to build authentication comfort: ??? As we've seen throughout the course, security mechanisms don't have to be perfect in order to be beneficial, as long as they aren't the primary line of defence. An authentication _signal_ doesn't provide authentication by itself, but like a Customs officer who picks up on a traveler acting nervous, it can provide a prompt to dig deeper into the primary sources. -- * IP address -- * Browser fingerprint -- * Time of day -- * User behaviour (e.g., queries) -- ### Maybe let's re-authenticate? --- # Summary ### Authentication factors ### TLS client certificates ### OAuth ### Cookies ### Authentication signals --- class: big, middle The End.