0 00:00:00,000 --> 00:00:30,000 This subtitle is not finished yet. If you are able to, please support us and watch the talk in amara for the last changes: https://c3subtitles.de/talk/695 Thanks! 1 00:00:04,870 --> 00:00:12,799 *33C3 preroll music* 2 00:00:12,799 --> 00:00:17,840 Presenter: So I think we're all set without further ado, I would like to I 3 00:00:17,840 --> 00:00:23,779 would like to introduce Guido Schmitz and Daniel Fett, who are going to be having 4 00:00:23,779 --> 00:00:29,980 this talk on a single-sign-on on the web. Give them a big round of applause. And I 5 00:00:29,980 --> 00:00:37,360 hope you're looking forward to the talk 6 00:00:37,360 --> 00:00:46,270 Guido: OK, hello, everybody, welcome to our talk on the security and privacy of 7 00:00:46,270 --> 00:00:53,340 modern single-sign-on the web. So in this talk, Daniel and me, we are going to 8 00:00:53,340 --> 00:01:01,500 pretend not only just a OAuth and OpenID Connect, but also some thoughts about 9 00:01:01,500 --> 00:01:10,310 analysis of all these standards. So first, a brief introduction who are. We are 10 00:01:10,310 --> 00:01:18,210 researchers from the University of Trier, but soon of University of Stuttgart. And 11 00:01:18,210 --> 00:01:24,369 also we happen to be the founders of the Maschinendeck, the hackerspace in Trier 12 00:01:24,369 --> 00:01:31,950 and the Pi and More raspberry jam. If you're interested in anything else, what 13 00:01:31,950 --> 00:01:38,799 we are doing, you can just follow us on Twitter. So what is the single-sign-on 14 00:01:38,799 --> 00:01:45,320 about? What are we talking about? So probably all of you have seen websites 15 00:01:45,320 --> 00:01:52,020 like this, like TripAdvisor, that you can use a lot of different methods to sign and 16 00:01:52,020 --> 00:01:55,930 you can sign in with your Facebook account, with your Google account, you can 17 00:01:55,930 --> 00:02:00,640 register account at their page with the email address and password, or you can use 18 00:02:00,640 --> 00:02:09,030 your Samsung account or probably now even more different systems. And if you click, 19 00:02:09,030 --> 00:02:13,020 for example, on this login with Facebook button and new window pops up, prompting 20 00:02:13,020 --> 00:02:18,470 for your Facebook credentials, or if you already signed into Facebook, just asks 21 00:02:18,470 --> 00:02:25,700 for confirmation. So this is a setting we are looking at and we have two parties 22 00:02:25,700 --> 00:02:31,410 here. We have the we have TripAdvisor as the so-called relying party and we have 23 00:02:31,410 --> 00:02:39,250 Facebook as the so-called identity provider. And the basic principle of how 24 00:02:39,250 --> 00:02:44,630 this works is the following. So first you go with your browser to the relying party. 25 00:02:44,630 --> 00:02:52,530 You say, I want to log in that RP, then you contact your identity provider, 26 00:02:52,530 --> 00:02:58,120 authenticate there. And this identity provider then issues some kind of token 27 00:02:58,120 --> 00:03:03,750 and this token you give to the relying party. And the ruling party can now use 28 00:03:03,750 --> 00:03:11,560 this token to access some parts of your account at the identity provider. And this 29 00:03:11,560 --> 00:03:15,910 is called authorization, for example, the ruling party can use this token now to 30 00:03:15,910 --> 00:03:24,150 post on your Facebook timeline or reach out your friends list from Facebook. And 31 00:03:24,150 --> 00:03:31,210 it the ruling party can also retrieve some unique user identifier and then consider 32 00:03:31,210 --> 00:03:35,500 you to be locked in with that user identifier. And then this is 33 00:03:35,500 --> 00:03:42,970 authentication. And then RP can set, for example, sensation Cookie and Mark. This 34 00:03:42,970 --> 00:03:49,310 session belongs. Remember that this session belongs to this user. So this is 35 00:03:49,310 --> 00:03:55,439 the basic the basic principle. Why should we use single-sign-on or why we shouldn't 36 00:03:55,439 --> 00:04:01,980 use single-sign-on? So for users, it's very convenient. You don't have to 37 00:04:01,980 --> 00:04:07,340 remember which account you used where, which password and so on. You just click 38 00:04:07,340 --> 00:04:10,700 and login with Facebook and you're all done. Of course, this comes with lack of 39 00:04:10,700 --> 00:04:18,140 privacy because Facebook then always knows where you log in. And also the identity 40 00:04:18,140 --> 00:04:22,360 provider you choose is also the single point of failure. If that one closes down 41 00:04:22,360 --> 00:04:28,669 or changes its terms and conditions, then you perhaps cannot log into your accounts 42 00:04:28,669 --> 00:04:36,560 anymore at some third party web pages. So relying parties, they need to store less 43 00:04:36,560 --> 00:04:41,400 data. They don't have to care about password databases that can leak. They 44 00:04:41,400 --> 00:04:44,419 don't have to care about user registration, password recovery on all the 45 00:04:44,419 --> 00:04:49,930 hassle that comes with user accounts. But they also have less control over this, 46 00:04:49,930 --> 00:04:54,949 over the users accounts because they outsource the authentication to this 47 00:04:54,949 --> 00:04:59,450 identity provider and also hear the identity provider as a single point of 48 00:04:59,450 --> 00:05:05,139 failure. Far identity providers, the advantage is clear. They get more user 49 00:05:05,139 --> 00:05:12,120 data and they can provide some service for their users, which makes, perhaps it makes 50 00:05:12,120 --> 00:05:19,160 it more attractive for users to use that identity provider. On the downside, they 51 00:05:19,160 --> 00:05:23,340 also have to take care about more user data. They have to store and protect it, 52 00:05:23,340 --> 00:05:27,130 and they have to have the overhead of implement, implementing and running the 53 00:05:27,130 --> 00:05:36,560 single-sign-on system. So what are these single-sign-on systems now? Now I will 54 00:05:36,560 --> 00:05:43,430 show you some prominent examples, so there is OAuth 1.0. So this is a not so modern 55 00:05:43,430 --> 00:05:50,870 single-sign-on system, it's now 10 years old. Many flaws are known for this system 56 00:05:50,870 --> 00:05:56,070 and basically nobody uses it anymore except for Twitter. So Twitter uses a 57 00:05:56,070 --> 00:06:04,669 modified version of OAuth 1, which more or less fixes all the known flaws. But in 58 00:06:04,669 --> 00:06:11,880 general, we can say don't use OAuth 1. There is also OpenID, which is also quite 59 00:06:11,880 --> 00:06:18,919 old, nine years. It's not that user friendly. It's a standard that's meant to 60 00:06:18,919 --> 00:06:25,120 be super flexible for every corner use case that they developers at that time 61 00:06:25,120 --> 00:06:31,260 thought of. And this makes it also extremely hard to use correctly because 62 00:06:31,260 --> 00:06:39,130 you have a lot of things going on. Things change during an OpenID running, and it's 63 00:06:39,130 --> 00:06:46,750 not that nice to develop something for OpenID. So also, OpenID, don't use this. 64 00:06:46,750 --> 00:06:52,790 And now modern single-sign-on systems, for example, OAuth 2, which is also used in 65 00:06:52,790 --> 00:07:02,480 login with Facebook. This is completely incompatible to OAuth 1 and OAuth 2 uses 66 00:07:02,480 --> 00:07:12,539 the so-called Bearer token approach. The old protocol is based on some random 67 00:07:12,539 --> 00:07:18,580 values that are passed around. But there's no crypto involved except for the 68 00:07:18,580 --> 00:07:27,139 transport layer for HTTPS, for example, and OAuth2 is used everywhere, almost. So 69 00:07:27,139 --> 00:07:31,699 it's the most popular of these systems, but it has never been developed for 70 00:07:31,699 --> 00:07:38,240 authentication and really, it's not meant for authentication. And if you google for 71 00:07:38,240 --> 00:07:45,360 OAuth 2 and authentication, you have to sometimes stumble upon the following 72 00:07:45,360 --> 00:07:50,580 picture. So these two guys are members of the OAuth working group and they are 73 00:07:50,580 --> 00:07:54,909 really insist it's not meant for authentication at all. It's just for 74 00:07:54,909 --> 00:08:03,310 authorization. OK. Nonetheless, it is used in practice also for authentication. 75 00:08:03,310 --> 00:08:10,539 Facebook, for example, uses it for authentication. And so the protocol is now 76 00:08:10,539 --> 00:08:15,139 five years old. Many flaws have been discovered. Most of them have been fixed. 77 00:08:15,139 --> 00:08:22,340 I will talk about some of these flaws later in the talk. So this is OAuth 2 and 78 00:08:22,340 --> 00:08:27,629 there's also OpenID Connect. OpenID Connect is quite new. It's from one and a 79 00:08:27,629 --> 00:08:34,840 half years old and it's an authentication layer on top of OAuth. So the first 80 00:08:34,840 --> 00:08:39,330 definition or real definition on how you should use of for authentication, but it 81 00:08:39,330 --> 00:08:45,350 changes the standard also so it can be seen as the protocol on its own, but 82 00:08:45,350 --> 00:08:49,830 OpenID Connect, although despite the name, it's also completely incompatible to 83 00:08:49,830 --> 00:08:57,220 OpenID. And it has also some dynamic features like IdP, Discovery and identity 84 00:08:57,220 --> 00:09:03,010 provider Discovery and stuff like that. So this leads us to the Web, single-sign-on 85 00:09:03,010 --> 00:09:09,529 chart of confusion. So we have OAuth 1 which is the marketing predecessor off of 86 00:09:09,529 --> 00:09:16,580 2, but completely incompatible to OAuth 2 and OAuth 2 serves as the foundation for 87 00:09:16,580 --> 00:09:21,470 login with Facebook, for authentication and also for OpenID Connect and OpenID 88 00:09:21,470 --> 00:09:26,420 Connect, there is OpenID, which is the marketing predecessor of OpenID Connect, 89 00:09:26,420 --> 00:09:33,180 but also same here, it's not compatible to each other. And OpenID Connect is used, 90 00:09:33,180 --> 00:09:43,269 for example, by Google. So these are the most commonly used single-sign-on systems. 91 00:09:43,269 --> 00:09:49,250 There's also some others, for example, Mozilla Persona. Who of you have heard 92 00:09:49,250 --> 00:09:59,090 about Mozilla persona.? Oh, OK. Around five percent, more or less. So, the 93 00:09:59,090 --> 00:10:06,340 original name is BrowserID and there the idea was that the email providers become 94 00:10:06,340 --> 00:10:12,320 the identity providers. So this comes from the thought that for classical website 95 00:10:12,320 --> 00:10:17,089 where you have to register, they send you emails with tokens you can click on to log 96 00:10:17,089 --> 00:10:23,970 into your account and to reset your password. So your identity, your e-mail 97 00:10:23,970 --> 00:10:28,810 provider already is the kind of identity provider. So why don't we just use it 98 00:10:28,810 --> 00:10:35,040 directly in the Web? And Mozilla Persona is the first single-sign-on system with 99 00:10:35,040 --> 00:10:40,899 the goal that we have some kind of privacy in the sense that the identity provider 100 00:10:40,899 --> 00:10:45,870 does not learn where you use your accounts. So we will talk about this also 101 00:10:45,870 --> 00:10:51,149 later in this talk. So it was developed by Mozilla and the first idea was to 102 00:10:51,149 --> 00:10:58,959 integrate this protocol in the browsers, which never happened. So they went from 103 00:10:58,959 --> 00:11:05,250 the target to have a pure Web implementation using just HTML5. And they 104 00:11:05,250 --> 00:11:13,870 also built bridges to OpenID and OAuth 2 to get some big identity providers in the 105 00:11:13,870 --> 00:11:19,450 system. But this this whole approach failed. But it's still interesting if you 106 00:11:19,450 --> 00:11:27,780 want to look for privacy. OK, there are also some other protocols I haven't talked 107 00:11:27,780 --> 00:11:32,820 about, and now I will hand over to Daniel. 108 00:11:32,820 --> 00:11:36,079 Daniel Fett: So what is this talk all about? 109 00:11:36,079 --> 00:11:40,399 *applause* 110 00:11:40,399 --> 00:11:45,540 Daniel: So what is all talk all about? So what we want to do is we want to analyze 111 00:11:45,540 --> 00:11:50,750 where the web mechanisms in this case websites and protocols are secure when 112 00:11:50,750 --> 00:11:55,880 they are implemented correctly. So this means if we follow all the standards and 113 00:11:55,880 --> 00:12:01,010 all the best practices, on other words: Are the standards and protocols that 114 00:12:01,010 --> 00:12:11,400 define the web secure? The current state of the art is that we have a lot of 115 00:12:11,400 --> 00:12:17,690 documents that define some locking mechanism, for example, like OAuth, and we 116 00:12:17,690 --> 00:12:22,970 have an expert or group of experts and they look at this and after a while they 117 00:12:22,970 --> 00:12:29,970 say, well, this seems kind of OK to me. So they say it's secure. So this is the 118 00:12:29,970 --> 00:12:35,190 current state of the art. And what we want to do also is part of our research is to 119 00:12:35,190 --> 00:12:41,780 change this. In a way that has been already successful for other things in 120 00:12:41,780 --> 00:12:48,430 Internet, for example, for TLS. We want to create a model of the Web infrastructure 121 00:12:48,430 --> 00:12:53,470 and of Web applications, the former model. And these models, of course, they are also 122 00:12:53,470 --> 00:13:02,360 always incomplete, but nonetheless useful, as has been shown with TLS 1.3. So we 123 00:13:02,360 --> 00:13:08,279 create this model and then we put a lot of work into this. And finally, hopefully we 124 00:13:08,279 --> 00:13:17,680 can create proofs of security for mechanisms of our standards. So of course 125 00:13:17,680 --> 00:13:27,079 the hard part is number 2 here, as always. Some things our model cannot capture and 126 00:13:27,079 --> 00:13:32,449 we don't want to capture this. So, for example, phishing attacks or clickjacking 127 00:13:32,449 --> 00:13:37,209 attacks or just stupid users. Let's send that password to the attacker. These are 128 00:13:37,209 --> 00:13:42,750 things that are out of the scope of the stuff that we are looking at. In the same 129 00:13:42,750 --> 00:13:53,220 manner, compromised browsers or compromised databases and so on. When we 130 00:13:53,220 --> 00:13:59,540 have this model for a Web application, one important question and maybe the most 131 00:13:59,540 --> 00:14:04,769 important question is what is security and what is privacy if you want to look at 132 00:14:04,769 --> 00:14:10,631 privacy as well? So we have to define this and luckily we can define this if we have 133 00:14:10,631 --> 00:14:15,500 a formal model like we have and a following, of course, I'm not going to 134 00:14:15,500 --> 00:14:20,779 present all the formal stuff, this is boring. Therefore, I have a high level 135 00:14:20,779 --> 00:14:25,089 overview of what authentication properties, for example, look like. 136 00:14:25,089 --> 00:14:30,889 Authentication in the Web single-sign-on system means that an attacker that even 137 00:14:30,889 --> 00:14:36,250 has full control over the network say NSA should not be able to use a service of a 138 00:14:36,250 --> 00:14:41,370 relying party as an honest user. So the NSA should be unable to log into my 139 00:14:41,370 --> 00:14:48,170 account at least. Yeah, if they're not forcing the owner of relying party or 140 00:14:48,170 --> 00:14:57,399 something. And this is an obvious property there's a slightly less obvious property, 141 00:14:57,399 --> 00:15:01,871 which says that an attacker should not be able to authenticate an honest browser to 142 00:15:01,871 --> 00:15:09,649 relying party as the attacker. So the attacker should be unable to force Alice's 143 00:15:09,649 --> 00:15:14,100 browser to be locked in under the attackers identity. This is a property 144 00:15:14,100 --> 00:15:18,790 that is often also called session fixation or session swapping, because if the 145 00:15:18,790 --> 00:15:22,759 attacker would be able to do this, he could, for example, force me to be locked 146 00:15:22,759 --> 00:15:28,139 in at some search engine. And if I then search something with a search engine and 147 00:15:28,139 --> 00:15:32,589 I'm locked into the attackers account, then the attacker could be able to read 148 00:15:32,589 --> 00:15:37,149 what I'm searching for in this search engine. OK, so these are the 149 00:15:37,149 --> 00:15:42,420 authentication properties. Then we also have another property that is important, 150 00:15:42,420 --> 00:15:49,970 namely session integrity . Session integrity means that if the relying party 151 00:15:49,970 --> 00:15:54,621 acts on Alice's behalf at the identity provider or retrieves Alice's data at the 152 00:15:54,621 --> 00:16:02,940 identity provider then Alice explicitly expresses her consent to log in at this 153 00:16:02,940 --> 00:16:12,019 ruling party. So. There's a session integrity and a third property that we 154 00:16:12,019 --> 00:16:19,000 have, is privacy and privacy in this case means that a malicious identity provider 155 00:16:19,000 --> 00:16:25,980 should not be able to tell whether the user logs in at the wrong party A or party 156 00:16:25,980 --> 00:16:33,899 B. So, for example, if OAuth would have privacy, which it doesn't, then Facebook 157 00:16:33,899 --> 00:16:36,670 would be unable to tell whether I log in at, say, Wikipedia or myfavoritebeer.com. 158 00:16:36,670 --> 00:16:46,000 There are also other notions of privacy, which we, however, will not look at in 159 00:16:46,000 --> 00:16:59,270 this talk. 160 00:16:59,270 --> 00:17:10,179 Guido: OK. Let's start with a closer look to OAuth when I say OAuth, I always mean 161 00:17:10,179 --> 00:17:21,839 OAuth 2 not the older OAuth 1. So OAuth 2 is mainly defined in RFC6749 and also some 162 00:17:21,839 --> 00:17:30,650 other RFC's and some other documents. OAuth itself has four different modes it 163 00:17:30,650 --> 00:17:35,360 can run. And so there is the Implicit Mode, the Authorization Code Mode, the 164 00:17:35,360 --> 00:17:41,870 Resource Owner Password Credentials mode, the Client Credentials mode and all these 165 00:17:41,870 --> 00:17:50,900 modes can have so options, which I won't list here. And out of these four modes, 166 00:17:50,900 --> 00:17:55,820 the first two Implicit Mode and the Authorization Code Mode are the most 167 00:17:55,820 --> 00:18:02,880 common ones. So let's have a closer look at these modes. So the Implicit Mode works 168 00:18:02,880 --> 00:18:08,799 like this. Here we have an example with some random relying party and Facebook as 169 00:18:08,799 --> 00:18:13,610 the identity provider. So first you say I want to login with Facebook at your 170 00:18:13,610 --> 00:18:20,669 relying party, then your browser gets redirected to Facebook. Facebook prompts 171 00:18:20,669 --> 00:18:25,429 you for your authentication data or for some confirmation if you're already logged 172 00:18:25,429 --> 00:18:36,880 in at Facebook. And then Facebook issues a token that's called the access token. And 173 00:18:36,880 --> 00:18:41,210 Facebook redirects your browser back to the relying party and puts the access 174 00:18:41,210 --> 00:18:49,530 token in the URI. And then for some technical reasons, we need some additional 175 00:18:49,530 --> 00:19:00,179 steps to retrieve the access token from the URI because it's in the fragment part. 176 00:19:00,179 --> 00:19:05,400 And then finally, the relying party gets to retrieve this access token. And now 177 00:19:05,400 --> 00:19:13,290 with this access token, an access token is the same basically the same thing as in 178 00:19:13,290 --> 00:19:19,090 the in this first high level overview when I just talked about tokens an access token 179 00:19:19,090 --> 00:19:25,090 is such a token, which gives the relying party access to the user's account at 180 00:19:25,090 --> 00:19:31,909 Facebook. And now the relying party can retrieve data on the user's behalf at 181 00:19:31,909 --> 00:19:37,809 Facebook or it can retrieve and user identifier and then consider this user to 182 00:19:37,809 --> 00:19:44,870 be logged in and issue, for example, some cookie. So this is the Implicit Mode. 183 00:19:44,870 --> 00:19:52,880 There is also the Authorization Code Mode there. Things start similar. The user says 184 00:19:52,880 --> 00:19:58,010 I want to login with Facebook, gets redirected to Facebook, authenticates at 185 00:19:58,010 --> 00:20:02,680 Facebook and then Facebook, instead of issuing an access token, it issues the so- 186 00:20:02,680 --> 00:20:09,299 called authorization code and the relying party then takes the authorization code 187 00:20:09,299 --> 00:20:14,820 and redeems it for an access token directly at Facebook. So we have here some 188 00:20:14,820 --> 00:20:21,830 one intermediate step for this authorization code and then the access 189 00:20:21,830 --> 00:20:29,390 token, the relying party retrieved, it can then use to act on the user's behalf at 190 00:20:29,390 --> 00:20:37,710 Facebook or consider the user to be logged in. So let's talk about selected attacks 191 00:20:37,710 --> 00:20:50,920 on OAuth. First, let's talk a bit about known attacks, there are attacks like the 192 00:20:50,920 --> 00:20:57,800 so-called cut and paste attacks where you reuse some of these tokens like access 193 00:20:57,800 --> 00:21:02,809 token, authorization code, or there are also some other tokens, which I haven't 194 00:21:02,809 --> 00:21:10,390 talked about. So I left out some details before. It's about reusing these tokens 195 00:21:10,390 --> 00:21:18,380 from different flows, mixing them into a new flow and then break the system. So 196 00:21:18,380 --> 00:21:26,000 there are a lot of cut and paste attacks known. And there OAuth working group is 197 00:21:26,000 --> 00:21:33,830 continuously giving tries on how to prevent these cut-and-paste attacks. 198 00:21:33,830 --> 00:21:39,480 Another problem is if you don't use HTTPS, then you are screwed because a man in the 199 00:21:39,480 --> 00:21:45,510 middle can easily read everything out, all the tokens that are exchanged. So if you 200 00:21:45,510 --> 00:21:51,490 are in some Wi-Fi and the guy next to you is sniffing on the Wi-Fi, you log in and 201 00:21:51,490 --> 00:21:59,059 don't use HTTPS because some developers forgot that there is the something called 202 00:21:59,059 --> 00:22:08,150 HTTPS, then basically the whole thing is screwed. And also, if you just rely on 203 00:22:08,150 --> 00:22:15,210 cookies, then you're also screwed because cookies lack integrity. It's very easy to 204 00:22:15,210 --> 00:22:22,460 just inject cookies into your browser over HTTP, and then these cookies will later 205 00:22:22,460 --> 00:22:33,640 also be used over HTTPS. So the cookies are also not a good thing to rely on. So 206 00:22:33,640 --> 00:22:40,440 let's talk about some attacks we have found in our research. There is the 307 207 00:22:40,440 --> 00:22:54,520 redirect attack and it works like this. First, we have some regular OAuth flow. In 208 00:22:54,520 --> 00:22:59,730 this OAuth flow, if you have a closer look at what happens here and step two to four, 209 00:22:59,730 --> 00:23:05,049 we have the user authentication. And after this authentication, the user gets 210 00:23:05,049 --> 00:23:11,840 redirected back to relying party. If you look more into the details of these 211 00:23:11,840 --> 00:23:20,669 requests, so first you have this request where you go to your identity provider and 212 00:23:20,669 --> 00:23:26,799 ask, I have started OAuth flow there. So you just came from the relying party where 213 00:23:26,799 --> 00:23:32,140 you want to log in and click on that button, log in with this IP, you get 214 00:23:32,140 --> 00:23:38,100 redirected and then your browser contacts this identity provider here I have been 215 00:23:38,100 --> 00:23:47,390 redirected to you in OAuth flow. Please authenticate the user. So this is a step 216 00:23:47,390 --> 00:23:53,520 2.a then your identity provider returns some form where you have to enter your 217 00:23:53,520 --> 00:23:58,350 username and password usually, and then you enter username and password and these 218 00:23:58,350 --> 00:24:03,690 are sent over to the identity provider. And now if this identity provider 219 00:24:03,690 --> 00:24:10,779 redirects you back to the relying party and uses the wrong HTTP location redirect 220 00:24:10,779 --> 00:24:18,630 method for this, namely the 307 method, then the following happens. The browsers 221 00:24:18,630 --> 00:24:23,900 instructed to just repost all of your credentials. So if you're logging in that 222 00:24:23,900 --> 00:24:31,059 some malicious relying party, that relying party gets your username and password. So 223 00:24:31,059 --> 00:24:36,880 this happens if you use 307, redirect. Fortunately, we didn't find any identity 224 00:24:36,880 --> 00:24:43,000 provider in the wild to actually use 307. But you can never exclude that there is 225 00:24:43,000 --> 00:24:49,730 some implementation which makes actually use of this location redirect method. 226 00:24:49,730 --> 00:24:54,970 Also, if you look at the standard, how these are defined, it's not always clear 227 00:24:54,970 --> 00:25:02,409 which redirects method has which details and behavior. And also the OAuth working 228 00:25:02,409 --> 00:25:07,460 group didn't think about this. So in their standard, their write, you just use any 229 00:25:07,460 --> 00:25:16,350 method. And surely the mitigation here is don't use 307, for example, use 303 230 00:25:16,350 --> 00:25:22,190 instead. So the next attack is the identity provider mix-up attack. I will 231 00:25:22,190 --> 00:25:30,770 present this in Implicit Mode and only one variant of this attack. So here in this 232 00:25:30,770 --> 00:25:38,690 attack, we have to have the following setting. From step two on all these 233 00:25:38,690 --> 00:25:44,289 requests are usually encrypted. But the very, very first request there, we cannot 234 00:25:44,289 --> 00:25:50,399 be sure it is encrypted because a lot of relying parties when you go to the 235 00:25:50,399 --> 00:25:57,250 website, you go over HTTP. And this the very first information we just click I 236 00:25:57,250 --> 00:26:02,720 want to use Facebook to log in there. You could easily assume this is not a 237 00:26:02,720 --> 00:26:10,480 sensitive information. So this a very first request goes off an unencrypted or 238 00:26:10,480 --> 00:26:16,049 if you, for example, consider other attacks like TLS stripping, then you also 239 00:26:16,049 --> 00:26:25,460 cannot guarantee that this request is encrypted. So now for an attacker who, for 240 00:26:25,460 --> 00:26:31,760 example, sits in a same Wi-Fi network as you, so probably the guy next to you could 241 00:26:31,760 --> 00:26:37,360 easily mount the attack as follows. So when your browser sends this request to 242 00:26:37,360 --> 00:26:44,370 relying party, login with Facebook, the attacker can easily change this and change 243 00:26:44,370 --> 00:26:51,370 its to just use the identity provider that is run by the attacker. Remember, you can 244 00:26:51,370 --> 00:26:56,030 have a lot of different options of identity providers and with some 245 00:26:56,030 --> 00:27:04,529 extension, this can also be extended dynamically just by entering some domains. 246 00:27:04,529 --> 00:27:09,179 And then the relying party thinks, OK, that user wants to use the attacker 247 00:27:09,179 --> 00:27:17,919 identity provider. It answers with the redirect to the attackers web page. But 248 00:27:17,919 --> 00:27:21,530 now the as the attacker attackers still sits in the middle, he can just change it 249 00:27:21,530 --> 00:27:28,990 back to Facebook. So the old dance continues as usual. You go to Facebook, 250 00:27:28,990 --> 00:27:33,710 authenticate there, you get redirected back. There's probably some access token 251 00:27:33,710 --> 00:27:40,840 and then eventually the relying party retrieve this access token and wants to 252 00:27:40,840 --> 00:27:47,019 use this access token. So what happens? It won't use this access token at Facebook, 253 00:27:47,019 --> 00:27:51,880 but at the relying at the attacker instead, because it still thinks that the 254 00:27:51,880 --> 00:27:57,549 attacker is for the identity provider that is used here. So in practice, if you want 255 00:27:57,549 --> 00:28:03,321 to mount this attack, then you have to take care of more details, like when you 256 00:28:03,321 --> 00:28:08,299 want to break authentication instead of authorization. So in the version I just 257 00:28:08,299 --> 00:28:13,779 presented, the attacker gets the token can act on the user's behalf at Facebook or at 258 00:28:13,779 --> 00:28:20,470 some other identity provider that he was off. So this is not limited for Facebook, 259 00:28:20,470 --> 00:28:26,510 but for authentication of the relying party. There are some other further steps 260 00:28:26,510 --> 00:28:31,760 needed. But there's also there are also some other details that have to be taken 261 00:28:31,760 --> 00:28:37,961 care of, like client identifiers, which are used by relying parties to identify 262 00:28:37,961 --> 00:28:44,159 themselves to identity providers, the same for client credentials, which are 263 00:28:44,159 --> 00:28:50,990 optional, by the way, and an OpenID Connect the layer on top of OAuth. If this 264 00:28:50,990 --> 00:28:56,710 is used, then you need to take care about some other stuff, like the switching of 265 00:28:56,710 --> 00:29:02,990 some signatures or exchanging some signatures and so on. But it's still 266 00:29:02,990 --> 00:29:08,470 possible so that we successfully attacked real world applications. And this 267 00:29:08,470 --> 00:29:12,390 definitely works. And there are also some variants that do not rely on that first 268 00:29:12,390 --> 00:29:19,730 request going over HTTPS. But explaining all the variance would take a whole talk 269 00:29:19,730 --> 00:29:28,260 on its own, so we now skip this and talk about mitigation. So the mitigation we 270 00:29:28,260 --> 00:29:35,230 propose is quite simple. So the the one problem is you're in step three. This 271 00:29:35,230 --> 00:29:41,750 access token is just some opaque string. Relying party cannot see who issued that 272 00:29:41,750 --> 00:29:46,580 access token. So it needs some further information carried along with this 273 00:29:46,580 --> 00:29:51,909 system. And that is who is the identity provider, which issued this access token. 274 00:29:51,909 --> 00:29:58,909 And if you have this information carried along and then the relying party can 275 00:29:58,909 --> 00:30:05,390 easily detect this attack and see that there is a mismatch between step five to 276 00:30:05,390 --> 00:30:11,661 the one in step 1.a, where relying line party received the message the attacker's 277 00:30:11,661 --> 00:30:15,970 identity provider is to be used and in five it gets the message she has access 278 00:30:15,970 --> 00:30:20,830 token and it's from Facebook. So there's a mismatch and this whole flow can be 279 00:30:20,830 --> 00:30:31,140 aborted without the attack being successful. So this is the mitigation we 280 00:30:31,140 --> 00:30:36,250 talk to the OAuth working group at the IETF, so they invited us to a kind of 281 00:30:36,250 --> 00:30:43,429 emergency meeting to discuss this attack and we scheduled public disclosure of 282 00:30:43,429 --> 00:30:50,429 these attacks. So at the beginning of this year, in June, we had a district at 283 00:30:50,429 --> 00:30:55,240 security workshop which took place in June. New RFC, with this service the 284 00:30:55,240 --> 00:31:02,559 mitigations is in preparation. And also the working group is interested in the 285 00:31:02,559 --> 00:31:10,929 kind of formal analysis we do to this, we carry out for these kind of standards. So 286 00:31:10,929 --> 00:31:19,240 to sum up, the security for OAuth 2 these fixes applied and there are no 287 00:31:19,240 --> 00:31:27,460 implementation errors, then we can say that in terms of security OAuth 2 is quite 288 00:31:27,460 --> 00:31:36,559 good. We have formal proof in our model for this, but regarding privacy OAuth 2 289 00:31:36,559 --> 00:31:41,799 does not provide any privacy at all. 290 00:31:41,799 --> 00:31:48,470 David: Speaking about privacy, we mentioned earlier already that there was a 291 00:31:48,470 --> 00:31:54,419 single-sign-on system that tried to provide privacy, namely BrowserID alias 292 00:31:54,419 --> 00:31:59,750 Mozilla Persona. So as we already said before, this is a Web based single-sign-on 293 00:31:59,750 --> 00:32:04,889 system with design goals of having no central authority and provide better 294 00:32:04,889 --> 00:32:14,210 privacy. Spoiler alert: they failed at both. So how does BrowserID work? So let's 295 00:32:14,210 --> 00:32:19,870 have a look at this on a very high level first. So like Guido already said in 296 00:32:19,870 --> 00:32:25,440 browser I.D., the mail provider is the identity provider. So we have a user, 297 00:32:25,440 --> 00:32:32,210 Alice, alice@mailprovider.com and in the first phase when using BrowserID, she does 298 00:32:32,210 --> 00:32:37,880 the following, she goes to her identity provider and first creates a 299 00:32:37,880 --> 00:32:43,830 public/private keypad. And then she sends the public key in a document with an 300 00:32:43,830 --> 00:32:50,660 identity to the mal provider and the mail provider then signs this document. And 301 00:32:50,660 --> 00:32:56,070 this creates the so-called user certificate. And this certificate is then 302 00:32:56,070 --> 00:33:02,221 sent back to Alice. Now, in the second phase, if Alice wants to actually log in 303 00:33:02,221 --> 00:33:09,620 that some website and then she does the following she creates and another document 304 00:33:09,620 --> 00:33:14,350 containing the identity of the website where she wants to log in, say Wikipedia, 305 00:33:14,350 --> 00:33:24,230 and to do so, she signs the identity of Wikipedia with her own private key. And 306 00:33:24,230 --> 00:33:28,200 this creates the so-called identity assertion. Now, Alice sends both documents 307 00:33:28,200 --> 00:33:34,059 to Wikipedia and Wikipedia can then, of course, check these documents, because 308 00:33:34,059 --> 00:33:39,870 Wikipedia can check first it can retrieve the public key of the mail provider, can 309 00:33:39,870 --> 00:33:46,500 check the user certificate, and then also can check the identity assertion. And 310 00:33:46,500 --> 00:33:52,769 yeah, then Wikipedia can consider Alice to be logged in. So this was the basic idea 311 00:33:52,769 --> 00:33:58,309 of BrowserID, which is quite nice and clean and simple. And then they started to 312 00:33:58,309 --> 00:34:04,350 implement this using just the browser features, including all the workarounds 313 00:34:04,350 --> 00:34:10,260 for the Internet Explorer and so on and so on. And they ended up with a quite 314 00:34:10,260 --> 00:34:18,679 complicated system. So here we have on the left side Alice's browser two Windows, 315 00:34:18,679 --> 00:34:23,599 namely Wikipedia and the login dialog, which is provided by a central authority 316 00:34:23,599 --> 00:34:29,820 which they try to avoid login.persona.org and inside both of these windows and other 317 00:34:29,820 --> 00:34:34,919 iframes and inside one of these iframes, that's another iframe. And on the right we 318 00:34:34,919 --> 00:34:39,800 have the servers. So the relying party, the identity provider and the central 319 00:34:39,800 --> 00:34:46,300 authority login.persona.org. And just to give you an idea of how complex the system 320 00:34:46,300 --> 00:34:53,320 ended up, they all talk to each other using HTTP requests, but also using 321 00:34:53,320 --> 00:34:59,990 postMessages and also using XML-HTTP requests. And as you can see, the system 322 00:34:59,990 --> 00:35:08,370 became quite complex. To add even more complexity, they did the following. They 323 00:35:08,370 --> 00:35:11,880 thought, well, some users, they are already using Gmail or Yahoo! So let's 324 00:35:11,880 --> 00:35:19,290 provide some nice. Yeah. Interface for them. They provided the so-called identity 325 00:35:19,290 --> 00:35:25,050 bridge specifically for Gmail and Yahoo! Which at the time supported OpenID 326 00:35:25,050 --> 00:35:31,210 authentication only. And they created two new servers, the so-called bridging 327 00:35:31,210 --> 00:35:38,620 servers, one for Gmail called Sideshow and the other one for Yahoo! Called BigTent. 328 00:35:38,620 --> 00:35:45,650 Now, the user authenticates, authenticates to the bridging server, using OpenID and 329 00:35:45,650 --> 00:35:54,819 then a bridging server has an interface to the standard BrowserID interface. So one 330 00:35:54,819 --> 00:35:59,120 problem was that OpenID identities, they are not email addresses. And so in OpenID 331 00:35:59,120 --> 00:36:06,109 you add an attribute, which is called the email attribute. And, um, we're talking 332 00:36:06,109 --> 00:36:11,640 about this email attribute in a minute. So let's have a look at how these identity 333 00:36:11,640 --> 00:36:17,520 breaches work. We are not going into all the details of the BrowserID or Persona 334 00:36:17,520 --> 00:36:21,280 protocol because this would be too complicated. But the identity bridge is 335 00:36:21,280 --> 00:36:28,910 interesting and also important for some of the attacks that we found. So in the 336 00:36:28,910 --> 00:36:32,631 identity bridge the following happens, so here on the left, we have Alice's browser 337 00:36:32,631 --> 00:36:38,250 and in the middle we have Sideshow service identity bridge and on the right side, we 338 00:36:38,250 --> 00:36:44,890 have Gmail, which could also be Yahoo in this case. But let's say it's Gmail. So 339 00:36:44,890 --> 00:36:51,800 first, the user says that she wants to log in at Sideshow and then Sideshow sends an 340 00:36:51,800 --> 00:36:59,310 OpenID request requesting the email attribute signed from Gmail. This request 341 00:36:59,310 --> 00:37:05,230 is then forwarded to Gmail. Gmail sees the request, the user logs in a Gmail for 342 00:37:05,230 --> 00:37:12,250 authentication. And then Gmail creates this OpenID assertion, which contains the 343 00:37:12,250 --> 00:37:17,790 signed email address attribute for Alice and as you can see, this is all in the 344 00:37:17,790 --> 00:37:25,680 green box. So all properly signed. Nice. And now Alice's browser redirects this 345 00:37:25,680 --> 00:37:31,849 document to Sideshow. Now Sideshow doesn't check the contents of this decision for 346 00:37:31,849 --> 00:37:39,329 itself. Instead, it sends these things to Gmail, Gmail checks everything that is 347 00:37:39,329 --> 00:37:45,200 signed. And Tells Sideshow, yes, this document looks correct to me, everything 348 00:37:45,200 --> 00:37:51,670 that was signed was signed by me and was not tampered with. Then Sideshow looks at 349 00:37:51,670 --> 00:37:56,780 the document and sees Alice wanted to log in. So this must be the user, must be 350 00:37:56,780 --> 00:38:04,290 Alice now and provides a cookie because the user is now logged in as Alice. So 351 00:38:04,290 --> 00:38:12,040 far, simple. Now for some of the attacks that we found. First attack, identity 352 00:38:12,040 --> 00:38:18,630 forgery. So here we have essentially the same that we saw before, the same setting, 353 00:38:18,630 --> 00:38:24,000 except now we don't have Alice's Browser on the left. We have the attackers browser 354 00:38:24,000 --> 00:38:30,530 on the left. The attacker can go to Sideshow and say, I want to sign in. Now 355 00:38:30,530 --> 00:38:37,790 Sideshow, sends this OpenID request to the attacker and it can change this request, 356 00:38:37,790 --> 00:38:43,960 the attacker can just remove the request for the email attribute from this request. 357 00:38:43,960 --> 00:38:51,790 Which is still a valid OpenID request. Gmail sees this request, and now the 358 00:38:51,790 --> 00:38:56,050 attacker logs in. The attacker doesn't have Alice's user data so the attacker 359 00:38:56,050 --> 00:39:03,329 just logs in with his own credentials. And now Gmail creates an automatic assertion 360 00:39:03,329 --> 00:39:10,560 containing the signed attribute, which was requested, which was nothing. So 361 00:39:10,560 --> 00:39:16,430 essentially, the document is empty, at least without any email address. Now, the 362 00:39:16,430 --> 00:39:23,800 attacker can simply add a new attribute to this document containing an email address 363 00:39:23,800 --> 00:39:31,330 that he has chosen arbitrarily. This, of course, is not signed, which is not a 364 00:39:31,330 --> 00:39:37,740 problem because this document can be partly signed and this document is 365 00:39:37,740 --> 00:39:43,640 forwarded to Gmail. Gmail now analyzes this document and sees whether there is a 366 00:39:43,640 --> 00:39:49,530 signed part in this document. So I check this signed part. The signed part doesn't 367 00:39:49,530 --> 00:39:59,950 contain anything useful, but it is correct. It's not the wrong signature. So 368 00:39:59,950 --> 00:40:05,400 it sends back to Sideshow: there I checked this document looks fine to me. Now 369 00:40:05,400 --> 00:40:09,630 Sideshow looks at a document, sees that as an email attribute, uses this email 370 00:40:09,630 --> 00:40:18,250 attribute and the attacker is signed into any Gmail account that he likes with using 371 00:40:18,250 --> 00:40:25,300 BrowserID. OK, so this is bad, as you can imagine. And we told the Mozilla guys 372 00:40:25,300 --> 00:40:30,960 about this and they were quite fast. So we were really surprised. They were really 373 00:40:30,960 --> 00:40:35,380 quick. So I think it was in the middle of the night for most of them, but they 374 00:40:35,380 --> 00:40:40,839 scrambled in the back and they wrote some patches and so on and so on. And I think 375 00:40:40,839 --> 00:40:46,850 it wasn't 24 hours later that it was all deployed and fixed. So that's what was 376 00:40:46,850 --> 00:40:54,369 quite good. But then we took another look at the system and we found identity 377 00:40:54,369 --> 00:41:02,569 forgery number two, which is actually remarkably similar to works as follows. So 378 00:41:02,569 --> 00:41:06,270 the attacker, since the authentication requests, you know this part at Sideshow 379 00:41:06,270 --> 00:41:12,570 once the signed e-mail attribute and the attacker now doesn't change anything, the 380 00:41:12,570 --> 00:41:18,370 attacker just forwards this request to Gmail, Gmail, ask for the credentials, the 381 00:41:18,370 --> 00:41:25,800 attacker signs and and sends back the OpenID assertion containing the signed 382 00:41:25,800 --> 00:41:31,690 email address of the attacker. So no attack to up to this point. But now the 383 00:41:31,690 --> 00:41:37,381 attacker can do the following. The attacker adds another attribute, another 384 00:41:37,381 --> 00:41:47,250 email attribute. And yeah, you can guess what happens. The document is forwarded to 385 00:41:47,250 --> 00:41:53,690 Gmail. Gmail checks the signed part of the document, which is still fine, sends back 386 00:41:53,690 --> 00:41:57,849 to Sideshow that everything is fine with this document. And Sideshow selects the 387 00:41:57,849 --> 00:42:04,880 wrong email address. Yeah, and now the user, the attacker signed into any user 388 00:42:04,880 --> 00:42:14,410 account again. OK, so this was the second identity forgery attack. We also found 389 00:42:14,410 --> 00:42:19,230 another attack, which is not very spectacular. And we also looked so this 390 00:42:19,230 --> 00:42:26,589 was all, of course, authentication. And we also took a look at privacy so as to 391 00:42:26,589 --> 00:42:34,170 remember privacy says that, in the words of Mozilla, the browser ID protocol never 392 00:42:34,170 --> 00:42:42,630 leaks tracking information back to the identity provider, except it does. So 393 00:42:42,630 --> 00:42:46,381 ideally, the identity provider should be unable to tell whether user logs in. In 394 00:42:46,381 --> 00:42:55,420 fact, this is broken, because in the browser, the following happens. If 395 00:42:55,420 --> 00:43:00,200 malicious identity provider wants to find out whether a user is logged in at some 396 00:43:00,200 --> 00:43:05,500 specific relying party or not, then the malicious identity provider can just open 397 00:43:05,500 --> 00:43:13,930 iframe containing the website of that relying party he wants to probe. Now the 398 00:43:13,930 --> 00:43:19,330 following happens, the normal JavaScript of BrowserID runs in this relying party 399 00:43:19,330 --> 00:43:25,340 because it has provided support, obviously, and creates an iframe and 400 00:43:25,340 --> 00:43:32,030 inside this iframe, another iframe will be created. But this innermost iframe will 401 00:43:32,030 --> 00:43:39,900 only be created if the user logged in at this RP before. Now, since the outermost 402 00:43:39,900 --> 00:43:43,730 and the innermost iframe, they come from the same source and of course they can 403 00:43:43,730 --> 00:43:50,260 collaborate and communicate. They can for example, just send postMessage saying: I, 404 00:43:50,260 --> 00:43:56,460 the user logged in at this ruling party before. So an identity provider can easily 405 00:43:56,460 --> 00:44:02,609 probe whether a user logged in at some relying party or not. And this 406 00:44:02,609 --> 00:44:05,550 unfortunately cannot be fixed without a major redesign of BrowserID, because they 407 00:44:05,550 --> 00:44:12,619 relied on all these iframes and so on. Yeah. So I think this can be considered 408 00:44:12,619 --> 00:44:18,940 broken beyond repair. We also found some variants of these privacy attacks which 409 00:44:18,940 --> 00:44:26,300 rely on other mechanisms. But essentially. Yeah, you get the idea right here. Privacy 410 00:44:26,300 --> 00:44:35,619 of BrowserID is broken. OK, so to sum up BrowserID, we found attacks, but we also 411 00:44:35,619 --> 00:44:44,849 were able to fix them with respect to security, and we also used our formal 412 00:44:44,849 --> 00:44:51,250 methods to improve the security of the fixed BrowserID system. But privacy is 413 00:44:51,250 --> 00:44:55,000 broken beyond repair. 414 00:44:55,000 --> 00:45:00,650 Guido: OK, this leads us to the question, can we build a single-sign-on system that 415 00:45:00,650 --> 00:45:08,559 provides security and privacy on the Web? So we thought a lot about this question. 416 00:45:08,559 --> 00:45:16,460 And then we used our formal model to design such a single-sign-on system. And 417 00:45:16,460 --> 00:45:22,700 we could also then use the former model to prove that these properties are actually 418 00:45:22,700 --> 00:45:30,940 fulfilled. So the basic principle of the system is called SPRESSO for Secure 419 00:45:30,940 --> 00:45:37,710 Privacy Respecting Single-Sign-On is the following. We have the user with a 420 00:45:37,710 --> 00:45:44,150 browser. This user wants to log in at some relying party, for example, at Wikipedia. 421 00:45:44,150 --> 00:45:51,171 So here we have the same same idea as in BrowserID to use the email address and the 422 00:45:51,171 --> 00:45:58,250 e-mail provider as the identity provider. So the user enters the email address and 423 00:45:58,250 --> 00:46:07,770 then the relying party asks for some proof of this identity. So the user goes to her 424 00:46:07,770 --> 00:46:13,780 email provider, which is identity provider in this case, authenticates there. And 425 00:46:13,780 --> 00:46:20,560 then this. The identity provider creates a document that proves the Alice's identity 426 00:46:20,560 --> 00:46:25,540 and then forwards this document to the relying party. And the relying party can 427 00:46:25,540 --> 00:46:31,510 check if everything is all right and then consider the user to be loggged in. So 428 00:46:31,510 --> 00:46:37,010 let's have a closer look on how this system works. So here again, we have 429 00:46:37,010 --> 00:46:45,089 Alice's browser, the window of the relying party. Alice enters her email address. The 430 00:46:45,089 --> 00:46:49,130 email address is sent to relying party. And now the relying party creates a 431 00:46:49,130 --> 00:46:55,630 document that contains the identity of the relying party itself. And this document is 432 00:46:55,630 --> 00:47:01,590 encrypted and we call this document the tag. So now the tag is sent, along with 433 00:47:01,590 --> 00:47:06,510 the key that was used to encrypt this document. So this is symmetric encryption 434 00:47:06,510 --> 00:47:16,089 with a fresh key sends it to the browser. And now in the browser, the SPRESSO code 435 00:47:16,089 --> 00:47:21,740 opens a new window of the identity provider that is given by the domain of 436 00:47:21,740 --> 00:47:33,810 the email address and sends the tag over to this window. This login dialog prompts 437 00:47:33,810 --> 00:47:40,550 the user to authenticate, so the user now enters her password. And this is sent 438 00:47:40,550 --> 00:47:47,300 along with the tag to the server and now the server creates this document I've just 439 00:47:47,300 --> 00:47:55,830 spoken of in the last slide and this document, we call it the user certificate, 440 00:47:55,830 --> 00:48:02,210 user assertion, sorry, user assertion. We send it back to the window at the login 441 00:48:02,210 --> 00:48:10,130 dialog and now we have a problem. We could just send it over to the Wikipedia window. 442 00:48:10,130 --> 00:48:16,750 But I show you in the minute why this is a bad idea. So instead, now we have a third 443 00:48:16,750 --> 00:48:25,150 party, the forwarder which serves just a single static JavaScript file, and this is 444 00:48:25,150 --> 00:48:32,970 loaded in an iframe and is login dialog. And this iframe gets the user assertion 445 00:48:32,970 --> 00:48:40,000 and it also gets the key and now it can decrypt the tag. Look who is the intended 446 00:48:40,000 --> 00:48:46,890 receiver and then it sends over the user assertion through the window of the 447 00:48:46,890 --> 00:48:51,430 relying party which forwards it to the server of the relying party, who could 448 00:48:51,430 --> 00:48:56,990 then can check if everything is all right and consider the user to be logged in. So 449 00:48:56,990 --> 00:49:03,569 why do we need this forward? So at first it may look strange. So let's look what 450 00:49:03,569 --> 00:49:09,400 happens if we just don't have this forwarder. So let's assume the user wants 451 00:49:09,400 --> 00:49:14,620 to log in at some malicious relying party at attacker.com and there is an email 452 00:49:14,620 --> 00:49:19,230 address but the attacker wants to impersonate the user who wants to log in 453 00:49:19,230 --> 00:49:24,339 at some other relying party. Let's say to Wikipedia, for example, and the attacker 454 00:49:24,339 --> 00:49:30,930 goes to Wikipedia, says, hi, I'm Alice. I want to log in. Wikipedia creates a tag. 455 00:49:30,930 --> 00:49:39,450 This is sent over to the attacker who just relays it to the user user. Protocol runs 456 00:49:39,450 --> 00:49:46,280 on, the user authenticates to her identity provider. And then we just sent the tag 457 00:49:46,280 --> 00:49:52,109 over as the identity provider does not know who is the intended receiver's 458 00:49:52,109 --> 00:49:58,430 because we want to have this privacy feature. This just went through and the 459 00:49:58,430 --> 00:50:03,240 attacker gets the user certificate and user assertion and forwards it to 460 00:50:03,240 --> 00:50:09,490 Wikipedia and then the attacker is considered to be Alice. And this is that. 461 00:50:09,490 --> 00:50:16,569 So we need some mechanism to prevent that the user assertion is forwarded to some 462 00:50:16,569 --> 00:50:21,550 random party, but only to the intended receiver. And for this, we have this 463 00:50:21,550 --> 00:50:29,450 forwarder. Now, you can think this forwarded may maybe be also malicious, but 464 00:50:29,450 --> 00:50:33,920 let's talk about about this in a second. So let's just talk about the key forwarded 465 00:50:33,920 --> 00:50:42,470 to us so the forwarder gets the user assertion and he gets the key to decrypt 466 00:50:42,470 --> 00:50:48,500 the tag. And now he can instruct the browser to send a postMessage, but only to 467 00:50:48,500 --> 00:50:54,540 give it to a window of Wikipedia. So the browser checks is the receiver of the 468 00:50:54,540 --> 00:51:00,270 window of Wikipedia or not. And if it's not, it doesn't deliver this message. So 469 00:51:00,270 --> 00:51:07,300 this protects the, um, the user assertion certain to be leaked. And now you may 470 00:51:07,300 --> 00:51:12,420 think this forwarder may be malicious and deliver some other script that does 471 00:51:12,420 --> 00:51:17,680 strange things like forwarding things att start to the attacker directly. But we can 472 00:51:17,680 --> 00:51:22,130 enforce that the correct script is running inside that iframe using separate source 473 00:51:22,130 --> 00:51:29,900 integrity where you just tell the browser and this window only this code may run. 474 00:51:29,900 --> 00:51:36,390 And in this case the forwarder cannot just put some arbitrary or malicious code in 475 00:51:36,390 --> 00:51:41,440 this iframe. And also there is no information that leaks back from the 476 00:51:41,440 --> 00:51:48,960 browser to the forwarder. So to sum this up, as I just presented SPRESSO, it 477 00:51:48,960 --> 00:51:55,390 features privacy and authentication. It's open and decentralized. So you don't need 478 00:51:55,390 --> 00:52:02,510 any specific central party. It's compliant to web standards. That's based on HTML5. 479 00:52:02,510 --> 00:52:09,849 And we have formal proof that all these properties we've talked at the beginning 480 00:52:09,849 --> 00:52:14,740 actually hold and you can find a demo and more information on spresso.me. 481 00:52:14,740 --> 00:52:26,181 Daniel: OK, now to conclude the talk, what is the takeaway? First of all, w talked, I 482 00:52:26,181 --> 00:52:30,880 think most of the time about OAuth 2.0. Most of the results also translate to 483 00:52:30,880 --> 00:52:37,510 OpenID Connect. We have formally proven the security of the protocol of OAuth and 484 00:52:37,510 --> 00:52:47,040 also OpenID Connect. Which is a nice result, of course, if you're OK with 485 00:52:47,040 --> 00:52:53,210 having no privacy, because OAuth and OpenID Connect don't have any kind of 486 00:52:53,210 --> 00:53:00,650 privacy that we talked about. Regarding OAuth 1.0 and OpenID, I think that can be 487 00:53:00,650 --> 00:53:05,040 considered deprecated and shouldn't be used. BrowserID, Mozilla Persona was a 488 00:53:05,040 --> 00:53:15,060 nice experiment. But is dead now and also has broken privacy. With SPRESSO we have 489 00:53:15,060 --> 00:53:19,359 shown, however, that you can achieve privacy on web single-sign-on using 490 00:53:19,359 --> 00:53:25,940 standard HTML5 features and standard web features. But of course for now it is a 491 00:53:25,940 --> 00:53:34,270 proof of concept. As you have seen, we don't even have a nice logo yet. Um, So 492 00:53:34,270 --> 00:53:39,920 and one target audience are certainly developers, developers, developers use 493 00:53:39,920 --> 00:53:47,240 libraries wherever possible. For example, the pyoidc is written even by members of 494 00:53:47,240 --> 00:53:56,890 the OAuth and OpenID working groups. So they know what they do. Hopefully. Also 495 00:53:56,890 --> 00:54:03,070 regarding RFC's, they are hard to read and information is often spread across several 496 00:54:03,070 --> 00:54:08,970 documents. They are often not written clearly and they are not always up to 497 00:54:08,970 --> 00:54:16,270 date, but they are still an important reference. And I think it's a good advice 498 00:54:16,270 --> 00:54:23,130 to look at RFC's from time to time, even if they are hard to read. So thank you 499 00:54:23,130 --> 00:54:27,940 very much for your attention. If you want to talk to us, come to us at the 500 00:54:27,940 --> 00:54:33,750 Maschinendeck assemblyin hall 3 free or join us at the next Pi and More,shameless 501 00:54:33,750 --> 00:54:40,170 plug here, January 14 in Krefield or at University of Stuttgart starting in 502 00:54:40,170 --> 00:54:46,710 January. Thank you very much. 503 00:54:46,710 --> 00:54:52,369 *applause* 504 00:54:52,369 --> 00:54:56,880 Presenter: Now we have eight minutes for questions, what do we have from the 505 00:54:56,880 --> 00:55:02,700 Internet? Question (internet): So we've got two 506 00:55:02,700 --> 00:55:10,790 questions from the Internet. You can you hear me? So at the diagram you showed one 507 00:55:10,790 --> 00:55:16,369 of the first slides, why does the authentication follow authorization? 508 00:55:16,369 --> 00:55:21,839 Shouldn't it normally be the other way around? 509 00:55:21,839 --> 00:55:32,530 Presenter: Can you try to repeat the question? 510 00:55:32,530 --> 00:55:40,130 Internet: Yeah, sorry, at the diagram you showed in one of the first slides. Why 511 00:55:40,130 --> 00:55:46,099 does the why does the authentication follow authorization? Shouldn't it 512 00:55:46,099 --> 00:55:53,150 normally be the other way around? Guido: OK, so these are two concepts that 513 00:55:53,150 --> 00:56:03,650 are kind of orthogonal to each other. So you can either do authentication to ensure 514 00:56:03,650 --> 00:56:08,650 yourself of the user's identity or you can act on the user's behalf at the identity 515 00:56:08,650 --> 00:56:14,329 provider, like posting on the user's Facebook timeline or doing different 516 00:56:14,329 --> 00:56:21,900 things there. But for authentication, you need to retrieve some unique user 517 00:56:21,900 --> 00:56:29,349 identifier. And this basically you make use of this authorization mechanism. So 518 00:56:29,349 --> 00:56:35,010 you get authorized to access this unique user identifier and you use this then for 519 00:56:35,010 --> 00:56:40,280 authentication. Presenter: Thank you. Questions from here. 520 00:56:40,280 --> 00:56:46,720 Question 2: So for the special protocol, you said you need the forwarding party to 521 00:56:46,720 --> 00:56:51,190 check whether this certificate was actually from Wikipedia or not from 522 00:56:51,190 --> 00:56:55,069 attacker.com. But could Alice do this check herself? 523 00:56:55,069 --> 00:57:02,210 Guido: You mean that you should present the user something and the user accepts 524 00:57:02,210 --> 00:57:07,410 this and or declines this in this sense? Or... 525 00:57:07,410 --> 00:57:11,920 Question 2: She has the challenge that is signed by her email provider and she has 526 00:57:11,920 --> 00:57:15,990 the key that encrypted Wikipedia's identity. So she could use that to decrypt 527 00:57:15,990 --> 00:57:19,240 it and check if it's Wikipedia or attacker.com. 528 00:57:19,240 --> 00:57:23,230 Guido: Yeah, yeah. I mean, in principle, yes. 529 00:57:23,230 --> 00:57:26,770 Daniel: So you mean the user? Question 2: Yeah, yes. 530 00:57:26,770 --> 00:57:30,300 Daniel: Yes. The user could, of course, check. We could ask the user, did you 531 00:57:30,300 --> 00:57:35,950 really want to sign attacker.com or wikipedia.com? But of course, we all know 532 00:57:35,950 --> 00:57:42,190 that users are better at making decisions. So, yeah. 533 00:57:42,190 --> 00:57:47,280 Presenter: Thank you. Questions from here? Question 3: Hi, thanks for the informative 534 00:57:47,280 --> 00:57:51,619 talk, but I wanted to add a remark. It is highly unfair to call users stupid for 535 00:57:51,619 --> 00:57:55,150 falling victim to clickjacking and phishing because they are working 536 00:57:55,150 --> 00:58:02,109 professionally on them on enabling clickjacking and phishing. And if you need 537 00:58:02,109 --> 00:58:06,349 a 4K monitor just to see that there is some JavaScript edit that like thousand 538 00:58:06,349 --> 00:58:13,869 zero delimiters, it is impossible to blame the user for being stupid or falling 539 00:58:13,869 --> 00:58:19,849 victim to clickjacking. Daniel: Yes, that's correct. It also 540 00:58:19,849 --> 00:58:28,119 sometimes you just can't see it. So yes. Presenter: Thank you. Questions from down 541 00:58:28,119 --> 00:58:35,260 there? Sorry. Questions? Question 4: You talked about formal 542 00:58:35,260 --> 00:58:43,750 verification of both the OAuth and your protocol. I wanted to know what kind of 543 00:58:43,750 --> 00:58:49,849 program or whatever you used like ProVerif or Tamarin or whatever. And also, I think 544 00:58:49,849 --> 00:58:56,559 you just proved the, you just verified a subset of OAuth? 545 00:58:56,559 --> 00:59:02,540 Daniel: Let's start with the second question first. So for OAuth, we really 546 00:59:02,540 --> 00:59:07,500 tried to introduce as many options as we could find in the standard, so to say. 547 00:59:07,500 --> 00:59:13,870 OAuth is a very loose standard. So they give you a lot of options. In many ways. 548 00:59:13,870 --> 00:59:19,190 We had to exclude some of them for practical reasons when modeling the stuff. 549 00:59:19,190 --> 00:59:25,540 But we included almost all of the options that are provided. And we also have a 550 00:59:25,540 --> 00:59:31,460 detailed write up of what the options are and what we excluded and what we included. 551 00:59:31,460 --> 00:59:36,599 And now for the first part of the question, our model currently is a manual 552 00:59:36,599 --> 00:59:44,039 model. So what we do is pen and paper proves. The reasoning behind this is that 553 00:59:44,039 --> 00:59:51,059 if you have tools, they are always, in some sense, limiting you. And when we 554 00:59:51,059 --> 00:59:58,369 started out with this work, there was or there were two models, essentially already 555 00:59:58,369 --> 01:00:04,099 existing web models, former models so in the same area as we are. But they were 556 01:00:04,099 --> 01:00:11,670 both based on a model checker, so one on ProVerif, one on another modeling tool... 557 01:00:11,670 --> 01:00:15,190 Guido: Alloy. Daniel: Alloy. And both were limited by 558 01:00:15,190 --> 01:00:19,859 the possibilities that you had in these model checkers. So what we went the other 559 01:00:19,859 --> 01:00:24,750 way around, what we wanted to do was a manual model that includes, that models 560 01:00:24,750 --> 01:00:29,510 the web really precisely and comprehensively. And then as a second step 561 01:00:29,510 --> 01:00:35,510 what we are currently working on or discussing about is to transfer this into 562 01:00:35,510 --> 01:00:38,910 some kind of tool. Question 4: Thank you. 563 01:00:38,910 --> 01:00:43,340 Presenter: Two more questions, questions from the Internet? 564 01:00:43,340 --> 01:00:51,349 Internet: So I was wondering if you know about ND-Auth(?) and RealMe Auth and what 565 01:00:51,349 --> 01:00:57,300 you think about the question of using domain names vs. email addresses as the 566 01:00:57,300 --> 01:01:01,190 user identifier. Daniel: Could you repeat that a bit 567 01:01:01,190 --> 01:01:05,350 louder? Internet: So if you have any comments 568 01:01:05,350 --> 01:01:12,220 aboutND-Auth(?) and RealMe Auth which is the domain name as identifier rather than 569 01:01:12,220 --> 01:01:16,329 an email address. Daniel: So we didn't look at these 570 01:01:16,329 --> 01:01:21,230 systems. Presenter: Yes, last question. 571 01:01:21,230 --> 01:01:27,490 Question 5: The question regarding the forwarder and the privacy protection, I 572 01:01:27,490 --> 01:01:32,339 realized with the forwarder as far as I understand, the forwarder is used in its 573 01:01:32,339 --> 01:01:38,720 own iframe to prevent the IDP from taking control of the verification process, 574 01:01:38,720 --> 01:01:44,630 knowing that who is the the final system? Guido: Yes. 575 01:01:44,630 --> 01:01:50,250 Question 5: But what if the identity provider at the forward to collaborate, 576 01:01:50,250 --> 01:01:58,059 then the privacy would be broken? Yes. If we have these parties collaborating then 577 01:01:58,059 --> 01:02:03,750 of course they are broken. So we haven't we haven't shown all the details of the 578 01:02:03,750 --> 01:02:13,460 system. So this is really hard to prevent. But in SPRESSO, the relying party is 579 01:02:13,460 --> 01:02:20,160 allowed to choose which forwarder has to be used. So line party, so choose water 580 01:02:20,160 --> 01:02:25,599 run by some trustworthy party. So this is the countermeasure to prevent 581 01:02:25,599 --> 01:02:30,789 collaboration. But if these parties collaborate, then you are screwed. Yes. 582 01:02:30,789 --> 01:02:35,440 Daniel: So I think it's also important to add some of the forwarder is kind of a 583 01:02:35,440 --> 01:02:42,369 semi trusted party, because on the one hand, we can enforce that as it uses the 584 01:02:42,369 --> 01:02:49,550 correct code. Of course, the IDP then has to enforce this. On the other hand, you 585 01:02:49,550 --> 01:02:53,829 still have some side channels like, for example, timing. So if you control the 586 01:02:53,829 --> 01:03:00,260 parties, then you could check which IP addresses access for example, the 587 01:03:00,260 --> 01:03:06,760 forwarder and IDP at the same time or and so on. So there are some side channels. So 588 01:03:06,760 --> 01:03:11,569 the idea that we have to minimize this risk is to provide a set of trusted 589 01:03:11,569 --> 01:03:20,480 forwarders that could be, for example, provided by some trusted parties like 590 01:03:20,480 --> 01:03:25,050 Mozilla or the EFF or something, so that you have a set of forwards to choose from 591 01:03:25,050 --> 01:03:29,119 and hopefully choose a trusted one. Question 5: Thank you. 592 01:03:29,119 --> 01:03:32,440 Daniel: You're welcome. Presenter: Guido Schmitz and Daniel Fett, 593 01:03:32,440 --> 01:03:48,650 thank you so much for the great talk. Please give a great round of applause. 594 01:03:48,650 --> 01:03:53,970 *applause* 595 01:03:53,970 --> 01:03:57,309 *postroll music* 596 01:03:57,309 --> 01:04:05,000 Subtitles created by many many volunteers and the c3subtitles.de team. Join us, and help us!