On the Security and Privacy of Modern Single Sign-On in the Web
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Schmitz, Guido (gtrs)
Fett, Daniel (dfett)
Many web sites allow users to log in with their Facebook or Google account. This so-called Web single sign-on (SSO) often uses the standard protocols OAuth and OpenID Connect. How secure are these protocols? What can go wrong? <p>OAuth and OpenID Connect do not protect your privacy at all, i.e., your identity provider (e.g., Facebook or Google) can always track, where you log in. Mozilla tried to create an authentication protocol that aimed to prevent tracking: BrowserID (a.k.a. Persona). Did their proposition really solve the privacy issue? What are the lessons learned and can we do better?</p>
 So, I think we're all set. Without further ado, I'd like to introduce Guido Schmidt and Daniel Fett, who are going to be having this talk on a single sign-on on the web. Give them a big round of applause, and I hope you're looking forward to the talk. Okay. Hello, everybody. Welcome to our talk on the security and privacy of modern single sign-on on the web. So, in this talk, Daniel and me, we are going to present not only just attacks on OAuth and OpenID Connect, but also some thoughts about analysis of all these standards. So, first, a brief introduction. Who are we? We are researchers from the University of Trier, but soon of the University of Stuttgart. And also, we happen to be the founders of the machine deck, Hacker Space in Trier, and the Piantmore Raspberry Jam. If you're interested in anything else, what we are doing, you can just follow us on Twitter. So, what is this single sign-on about? What are we talking about? So, probably all of you have seen websites like this, like TripAdvisor, where you can use a lot of different methods to sign-in. You can sign in with your Facebook account, with your Google account, you can register account at their page with email address and password, or you can use your Samsung account or probably now even more different systems. And if you click, for example, on this login with Facebook button, and your window pops up, prompting for your Facebook credentials, or if you're already signed in into Facebook, just asks for confirmation. So, this is a setting we are looking at. And we have two parties here. We have TripAdvisor as the so-called relying party, and we have Facebook as the so-called identity provider. And the basic principle of how this works is the following. So, first you go with your browser to the relying party, you say, I want to log in with that IDP. Then you contact your identity provider, authenticate there, and this identity provider then issues some kind of token. And this token you give to the relying party, and the relying party can now use this token to access some parts of your account at the identity provider. And this is called authorization. For example, the relying party can use this token now to post on your Facebook timeline or reach out your friends list from Facebook. And the relying party can also retrieve some unique user identifier and then consider you to be logged in with that user identifier. And then this is authentication. And then RP can set, for example, some session cookie and mark this session belongs. Remember that this session belongs to this user. So, this was the basic principle. Why should we use single sign on or why shouldn't we use single sign on? So, for users, it's very convenient. You don't have to remember which account you used, where, which you password, and so on. You just click and log in with Facebook and you're all done. Of course, this comes with lack of privacy because Facebook then always knows where you log in. And also, the identity provider you choose is also a single point of failure. If that one closes down or changes its terms and conditions, then you perhaps cannot log in into your accounts anymore at some third party web pages. So, for relying parties, they need to store less data. They don't have to care about password databases that can leak. They don't have to care about user registration, password recovery on all the hassle that comes with user accounts. But they also have less control over the user's accounts because they outsource the authentication to this identity provider. And also here, the identity provider is a single point of failure. So, for identity providers, the advantage is clear. They get more user data and they can provide some service for their users which makes perhaps it makes it more attractive for users to use that identity provider. On the downside, they also have to take care about more user data. They have to store and protect it. And they have to have the overhead of implementing and running the single sign-on system. So, what are these single sign-on systems? Now, I will show you some prominent examples. So, there's O of 1.0. So, this is a not-so-modern single sign-on system. It's now 10 years old. Many flaws are known for this system and basically nobody uses it anymore except for Twitter. So, Twitter uses a modified version of O of 1.0 which more or less fixes all the known flaws. But in general, we can say, don't use O of 1.0. There's also OpenID, which is also quite old, nine years. It's not that user-friendly. It's a standard that's meant to be super flexible for every corner use case that the developers at that time thought of. And this makes it also extremely hard to use correctly because you have a lot of things going on, things change during an OpenID run at talk and it's not that nice to develop something for OpenID. So also for OpenID, don't use this. And they are now modern single sign-on systems for example O of 2.0, which is also used in login with Facebook. This is completely incompatible to O of 1.0. O of 2.0 uses the so-called Beera token approach. That is, the old protocol is based on some random values that are passed around, but there's no crypto involved except for the transport layer for HTTPS for example. O of 2.0 is used everywhere almost. So it's the most popular of these systems, but it has never been developed for authentication. And really it's not meant for authentication. And if you Google for O of 2.0 and authentication, you are after some time stumble upon the following picture. So these two guys are members of the O of working group and they really insist it's not meant for authentication at all. It's just for authorization. Okay. Nonetheless, it is used in practice also for authentication. Facebook for example uses it for authentication. And so the protocol is now five years old. Many flaws have been discovered. Most of them have been fixed. I will talk about some of these flaws later in the talk. So this is O of 2.0 and there's also OpenID Connect. OpenID Connect is quite new. It's one and a half years old and it's an authentication layer on top of O of. So the first definition or real definition on how you should use O of for authentication, but it changes the standard also a bit so it can be seen as a protocol of it on its own. But OpenID Connect, although despite the name, it's also completely incompatible to OpenID. And it has also some dynamic features like IDP discovery, identity provider discovery and stuff like that. So this leads us to the web signal on chart of confusion. So we have O of 1, which is the marketing predecessor of O of 2, but completely incompatible to O of 2. And O of 2 serves as the foundation for login with Facebook, for authentication and also for OpenID Connect. And OpenID Connect, there's OpenID, which is the marketing predecessor of OpenID Connect, but all are saying here it's not compatible to each other. And OpenID Connect is used, for example, by Google. So these are the most commonly used web signal sign-on systems. There's also some others. For example, Mozilla persona, who of you have heard about Mozilla persona? Okay, around 5% more or less. So the original name is browser ID. And there the idea was that the email providers become the identity providers. So this comes from the thought that for classical website where you have to register, they send you emails with tokens you can click on to log in into your account or to reset your password. So your email provider already is a kind of identity provider. So why don't we just use it directly in the web? And Mozilla persona is the first single sign-on system with the goal that we have some kind of privacy in the sense that the identity provider does not learn where you use your accounts. So we will talk about this also later in this talk. So it was developed by Mozilla. And the first idea was to integrate this protocol in the browsers, which never happened. So they went for the target to have a pure web implementation using just HTML5. And they also built bridges to open ID and to get some big identity providers in the system. But this whole approach failed, but it's still interesting if you want to look for privacy. Okay. There are also some other protocols I haven't talked about. And now I will hand over to Daniel. So what is this talk all about? So what is our talk all about? So what we want to do is we want to analyze whether web mechanisms, in this case web signals and on protocols, are secure when they are implemented correctly. So this means if we follow all the standards and all the best practices. On other words, are the standards and protocols that define the web secure? And so the current state of the art is that we have a lot of documents that define some login mechanism, for example, like a Roth. And we have an expert or group of experts and they look at this and after a while they say, well, this seems kind of okay to me. So they say it's secure. So this is the current state of the art. And what we want to do also as part of our PhD research is to change this in a way that has been already successful for other things in the web, in the internet for example, for TLS. We want to create a model of the web infrastructure and of web applications, a formal model. And these models, of course, they are also always incomplete but nonetheless useful as has been shown with TLS 1.3. So we create this model and then we put a lot of work into this. And finally, hopefully, we can create proofs of security for mechanisms or for standards. So of course, the hard part is number two here, as always. And some things our model cannot capture and we don't want to capture these. So for example, phishing attacks or click-jacking attacks or just stupid users that send their password to the attacker, these are things that are out of the scope of the stuff that we are looking at here. In the same manner, compromised browsers or compromised databases and so on. So when we have this model for a web application, one important question and maybe the most important question is what is security? And what is privacy if you want to look at privacy as well? So we have to define this and luckily we can define this if we have a formal model like we have. And the following, of course, I'm not going to present all the formal stuff. This is boring. Therefore, I have a high-level overview of what our authentication properties, for example, look like. Authentication in a web single sign-on system means that an attacker that even has full control over the network, say NSA, should not be able to use a service of a relying party as an honest user. So the NSA should be unable to log into my account, at least if they're not cursing the owner of the relying party or something. And this is an obvious property. There's a slightly less obvious property which says that an attacker should not be able to authenticate an honest browser to a relying party as the attacker. So the attacker should be unable to force Alice's browser to be locked in under the attacker's identity. This is a property that is often also called session fixation or session swapping because if the attacker would be able to do this, he could, for example, force me to be locked in at some search engine and if I then search something with the search engine and I'm locked in into the attacker's account, then the attacker could be able to read what I'm searching for at this search engine. Okay, so these are the authentication properties. Then we also have another property that is important, namely session integrity. Session integrity means that if the relying party acts on Alice's behalf at the identity provider or retrieves Alice's data at the identity provider, then Alice explicitly expressed her consent to lock in at this relying party. So yeah. There's a session integrity and the third property that we have is privacy. And privacy in this case means that a malicious identity provider should not be able to tell whether the user locks in at the relying party A or relying party B. So for example, if auth would have privacy, which it doesn't, then Facebook would be unable to tell whether I log in at Save Wikipedia or my favorite beer.com. There are also other notions of privacy, which we however will not look at in this talk. Okay. Okay. Good. Let's start with a closer look to OAuth. When I say OAuth, I always mean OAuth 2, not the older OAuth 1. So OAuth 2 is mainly defined in RFC 6749 and also some other RFCs and some other documents. OAuth itself has four different modes it can run in. So there's the implicit mode, the authorization code mode, the resource owner password credentials mode, the client credentials mode, and all these modes can have many options, which I won't list here. And out of these four modes, the first two implicit mode and the authorization code mode are the most common ones. So let's have a closer look at these modes. So the implicit mode works like this here. We have an example with some random relying party and Facebook as the identity provider. So first you say I want to log in with Facebook at your relying party. Then your browser gets redirected to Facebook. Facebook prompts you for your authentication data or for some confirmation if you're already logged in at Facebook. And then Facebook issues a token that's called the access token. And Facebook redirects your browser back to the relying party and puts the access token in the URI. And then for some technical reasons, we need some additional steps to retrieve this access token from the URI because it's in the fragment part. And then finally the relying party gets to retrieve this access token. And now with this access token, this is an access token. It's basically the same thing as in this first high-level overview when I just talked about tokens. So access token is such a token which gives the relying party access to the user's account at Facebook. And now the relying party can retrieve data on the user's behalf at Facebook. Or it can retrieve a user identifier and then consider this user to be logged in and issue, for example, some cookie. So this is the implicit mode. There's also the authorization code mode. There are things that are similar. The user says I want to log in with Facebook, gets redirected to Facebook, authenticates at Facebook, and then Facebook instead of issuing an access token, it issues a so-called authorization code. And the relying party then takes this authorization code and redeems it for an access token directly at Facebook. So we have here some one intermediate step with this authorization code. And then the access token, the relying party retrieved, it can then use to act on the user's behalf at Facebook or consider the user to be logged in. So let's talk about selected attacks on OALF. First, let's talk a bit about known attacks. There are attacks like the so-called cut and paste attacks where you reuse some of these tokens like access token or authorization code or there are also some other tokens which I haven't talked about. So I left out some details before. It's about reusing these tokens from different flows, mixing them into a new flow, and then break the system. So there are a lot of cut and paste attacks known. And the OALF working group is continuously giving a try on how to prevent these cut and paste attacks. Another problem is if you don't use HTTPS, then you are screwed because a man in the middle can easily read everything or the tokens that are exchanged. So if you're in some Wi-Fi and the guy next to you is sniffing on the Wi-Fi, you log in and don't use HTTPS because some developers forgot that there is something called HTTPS, then basically the whole thing is screwed. And also if you just rely on cookies, then you're also screwed because cookies lack integrity. It's very easy to just inject cookies into your browser over HTTP and then these cookies will later also be used over HTTPS. So cookies are also not a good thing to rely on. So let's talk about some attacks we have found in our research. There is the 307 redirect attack and it works like this. First we have some regular OALF flow. And in this OALF flow, if you have a closer look at what happens here in step 2 to 4, we have the user authentication and after this authentication, the user gets redirected back to the relying party. If you look more into the details of these requests, so first you have this request where you go to your identity provider and ask, I have start the OALF flow there. So you just came from the relying party where you want to log in, click on that button, log in with this IDP, you get redirected and then your browser contacts this identity provider here. I have been redirected to you in an OALF flow. Please authenticate the user. So this is the step 2A. Then your identity provider returns some form where you have to enter your username and password usually. And then you enter username and password and these are sent over to the identity provider. And now if this identity provider redirects you back to the relying party and uses the wrong HTTP location redirect method for this, namely the 307 method, then the following happens, the browser is instructed to just repost all your credentials. So if you're logging in at some malicious relying party, that relying party gets your username and password. So this happens if you use 307 redirect. Fortunately, we didn't find any identity provider in the wild who actually uses 307, but you can never exclude that there is some implementation which makes actually use of this location redirect method. Also, if you look at the standard, how these are defined, it's not always clear which redirect method has which details and behavior. And also the OALF working group didn't think about this. So in their standard, they write, I just use any method. And surely the mitigation here is don't use 307, for example, use 303 instead. So the next attack is the identity provider mix up attack. I will present this in implicit mode and only one variant of this attack. So here in this attack, we have the following setting. We have from step two on all these requests are usually encrypted, but the very, very first request there, we cannot be sure it is encrypted because a lot of relying parties, when you go to the website, you go over HTTP. And this very first information, where you just click, I want to use Facebook to log in, there you could easily assume this is not a sensitive information. So this very first request goes off and unencrypted. Or if you, for example, consider other attacks like TLS stripping, then you also cannot guarantee that this request is encrypted. So now for an attacker who, for example, sits in the same Wi-Fi network as you, so probably the guy next to you could easily mount the attack as follows. So when your browser sends this request to a relying party, log in with Facebook, the attacker can easily change this and changes to just use the identity provider that is run by the attacker. Remember, you can have a lot of different options of identity providers and with some extension, this can also be extended dynamically just by entering some domains. And then the relying party thinks, okay, that user wants to use the attacker identity provider. It answers with a redirect to the attacker's web page. But now as the attacker still sits in the middle, he can just change it back to Facebook. So the OOS dense continues as usual. You go to Facebook, authenticate there, you get redirected back with probably some access token, and then eventually the relying party retrieves this access token and wants to use this access token. So what happens? It won't use this access token at Facebook, but at the attacker instead because it still thinks that the attacker is the identity provider that is used here. So in practice, if you want to mount this attack, then you have to take care of more details like when you want to break authentication instead of authorization. So in the version I just presented, the attacker gets the access token, can act on the user as behalf at Facebook or at some other identity provider that uses OOS. So this is not limited to Facebook. But for break authentication at the relying party, there are some other further steps needed, but there are also some other details that have to be taken care of like client identifiers, which are P's relying parties used to identify themselves to identity providers, the same for client credentials, which are optional by the way. And in OpenID Connect, the layer on top of OOS, if this is used, then you need to take care about some other stuff like the switching of some signatures or exchanging some signatures and so on. But it's still possible, so we successfully attacked real-world applications, and this definitely works. And there are also some variants that do not rely on that first request going over HTTPS. But explaining all the variants would take a whole talk on its own. So we'll now skip this and talk about mitigation. So the mitigation we propose is quite simple. So the one problem is here in step three, this access token is just some opaque string. The relying party cannot see who issued that access token, so it needs some further information carried along with this access token, and that is who is the identity provider which issued this access token. And if you have this information carried along, then the relying party can easily detect this attack and see that there is a mismatch between step five to the one in step 1A, where the relying party received the message, the attacker identity provider is to be used, and in five it gets the message here as an access token, and it's from Facebook. So there's a mismatch, and this whole flow can be aborted without the attack being successful. So this is the mitigation. We talked to the working group at the ITF, so they invited us to an emergency meeting to discuss this attack, and we scheduled public disclosure of these attacks, so at the beginning of this year. In June we had this triggered an OF security workshop which took place in June. New RFC with the mitigations is in preparation, and also the working group showed interest in the kind of formal analysis we do to carry out for these kind of standards. So to sum up, the security for OF2, if you have all these fixes applied and there are no implementation errors, then we can say that in terms of security OF2 is quite good. We have formal proof in our model for this, but regarding privacy, OF2 does not provide any privacy at all. Speaking about privacy, we mentioned earlier already that there was a single sign-on system that tried to provide privacy, namely browser ID, alias Mozilla persona. So as we already said before, this is a web-based single sign-on system with design goals of having no central authority and provide better privacy. Spoiler word, they failed at both. So how does browser ID work? So let's have a look at this on a very high level first. So as Gito already said in browser ID, the mail provider is the identity provider. So we have a user, alias, alias at mailprovider.com, and in the first phase, when using browser ID, she does the following. She goes to her identity provider and first creates a public-private key pair. And then she sends the public key in a document with her own identity to the mail provider, and the mail provider then signs this document. And this creates the so-called user certificate. And this certificate is then sent back to alias. Now in the second phase, if Alice wants to actually log in at some website, and then she does the following. She creates another document containing the identity of the website where she wants to log in, say Wikipedia. And to do so, she signs the identity of Wikipedia with her own private key. And this creates the so-called identity search. Now Alice sends both documents to Wikipedia. And Wikipedia can then, of course, check these documents because Wikipedia can check first, it can retrieve the public key of the mail provider, can check the user certificate, and then also can check the identity assertion. And then Wikipedia can consider Alice to be logged in. So this was the basic idea of browser ID, which is quite nice and clean and simple. And then they started to implement this using just standard browser features, including all the workarounds for the Internet Explorer and so on and so on. And they ended up with a quite complicated system. So here we have on the left side an Alice's browser to Windows, namely Wikipedia. And the lock-in dialogue, which is provided by a central authority, which they tried to avoid, lock-in.persona.org. And inside both of these windows, there are other iframes. And inside one of these iframes, there's another iframe. And on the right, we have the servers, so the relying party, the identity provider, and the central authority, lock-in.persona.org. And just to give you an idea how complex the system ended up, they all talked to each other using HTTP requests, but also using post-messages and also using XML HTTP requests. And as you can see, the system became quite complex. To add even more complexity, they did the following. They thought, well, some users, they are already using Gmail or Yahoo. So let's provide some nice interface for them. They provided the so-called identity purchase, specifically for Gmail and Yahoo, which at the time supported OpenID authentication only. And they created two new servers, the so-called bridging servers, one for Gmail called Sideshow and the other one for Yahoo called BigTent. Now the user authenticates to the bridging server using OpenID. And then the bridging server has an interface to the standard browser ID interface. Yeah. So one problem was that OpenID identities, they are not email addresses. So in OpenID, you add an attribute, which is called the email attribute, and we are talking about this email attribute in a minute. So let's have a look at how these identity bridges work. We are not going into all the details of the browser ID or persona protocol, because this would be too complicated. But the identity bridge is interesting and also important for some of the attacks that we found. So in the identity bridge, the following happens. So here on the left, we have Alice's browser. In the middle, we have Sideshow, so this identity bridge. And on the right side, we have Gmail, which could also be Yahoo in this case. But yeah, let's say it's Gmail. So first, the user says that she wants to log in at Sideshow. And then Sideshow sends an OpenID request requesting the email attribute signed from Gmail. This request is then forwarded to Gmail. And Gmail sees this request. The user logs in at Gmail for authentication. And then Gmail creates this OpenID assertion, which contains the signed email address attribute for Alice. And as you can see, this is all in the green box. So all properly signed and nice. And now Alice's browser redirects this document to Sideshow. Now Sideshow doesn't check the contents of this assertion for itself. Instead, it sends these things to Gmail. Gmail checks everything that is signed. And tells Sideshow, yes, this document looks correct to me. Everything that was signed was signed by me and was not tempered with. Then Sideshow looks at the document and sees, ah, Alice wanted to log in. So this must be Alice. The user must be Alice now. And provides a cookie because the user is now logged in as Alice. So far, so simple. Now for some of the attacks that we found. First attack, identity forgery. So here we have essentially the same that we saw before, the same setting. Except now we don't have Alice's browser on the left. We have the attacker's browser on the left. The attacker can go to Sideshow and say, I want to sign in. Now Sideshow sends this OpenID request to the attacker. And the attacker can change this request. The attacker can just remove the request for the email attribute from this request. Which is still a valid OpenID request. Gmail sees this request. And now the attacker logs in. The attacker doesn't have Alice's user data. So the attacker just logs in with his own credentials. And now Gmail creates an OpenID assertion containing the signed attribute which was requested, which was none. So essentially the document is empty. At least it is without any email address. Now the attacker can simply add a new attribute to this document containing an email address that he has chosen arbitrarily. This of course is not signed. Which is not a problem because this document can be partly signed. And this document is forwarded to Gmail. Gmail now analyzes this document and sees, well, there's a signed part in this document. So I check this signed part. This signed part doesn't contain anything useful. But it is correct. It's not the wrong signature. So it checks out. And it sends back to Sideshow. I checked this document. Looks fine to me. Now Sideshow looks at the document. Sees that there's an email attribute. Uses this email attribute. And the attacker is signed into any Gmail account that he likes. With browser ID. Okay. So this is bad. As you can imagine. And we told the Mozilla guys about this. And they were quite fast. So we were really surprised. They were really quick. So I think it was in the middle of the night for most of them. But they scrambled in the bug tracker. And they wrote some patches and so on and so on. And I think it wasn't 24 hours later that it was all deployed and fixed. So this was both quite good. But then we took another look at the system. And we found identity forgery number two. Which is actually remarkably similar. It works as follows. So the attacker sends the authentication request. You know this part. And Sideshow wants the signed email attribute. And the attacker now doesn't change anything. The attacker just forwards this request to Gmail. Gmail asks for the credentials. The attacker signs in. And sends back the OpenID assertion containing the signed email address of the attacker. So no attack up to this point. And now the attacker can do the following. The attacker adds another attribute. And yeah, you can guess what happens. The document is forwarded to Gmail. Gmail checks the signed part of the document, which is still fine. Sends back to Sideshow that everything is fine with this document. And Sideshow selects the wrong email address. Yeah. And now the attacker is signed into any user account. Again. Okay. So this was the second identity forgery attack. We also found another attack, which is not very spectacular. And we also looked. So this was all, of course, authentication. And we also took a look at privacy. So as you remember, privacy says that in the words of Mozilla, the browser ID protocol never leaks tracking information back to the identity provider. Except it does. So ideally, the identity provider should be unable to tell where the user looks in. In fact, this is broken. Because in the browser, the following happens. If malicious identity provider wants to find out whether a user is locked in at some specific relying party or not, then the malicious identity provider can just open an iframe containing the website of that relying party he wants to probe. Now the following happens. The normal JavaScript of browser ID runs in this relying party because it has browser ID support, obviously, and creates an iframe. And inside this iframe, another iframe will be created. But this innermost iframe will only be created if the user locked in at this RP before. Now, since the outermost and the innermost iframe come from the same source and they can collaborate and communicate, they can for example just send a post message, say, the user locked in at this relying party before. So an identity provider can easily probe whether a user locked in at some relying party or not. And this, unfortunately, cannot be fixed without a major redesign of browser ID because they relied on all these iframes and so on. Yeah, so I think this can be considered broken beyond repair. We also found some variants of these privacy attacks which rely on other mechanisms but essentially, yeah, you get the idea, privacy and browser ID is broken. So to sum up, browser ID, we found attacks but we also were able to fix them with respect to security. And we also used our formal methods to prove the security of the fixed browser ID system. But privacy is broken beyond repair. Okay, this leads us to the question, can we build a single sign-on system that provides security and privacy in the web? So we thought a lot about this question and then we used our formal model to design such a single sign-on system and we could also then use the formal model to prove that these properties are actually fulfilled. So the basic principle of this system is called Espresso for secure privacy respecting single sign-on. It's the following. We have the user with a browser. This user wants to log in at some relying party, for example, at Wikipedia. So here we have the same idea as a browser ID to use the email address and the email provider as the identity provider. So the user enters the email address and then the relying party asks for some proof of this identity. So the user goes to her email provider, which is her identity provider in this case, authenticates there and then the identity provider creates a document that proves the Alice's identity and Alice then forwards this document to the relying party and the relying party can check if everything is all right and then consider the user to be logged in. So let's have a closer look on how this system works. So here again we have Alice's browser, the window of the relying party. Alice enters her email address. The email address is sent to the relying party and now the relying party creates a document that contains the identity of the relying party itself and this document is encrypted and we call this document then the tag. So now the tag is sent along with the key that was used to encrypt this document. So this is symmetric encryption with a fresh key, sends it to the browser and now in the browser the express code opens a new window of the identity provider that is given by the domain of the email address and sends the tag over to this window. This login dialog prompts the user to authenticate so the user now enters her password and this is sent along with the tag to the server and now the server creates this document I've just spoken of in the last slide and this document we call it the user assertion. We send it back to the window, the login dialog and now we have a problem. We could just send it over to the Wikipedia window but I will show you in a minute why this is a bad idea. So instead now we have a third party, the forwarder which serves just a single static JavaScript file and this is loaded in an iframe and this login dialog and this iframe gets the user assertion and it also gets the key and now it can decrypt the tag, look who is the intended receiver and then it sends over the user assertion to the window of the relying party which forwards it to the server of the relying party who can check if everything is all right and consider the user to be logged in. So why do we need this forwarder? First it may look strange. So let's look what happens if we just don't have this forwarder. So let's assume the user wants to log in at some malicious relying party at attacker.com and there is an email address but the attacker wants to impersonate the user. He wants to log in at some other relying party, let's say to Wikipedia for example and the attacker goes to Wikipedia and says hi, I'm Alice, I want to log in. Wikipedia creates a tag, does this send over to the attacker who just relays it to the user. The protocol runs on, the user authenticates to her identity provider and then we just send the tag over. The identity provider does not know who the intended receiver is because we want to have this privacy feature. This just went through and the attacker gets the user certificate and user assertion and forwards it to Wikipedia and then the attacker is considered to be Alice and this is bad. So we need some mechanism to prevent that the user assertion is forwarded to some random party but only to the intended receiver. For this we have this forwarder. Now you can think this forwarder may be also malicious but let's talk about this in a second. So let's just talk about what the forwarder does. So the forwarder gets the user assertion and he gets the key to decrypt the tag and now he can instruct the browser to send a post message but only to a window of Wikipedia. So the browser checks if the receiver of a window of Wikipedia or not and if it's not, it doesn't deliver this message. So this protects the user assertion to be leaked and now you may think this forwarder may be malicious and deliver some other script that does strange things like forwarding things to the attacker directly but we can enforce that the correct script is running inside that iframe using separate source integrity where you just tell the browser in this window only this code may run and in this case the forwarder cannot just put some arbitrary or malicious code in this iframe and also there is no information that leaks back from the browser to the forwarder. So to sum this up as I've just presented Espresso, it features privacy and authentication. It's open and decentralized so you don't need any specific central party. It's compliant to web standards that's based on HTML5 and we have formal proofs that all these properties we've talked at the beginning actually hold and you can find a demo and more information on Espresso.me. Okay now to conclude the talk what is the take away? First of all we've talked I think most of the time about OAuth 2.0 most of the results also translate to OpenID Connect. We have formally proven the security of the protocol of OAuth and also OpenID Connect which is a nice result of course if you are okay with having no privacy because OAuth and OpenID Connect don't have any kind of privacy that we talked about. Regarding OAuth 1.0 and OpenID I think they can be considered deprecated and shouldn't be used. BrowseID Mozilla persona was a nice experiment but is dead now and also has broken privacy. With Espresso we have shown however that you can achieve privacy and web single sign-on using standard HTML5 features and standard web features but of course for now it is a proof of concept as you have seen we don't even have a nice logo yet. Yeah so and one target audience are certainly developers, developers, developers. Use libraries wherever possible for example PYOIDC is written even by members of the OAuth and OpenID Connect working groups so they know what they do hopefully. Also regarding RSCs they are hard to read and information is often spread across several documents. They are often not written clearly and they are not always up to date but they are still an important reference and I think it's a good advice to look at the RSCs from time to time even if they are hard to read. So thank you very much for your attention. If you want to talk to us come to us at the machine deck assembly in hall 3 or join us at the next Pylen Moor, Shameless Pluck here in January 14 in Kielfeld or at the University of Stuttgart starting in January. Thank you very much. Now we have 8 minutes for questions. What do we have from the internet? So we've got two questions from the internet. Can you hear me? So at the diagram you showed one of the first slides, why does the authentication follow authorization? Shouldn't it normally be the other way around? Can you try to repeat the question? Yeah, sorry. At the diagram you showed in one of the first slides, why does the authentication follow authorization? Shouldn't it normally be the other way around? Okay, so these are two concepts that are kind of orthogonal to each other. So you can either do authentication to ensure yourself of the user's identity or you can act on the user's behalf at the identity provider like posting on the user's Facebook timeline or doing different things there. But for authentication you need to retrieve some unique user identifier and this basically makes use of this authorization mechanism. So you get authorized to access this unique user identifier and you use this then for authentication. Thank you. Questions from here? So for the special protocol, you need the forwarding party to check whether the certificate was actually from Wikipedia not from attacker.com. But could Nala's do this check herself? You mean that you present the user something and the user accepts this or declines this in this sense? She has the challenge that is signed by her email provider and she has the key that encrypted Wikipedia identity. So she could use that to do encrypted and check if it's Wikipedia or attacker.com. In principle, yes. So you mean the user could check? Yes. The user could of course check. Ask the user did you really want to sign in at attacker.com or at Wikipedia.com. But of course we all know that users are better at making decisions. So, yeah. Thank you. Questions from here? Hi. Thanks for the informative talk. But I wanted to add a remark that's highly unfair to call users stupid for falling victim to click checking and phishing because they are working professionally on enabling click checking and phishing. And if you need a 4K monitor just to see that there is some JavaScript data that like 1000 zero delimiters, it is impossible to blame the user for being stupid for falling victim to click checking. So just yes. That is correct. Also sometimes you just can't see it. So, yes. Thank you. Questions from down there? Sorry. Questions? You talked about formal verification of both OAuth and your protocol. I wanted to know what kind of program or whatever used like Proverif, Tamarin, whatever. And also I think you just proved the, you just verified the subset of OAuth. So let's start with the second question first. So for OAuth we really try to introduce as many options as we could find in the standard, so to say. OAuth is a very like loose standard so they give you a lot of options in many ways. We had to exclude some of them for practical reasons when modeling the stuff. But we included almost all of the options that OAuth provides. And we also have a detailed write up of what the options are and that we excluded and that we included. And now for the first part of the question, our model currently is a manual model. So what we do is pen and paper proofs. The reasoning behind this is that if you have tools they are always in some sense limiting you. And when we started out with this work there was, or there were two models essentially already existing web models, formal web models so in the same area as we are. But they were both based on model checkers, so one on Proverif, the other one on another model into... Alloy. Alloy. And both were limited by the possibilities that you had in these model checkers. So what we went the other way around, what we wanted to do is a manual model that includes... that models the web really precisely and comprehensively. And then as a second step what we are currently working on or discussing about is to transfer this into some kind of tool. Thank you. Two more questions. Questions from the internet? So I was wondering if you know about IndiAuth and RelmiAuth and what you think about the question of using domain names versus email addresses as the user identifier. Could you repeat that a bit louder please? So if you have any comments about IndiAuth and RelmiAuth which uses the domain name as identifier rather than an email address. So we didn't look at these systems. Okay. Yes, last question. The question regarding the forewater and the privacy protection realized with the forewater. As far as I understand the forewater is used in its own iframe to prevent the IDP from taking control of the verification process knowing that who is the final system. But what if the identity provider and the forewater collaborate then the privacy would be broken? Yes. If we have these parties collaborating then of course they are broken. So we haven't shown all the details of this system. So this is really hard to prevent. But in Espresso the relying party is allowed to choose which forewater has to be used. So relying party should choose a forewater run by some trustworthy party. So this is the counter measure to prevent collaboration. But if these parties collaborate then you are screwed. So we also, so I think it's also important to add, so the forewater is kind of a semi-trusted party. Because on the one hand we can enforce that it uses the correct code. Of course the IDP then has to enforce this. On the other hand you still have some side channels like for example timing. So if you control the parties then you could check which IP addresses access for example the forewater and the IDP at the same time and so on. So there are some side channels though. So the idea that we have to minimize this risk is to provide a set of trusted forewaters that could be for example provided by some trusted parties like Mozilla or the EFF or something. So that you have set of forewaters to choose from and hopefully choose a trusted one. Thank you. You're welcome. Girosh Mitz and Daniel Fett. Thank you so much for the great talk. Please give them another great round of applause. Thank you.
 So, I think we're all set. Without further ado, I'd like to introduce Guido Schmidt and  Daniel Fett, who are going to be having this talk on a single sign-on on the web. Give  them a big round of applause, and I hope you're looking forward to the talk.  Okay. Hello, everybody. Welcome to our talk on the security and privacy of modern single  sign-on on the web. So, in this talk, Daniel and me, we are going to present not only just  attacks on OAuth and OpenID Connect, but also some thoughts about analysis of all these  standards. So, first, a brief introduction. Who are we? We are researchers from the University  of Trier, but soon of the University of Stuttgart. And also, we happen to be the founders of the  machine deck, Hacker Space in Trier, and the Piantmore Raspberry Jam. If you're interested  in anything else, what we are doing, you can just follow us on Twitter. So, what is this  single sign-on about? What are we talking about? So, probably all of you have seen websites  like this, like TripAdvisor, where you can use a lot of different methods to sign-in.  You can sign in with your Facebook account, with your Google account, you can register  account at their page with email address and password, or you can use your Samsung account  or probably now even more different systems. And if you click, for example, on this login  with Facebook button, and your window pops up, prompting for your Facebook credentials,  or if you're already signed in into Facebook, just asks for confirmation. So, this is a  setting we are looking at. And we have two parties here. We have TripAdvisor as the so-called  relying party, and we have Facebook as the so-called identity provider. And the basic  principle of how this works is the following. So, first you go with your browser to the  relying party, you say, I want to log in with that IDP. Then you contact your identity provider,  authenticate there, and this identity provider then issues some kind of token. And this token  you give to the relying party, and the relying party can now use this token to access some  parts of your account at the identity provider. And this is called authorization. For example,  the relying party can use this token now to post on your Facebook timeline or reach  out your friends list from Facebook. And the relying party can also retrieve some unique  user identifier and then consider you to be logged in with that user identifier. And then  this is authentication. And then RP can set, for example, some session cookie and mark this  session belongs. Remember that this session belongs to this user. So, this was the basic  principle. Why should we use single sign on or why shouldn't we use single sign on? So,  for users, it's very convenient. You don't have to remember which account you used, where,  which you password, and so on. You just click and log in with Facebook and you're all done.  Of course, this comes with lack of privacy because Facebook then always knows where you  log in. And also, the identity provider you choose is also a single point of failure.  If that one closes down or changes its terms and conditions, then you perhaps cannot log  in into your accounts anymore at some third party web pages. So, for relying parties,  they need to store less data. They don't have to care about password databases that can  leak. They don't have to care about user registration, password recovery on all the hassle that comes  with user accounts. But they also have less control over the user's accounts because they  outsource the authentication to this identity provider. And also here, the identity provider  is a single point of failure. So, for identity providers, the advantage is clear. They get  more user data and they can provide some service for their users which makes perhaps it makes  it more attractive for users to use that identity provider. On the downside, they also have to  take care about more user data. They have to store and protect it. And they have to have  the overhead of implementing and running the single sign-on system. So, what are these  single sign-on systems? Now, I will show you some prominent examples. So, there's O of  1.0. So, this is a not-so-modern single sign-on system. It's now 10 years old. Many flaws  are known for this system and basically nobody uses it anymore except for Twitter. So, Twitter  uses a modified version of O of 1.0 which more or less fixes all the known flaws. But  in general, we can say, don't use O of 1.0. There's also OpenID, which is also quite old,  nine years. It's not that user-friendly. It's a standard that's meant to be super flexible  for every corner use case that the developers at that time thought of. And this makes it  also extremely hard to use correctly because you have a lot of things going on, things  change during an OpenID run at talk and it's not that nice to develop something for OpenID.  So also for OpenID, don't use this. And they are now modern single sign-on systems for  example O of 2.0, which is also used in login with Facebook. This is completely incompatible  to O of 1.0. O of 2.0 uses the so-called Beera token approach. That is, the old protocol  is based on some random values that are passed around, but there's no crypto involved except  for the transport layer for HTTPS for example. O of 2.0 is used everywhere almost. So it's  the most popular of these systems, but it has never been developed for authentication.  And really it's not meant for authentication. And if you Google for O of 2.0 and authentication,  you are after some time stumble upon the following picture. So these two guys are members of  the O of working group and they really insist it's not meant for authentication at all.  It's just for authorization. Okay. Nonetheless, it is used in practice also for authentication.  Facebook for example uses it for authentication. And so the protocol is now five years old.  Many flaws have been discovered. Most of them have been fixed. I will talk about some of  these flaws later in the talk. So this is O of 2.0 and there's also OpenID Connect. OpenID  Connect is quite new. It's one and a half years old and it's an authentication layer  on top of O of. So the first definition or real definition on how you should use O of  for authentication, but it changes the standard also a bit so it can be seen as a protocol  of it on its own. But OpenID Connect, although despite the name, it's also completely incompatible  to OpenID. And it has also some dynamic features like IDP discovery, identity provider discovery  and stuff like that. So this leads us to the web signal on chart of confusion. So we have  O of 1, which is the marketing predecessor of O of 2, but completely incompatible to  O of 2. And O of 2 serves as the foundation for login with Facebook, for authentication  and also for OpenID Connect. And OpenID Connect, there's OpenID, which is the marketing predecessor  of OpenID Connect, but all are saying here it's not compatible to each other. And OpenID  Connect is used, for example, by Google. So these are the most commonly used web signal  sign-on systems. There's also some others. For example, Mozilla persona, who of you have  heard about Mozilla persona? Okay, around 5% more or less. So the original name is browser  ID. And there the idea was that the email providers become the identity providers. So  this comes from the thought that for classical website where you have to register, they send  you emails with tokens you can click on to log in into your account or to reset your password.  So your email provider already is a kind of identity provider. So why don't we just use  it directly in the web? And Mozilla persona is the first single sign-on system with the  goal that we have some kind of privacy in the sense that the identity provider does  not learn where you use your accounts. So we will talk about this also later in this  talk. So it was developed by Mozilla. And the first idea was to integrate this protocol  in the browsers, which never happened. So they went for the target to have a pure web  implementation using just HTML5. And they also built bridges to open ID and to get some  big identity providers in the system. But this whole approach failed, but it's still  interesting if you want to look for privacy. Okay. There are also some other protocols  I haven't talked about. And now I will hand over to Daniel. So what is this talk all about?  So what is our talk all about? So what we want to do is we want to analyze whether web  mechanisms, in this case web signals and on protocols, are secure when they are implemented  correctly. So this means if we follow all the standards and all the best practices. On  other words, are the standards and protocols that define the web secure? And so the current  state of the art is that we have a lot of documents that define some login mechanism,  for example, like a Roth. And we have an expert or group of experts and they look at this  and after a while they say, well, this seems kind of okay to me. So they say it's secure.  So this is the current state of the art. And what we want to do also as part of our PhD  research is to change this in a way that has been already successful for other things in  the web, in the internet for example, for TLS. We want to create a model of the web infrastructure  and of web applications, a formal model. And these models, of course, they are also always  incomplete but nonetheless useful as has been shown with TLS 1.3. So we create this model  and then we put a lot of work into this. And finally, hopefully, we can create proofs  of security for mechanisms or for standards. So of course, the hard part is number two  here, as always. And some things our model cannot capture and we don't want to capture  these. So for example, phishing attacks or click-jacking attacks or just stupid users  that send their password to the attacker, these are things that are out of the scope  of the stuff that we are looking at here. In the same manner, compromised browsers or  compromised databases and so on. So when we have this model for a web application, one  important question and maybe the most important question is what is security? And what is  privacy if you want to look at privacy as well? So we have to define this and luckily  we can define this if we have a formal model like we have. And the following, of course,  I'm not going to present all the formal stuff. This is boring. Therefore, I have a high-level  overview of what our authentication properties, for example, look like. Authentication in  a web single sign-on system means that an attacker that even has full control over the  network, say NSA, should not be able to use a service of a relying party as an honest  user. So the NSA should be unable to log into my account, at least if they're not cursing  the owner of the relying party or something. And this is an obvious property. There's a  slightly less obvious property which says that an attacker should not be able to authenticate  an honest browser to a relying party as the attacker. So the attacker should be unable to  force Alice's browser to be locked in under the attacker's identity. This is a property  that is often also called session fixation or session swapping because if the attacker  would be able to do this, he could, for example, force me to be locked in at some search engine  and if I then search something with the search engine and I'm locked in into the attacker's  account, then the attacker could be able to read what I'm searching for at this search  engine. Okay, so these are the authentication properties. Then we also have another property  that is important, namely session integrity. Session integrity means that if the relying  party acts on Alice's behalf at the identity provider or retrieves Alice's data at the  identity provider, then Alice explicitly expressed her consent to lock in at this relying party.  So yeah. There's a session integrity and the third property that we have is privacy. And  privacy in this case means that a malicious identity provider should not be able to tell  whether the user locks in at the relying party A or relying party B. So for example,  if auth would have privacy, which it doesn't, then Facebook would be unable to tell whether  I log in at Save Wikipedia or my favorite beer.com. There are also other notions of  privacy, which we however will not look at in this talk. Okay. Okay. Good. Let's start  with a closer look to OAuth. When I say OAuth, I always mean OAuth 2, not the older OAuth  1. So OAuth 2 is mainly defined in RFC 6749 and also some other RFCs and some other documents.  OAuth itself has four different modes it can run in. So there's the implicit mode, the  authorization code mode, the resource owner password credentials mode, the client credentials  mode, and all these modes can have many options, which I won't list here. And out of these  four modes, the first two implicit mode and the authorization code mode are the most common  ones. So let's have a closer look at these modes. So the implicit mode works like this  here. We have an example with some random relying party and Facebook as the identity  provider. So first you say I want to log in with Facebook at your relying party. Then  your browser gets redirected to Facebook. Facebook prompts you for your authentication  data or for some confirmation if you're already logged in at Facebook. And then Facebook issues  a token that's called the access token. And Facebook redirects your browser back to the  relying party and puts the access token in the URI. And then for some technical reasons,  we need some additional steps to retrieve this access token from the URI because it's  in the fragment part. And then finally the relying party gets to retrieve this access  token. And now with this access token, this is an access token. It's basically the same  thing as in this first high-level overview when I just talked about tokens. So access  token is such a token which gives the relying party access to the user's account at Facebook.  And now the relying party can retrieve data on the user's behalf at Facebook. Or it can  retrieve a user identifier and then consider this user to be logged in and issue, for example,  some cookie. So this is the implicit mode. There's also the authorization code mode.  There are things that are similar. The user says I want to log in with Facebook, gets  redirected to Facebook, authenticates at Facebook, and then Facebook instead of issuing an access  token, it issues a so-called authorization code. And the relying party then takes this  authorization code and redeems it for an access token directly at Facebook. So we have here  some one intermediate step with this authorization code. And then the access token, the relying  party retrieved, it can then use to act on the user's behalf at Facebook or consider  the user to be logged in. So let's talk about selected attacks on OALF. First, let's talk  a bit about known attacks. There are attacks like the so-called cut and paste attacks where  you reuse some of these tokens like access token or authorization code or there are also  some other tokens which I haven't talked about. So I left out some details before. It's about  reusing these tokens from different flows, mixing them into a new flow, and then break  the system. So there are a lot of cut and paste attacks known. And the OALF working  group is continuously giving a try on how to prevent these cut and paste attacks. Another  problem is if you don't use HTTPS, then you are screwed because a man in the middle can  easily read everything or the tokens that are exchanged. So if you're in some Wi-Fi  and the guy next to you is sniffing on the Wi-Fi, you log in and don't use HTTPS because  some developers forgot that there is something called HTTPS, then basically the whole thing  is screwed. And also if you just rely on cookies, then you're also screwed because cookies lack  integrity. It's very easy to just inject cookies into your browser over HTTP and then these  cookies will later also be used over HTTPS. So cookies are also not a good thing to rely  on. So let's talk about some attacks we have found in our research. There is the 307 redirect  attack and it works like this. First we have some regular OALF flow. And in this OALF flow,  if you have a closer look at what happens here in step 2 to 4, we have the user authentication  and after this authentication, the user gets redirected back to the relying party. If you  look more into the details of these requests, so first you have this request where you go  to your identity provider and ask, I have start the OALF flow there. So you just came  from the relying party where you want to log in, click on that button, log in with this  IDP, you get redirected and then your browser contacts this identity provider here. I have  been redirected to you in an OALF flow. Please authenticate the user. So this is the step  2A. Then your identity provider returns some form where you have to enter your username  and password usually. And then you enter username and password and these are sent over to the  identity provider. And now if this identity provider redirects you back to the relying  party and uses the wrong HTTP location redirect method for this, namely the 307 method, then  the following happens, the browser is instructed to just repost all your credentials. So if  you're logging in at some malicious relying party, that relying party gets your username  and password. So this happens if you use 307 redirect. Fortunately, we didn't find any  identity provider in the wild who actually uses 307, but you can never exclude that there  is some implementation which makes actually use of this location redirect method. Also,  if you look at the standard, how these are defined, it's not always clear which redirect  method has which details and behavior. And also the OALF working group didn't think about  this. So in their standard, they write, I just use any method. And surely the mitigation  here is don't use 307, for example, use 303 instead. So the next attack is the identity  provider mix up attack. I will present this in implicit mode and only one variant of this  attack. So here in this attack, we have the following setting. We have from step two on  all these requests are usually encrypted, but the very, very first request there, we  cannot be sure it is encrypted because a lot of relying parties, when you go to the website,  you go over HTTP. And this very first information, where you just click, I want to use Facebook  to log in, there you could easily assume this is not a sensitive information. So this very  first request goes off and unencrypted. Or if you, for example, consider other attacks  like TLS stripping, then you also cannot guarantee that this request is encrypted. So now for  an attacker who, for example, sits in the same Wi-Fi network as you, so probably the  guy next to you could easily mount the attack as follows. So when your browser sends this  request to a relying party, log in with Facebook, the attacker can easily change this and changes  to just use the identity provider that is run by the attacker. Remember, you can have  a lot of different options of identity providers and with some extension, this can also be  extended dynamically just by entering some domains. And then the relying party thinks,  okay, that user wants to use the attacker identity provider. It answers with a redirect  to the attacker's web page. But now as the attacker still sits in the middle, he can  just change it back to Facebook. So the OOS dense continues as usual. You go to Facebook,  authenticate there, you get redirected back with probably some access token, and then  eventually the relying party retrieves this access token and wants to use this access  token. So what happens? It won't use this access token at Facebook, but at the attacker  instead because it still thinks that the attacker is the identity provider that is used here.  So in practice, if you want to mount this attack, then you have to take care of more  details like when you want to break authentication instead of authorization. So in the version  I just presented, the attacker gets the access token, can act on the user as behalf at Facebook  or at some other identity provider that uses OOS. So this is not limited to Facebook. But  for break authentication at the relying party, there are some other further steps needed,  but there are also some other details that have to be taken care of like client identifiers,  which are P's relying parties used to identify themselves to identity providers, the same  for client credentials, which are optional by the way. And in OpenID Connect, the layer  on top of OOS, if this is used, then you need to take care about some other stuff like the  switching of some signatures or exchanging some signatures and so on. But it's still  possible, so we successfully attacked real-world applications, and this definitely works. And  there are also some variants that do not rely on that first request going over HTTPS. But  explaining all the variants would take a whole talk on its own. So we'll now skip this and  talk about mitigation. So the mitigation we propose is quite simple. So the one problem  is here in step three, this access token is just some opaque string. The relying party  cannot see who issued that access token, so it needs some further information carried  along with this access token, and that is who is the identity provider which issued  this access token. And if you have this information carried along, then the relying party can  easily detect this attack and see that there is a mismatch between step five to the one  in step 1A, where the relying party received the message, the attacker identity provider  is to be used, and in five it gets the message here as an access token, and it's from Facebook.  So there's a mismatch, and this whole flow can be aborted without the attack being successful.  So this is the mitigation. We talked to the working group at the ITF, so they invited  us to an emergency meeting to discuss this attack, and we scheduled public disclosure  of these attacks, so at the beginning of this year. In June we had this triggered an OF  security workshop which took place in June. New RFC with the mitigations is in preparation,  and also the working group showed interest in the kind of formal analysis we do to carry  out for these kind of standards. So to sum up, the security for OF2, if you have all  these fixes applied and there are no implementation errors, then we can say that in terms of security  OF2 is quite good. We have formal proof in our model for this, but regarding privacy,  OF2 does not provide any privacy at all. Speaking about privacy, we mentioned earlier  already that there was a single sign-on system that tried to provide privacy, namely browser  ID, alias Mozilla persona. So as we already said before, this is a web-based single sign-on  system with design goals of having no central authority and provide better privacy. Spoiler  word, they failed at both. So how does browser ID work? So let's have a look at this on a  very high level first. So as Gito already said in browser ID, the mail provider is the  identity provider. So we have a user, alias, alias at mailprovider.com, and in the first  phase, when using browser ID, she does the following. She goes to her identity provider  and first creates a public-private key pair. And then she sends the public key in a document  with her own identity to the mail provider, and the mail provider then signs this document.  And this creates the so-called user certificate. And this certificate is then sent back to  alias. Now in the second phase, if Alice wants to actually log in at some website, and then  she does the following. She creates another document containing the identity of the website  where she wants to log in, say Wikipedia. And to do so, she signs the identity of Wikipedia  with her own private key. And this creates the so-called identity search. Now Alice sends  both documents to Wikipedia. And Wikipedia can then, of course, check these documents  because Wikipedia can check first, it can retrieve the public key of the mail provider, can check  the user certificate, and then also can check the identity assertion. And then Wikipedia  can consider Alice to be logged in. So this was the basic idea of browser ID, which is  quite nice and clean and simple. And then they started to implement this using just standard  browser features, including all the workarounds for the Internet Explorer and so on and so  on. And they ended up with a quite complicated system. So here we have on the left side an  Alice's browser to Windows, namely Wikipedia. And the lock-in dialogue, which is provided  by a central authority, which they tried to avoid, lock-in.persona.org. And inside both  of these windows, there are other iframes. And inside one of these iframes, there's another  iframe. And on the right, we have the servers, so the relying party, the identity provider,  and the central authority, lock-in.persona.org. And just to give you an idea how complex the  system ended up, they all talked to each other using HTTP requests, but also using post-messages  and also using XML HTTP requests. And as you can see, the system became quite complex.  To add even more complexity, they did the following. They thought, well, some users,  they are already using Gmail or Yahoo. So let's provide some nice interface for them.  They provided the so-called identity purchase, specifically for Gmail and Yahoo, which at  the time supported OpenID authentication only. And they created two new servers, the so-called  bridging servers, one for Gmail called Sideshow and the other one for Yahoo called BigTent.  Now the user authenticates to the bridging server using OpenID. And then the bridging  server has an interface to the standard browser ID interface. Yeah. So one problem was that  OpenID identities, they are not email addresses. So in OpenID, you add an attribute, which  is called the email attribute, and we are talking about this email attribute in a minute.  So let's have a look at how these identity bridges work. We are not going into all the  details of the browser ID or persona protocol, because this would be too complicated. But  the identity bridge is interesting and also important for some of the attacks that we  found. So in the identity bridge, the following happens. So here on the left, we have Alice's  browser. In the middle, we have Sideshow, so this identity bridge. And on the right side,  we have Gmail, which could also be Yahoo in this case. But yeah, let's say it's Gmail.  So first, the user says that she wants to log in at Sideshow. And then Sideshow sends  an OpenID request requesting the email attribute signed from Gmail. This request is then forwarded  to Gmail. And Gmail sees this request. The user logs in at Gmail for authentication.  And then Gmail creates this OpenID assertion, which contains the signed email address attribute  for Alice. And as you can see, this is all in the green box. So all properly signed and  nice. And now Alice's browser redirects this document to Sideshow. Now Sideshow doesn't  check the contents of this assertion for itself. Instead, it sends these things to Gmail. Gmail  checks everything that is signed. And tells Sideshow, yes, this document looks correct  to me. Everything that was signed was signed by me and was not tempered with. Then Sideshow  looks at the document and sees, ah, Alice wanted to log in. So this must be Alice. The  user must be Alice now. And provides a cookie because the user is now logged in as Alice.  So far, so simple. Now for some of the attacks that we found. First attack, identity forgery.  So here we have essentially the same that we saw before, the same setting. Except now  we don't have Alice's browser on the left. We have the attacker's browser on the left.  The attacker can go to Sideshow and say, I want to sign in. Now Sideshow sends this OpenID  request to the attacker. And the attacker can change this request. The attacker can just  remove the request for the email attribute from this request. Which is still a valid OpenID  request. Gmail sees this request. And now the attacker logs in. The attacker doesn't  have Alice's user data. So the attacker just logs in with his own credentials. And now  Gmail creates an OpenID assertion containing the signed attribute which was requested,  which was none. So essentially the document is empty. At least it is without any email  address. Now the attacker can simply add a new attribute to this document containing  an email address that he has chosen arbitrarily. This of course is not signed. Which is not  a problem because this document can be partly signed. And this document is forwarded to  Gmail. Gmail now analyzes this document and sees, well, there's a signed part in this  document. So I check this signed part. This signed part doesn't contain anything useful.  But it is correct. It's not the wrong signature. So it checks out. And it sends back to Sideshow.  I checked this document. Looks fine to me. Now Sideshow looks at the document. Sees that  there's an email attribute. Uses this email attribute. And the attacker is signed into  any Gmail account that he likes. With browser ID. Okay. So this is bad. As you can imagine.  And we told the Mozilla guys about this. And they were quite fast. So we were really surprised.  They were really quick. So I think it was in the middle of the night for most of them.  But they scrambled in the bug tracker. And they wrote some patches and so on and so on.  And I think it wasn't 24 hours later that it was all deployed and fixed. So this was  both quite good. But then we took another look at the system. And we found identity  forgery number two. Which is actually remarkably similar. It works as follows. So the attacker  sends the authentication request. You know this part. And Sideshow wants the signed email  attribute. And the attacker now doesn't change anything. The attacker just forwards this request  to Gmail. Gmail asks for the credentials. The attacker signs in. And sends back the  OpenID assertion containing the signed email address of the attacker. So no attack up to  this point. And now the attacker can do the following. The attacker adds another attribute.  And yeah, you can guess what happens. The document is forwarded to Gmail. Gmail checks  the signed part of the document, which is still fine. Sends back to Sideshow that everything  is fine with this document. And Sideshow selects the wrong email address. Yeah. And now the  attacker is signed into any user account. Again. Okay. So this was the second identity  forgery attack. We also found another attack, which is not very spectacular. And we also  looked. So this was all, of course, authentication. And we also took a look at privacy. So as  you remember, privacy says that in the words of Mozilla, the browser ID protocol never  leaks tracking information back to the identity provider. Except it does. So ideally, the  identity provider should be unable to tell where the user looks in. In fact, this is  broken. Because in the browser, the following happens. If malicious identity provider wants  to find out whether a user is locked in at some specific relying party or not, then the  malicious identity provider can just open an iframe containing the website of that relying  party he wants to probe. Now the following happens. The normal JavaScript of browser ID  runs in this relying party because it has browser ID support, obviously, and creates  an iframe. And inside this iframe, another iframe will be created. But this innermost  iframe will only be created if the user locked in at this RP before. Now, since the outermost  and the innermost iframe come from the same source and they can collaborate and communicate,  they can for example just send a post message, say, the user locked in at this relying party  before. So an identity provider can easily probe whether a user locked in at some relying  party or not. And this, unfortunately, cannot be fixed without a major redesign of browser  ID because they relied on all these iframes and so on. Yeah, so I think this can be considered  broken beyond repair. We also found some variants of these privacy attacks which rely on other  mechanisms but essentially, yeah, you get the idea, privacy and browser ID is broken.  So to sum up, browser ID, we found attacks but we also were able to fix them with respect  to security. And we also used our formal methods to prove the security of the fixed browser  ID system. But privacy is broken beyond repair.  Okay, this leads us to the question, can we build a single sign-on system that provides  security and privacy in the web? So we thought a lot about this question and then we used  our formal model to design such a single sign-on system and we could also then use the formal  model to prove that these properties are actually fulfilled. So the basic principle of this  system is called Espresso for secure privacy respecting single sign-on. It's the following.  We have the user with a browser. This user wants to log in at some relying party, for  example, at Wikipedia. So here we have the same idea as a browser ID to use the email  address and the email provider as the identity provider. So the user enters the email address  and then the relying party asks for some proof of this identity. So the user goes to her  email provider, which is her identity provider in this case, authenticates there and then  the identity provider creates a document that proves the Alice's identity and Alice then  forwards this document to the relying party and the relying party can check if everything  is all right and then consider the user to be logged in.  So let's have a closer look on how this system works. So here again we have Alice's browser,  the window of the relying party. Alice enters her email address. The email address is sent  to the relying party and now the relying party creates a document that contains the identity  of the relying party itself and this document is encrypted and we call this document then  the tag. So now the tag is sent along with the key that was used to encrypt this document.  So this is symmetric encryption with a fresh key, sends it to the browser and now in the  browser the express code opens a new window of the identity provider that is given by  the domain of the email address and sends the tag over to this window. This login dialog  prompts the user to authenticate so the user now enters her password and this is sent along  with the tag to the server and now the server creates this document I've just spoken of  in the last slide and this document we call it the user assertion. We send it back to  the window, the login dialog and now we have a problem. We could just send it over to the  Wikipedia window but I will show you in a minute why this is a bad idea. So instead  now we have a third party, the forwarder which serves just a single static JavaScript file  and this is loaded in an iframe and this login dialog and this iframe gets the user assertion  and it also gets the key and now it can decrypt the tag, look who is the intended receiver  and then it sends over the user assertion to the window of the relying party which forwards  it to the server of the relying party who can check if everything is all right and consider  the user to be logged in. So why do we need this forwarder? First it may look strange.  So let's look what happens if we just don't have this forwarder. So let's assume the user  wants to log in at some malicious relying party at attacker.com and there is an email  address but the attacker wants to impersonate the user. He wants to log in at some other  relying party, let's say to Wikipedia for example and the attacker goes to Wikipedia  and says hi, I'm Alice, I want to log in. Wikipedia creates a tag, does this send over  to the attacker who just relays it to the user. The protocol runs on, the user authenticates  to her identity provider and then we just send the tag over. The identity provider does  not know who the intended receiver is because we want to have this privacy feature. This  just went through and the attacker gets the user certificate and user assertion and forwards  it to Wikipedia and then the attacker is considered to be Alice and this is bad. So we need some  mechanism to prevent that the user assertion is forwarded to some random party but only  to the intended receiver. For this we have this forwarder. Now you can think this forwarder  may be also malicious but let's talk about this in a second. So let's just talk about  what the forwarder does. So the forwarder gets the user assertion and he gets the key  to decrypt the tag and now he can instruct the browser to send a post message but only  to a window of Wikipedia. So the browser checks if the receiver of a window of Wikipedia  or not and if it's not, it doesn't deliver this message. So this protects the user assertion  to be leaked and now you may think this forwarder may be malicious and deliver some other script  that does strange things like forwarding things to the attacker directly but we can enforce  that the correct script is running inside that iframe using separate source integrity  where you just tell the browser in this window only this code may run and in this case the  forwarder cannot just put some arbitrary or malicious code in this iframe and also there  is no information that leaks back from the browser to the forwarder. So to sum this up  as I've just presented Espresso, it features privacy and authentication. It's open and  decentralized so you don't need any specific central party. It's compliant to web standards  that's based on HTML5 and we have formal proofs that all these properties we've talked at  the beginning actually hold and you can find a demo and more information on Espresso.me.  Okay now to conclude the talk what is the take away? First of all we've talked I think  most of the time about OAuth 2.0 most of the results also translate to OpenID Connect.  We have formally proven the security of the protocol of OAuth and also OpenID Connect  which is a nice result of course if you are okay with having no privacy because OAuth  and OpenID Connect don't have any kind of privacy that we talked about. Regarding OAuth  1.0 and OpenID I think they can be considered deprecated and shouldn't be used. BrowseID  Mozilla persona was a nice experiment but is dead now and also has broken privacy. With  Espresso we have shown however that you can achieve privacy and web single sign-on using  standard HTML5 features and standard web features but of course for now it is a proof of concept  as you have seen we don't even have a nice logo yet. Yeah so and one target audience  are certainly developers, developers, developers. Use libraries wherever possible for example  PYOIDC is written even by members of the OAuth and OpenID Connect working groups so they  know what they do hopefully. Also regarding RSCs they are hard to read and information  is often spread across several documents. They are often not written clearly and they  are not always up to date but they are still an important reference and I think it's a  good advice to look at the RSCs from time to time even if they are hard to read. So  thank you very much for your attention. If you want to talk to us come to us at the  machine deck assembly in hall 3 or join us at the next Pylen Moor, Shameless Pluck here  in January 14 in Kielfeld or at the University of Stuttgart starting in January. Thank you  very much. Now we have 8 minutes for questions. What do we have from the internet? So we've  got two questions from the internet. Can you hear me? So at the diagram you showed one  of the first slides, why does the authentication follow authorization? Shouldn't it normally  be the other way around? Can you try to repeat the question? Yeah, sorry. At the diagram  you showed in one of the first slides, why does the authentication follow authorization?  Shouldn't it normally be the other way around? Okay, so these are two concepts that are kind  of orthogonal to each other. So you can either do authentication to ensure yourself of the  user's identity or you can act on the user's behalf at the identity provider like posting  on the user's Facebook timeline or doing different things there. But for authentication  you need to retrieve some unique user identifier and this basically makes use of this authorization  mechanism. So you get authorized to access this unique user identifier and you use this  then for authentication. Thank you. Questions from here? So for the special protocol, you  need the forwarding party to check whether the certificate was actually from Wikipedia  not from attacker.com. But could Nala's do this check herself? You mean that you present  the user something and the user accepts this or declines this in this sense? She has the  challenge that is signed by her email provider and she has the key that encrypted Wikipedia  identity. So she could use that to do encrypted and check if it's Wikipedia or attacker.com.  In principle, yes. So you mean the user could check? Yes. The user could of course check.  Ask the user did you really want to sign in at attacker.com or at Wikipedia.com. But of  course we all know that users are better at making decisions. So, yeah. Thank you. Questions  from here? Hi. Thanks for the informative talk. But I wanted to add a remark that's highly  unfair to call users stupid for falling victim to click checking and phishing because they  are working professionally on enabling click checking and phishing. And if you need a 4K  monitor just to see that there is some JavaScript data that like 1000 zero delimiters, it is  impossible to blame the user for being stupid for falling victim to click checking. So just  yes. That is correct. Also sometimes you just can't see it. So, yes. Thank you. Questions  from down there? Sorry. Questions? You talked about formal verification of both OAuth and  your protocol. I wanted to know what kind of program or whatever used like Proverif,  Tamarin, whatever. And also I think you just proved the, you just verified the subset of  OAuth. So let's start with the second question first. So for OAuth we really try to introduce  as many options as we could find in the standard, so to say. OAuth is a very like loose standard  so they give you a lot of options in many ways. We had to exclude some of them for practical  reasons when modeling the stuff. But we included almost all of the options that OAuth provides.  And we also have a detailed write up of what the options are and that we excluded and that  we included. And now for the first part of the question, our model currently is a manual  model. So what we do is pen and paper proofs. The reasoning behind this is that if you have  tools they are always in some sense limiting you. And when we started out with this work  there was, or there were two models essentially already existing web models, formal web models  so in the same area as we are. But they were both based on model checkers, so one on Proverif,  the other one on another model into...  Alloy. Alloy. And both were limited by the possibilities that you had in these model  checkers. So what we went the other way around, what we wanted to do is a manual model that  includes... that models the web really precisely and comprehensively. And then as a second  step what we are currently working on or discussing about is to transfer this into some kind of  tool.  Thank you.  Two more questions. Questions from the internet?  So I was wondering if you know about IndiAuth and RelmiAuth and what you think about the  question of using domain names versus email addresses as the user identifier.  Could you repeat that a bit louder please?  So if you have any comments about IndiAuth and RelmiAuth which uses the domain name as  identifier rather than an email address.  So we didn't look at these systems.  Okay. Yes, last question.  The question regarding the forewater and the privacy protection realized with the forewater.  As far as I understand the forewater is used in its own iframe to prevent the IDP from  taking control of the verification process knowing that who is the final system.  But what if the identity provider and the forewater collaborate then the privacy would  be broken?  Yes.  If we have these parties collaborating then of course they are broken.  So we haven't shown all the details of this system.  So this is really hard to prevent.  But in Espresso the relying party is allowed to choose which forewater has to be used.  So relying party should choose a forewater run by some trustworthy party.  So this is the counter measure to prevent collaboration.  But if these parties collaborate then you are screwed.  So we also, so I think it's also important to add, so the forewater is kind of a semi-trusted  party.  Because on the one hand we can enforce that it uses the correct code.  Of course the IDP then has to enforce this.  On the other hand you still have some side channels like for example timing.  So if you control the parties then you could check which IP addresses access for example  the forewater and the IDP at the same time and so on.  So there are some side channels though.  So the idea that we have to minimize this risk is to provide a set of trusted forewaters  that could be for example provided by some trusted parties like Mozilla or the EFF or  something.  So that you have set of forewaters to choose from and hopefully choose a trusted one.  Thank you.  You're welcome.  Girosh Mitz and Daniel Fett.  Thank you so much for the great talk.  Please give them another great round of applause.  Thank you.
33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_0_335.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_336_827.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_828_1007.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_1008_1523.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_1524_17111.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_17112_17423.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_17424_17543.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_17544_17639.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_17640_18215.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_18216_21011.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_21012_21191.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_21192_25223.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_25224_25295.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_25296_26135.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_26136_31151.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_31152_34175.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_34176_36959.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_36960_37079.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_37080_37211.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_37212_37619.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_37620_43751.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_43752_46607.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_46608_52943.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_52944_54623.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_54624_58019.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_58020_58115.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_58116_61571.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_61572_63659.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_63660_66695.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_66696_67499.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_67500_67679.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_67680_69839.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_69840_70751.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_70752_71363.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_71364_78551.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_78552_78635.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_78636_78743.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_78744_82067.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_82068_82283.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_82284_83255.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_83256_84527.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_84528_84611.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_84612_84659.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_84660_84731.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_84732_85643.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_85644_88463.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_88464_89375.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_89376_90803.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_90804_90863.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_90864_91007.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_91008_91127.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_91128_91847.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_91848_93647.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_93648_93839.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_93840_93947.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_93948_94607.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_94608_95795.png 33c3-7827-on_the_security_and_privacy_of_modern_single_sign-on_in_the_web_95796_96109.png