 So I think we're all set. Without further ado, I'd like to I'd like to introduce Gido 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 in the web So in this talk Daniel and me we are going to present not only Just a text on wealth and open ID 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 University of Stuttgart and Also, we happen to be the founders of the machine deck Hacker space in Trier and the Piantmoor 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 If you 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 the we have TripAdvisor as the so-called relying party and we have Facebook as their so-called identity provider and The basic principle on 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 It come out the relying party can also retrieve some unique user identifier and Then consider you to be locked 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 is the basic The basic principle why shouldn't we 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 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 It's terms and conditions then you perhaps can 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 this over the users 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 implement implementing and running the single sign on system So what are the single sign on systems now we now I will show you some prominent examples So there's 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 use uses it anymore except for Twitter. So Twitter uses a modified version of all of one Which more or less fixes all the known flaws But in general you can we can say don't use all of one There's also open ID, which is also quite old nine years. That's it's Yeah, 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 open ID run at Hock and it's Yeah, not that nice to develop open with something for open ID. So also for open ID. Don't use this And they are now modern single sign on systems for a scam example of two, which is also used in login with Facebook this is completely incompatible to all of one and All of two uses the so-called beer token approach that is they 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 and O of two is yeah 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 two and Authentication you After sometimes 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 And 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 all of two and there's also open ID connect open ID connect is quite new It's from it's yeah one and a half years old and it's an authentication layer on top of all off so The first definition or real definition on how you should use or off for authentication But it changes the standard also a bit so it can be seen as a protocol of it on its own But open ID connect although it despite the name. It's also completely incompatible to open ID 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 and sign on chart of confusion So we have all of one which is the marketing predecessor of all of two but completely incompatible to all of two and Of two serves as the Foundation for login with Facebook for authentication and also for open ID connect and the open ID connect There's open ID, which is the marketing predecessor of open ID connect, but all same here It's not compatible to each other And open ID connect is used for example by Google So these are the Most commonly used see a web single sign-on systems. There's also there are also some others for example Mozilla persona who of you have heard about Mozilla persona Okay around five percent more or less so it's 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 sent you emails with tokens you can click on to log in into your account or to To reset your password so your identity as 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 they 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 HTML 5 and They also built bridges to open ID and to off to Get some big identity providers in the system, but this 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 non-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 like the current state of the art Is that we have a lot of documents that define some locking mechanism for example, I go off 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 ish 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 a web in 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 fishing attacks or click-jacking attacks or just stupid users. Let's send that password to the attacker These are things that are out of the scope of the stuff that we are looking at you In the same manner compromise browsers or compromise compromise databases and so on so when we Have this model for web application One important questions 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 In the following of course, I'm not going to present all the formal stuff. This is boring Therefore, I'm I have a high level overview of what are 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 lock into my account at least Yeah, if they're not cursing the owner of the relying party or something And this is a obvious property there's a slightly less obvious property Which says that an attacker should not be able to authenticate an honest browser to relying party as the attacker So the attacker should be unable to force Alice's browser to be locked in under the attackers 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 this search engine and I'm locked in into the attackers 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 This is session integrity and a 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 Orth 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 That's okay. Good. Let's start with more closer look to Of when we I say of I always mean of to not the older of one So of to is mainly defined in RFC 6749 and also some other RFCs and some other documents of 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 cannot 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 year. 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 lying party. Then your browser gets redirected to Facebook Facebook prompts you for your authentication data or for some confirmation if you're already locked in at Facebook and Then Facebook issues a token that's called the access token and Facebook redirects your browser back to the lying 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 a retrieve this access token and now with this access token this is an access token is the same basically the same thing as in the In this first high-level overview when I just talked about tokens or 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 or act on the user's behalf at Facebook Or it can retrieve and user identifier and then consider this user to be locked in and issue for example some cookie So this is the implicit mode There's also the authorization code mode Their things start 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 locked in so Let's talk about Selected attacks on all First let's talk a bit about known attacks There are texts like the so-called cut and paste attacks where you Reuse some of these code tokens like access token or authorization code or there's also some other tokens Which I haven't talked about so I left out some details before This 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 the off 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 are all 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 the 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 Yeah 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 all flow and If we In this all flow if you have a closer look at what happens here in step two to four 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 all flow there So you just came from the relying party where you want to log in click on that button lock in the fit this IDP you get redirected and Then your browser contacts this identity provider here. I've been redirected to you In an all flow, please authenticate the user So this is the step to a Then your identity provider returns some Form where you have to enter your username and your 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's some implementation, which makes actually use of this Location redirect method Also, it's 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 all of working group didn't think about this so in their standard they write I use 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 of this attack so Here in this Attack we have to set I 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 Lot of web relying parties when you go to the website you go over HTTP and This 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 for a very first request goes often 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 relying party Log in with Facebook the attacker can easily change this and changes to Yeah, 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 things. Okay, that user wants to use the attacker identity provider It answers with a redirect to this to the attackers webpage But now the as the attacker still sits as man in the middle. He can just change it back to Facebook So the old dance continues as usual you go to Facebook Authenticate there you get redirected back with there's probably some access token and then fire 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 relying 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 off So this is not limited to Facebook But for break to break authentication at the relying party there are some other further steps needed but there's also there are also some other details that Have to be taken care of like client identifiers which are PC use relying parties is used to identify themselves to Identity providers the same for client credentials, which are optional by the way And an open ID connect the layer on top of all if this is used then you need to take care about some other stuff like the Switching off some signatures or exchanging some signatures And so on but it's still possible. So did we Successfully attack 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 the one problem is here in step three this access token is just some opaque string The relying party cannot see what 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's a mid mismatch bit in step five to the one in step 1a where the where the relying party received the message the attacker identity provider is to be used and in five It gets the message she has an access token and it's from Facebook So there's a mid mismatch and this whole flow can be aborted without the attack being successful so This is the mitigation We talked to the Wolf working group at the ITF. So they invited us to a kind of 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 a this triggered a know of security workshop, which took place in June new RFC with this with the mitigations is in preparation and also the working group is Showed her interest in the kind of formal analysis We do to this star we carry out for these kind of standards So to sum up the security for of two if you have all these Fixes applied and there are no implementation errors then we can say that terms of security Or else to is Quite good. We have formal proof in our model for this but regarding privacy Or else to 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 the design goals of having no central authority and Provide better privacy Spoiler they failed at both Um So so how does browser ID work? So let's have a look at this on a very high level first So as you already said in browser ID the male provider is the identity provider So we have a user Alice Alice at male provider 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 our own identity to the main provider and a main provider then signs this document and this creates the so-called user certificate and This certificate is then sent back to Alice Now in the second phase if Alice wants to actually log in at some website And then she does the following she Creates another another document containing the identity of the website where she wants to lock in say Wikipedia and To do so see 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 main provider can check the user certificate and then also can can check the identity assertion and Yeah, then Wikipedia can consider Alice to be locked 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 these 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 talk 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 Yeah interface for them They provided the so-called identity bridges 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 a 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 an 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 a 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 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 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 locked in as Alice So far simple Now for some of the attacks that we found First attack identity for three 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 locks in the attacker doesn't have Alice's user data. So she the attacker just locks 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. Yeah, 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 in into any Gmail account that he likes with browser that is used 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 And We found identity for tree number two, which is actually remarkably similar It works as follows So the attacker sends the authentication request, you know this part and Sideshow once the signed email attribute and the attacker now doesn't change anything the attacker just forwards this request to Gmail Gmail ask for the credentials the attacker signs in and Sends back the open ID 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 another email 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 user the attacker is signed into any user account again Okay So this was the second identity for tree 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 locks in in fact, this is broken Because in a 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 they come from the same source and of course they can collaborate and communicate They can for example just send a post message say I 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 Yeah, this 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 Rise privacy and browser ID is broken Okay, so to sum up Browser ID We found attacks, but we also were able to fix them in respect with respect to security and We also used our former 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 Their basic principle of the system it's called espresso for secure privacy respecting single sign-on is the following We have the user with her browser This user wants to log in at summary line party for example at Wikipedia so it Here we have the same idea same idea as in browser ID to use the email address and the email provider As the identity provider so the user enters her email address and Then the relying party asks for some proof of the of this identity so the user goes to your email provider, which is her identity provider in this case Authenticates there and then this I the identity provider creates 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 alright 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 Sensor to the browser and now in the browser The as pressure 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 log in dialogue 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 certificate. I didn't know a user user assertion Sorry user assertion. We send it back to the window the login dialogue and now we have a problem We could just send it over to the Wikipedia window But I will show you in the minute why this is a bad idea So instead now we have a third party the forwarder which Which serves just a single static JavaScript file and this is loaded in an iframe in this login dialogue and This iframe gets this 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 could then can check if everything is alright and consider the user to be locked in So why do we need this forward? So at first it may look strange So Let's look what happened 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's an email address, but the attacker Wants to impersonate the user. He wants to log in at some other relying party Let's say it to Wikipedia for example and the attacker goes to Wikipedia says hi. I'm Alice. I want to log in Wikipedia creates the tag does this send over to the attacker who just relays it to the user user The protocol runs on the user authenticates To her identity provider and then we just send the tag over as The identity provider does not know who is the really 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 and for this we have this forwarder now You can think this forwarder may be also malicious, but Let's talk about them about this in a second. So let's just talk about what the forwarder does so the forwarder gets this He gets the user assertion and He gets the key To decrypt the tech and now he can instruct the browser to send a post message But only to we give it to a window of Wikipedia. So the browser checks Is the receiver of Window of Wikipedia or not and if it's not it doesn't deliver this message. So this protects the 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 start 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's no information that leaks back from the browser to the forwarder So to sum this up as 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 HTML 5 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 dot me Okay now to conclude the talk. What is the takeaway? First of all We've talked I think most of the time about OAuth 2.0 most of the results also translate to open mighty connect We have formally proven the security of the protocol of OAuth and also open mighty connect Which is Which is a nice result of course if you are okay with having no privacy because OAuth and open mighty connect don't have any of Any any kind of privacy that we talked about Regarding OAuth 1.0 and open mighty. I think they can be considered deprecated and shouldn't be used Browser ID Mozilla persona was a nice experiment But is that now And also has broken privacy With Espresso we have shown however that you can achieve Privacy and web single sign-on using standard HTML 5 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 py OIDC is written even by members of the OAuth and open mighty connect working groups so they know what they do hopefully Also regarding our seas 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 RFCs 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 pie and more shameless plug here January 14 in Kirchfeld or At the University of Stuttgart start starting in January. Thank you very much Now we have eight minutes for questions What do we have from the Internet's? So we've got two questions from the internet 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 round? Barely, so can you try to repeat the question? Yeah, sorry At the diagram you showed in one of the first slides Why does the thought why does the authentication follow authorization? Shouldn't it normally be the other way round? Okay, so these are two concepts that are kind of orthogonal to each other So you can either do authentication to Be 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 you makes use of this authorization Mechanisms 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 said you need the forwarding party to check Whether the certificate was actually from Wikipedia not from attacker.com, but could now let's do this check herself You mean that you show present the user something and the user accepts this and or Declines this in this sense or Or She has the challenge that is signed by her email provider and she has the key that encrypted Wikipedia's identity So she could use that to do crept it and check if it's Wikipedia or attacker.com Yeah Yeah, I mean in principle. Yes. So you mean the user could check. Yes. Yes The user could of course check we could ask the user. Did you really want to sign it 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're working professionally on then on Enabling click checking and phishing and if you need a 4k monitor just to see that there's some JavaScript added that like Thousand zero Delimiters it is impossible to blame the user for being stupid. Yes for falling victim to click checking. So just yes Yes, that is correct. Um, it 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 Out and your protocol I Wanted to know what kind of I don't know program or whatever used like proverive tamarin whatever and also I think you just proved the You just verify the subset of wow So let's start with a second question first So for what we really tried to introduce as many options as we could find in the standard so to say What is the 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 or provides and we also have an 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 checker. So one on prove a reef the other one on another modeling to 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 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 indy off and realm II off and what you think about the question of Using domain names versus email addresses as the user identifier Yeah, could you repeat that a bit louder? so if you have any comments about indy off and realm II off which uses the Domain name as identifier rather than an email address So we didn't look at these systems 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 The final system yes, but what if the Identity provider and the forewater collaborate Then the privacy would be broken. Yes, if we if we have these parties Collaborating them, of course, they are broken So we I haven't 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 Forwarder has to be used so relying party should choose Forwarder run by some trustworthy party. So this is the counter measure to prevent Collaboration, but if these parties collaborate then you are screwed. Yes, so we also so I think it's also important to add So the forwarder is kind of a semi trusted party because on the one hand we can enforce that it's 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 forwarder and the IDP at the same time or 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 Forwarders that could be for example Provided by some trusted Parties like Mozilla or the EFF or something so that you have set of forwarders to choose from and hopefully choose trusted one. Thank you You're welcome. Kiroschmitz and Daniel Fett. Thank you so much for the great talk. Please give them another great round of applause