[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:04.87,0:00:12.80,Default,,0000,0000,0000,,{\i1}33C3 preroll music{\i0}
Dialogue: 0,0:00:12.80,0:00:17.84,Default,,0000,0000,0000,,Presenter: So I think we're all set\Nwithout further ado, I would like to I
Dialogue: 0,0:00:17.84,0:00:23.78,Default,,0000,0000,0000,,would like to introduce Guido Schmitz and\NDaniel Fett, who are going to be having
Dialogue: 0,0:00:23.78,0:00:29.98,Default,,0000,0000,0000,,this talk on a single-sign-on on the web.\NGive them a big round of applause. And I
Dialogue: 0,0:00:29.98,0:00:37.36,Default,,0000,0000,0000,,hope you're looking forward to the talk
Dialogue: 0,0:00:37.36,0:00:46.27,Default,,0000,0000,0000,,Guido: OK, hello, everybody, welcome to\Nour talk on the security and privacy of
Dialogue: 0,0:00:46.27,0:00:53.34,Default,,0000,0000,0000,,modern single-sign-on the web. So in this\Ntalk, Daniel and me, we are going to
Dialogue: 0,0:00:53.34,0:01:01.50,Default,,0000,0000,0000,,pretend not only just a OAuth and OpenID\NConnect, but also some thoughts about
Dialogue: 0,0:01:01.50,0:01:10.31,Default,,0000,0000,0000,,analysis of all these standards. So first,\Na brief introduction who are. We are
Dialogue: 0,0:01:10.31,0:01:18.21,Default,,0000,0000,0000,,researchers from the University of Trier,\Nbut soon of University of Stuttgart. And
Dialogue: 0,0:01:18.21,0:01:24.37,Default,,0000,0000,0000,,also we happen to be the founders of the\NMaschinendeck, the hackerspace in Trier
Dialogue: 0,0:01:24.37,0:01:31.95,Default,,0000,0000,0000,,and the Pi and More raspberry jam. If\Nyou're interested in anything else, what
Dialogue: 0,0:01:31.95,0:01:38.80,Default,,0000,0000,0000,,we are doing, you can just follow us on\NTwitter. So what is the single-sign-on
Dialogue: 0,0:01:38.80,0:01:45.32,Default,,0000,0000,0000,,about? What are we talking about? So\Nprobably all of you have seen websites
Dialogue: 0,0:01:45.32,0:01:52.02,Default,,0000,0000,0000,,like this, like TripAdvisor, that you can\Nuse a lot of different methods to sign and
Dialogue: 0,0:01:52.02,0:01:55.93,Default,,0000,0000,0000,,you can sign in with your Facebook\Naccount, with your Google account, you can
Dialogue: 0,0:01:55.93,0:02:00.64,Default,,0000,0000,0000,,register account at their page with the\Nemail address and password, or you can use
Dialogue: 0,0:02:00.64,0:02:09.03,Default,,0000,0000,0000,,your Samsung account or probably now even\Nmore different systems. And if you click,
Dialogue: 0,0:02:09.03,0:02:13.02,Default,,0000,0000,0000,,for example, on this login with Facebook\Nbutton and new window pops up, prompting
Dialogue: 0,0:02:13.02,0:02:18.47,Default,,0000,0000,0000,,for your Facebook credentials, or if you\Nalready signed into Facebook, just asks
Dialogue: 0,0:02:18.47,0:02:25.70,Default,,0000,0000,0000,,for confirmation. So this is a setting we\Nare looking at and we have two parties
Dialogue: 0,0:02:25.70,0:02:31.41,Default,,0000,0000,0000,,here. We have the we have TripAdvisor as\Nthe so-called relying party and we have
Dialogue: 0,0:02:31.41,0:02:39.25,Default,,0000,0000,0000,,Facebook as the so-called identity\Nprovider. And the basic principle of how
Dialogue: 0,0:02:39.25,0:02:44.63,Default,,0000,0000,0000,,this works is the following. So first you\Ngo with your browser to the relying party.
Dialogue: 0,0:02:44.63,0:02:52.53,Default,,0000,0000,0000,,You say, I want to log in that RP, then\Nyou contact your identity provider,
Dialogue: 0,0:02:52.53,0:02:58.12,Default,,0000,0000,0000,,authenticate there. And this identity\Nprovider then issues some kind of token
Dialogue: 0,0:02:58.12,0:03:03.75,Default,,0000,0000,0000,,and this token you give to the relying\Nparty. And the ruling party can now use
Dialogue: 0,0:03:03.75,0:03:11.56,Default,,0000,0000,0000,,this token to access some parts of your\Naccount at the identity provider. And this
Dialogue: 0,0:03:11.56,0:03:15.91,Default,,0000,0000,0000,,is called authorization, for example, the\Nruling party can use this token now to
Dialogue: 0,0:03:15.91,0:03:24.15,Default,,0000,0000,0000,,post on your Facebook timeline or reach\Nout your friends list from Facebook. And
Dialogue: 0,0:03:24.15,0:03:31.21,Default,,0000,0000,0000,,it the ruling party can also retrieve some\Nunique user identifier and then consider
Dialogue: 0,0:03:31.21,0:03:35.50,Default,,0000,0000,0000,,you to be locked in with that user\Nidentifier. And then this is
Dialogue: 0,0:03:35.50,0:03:42.97,Default,,0000,0000,0000,,authentication. And then RP can set, for\Nexample, sensation Cookie and Mark. This
Dialogue: 0,0:03:42.97,0:03:49.31,Default,,0000,0000,0000,,session belongs. Remember that this\Nsession belongs to this user. So this is
Dialogue: 0,0:03:49.31,0:03:55.44,Default,,0000,0000,0000,,the basic the basic principle. Why should\Nwe use single-sign-on or why we shouldn't
Dialogue: 0,0:03:55.44,0:04:01.98,Default,,0000,0000,0000,,use single-sign-on? So for users, it's\Nvery convenient. You don't have to
Dialogue: 0,0:04:01.98,0:04:07.34,Default,,0000,0000,0000,,remember which account you used where,\Nwhich password and so on. You just click
Dialogue: 0,0:04:07.34,0:04:10.70,Default,,0000,0000,0000,,and login with Facebook and you're all\Ndone. Of course, this comes with lack of
Dialogue: 0,0:04:10.70,0:04:18.14,Default,,0000,0000,0000,,privacy because Facebook then always knows\Nwhere you log in. And also the identity
Dialogue: 0,0:04:18.14,0:04:22.36,Default,,0000,0000,0000,,provider you choose is also the single\Npoint of failure. If that one closes down
Dialogue: 0,0:04:22.36,0:04:28.67,Default,,0000,0000,0000,,or changes its terms and conditions, then\Nyou perhaps cannot log into your accounts
Dialogue: 0,0:04:28.67,0:04:36.56,Default,,0000,0000,0000,,anymore at some third party web pages. So\Nrelying parties, they need to store less
Dialogue: 0,0:04:36.56,0:04:41.40,Default,,0000,0000,0000,,data. They don't have to care about\Npassword databases that can leak. They
Dialogue: 0,0:04:41.40,0:04:44.42,Default,,0000,0000,0000,,don't have to care about user\Nregistration, password recovery on all the
Dialogue: 0,0:04:44.42,0:04:49.93,Default,,0000,0000,0000,,hassle that comes with user accounts. But\Nthey also have less control over this,
Dialogue: 0,0:04:49.93,0:04:54.95,Default,,0000,0000,0000,,over the users accounts because they\Noutsource the authentication to this
Dialogue: 0,0:04:54.95,0:04:59.45,Default,,0000,0000,0000,,identity provider and also hear the\Nidentity provider as a single point of
Dialogue: 0,0:04:59.45,0:05:05.14,Default,,0000,0000,0000,,failure. Far identity providers, the\Nadvantage is clear. They get more user
Dialogue: 0,0:05:05.14,0:05:12.12,Default,,0000,0000,0000,,data and they can provide some service for\Ntheir users, which makes, perhaps it makes
Dialogue: 0,0:05:12.12,0:05:19.16,Default,,0000,0000,0000,,it more attractive for users to use that\Nidentity provider. On the downside, they
Dialogue: 0,0:05:19.16,0:05:23.34,Default,,0000,0000,0000,,also have to take care about more user\Ndata. They have to store and protect it,
Dialogue: 0,0:05:23.34,0:05:27.13,Default,,0000,0000,0000,,and they have to have the overhead of\Nimplement, implementing and running the
Dialogue: 0,0:05:27.13,0:05:36.56,Default,,0000,0000,0000,,single-sign-on system. So what are these\Nsingle-sign-on systems now? Now I will
Dialogue: 0,0:05:36.56,0:05:43.43,Default,,0000,0000,0000,,show you some prominent examples, so there\Nis OAuth 1.0. So this is a not so modern
Dialogue: 0,0:05:43.43,0:05:50.87,Default,,0000,0000,0000,,single-sign-on system, it's now 10 years\Nold. Many flaws are known for this system
Dialogue: 0,0:05:50.87,0:05:56.07,Default,,0000,0000,0000,,and basically nobody uses it anymore\Nexcept for Twitter. So Twitter uses a
Dialogue: 0,0:05:56.07,0:06:04.67,Default,,0000,0000,0000,,modified version of OAuth 1, which more or\Nless fixes all the known flaws. But in
Dialogue: 0,0:06:04.67,0:06:11.88,Default,,0000,0000,0000,,general, we can say don't use OAuth 1.\NThere is also OpenID, which is also quite
Dialogue: 0,0:06:11.88,0:06:18.92,Default,,0000,0000,0000,,old, nine years. It's not that user\Nfriendly. It's a standard that's meant to
Dialogue: 0,0:06:18.92,0:06:25.12,Default,,0000,0000,0000,,be super flexible for every corner use\Ncase that they developers at that time
Dialogue: 0,0:06:25.12,0:06:31.26,Default,,0000,0000,0000,,thought of. And this makes it also\Nextremely hard to use correctly because
Dialogue: 0,0:06:31.26,0:06:39.13,Default,,0000,0000,0000,,you have a lot of things going on. Things\Nchange during an OpenID running, and it's
Dialogue: 0,0:06:39.13,0:06:46.75,Default,,0000,0000,0000,,not that nice to develop something for\NOpenID. So also, OpenID, don't use this.
Dialogue: 0,0:06:46.75,0:06:52.79,Default,,0000,0000,0000,,And now modern single-sign-on systems, for\Nexample, OAuth 2, which is also used in
Dialogue: 0,0:06:52.79,0:07:02.48,Default,,0000,0000,0000,,login with Facebook. This is completely\Nincompatible to OAuth 1 and OAuth 2 uses
Dialogue: 0,0:07:02.48,0:07:12.54,Default,,0000,0000,0000,,the so-called Bearer token approach. The\Nold protocol is based on some random
Dialogue: 0,0:07:12.54,0:07:18.58,Default,,0000,0000,0000,,values that are passed around. But there's\Nno crypto involved except for the
Dialogue: 0,0:07:18.58,0:07:27.14,Default,,0000,0000,0000,,transport layer for HTTPS, for example,\Nand OAuth2 is used everywhere, almost. So
Dialogue: 0,0:07:27.14,0:07:31.70,Default,,0000,0000,0000,,it's the most popular of these systems,\Nbut it has never been developed for
Dialogue: 0,0:07:31.70,0:07:38.24,Default,,0000,0000,0000,,authentication and really, it's not meant\Nfor authentication. And if you google for
Dialogue: 0,0:07:38.24,0:07:45.36,Default,,0000,0000,0000,,OAuth 2 and authentication, you have to\Nsometimes stumble upon the following
Dialogue: 0,0:07:45.36,0:07:50.58,Default,,0000,0000,0000,,picture. So these two guys are members of\Nthe OAuth working group and they are
Dialogue: 0,0:07:50.58,0:07:54.91,Default,,0000,0000,0000,,really insist it's not meant for\Nauthentication at all. It's just for
Dialogue: 0,0:07:54.91,0:08:03.31,Default,,0000,0000,0000,,authorization. OK. Nonetheless, it is used\Nin practice also for authentication.
Dialogue: 0,0:08:03.31,0:08:10.54,Default,,0000,0000,0000,,Facebook, for example, uses it for\Nauthentication. And so the protocol is now
Dialogue: 0,0:08:10.54,0:08:15.14,Default,,0000,0000,0000,,five years old. Many flaws have been\Ndiscovered. Most of them have been fixed.
Dialogue: 0,0:08:15.14,0:08:22.34,Default,,0000,0000,0000,,I will talk about some of these flaws\Nlater in the talk. So this is OAuth 2 and
Dialogue: 0,0:08:22.34,0:08:27.63,Default,,0000,0000,0000,,there's also OpenID Connect. OpenID\NConnect is quite new. It's from one and a
Dialogue: 0,0:08:27.63,0:08:34.84,Default,,0000,0000,0000,,half years old and it's an authentication\Nlayer on top of OAuth. So the first
Dialogue: 0,0:08:34.84,0:08:39.33,Default,,0000,0000,0000,,definition or real definition on how you\Nshould use of for authentication, but it
Dialogue: 0,0:08:39.33,0:08:45.35,Default,,0000,0000,0000,,changes the standard also so it can be\Nseen as the protocol on its own, but
Dialogue: 0,0:08:45.35,0:08:49.83,Default,,0000,0000,0000,,OpenID Connect, although despite the name,\Nit's also completely incompatible to
Dialogue: 0,0:08:49.83,0:08:57.22,Default,,0000,0000,0000,,OpenID. And it has also some dynamic\Nfeatures like IdP, Discovery and identity
Dialogue: 0,0:08:57.22,0:09:03.01,Default,,0000,0000,0000,,provider Discovery and stuff like that. So\Nthis leads us to the Web, single-sign-on
Dialogue: 0,0:09:03.01,0:09:09.53,Default,,0000,0000,0000,,chart of confusion. So we have OAuth 1\Nwhich is the marketing predecessor off of
Dialogue: 0,0:09:09.53,0:09:16.58,Default,,0000,0000,0000,,2, but completely incompatible to OAuth 2\Nand OAuth 2 serves as the foundation for
Dialogue: 0,0:09:16.58,0:09:21.47,Default,,0000,0000,0000,,login with Facebook, for authentication\Nand also for OpenID Connect and OpenID
Dialogue: 0,0:09:21.47,0:09:26.42,Default,,0000,0000,0000,,Connect, there is OpenID, which is the\Nmarketing predecessor of OpenID Connect,
Dialogue: 0,0:09:26.42,0:09:33.18,Default,,0000,0000,0000,,but also same here, it's not compatible to\Neach other. And OpenID Connect is used,
Dialogue: 0,0:09:33.18,0:09:43.27,Default,,0000,0000,0000,,for example, by Google. So these are the\Nmost commonly used single-sign-on systems.
Dialogue: 0,0:09:43.27,0:09:49.25,Default,,0000,0000,0000,,There's also some others, for example,\NMozilla Persona. Who of you have heard
Dialogue: 0,0:09:49.25,0:09:59.09,Default,,0000,0000,0000,,about Mozilla persona.? Oh, OK. Around\Nfive percent, more or less. So, the
Dialogue: 0,0:09:59.09,0:10:06.34,Default,,0000,0000,0000,,original name is BrowserID and there the\Nidea was that the email providers become
Dialogue: 0,0:10:06.34,0:10:12.32,Default,,0000,0000,0000,,the identity providers. So this comes from\Nthe thought that for classical website
Dialogue: 0,0:10:12.32,0:10:17.09,Default,,0000,0000,0000,,where you have to register, they send you\Nemails with tokens you can click on to log
Dialogue: 0,0:10:17.09,0:10:23.97,Default,,0000,0000,0000,,into your account and to reset your\Npassword. So your identity, your e-mail
Dialogue: 0,0:10:23.97,0:10:28.81,Default,,0000,0000,0000,,provider already is the kind of identity\Nprovider. So why don't we just use it
Dialogue: 0,0:10:28.81,0:10:35.04,Default,,0000,0000,0000,,directly in the Web? And Mozilla Persona\Nis the first single-sign-on system with
Dialogue: 0,0:10:35.04,0:10:40.90,Default,,0000,0000,0000,,the goal that we have some kind of privacy\Nin the sense that the identity provider
Dialogue: 0,0:10:40.90,0:10:45.87,Default,,0000,0000,0000,,does not learn where you use your\Naccounts. So we will talk about this also
Dialogue: 0,0:10:45.87,0:10:51.15,Default,,0000,0000,0000,,later in this talk. So it was developed by\NMozilla and the first idea was to
Dialogue: 0,0:10:51.15,0:10:58.96,Default,,0000,0000,0000,,integrate this protocol in the browsers,\Nwhich never happened. So they went from
Dialogue: 0,0:10:58.96,0:11:05.25,Default,,0000,0000,0000,,the target to have a pure Web\Nimplementation using just HTML5. And they
Dialogue: 0,0:11:05.25,0:11:13.87,Default,,0000,0000,0000,,also built bridges to OpenID and OAuth 2\Nto get some big identity providers in the
Dialogue: 0,0:11:13.87,0:11:19.45,Default,,0000,0000,0000,,system. But this this whole approach\Nfailed. But it's still interesting if you
Dialogue: 0,0:11:19.45,0:11:27.78,Default,,0000,0000,0000,,want to look for privacy. OK, there are\Nalso some other protocols I haven't talked
Dialogue: 0,0:11:27.78,0:11:32.82,Default,,0000,0000,0000,,about, and now I will hand over to Daniel.
Dialogue: 0,0:11:32.82,0:11:36.08,Default,,0000,0000,0000,,Daniel Fett: So what is this talk all\Nabout?
Dialogue: 0,0:11:36.08,0:11:40.40,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:11:40.40,0:11:45.54,Default,,0000,0000,0000,,Daniel: So what is all talk all about? So\Nwhat we want to do is we want to analyze
Dialogue: 0,0:11:45.54,0:11:50.75,Default,,0000,0000,0000,,where the web mechanisms in this case\Nwebsites and protocols are secure when
Dialogue: 0,0:11:50.75,0:11:55.88,Default,,0000,0000,0000,,they are implemented correctly. So this\Nmeans if we follow all the standards and
Dialogue: 0,0:11:55.88,0:12:01.01,Default,,0000,0000,0000,,all the best practices, on other words:\NAre the standards and protocols that
Dialogue: 0,0:12:01.01,0:12:11.40,Default,,0000,0000,0000,,define the web secure? The current state\Nof the art is that we have a lot of
Dialogue: 0,0:12:11.40,0:12:17.69,Default,,0000,0000,0000,,documents that define some locking\Nmechanism, for example, like OAuth, and we
Dialogue: 0,0:12:17.69,0:12:22.97,Default,,0000,0000,0000,,have an expert or group of experts and\Nthey look at this and after a while they
Dialogue: 0,0:12:22.97,0:12:29.97,Default,,0000,0000,0000,,say, well, this seems kind of OK to me. So\Nthey say it's secure. So this is the
Dialogue: 0,0:12:29.97,0:12:35.19,Default,,0000,0000,0000,,current state of the art. And what we want\Nto do also is part of our research is to
Dialogue: 0,0:12:35.19,0:12:41.78,Default,,0000,0000,0000,,change this. In a way that has been\Nalready successful for other things in
Dialogue: 0,0:12:41.78,0:12:48.43,Default,,0000,0000,0000,,Internet, for example, for TLS. We want to\Ncreate a model of the Web infrastructure
Dialogue: 0,0:12:48.43,0:12:53.47,Default,,0000,0000,0000,,and of Web applications, the former model.\NAnd these models, of course, they are also
Dialogue: 0,0:12:53.47,0:13:02.36,Default,,0000,0000,0000,,always incomplete, but nonetheless useful,\Nas has been shown with TLS 1.3. So we
Dialogue: 0,0:13:02.36,0:13:08.28,Default,,0000,0000,0000,,create this model and then we put a lot of\Nwork into this. And finally, hopefully we
Dialogue: 0,0:13:08.28,0:13:17.68,Default,,0000,0000,0000,,can create proofs of security for\Nmechanisms of our standards. So of course
Dialogue: 0,0:13:17.68,0:13:27.08,Default,,0000,0000,0000,,the hard part is number 2 here, as always.\NSome things our model cannot capture and
Dialogue: 0,0:13:27.08,0:13:32.45,Default,,0000,0000,0000,,we don't want to capture this. So, for\Nexample, phishing attacks or clickjacking
Dialogue: 0,0:13:32.45,0:13:37.21,Default,,0000,0000,0000,,attacks or just stupid users. Let's send\Nthat password to the attacker. These are
Dialogue: 0,0:13:37.21,0:13:42.75,Default,,0000,0000,0000,,things that are out of the scope of the\Nstuff that we are looking at. In the same
Dialogue: 0,0:13:42.75,0:13:53.22,Default,,0000,0000,0000,,manner, compromised browsers or\Ncompromised databases and so on. When we
Dialogue: 0,0:13:53.22,0:13:59.54,Default,,0000,0000,0000,,have this model for a Web application, one\Nimportant question and maybe the most
Dialogue: 0,0:13:59.54,0:14:04.77,Default,,0000,0000,0000,,important question is what is security and\Nwhat is privacy if you want to look at
Dialogue: 0,0:14:04.77,0:14:10.63,Default,,0000,0000,0000,,privacy as well? So we have to define this\Nand luckily we can define this if we have
Dialogue: 0,0:14:10.63,0:14:15.50,Default,,0000,0000,0000,,a formal model like we have and a\Nfollowing, of course, I'm not going to
Dialogue: 0,0:14:15.50,0:14:20.78,Default,,0000,0000,0000,,present all the formal stuff, this is\Nboring. Therefore, I have a high level
Dialogue: 0,0:14:20.78,0:14:25.09,Default,,0000,0000,0000,,overview of what authentication\Nproperties, for example, look like.
Dialogue: 0,0:14:25.09,0:14:30.89,Default,,0000,0000,0000,,Authentication in the Web single-sign-on\Nsystem means that an attacker that even
Dialogue: 0,0:14:30.89,0:14:36.25,Default,,0000,0000,0000,,has full control over the network say NSA\Nshould not be able to use a service of a
Dialogue: 0,0:14:36.25,0:14:41.37,Default,,0000,0000,0000,,relying party as an honest user. So the\NNSA should be unable to log into my
Dialogue: 0,0:14:41.37,0:14:48.17,Default,,0000,0000,0000,,account at least. Yeah, if they're not\Nforcing the owner of relying party or
Dialogue: 0,0:14:48.17,0:14:57.40,Default,,0000,0000,0000,,something. And this is an obvious property\Nthere's a slightly less obvious property,
Dialogue: 0,0:14:57.40,0:15:01.87,Default,,0000,0000,0000,,which says that an attacker should not be\Nable to authenticate an honest browser to
Dialogue: 0,0:15:01.87,0:15:09.65,Default,,0000,0000,0000,,relying party as the attacker. So the\Nattacker should be unable to force Alice's
Dialogue: 0,0:15:09.65,0:15:14.10,Default,,0000,0000,0000,,browser to be locked in under the\Nattackers identity. This is a property
Dialogue: 0,0:15:14.10,0:15:18.79,Default,,0000,0000,0000,,that is often also called session fixation\Nor session swapping, because if the
Dialogue: 0,0:15:18.79,0:15:22.76,Default,,0000,0000,0000,,attacker would be able to do this, he\Ncould, for example, force me to be locked
Dialogue: 0,0:15:22.76,0:15:28.14,Default,,0000,0000,0000,,in at some search engine. And if I then\Nsearch something with a search engine and
Dialogue: 0,0:15:28.14,0:15:32.59,Default,,0000,0000,0000,,I'm locked into the attackers account,\Nthen the attacker could be able to read
Dialogue: 0,0:15:32.59,0:15:37.15,Default,,0000,0000,0000,,what I'm searching for in this search\Nengine. OK, so these are the
Dialogue: 0,0:15:37.15,0:15:42.42,Default,,0000,0000,0000,,authentication properties. Then we also\Nhave another property that is important,
Dialogue: 0,0:15:42.42,0:15:49.97,Default,,0000,0000,0000,,namely session integrity . Session\Nintegrity means that if the relying party
Dialogue: 0,0:15:49.97,0:15:54.62,Default,,0000,0000,0000,,acts on Alice's behalf at the identity\Nprovider or retrieves Alice's data at the
Dialogue: 0,0:15:54.62,0:16:02.94,Default,,0000,0000,0000,,identity provider then Alice explicitly\Nexpresses her consent to log in at this
Dialogue: 0,0:16:02.94,0:16:12.02,Default,,0000,0000,0000,,ruling party. So. There's a session\Nintegrity and a third property that we
Dialogue: 0,0:16:12.02,0:16:19.00,Default,,0000,0000,0000,,have, is privacy and privacy in this case\Nmeans that a malicious identity provider
Dialogue: 0,0:16:19.00,0:16:25.98,Default,,0000,0000,0000,,should not be able to tell whether the\Nuser logs in at the wrong party A or party
Dialogue: 0,0:16:25.98,0:16:33.90,Default,,0000,0000,0000,,B. So, for example, if OAuth would have\Nprivacy, which it doesn't, then Facebook
Dialogue: 0,0:16:33.90,0:16:36.67,Default,,0000,0000,0000,,would be unable to tell whether I log in\Nat, say, Wikipedia or myfavoritebeer.com.
Dialogue: 0,0:16:36.67,0:16:46.00,Default,,0000,0000,0000,,There are also other notions of privacy,\Nwhich we, however, will not look at in
Dialogue: 0,0:16:46.00,0:16:59.27,Default,,0000,0000,0000,,this talk.
Dialogue: 0,0:16:59.27,0:17:10.18,Default,,0000,0000,0000,,Guido: OK. Let's start with a closer look\Nto OAuth when I say OAuth, I always mean
Dialogue: 0,0:17:10.18,0:17:21.84,Default,,0000,0000,0000,,OAuth 2 not the older OAuth 1. So OAuth 2\Nis mainly defined in RFC6749 and also some
Dialogue: 0,0:17:21.84,0:17:30.65,Default,,0000,0000,0000,,other RFC's and some other documents.\NOAuth itself has four different modes it
Dialogue: 0,0:17:30.65,0:17:35.36,Default,,0000,0000,0000,,can run. And so there is the Implicit\NMode, the Authorization Code Mode, the
Dialogue: 0,0:17:35.36,0:17:41.87,Default,,0000,0000,0000,,Resource Owner Password Credentials mode,\Nthe Client Credentials mode and all these
Dialogue: 0,0:17:41.87,0:17:50.90,Default,,0000,0000,0000,,modes can have so options, which I won't\Nlist here. And out of these four modes,
Dialogue: 0,0:17:50.90,0:17:55.82,Default,,0000,0000,0000,,the first two Implicit Mode and the\NAuthorization Code Mode are the most
Dialogue: 0,0:17:55.82,0:18:02.88,Default,,0000,0000,0000,,common ones. So let's have a closer look\Nat these modes. So the Implicit Mode works
Dialogue: 0,0:18:02.88,0:18:08.80,Default,,0000,0000,0000,,like this. Here we have an example with\Nsome random relying party and Facebook as
Dialogue: 0,0:18:08.80,0:18:13.61,Default,,0000,0000,0000,,the identity provider. So first you say I\Nwant to login with Facebook at your
Dialogue: 0,0:18:13.61,0:18:20.67,Default,,0000,0000,0000,,relying party, then your browser gets\Nredirected to Facebook. Facebook prompts
Dialogue: 0,0:18:20.67,0:18:25.43,Default,,0000,0000,0000,,you for your authentication data or for\Nsome confirmation if you're already logged
Dialogue: 0,0:18:25.43,0:18:36.88,Default,,0000,0000,0000,,in at Facebook. And then Facebook issues a\Ntoken that's called the access token. And
Dialogue: 0,0:18:36.88,0:18:41.21,Default,,0000,0000,0000,,Facebook redirects your browser back to\Nthe relying party and puts the access
Dialogue: 0,0:18:41.21,0:18:49.53,Default,,0000,0000,0000,,token in the URI. And then for some\Ntechnical reasons, we need some additional
Dialogue: 0,0:18:49.53,0:19:00.18,Default,,0000,0000,0000,,steps to retrieve the access token from\Nthe URI because it's in the fragment part.
Dialogue: 0,0:19:00.18,0:19:05.40,Default,,0000,0000,0000,,And then finally, the relying party gets\Nto retrieve this access token. And now
Dialogue: 0,0:19:05.40,0:19:13.29,Default,,0000,0000,0000,,with this access token, an access token is\Nthe same basically the same thing as in
Dialogue: 0,0:19:13.29,0:19:19.09,Default,,0000,0000,0000,,the in this first high level overview when\NI just talked about tokens an access token
Dialogue: 0,0:19:19.09,0:19:25.09,Default,,0000,0000,0000,,is such a token, which gives the relying\Nparty access to the user's account at
Dialogue: 0,0:19:25.09,0:19:31.91,Default,,0000,0000,0000,,Facebook. And now the relying party can\Nretrieve data on the user's behalf at
Dialogue: 0,0:19:31.91,0:19:37.81,Default,,0000,0000,0000,,Facebook or it can retrieve and user\Nidentifier and then consider this user to
Dialogue: 0,0:19:37.81,0:19:44.87,Default,,0000,0000,0000,,be logged in and issue, for example, some\Ncookie. So this is the Implicit Mode.
Dialogue: 0,0:19:44.87,0:19:52.88,Default,,0000,0000,0000,,There is also the Authorization Code Mode\Nthere. Things start similar. The user says
Dialogue: 0,0:19:52.88,0:19:58.01,Default,,0000,0000,0000,,I want to login with Facebook, gets\Nredirected to Facebook, authenticates at
Dialogue: 0,0:19:58.01,0:20:02.68,Default,,0000,0000,0000,,Facebook and then Facebook, instead of\Nissuing an access token, it issues the so-
Dialogue: 0,0:20:02.68,0:20:09.30,Default,,0000,0000,0000,,called authorization code and the relying\Nparty then takes the authorization code
Dialogue: 0,0:20:09.30,0:20:14.82,Default,,0000,0000,0000,,and redeems it for an access token\Ndirectly at Facebook. So we have here some
Dialogue: 0,0:20:14.82,0:20:21.83,Default,,0000,0000,0000,,one intermediate step for this\Nauthorization code and then the access
Dialogue: 0,0:20:21.83,0:20:29.39,Default,,0000,0000,0000,,token, the relying party retrieved, it can\Nthen use to act on the user's behalf at
Dialogue: 0,0:20:29.39,0:20:37.71,Default,,0000,0000,0000,,Facebook or consider the user to be logged\Nin. So let's talk about selected attacks
Dialogue: 0,0:20:37.71,0:20:50.92,Default,,0000,0000,0000,,on OAuth. First, let's talk a bit about\Nknown attacks, there are attacks like the
Dialogue: 0,0:20:50.92,0:20:57.80,Default,,0000,0000,0000,,so-called cut and paste attacks where you\Nreuse some of these tokens like access
Dialogue: 0,0:20:57.80,0:21:02.81,Default,,0000,0000,0000,,token, authorization code, or there are\Nalso some other tokens, which I haven't
Dialogue: 0,0:21:02.81,0:21:10.39,Default,,0000,0000,0000,,talked about. So I left out some details\Nbefore. It's about reusing these tokens
Dialogue: 0,0:21:10.39,0:21:18.38,Default,,0000,0000,0000,,from different flows, mixing them into a\Nnew flow and then break the system. So
Dialogue: 0,0:21:18.38,0:21:26.00,Default,,0000,0000,0000,,there are a lot of cut and paste attacks\Nknown. And there OAuth working group is
Dialogue: 0,0:21:26.00,0:21:33.83,Default,,0000,0000,0000,,continuously giving tries on how to\Nprevent these cut-and-paste attacks.
Dialogue: 0,0:21:33.83,0:21:39.48,Default,,0000,0000,0000,,Another problem is if you don't use HTTPS,\Nthen you are screwed because a man in the
Dialogue: 0,0:21:39.48,0:21:45.51,Default,,0000,0000,0000,,middle can easily read everything out, all\Nthe tokens that are exchanged. So if you
Dialogue: 0,0:21:45.51,0:21:51.49,Default,,0000,0000,0000,,are in some Wi-Fi and the guy next to you\Nis sniffing on the Wi-Fi, you log in and
Dialogue: 0,0:21:51.49,0:21:59.06,Default,,0000,0000,0000,,don't use HTTPS because some developers\Nforgot that there is the something called
Dialogue: 0,0:21:59.06,0:22:08.15,Default,,0000,0000,0000,,HTTPS, then basically the whole thing is\Nscrewed. And also, if you just rely on
Dialogue: 0,0:22:08.15,0:22:15.21,Default,,0000,0000,0000,,cookies, then you're also screwed because\Ncookies lack integrity. It's very easy to
Dialogue: 0,0:22:15.21,0:22:22.46,Default,,0000,0000,0000,,just inject cookies into your browser over\NHTTP, and then these cookies will later
Dialogue: 0,0:22:22.46,0:22:33.64,Default,,0000,0000,0000,,also be used over HTTPS. So the cookies\Nare also not a good thing to rely on. So
Dialogue: 0,0:22:33.64,0:22:40.44,Default,,0000,0000,0000,,let's talk about some attacks we have\Nfound in our research. There is the 307
Dialogue: 0,0:22:40.44,0:22:54.52,Default,,0000,0000,0000,,redirect attack and it works like this.\NFirst, we have some regular OAuth flow. In
Dialogue: 0,0:22:54.52,0:22:59.73,Default,,0000,0000,0000,,this OAuth flow, if you have a closer look\Nat what happens here and step two to four,
Dialogue: 0,0:22:59.73,0:23:05.05,Default,,0000,0000,0000,,we have the user authentication. And after\Nthis authentication, the user gets
Dialogue: 0,0:23:05.05,0:23:11.84,Default,,0000,0000,0000,,redirected back to relying party. If you\Nlook more into the details of these
Dialogue: 0,0:23:11.84,0:23:20.67,Default,,0000,0000,0000,,requests, so first you have this request\Nwhere you go to your identity provider and
Dialogue: 0,0:23:20.67,0:23:26.80,Default,,0000,0000,0000,,ask, I have started OAuth flow there. So\Nyou just came from the relying party where
Dialogue: 0,0:23:26.80,0:23:32.14,Default,,0000,0000,0000,,you want to log in and click on that\Nbutton, log in with this IP, you get
Dialogue: 0,0:23:32.14,0:23:38.10,Default,,0000,0000,0000,,redirected and then your browser contacts\Nthis identity provider here I have been
Dialogue: 0,0:23:38.10,0:23:47.39,Default,,0000,0000,0000,,redirected to you in OAuth flow. Please\Nauthenticate the user. So this is a step
Dialogue: 0,0:23:47.39,0:23:53.52,Default,,0000,0000,0000,,2.a then your identity provider returns\Nsome form where you have to enter your
Dialogue: 0,0:23:53.52,0:23:58.35,Default,,0000,0000,0000,,username and password usually, and then\Nyou enter username and password and these
Dialogue: 0,0:23:58.35,0:24:03.69,Default,,0000,0000,0000,,are sent over to the identity provider.\NAnd now if this identity provider
Dialogue: 0,0:24:03.69,0:24:10.78,Default,,0000,0000,0000,,redirects you back to the relying party\Nand uses the wrong HTTP location redirect
Dialogue: 0,0:24:10.78,0:24:18.63,Default,,0000,0000,0000,,method for this, namely the 307 method,\Nthen the following happens. The browsers
Dialogue: 0,0:24:18.63,0:24:23.90,Default,,0000,0000,0000,,instructed to just repost all of your\Ncredentials. So if you're logging in that
Dialogue: 0,0:24:23.90,0:24:31.06,Default,,0000,0000,0000,,some malicious relying party, that relying\Nparty gets your username and password. So
Dialogue: 0,0:24:31.06,0:24:36.88,Default,,0000,0000,0000,,this happens if you use 307, redirect.\NFortunately, we didn't find any identity
Dialogue: 0,0:24:36.88,0:24:43.00,Default,,0000,0000,0000,,provider in the wild to actually use 307.\NBut you can never exclude that there is
Dialogue: 0,0:24:43.00,0:24:49.73,Default,,0000,0000,0000,,some implementation which makes actually\Nuse of this location redirect method.
Dialogue: 0,0:24:49.73,0:24:54.97,Default,,0000,0000,0000,,Also, if you look at the standard, how\Nthese are defined, it's not always clear
Dialogue: 0,0:24:54.97,0:25:02.41,Default,,0000,0000,0000,,which redirects method has which details\Nand behavior. And also the OAuth working
Dialogue: 0,0:25:02.41,0:25:07.46,Default,,0000,0000,0000,,group didn't think about this. So in their\Nstandard, their write, you just use any
Dialogue: 0,0:25:07.46,0:25:16.35,Default,,0000,0000,0000,,method. And surely the mitigation here is\Ndon't use 307, for example, use 303
Dialogue: 0,0:25:16.35,0:25:22.19,Default,,0000,0000,0000,,instead. So the next attack is the\Nidentity provider mix-up attack. I will
Dialogue: 0,0:25:22.19,0:25:30.77,Default,,0000,0000,0000,,present this in Implicit Mode and only one\Nvariant of this attack. So here in this
Dialogue: 0,0:25:30.77,0:25:38.69,Default,,0000,0000,0000,,attack, we have to have the following\Nsetting. From step two on all these
Dialogue: 0,0:25:38.69,0:25:44.29,Default,,0000,0000,0000,,requests are usually encrypted. But the\Nvery, very first request there, we cannot
Dialogue: 0,0:25:44.29,0:25:50.40,Default,,0000,0000,0000,,be sure it is encrypted because a lot of\Nrelying parties when you go to the
Dialogue: 0,0:25:50.40,0:25:57.25,Default,,0000,0000,0000,,website, you go over HTTP. And this the\Nvery first information we just click I
Dialogue: 0,0:25:57.25,0:26:02.72,Default,,0000,0000,0000,,want to use Facebook to log in there. You\Ncould easily assume this is not a
Dialogue: 0,0:26:02.72,0:26:10.48,Default,,0000,0000,0000,,sensitive information. So this a very\Nfirst request goes off an unencrypted or
Dialogue: 0,0:26:10.48,0:26:16.05,Default,,0000,0000,0000,,if you, for example, consider other\Nattacks like TLS stripping, then you also
Dialogue: 0,0:26:16.05,0:26:25.46,Default,,0000,0000,0000,,cannot guarantee that this request is\Nencrypted. So now for an attacker who, for
Dialogue: 0,0:26:25.46,0:26:31.76,Default,,0000,0000,0000,,example, sits in a same Wi-Fi network as\Nyou, so probably the guy next to you could
Dialogue: 0,0:26:31.76,0:26:37.36,Default,,0000,0000,0000,,easily mount the attack as follows. So\Nwhen your browser sends this request to
Dialogue: 0,0:26:37.36,0:26:44.37,Default,,0000,0000,0000,,relying party, login with Facebook, the\Nattacker can easily change this and change
Dialogue: 0,0:26:44.37,0:26:51.37,Default,,0000,0000,0000,,its to just use the identity provider that\Nis run by the attacker. Remember, you can
Dialogue: 0,0:26:51.37,0:26:56.03,Default,,0000,0000,0000,,have a lot of different options of\Nidentity providers and with some
Dialogue: 0,0:26:56.03,0:27:04.53,Default,,0000,0000,0000,,extension, this can also be extended\Ndynamically just by entering some domains.
Dialogue: 0,0:27:04.53,0:27:09.18,Default,,0000,0000,0000,,And then the relying party thinks, OK,\Nthat user wants to use the attacker
Dialogue: 0,0:27:09.18,0:27:17.92,Default,,0000,0000,0000,,identity provider. It answers with the\Nredirect to the attackers web page. But
Dialogue: 0,0:27:17.92,0:27:21.53,Default,,0000,0000,0000,,now the as the attacker attackers still\Nsits in the middle, he can just change it
Dialogue: 0,0:27:21.53,0:27:28.99,Default,,0000,0000,0000,,back to Facebook. So the old dance\Ncontinues as usual. You go to Facebook,
Dialogue: 0,0:27:28.99,0:27:33.71,Default,,0000,0000,0000,,authenticate there, you get redirected\Nback. There's probably some access token
Dialogue: 0,0:27:33.71,0:27:40.84,Default,,0000,0000,0000,,and then eventually the relying party\Nretrieve this access token and wants to
Dialogue: 0,0:27:40.84,0:27:47.02,Default,,0000,0000,0000,,use this access token. So what happens? It\Nwon't use this access token at Facebook,
Dialogue: 0,0:27:47.02,0:27:51.88,Default,,0000,0000,0000,,but at the relying at the attacker\Ninstead, because it still thinks that the
Dialogue: 0,0:27:51.88,0:27:57.55,Default,,0000,0000,0000,,attacker is for the identity provider that\Nis used here. So in practice, if you want
Dialogue: 0,0:27:57.55,0:28:03.32,Default,,0000,0000,0000,,to mount this attack, then you have to\Ntake care of more details, like when you
Dialogue: 0,0:28:03.32,0:28:08.30,Default,,0000,0000,0000,,want to break authentication instead of\Nauthorization. So in the version I just
Dialogue: 0,0:28:08.30,0:28:13.78,Default,,0000,0000,0000,,presented, the attacker gets the token can\Nact on the user's behalf at Facebook or at
Dialogue: 0,0:28:13.78,0:28:20.47,Default,,0000,0000,0000,,some other identity provider that he was\Noff. So this is not limited for Facebook,
Dialogue: 0,0:28:20.47,0:28:26.51,Default,,0000,0000,0000,,but for authentication of the relying\Nparty. There are some other further steps
Dialogue: 0,0:28:26.51,0:28:31.76,Default,,0000,0000,0000,,needed. But there's also there are also\Nsome other details that have to be taken
Dialogue: 0,0:28:31.76,0:28:37.96,Default,,0000,0000,0000,,care of, like client identifiers, which\Nare used by relying parties to identify
Dialogue: 0,0:28:37.96,0:28:44.16,Default,,0000,0000,0000,,themselves to identity providers, the same\Nfor client credentials, which are
Dialogue: 0,0:28:44.16,0:28:50.99,Default,,0000,0000,0000,,optional, by the way, and an OpenID\NConnect the layer on top of OAuth. If this
Dialogue: 0,0:28:50.99,0:28:56.71,Default,,0000,0000,0000,,is used, then you need to take care about\Nsome other stuff, like the switching of
Dialogue: 0,0:28:56.71,0:29:02.99,Default,,0000,0000,0000,,some signatures or exchanging some\Nsignatures and so on. But it's still
Dialogue: 0,0:29:02.99,0:29:08.47,Default,,0000,0000,0000,,possible so that we successfully attacked\Nreal world applications. And this
Dialogue: 0,0:29:08.47,0:29:12.39,Default,,0000,0000,0000,,definitely works. And there are also some\Nvariants that do not rely on that first
Dialogue: 0,0:29:12.39,0:29:19.73,Default,,0000,0000,0000,,request going over HTTPS. But explaining\Nall the variance would take a whole talk
Dialogue: 0,0:29:19.73,0:29:28.26,Default,,0000,0000,0000,,on its own, so we now skip this and talk\Nabout mitigation. So the mitigation we
Dialogue: 0,0:29:28.26,0:29:35.23,Default,,0000,0000,0000,,propose is quite simple. So the the one\Nproblem is you're in step three. This
Dialogue: 0,0:29:35.23,0:29:41.75,Default,,0000,0000,0000,,access token is just some opaque string.\NRelying party cannot see who issued that
Dialogue: 0,0:29:41.75,0:29:46.58,Default,,0000,0000,0000,,access token. So it needs some further\Ninformation carried along with this
Dialogue: 0,0:29:46.58,0:29:51.91,Default,,0000,0000,0000,,system. And that is who is the identity\Nprovider, which issued this access token.
Dialogue: 0,0:29:51.91,0:29:58.91,Default,,0000,0000,0000,,And if you have this information carried\Nalong and then the relying party can
Dialogue: 0,0:29:58.91,0:30:05.39,Default,,0000,0000,0000,,easily detect this attack and see that\Nthere is a mismatch between step five to
Dialogue: 0,0:30:05.39,0:30:11.66,Default,,0000,0000,0000,,the one in step 1.a, where relying line\Nparty received the message the attacker's
Dialogue: 0,0:30:11.66,0:30:15.97,Default,,0000,0000,0000,,identity provider is to be used and in\Nfive it gets the message she has access
Dialogue: 0,0:30:15.97,0:30:20.83,Default,,0000,0000,0000,,token and it's from Facebook. So there's a\Nmismatch and this whole flow can be
Dialogue: 0,0:30:20.83,0:30:31.14,Default,,0000,0000,0000,,aborted without the attack being\Nsuccessful. So this is the mitigation we
Dialogue: 0,0:30:31.14,0:30:36.25,Default,,0000,0000,0000,,talk to the OAuth working group at the\NIETF, so they invited us to a kind of
Dialogue: 0,0:30:36.25,0:30:43.43,Default,,0000,0000,0000,,emergency meeting to discuss this attack\Nand we scheduled public disclosure of
Dialogue: 0,0:30:43.43,0:30:50.43,Default,,0000,0000,0000,,these attacks. So at the beginning of this\Nyear, in June, we had a district at
Dialogue: 0,0:30:50.43,0:30:55.24,Default,,0000,0000,0000,,security workshop which took place in\NJune. New RFC, with this service the
Dialogue: 0,0:30:55.24,0:31:02.56,Default,,0000,0000,0000,,mitigations is in preparation. And also\Nthe working group is interested in the
Dialogue: 0,0:31:02.56,0:31:10.93,Default,,0000,0000,0000,,kind of formal analysis we do to this, we\Ncarry out for these kind of standards. So
Dialogue: 0,0:31:10.93,0:31:19.24,Default,,0000,0000,0000,,to sum up, the security for OAuth 2 these\Nfixes applied and there are no
Dialogue: 0,0:31:19.24,0:31:27.46,Default,,0000,0000,0000,,implementation errors, then we can say\Nthat in terms of security OAuth 2 is quite
Dialogue: 0,0:31:27.46,0:31:36.56,Default,,0000,0000,0000,,good. We have formal proof in our model\Nfor this, but regarding privacy OAuth 2
Dialogue: 0,0:31:36.56,0:31:41.80,Default,,0000,0000,0000,,does not provide any privacy at all.
Dialogue: 0,0:31:41.80,0:31:48.47,Default,,0000,0000,0000,,David: Speaking about privacy, we\Nmentioned earlier already that there was a
Dialogue: 0,0:31:48.47,0:31:54.42,Default,,0000,0000,0000,,single-sign-on system that tried to\Nprovide privacy, namely BrowserID alias
Dialogue: 0,0:31:54.42,0:31:59.75,Default,,0000,0000,0000,,Mozilla Persona. So as we already said\Nbefore, this is a Web based single-sign-on
Dialogue: 0,0:31:59.75,0:32:04.89,Default,,0000,0000,0000,,system with design goals of having no\Ncentral authority and provide better
Dialogue: 0,0:32:04.89,0:32:14.21,Default,,0000,0000,0000,,privacy. Spoiler alert: they failed at\Nboth. So how does BrowserID work? So let's
Dialogue: 0,0:32:14.21,0:32:19.87,Default,,0000,0000,0000,,have a look at this on a very high level\Nfirst. So like Guido already said in
Dialogue: 0,0:32:19.87,0:32:25.44,Default,,0000,0000,0000,,browser I.D., the mail provider is the\Nidentity provider. So we have a user,
Dialogue: 0,0:32:25.44,0:32:32.21,Default,,0000,0000,0000,,Alice, alice@mailprovider.com and in the\Nfirst phase when using BrowserID, she does
Dialogue: 0,0:32:32.21,0:32:37.88,Default,,0000,0000,0000,,the following, she goes to her identity\Nprovider and first creates a
Dialogue: 0,0:32:37.88,0:32:43.83,Default,,0000,0000,0000,,public/private keypad. And then she sends\Nthe public key in a document with an
Dialogue: 0,0:32:43.83,0:32:50.66,Default,,0000,0000,0000,,identity to the mal provider and the mail\Nprovider then signs this document. And
Dialogue: 0,0:32:50.66,0:32:56.07,Default,,0000,0000,0000,,this creates the so-called user\Ncertificate. And this certificate is then
Dialogue: 0,0:32:56.07,0:33:02.22,Default,,0000,0000,0000,,sent back to Alice. Now, in the second\Nphase, if Alice wants to actually log in
Dialogue: 0,0:33:02.22,0:33:09.62,Default,,0000,0000,0000,,that some website and then she does the\Nfollowing she creates and another document
Dialogue: 0,0:33:09.62,0:33:14.35,Default,,0000,0000,0000,,containing the identity of the website\Nwhere she wants to log in, say Wikipedia,
Dialogue: 0,0:33:14.35,0:33:24.23,Default,,0000,0000,0000,,and to do so, she signs the identity of\NWikipedia with her own private key. And
Dialogue: 0,0:33:24.23,0:33:28.20,Default,,0000,0000,0000,,this creates the so-called identity\Nassertion. Now, Alice sends both documents
Dialogue: 0,0:33:28.20,0:33:34.06,Default,,0000,0000,0000,,to Wikipedia and Wikipedia can then, of\Ncourse, check these documents, because
Dialogue: 0,0:33:34.06,0:33:39.87,Default,,0000,0000,0000,,Wikipedia can check first it can retrieve\Nthe public key of the mail provider, can
Dialogue: 0,0:33:39.87,0:33:46.50,Default,,0000,0000,0000,,check the user certificate, and then also\Ncan check the identity assertion. And
Dialogue: 0,0:33:46.50,0:33:52.77,Default,,0000,0000,0000,,yeah, then Wikipedia can consider Alice to\Nbe logged in. So this was the basic idea
Dialogue: 0,0:33:52.77,0:33:58.31,Default,,0000,0000,0000,,of BrowserID, which is quite nice and\Nclean and simple. And then they started to
Dialogue: 0,0:33:58.31,0:34:04.35,Default,,0000,0000,0000,,implement this using just the browser\Nfeatures, including all the workarounds
Dialogue: 0,0:34:04.35,0:34:10.26,Default,,0000,0000,0000,,for the Internet Explorer and so on and so\Non. And they ended up with a quite
Dialogue: 0,0:34:10.26,0:34:18.68,Default,,0000,0000,0000,,complicated system. So here we have on the\Nleft side Alice's browser two Windows,
Dialogue: 0,0:34:18.68,0:34:23.60,Default,,0000,0000,0000,,namely Wikipedia and the login dialog,\Nwhich is provided by a central authority
Dialogue: 0,0:34:23.60,0:34:29.82,Default,,0000,0000,0000,,which they try to avoid login.persona.org\Nand inside both of these windows and other
Dialogue: 0,0:34:29.82,0:34:34.92,Default,,0000,0000,0000,,iframes and inside one of these iframes,\Nthat's another iframe. And on the right we
Dialogue: 0,0:34:34.92,0:34:39.80,Default,,0000,0000,0000,,have the servers. So the relying party,\Nthe identity provider and the central
Dialogue: 0,0:34:39.80,0:34:46.30,Default,,0000,0000,0000,,authority login.persona.org. And just to\Ngive you an idea of how complex the system
Dialogue: 0,0:34:46.30,0:34:53.32,Default,,0000,0000,0000,,ended up, they all talk to each other\Nusing HTTP requests, but also using
Dialogue: 0,0:34:53.32,0:34:59.99,Default,,0000,0000,0000,,postMessages and also using XML-HTTP\Nrequests. And as you can see, the system
Dialogue: 0,0:34:59.99,0:35:08.37,Default,,0000,0000,0000,,became quite complex. To add even more\Ncomplexity, they did the following. They
Dialogue: 0,0:35:08.37,0:35:11.88,Default,,0000,0000,0000,,thought, well, some users, they are\Nalready using Gmail or Yahoo! So let's
Dialogue: 0,0:35:11.88,0:35:19.29,Default,,0000,0000,0000,,provide some nice. Yeah. Interface for\Nthem. They provided the so-called identity
Dialogue: 0,0:35:19.29,0:35:25.05,Default,,0000,0000,0000,,bridge specifically for Gmail and Yahoo!\NWhich at the time supported OpenID
Dialogue: 0,0:35:25.05,0:35:31.21,Default,,0000,0000,0000,,authentication only. And they created two\Nnew servers, the so-called bridging
Dialogue: 0,0:35:31.21,0:35:38.62,Default,,0000,0000,0000,,servers, one for Gmail called Sideshow and\Nthe other one for Yahoo! Called BigTent.
Dialogue: 0,0:35:38.62,0:35:45.65,Default,,0000,0000,0000,,Now, the user authenticates, authenticates\Nto the bridging server, using OpenID and
Dialogue: 0,0:35:45.65,0:35:54.82,Default,,0000,0000,0000,,then a bridging server has an interface to\Nthe standard BrowserID interface. So one
Dialogue: 0,0:35:54.82,0:35:59.12,Default,,0000,0000,0000,,problem was that OpenID identities, they\Nare not email addresses. And so in OpenID
Dialogue: 0,0:35:59.12,0:36:06.11,Default,,0000,0000,0000,,you add an attribute, which is called the\Nemail attribute. And, um, we're talking
Dialogue: 0,0:36:06.11,0:36:11.64,Default,,0000,0000,0000,,about this email attribute in a minute. So\Nlet's have a look at how these identity
Dialogue: 0,0:36:11.64,0:36:17.52,Default,,0000,0000,0000,,breaches work. We are not going into all\Nthe details of the BrowserID or Persona
Dialogue: 0,0:36:17.52,0:36:21.28,Default,,0000,0000,0000,,protocol because this would be too\Ncomplicated. But the identity bridge is
Dialogue: 0,0:36:21.28,0:36:28.91,Default,,0000,0000,0000,,interesting and also important for some of\Nthe attacks that we found. So in the
Dialogue: 0,0:36:28.91,0:36:32.63,Default,,0000,0000,0000,,identity bridge the following happens, so\Nhere on the left, we have Alice's browser
Dialogue: 0,0:36:32.63,0:36:38.25,Default,,0000,0000,0000,,and in the middle we have Sideshow service\Nidentity bridge and on the right side, we
Dialogue: 0,0:36:38.25,0:36:44.89,Default,,0000,0000,0000,,have Gmail, which could also be Yahoo in\Nthis case. But let's say it's Gmail. So
Dialogue: 0,0:36:44.89,0:36:51.80,Default,,0000,0000,0000,,first, the user says that she wants to log\Nin at Sideshow and then Sideshow sends an
Dialogue: 0,0:36:51.80,0:36:59.31,Default,,0000,0000,0000,,OpenID request requesting the email\Nattribute signed from Gmail. This request
Dialogue: 0,0:36:59.31,0:37:05.23,Default,,0000,0000,0000,,is then forwarded to Gmail. Gmail sees the\Nrequest, the user logs in a Gmail for
Dialogue: 0,0:37:05.23,0:37:12.25,Default,,0000,0000,0000,,authentication. And then Gmail creates\Nthis OpenID assertion, which contains the
Dialogue: 0,0:37:12.25,0:37:17.79,Default,,0000,0000,0000,,signed email address attribute for Alice\Nand as you can see, this is all in the
Dialogue: 0,0:37:17.79,0:37:25.68,Default,,0000,0000,0000,,green box. So all properly signed. Nice.\NAnd now Alice's browser redirects this
Dialogue: 0,0:37:25.68,0:37:31.85,Default,,0000,0000,0000,,document to Sideshow. Now Sideshow doesn't\Ncheck the contents of this decision for
Dialogue: 0,0:37:31.85,0:37:39.33,Default,,0000,0000,0000,,itself. Instead, it sends these things to\NGmail, Gmail checks everything that is
Dialogue: 0,0:37:39.33,0:37:45.20,Default,,0000,0000,0000,,signed. And Tells Sideshow, yes, this\Ndocument looks correct to me, everything
Dialogue: 0,0:37:45.20,0:37:51.67,Default,,0000,0000,0000,,that was signed was signed by me and was\Nnot tampered with. Then Sideshow looks at
Dialogue: 0,0:37:51.67,0:37:56.78,Default,,0000,0000,0000,,the document and sees Alice wanted to log\Nin. So this must be the user, must be
Dialogue: 0,0:37:56.78,0:38:04.29,Default,,0000,0000,0000,,Alice now and provides a cookie because\Nthe user is now logged in as Alice. So
Dialogue: 0,0:38:04.29,0:38:12.04,Default,,0000,0000,0000,,far, simple. Now for some of the attacks\Nthat we found. First attack, identity
Dialogue: 0,0:38:12.04,0:38:18.63,Default,,0000,0000,0000,,forgery. So here we have essentially the\Nsame that we saw before, the same setting,
Dialogue: 0,0:38:18.63,0:38:24.00,Default,,0000,0000,0000,,except now we don't have Alice's Browser\Non the left. We have the attackers browser
Dialogue: 0,0:38:24.00,0:38:30.53,Default,,0000,0000,0000,,on the left. The attacker can go to\NSideshow and say, I want to sign in. Now
Dialogue: 0,0:38:30.53,0:38:37.79,Default,,0000,0000,0000,,Sideshow, sends this OpenID request to the\Nattacker and it can change this request,
Dialogue: 0,0:38:37.79,0:38:43.96,Default,,0000,0000,0000,,the attacker can just remove the request\Nfor the email attribute from this request.
Dialogue: 0,0:38:43.96,0:38:51.79,Default,,0000,0000,0000,,Which is still a valid OpenID request.\NGmail sees this request, and now the
Dialogue: 0,0:38:51.79,0:38:56.05,Default,,0000,0000,0000,,attacker logs in. The attacker doesn't\Nhave Alice's user data so the attacker
Dialogue: 0,0:38:56.05,0:39:03.33,Default,,0000,0000,0000,,just logs in with his own credentials. And\Nnow Gmail creates an automatic assertion
Dialogue: 0,0:39:03.33,0:39:10.56,Default,,0000,0000,0000,,containing the signed attribute, which was\Nrequested, which was nothing. So
Dialogue: 0,0:39:10.56,0:39:16.43,Default,,0000,0000,0000,,essentially, the document is empty, at\Nleast without any email address. Now, the
Dialogue: 0,0:39:16.43,0:39:23.80,Default,,0000,0000,0000,,attacker can simply add a new attribute to\Nthis document containing an email address
Dialogue: 0,0:39:23.80,0:39:31.33,Default,,0000,0000,0000,,that he has chosen arbitrarily. This, of\Ncourse, is not signed, which is not a
Dialogue: 0,0:39:31.33,0:39:37.74,Default,,0000,0000,0000,,problem because this document can be\Npartly signed and this document is
Dialogue: 0,0:39:37.74,0:39:43.64,Default,,0000,0000,0000,,forwarded to Gmail. Gmail now analyzes\Nthis document and sees whether there is a
Dialogue: 0,0:39:43.64,0:39:49.53,Default,,0000,0000,0000,,signed part in this document. So I check\Nthis signed part. The signed part doesn't
Dialogue: 0,0:39:49.53,0:39:59.95,Default,,0000,0000,0000,,contain anything useful, but it is\Ncorrect. It's not the wrong signature. So
Dialogue: 0,0:39:59.95,0:40:05.40,Default,,0000,0000,0000,,it sends back to Sideshow: there I checked\Nthis document looks fine to me. Now
Dialogue: 0,0:40:05.40,0:40:09.63,Default,,0000,0000,0000,,Sideshow looks at a document, sees that as\Nan email attribute, uses this email
Dialogue: 0,0:40:09.63,0:40:18.25,Default,,0000,0000,0000,,attribute and the attacker is signed into\Nany Gmail account that he likes with using
Dialogue: 0,0:40:18.25,0:40:25.30,Default,,0000,0000,0000,,BrowserID. OK, so this is bad, as you can\Nimagine. And we told the Mozilla guys
Dialogue: 0,0:40:25.30,0:40:30.96,Default,,0000,0000,0000,,about this and they were quite fast. So we\Nwere really surprised. They were really
Dialogue: 0,0:40:30.96,0:40:35.38,Default,,0000,0000,0000,,quick. So I think it was in the middle of\Nthe night for most of them, but they
Dialogue: 0,0:40:35.38,0:40:40.84,Default,,0000,0000,0000,,scrambled in the back and they wrote some\Npatches and so on and so on. And I think
Dialogue: 0,0:40:40.84,0:40:46.85,Default,,0000,0000,0000,,it wasn't 24 hours later that it was all\Ndeployed and fixed. So that's what was
Dialogue: 0,0:40:46.85,0:40:54.37,Default,,0000,0000,0000,,quite good. But then we took another look\Nat the system and we found identity
Dialogue: 0,0:40:54.37,0:41:02.57,Default,,0000,0000,0000,,forgery number two, which is actually\Nremarkably similar to works as follows. So
Dialogue: 0,0:41:02.57,0:41:06.27,Default,,0000,0000,0000,,the attacker, since the authentication\Nrequests, you know this part at Sideshow
Dialogue: 0,0:41:06.27,0:41:12.57,Default,,0000,0000,0000,,once the signed e-mail attribute and the\Nattacker now doesn't change anything, the
Dialogue: 0,0:41:12.57,0:41:18.37,Default,,0000,0000,0000,,attacker just forwards this request to\NGmail, Gmail, ask for the credentials, the
Dialogue: 0,0:41:18.37,0:41:25.80,Default,,0000,0000,0000,,attacker signs and and sends back the\NOpenID assertion containing the signed
Dialogue: 0,0:41:25.80,0:41:31.69,Default,,0000,0000,0000,,email address of the attacker. So no\Nattack to up to this point. But now the
Dialogue: 0,0:41:31.69,0:41:37.38,Default,,0000,0000,0000,,attacker can do the following. The\Nattacker adds another attribute, another
Dialogue: 0,0:41:37.38,0:41:47.25,Default,,0000,0000,0000,,email attribute. And yeah, you can guess\Nwhat happens. The document is forwarded to
Dialogue: 0,0:41:47.25,0:41:53.69,Default,,0000,0000,0000,,Gmail. Gmail checks the signed part of the\Ndocument, which is still fine, sends back
Dialogue: 0,0:41:53.69,0:41:57.85,Default,,0000,0000,0000,,to Sideshow that everything is fine with\Nthis document. And Sideshow selects the
Dialogue: 0,0:41:57.85,0:42:04.88,Default,,0000,0000,0000,,wrong email address. Yeah, and now the\Nuser, the attacker signed into any user
Dialogue: 0,0:42:04.88,0:42:14.41,Default,,0000,0000,0000,,account again. OK, so this was the second\Nidentity forgery attack. We also found
Dialogue: 0,0:42:14.41,0:42:19.23,Default,,0000,0000,0000,,another attack, which is not very\Nspectacular. And we also looked so this
Dialogue: 0,0:42:19.23,0:42:26.59,Default,,0000,0000,0000,,was all, of course, authentication. And we\Nalso took a look at privacy so as to
Dialogue: 0,0:42:26.59,0:42:34.17,Default,,0000,0000,0000,,remember privacy says that, in the words\Nof Mozilla, the browser ID protocol never
Dialogue: 0,0:42:34.17,0:42:42.63,Default,,0000,0000,0000,,leaks tracking information back to the\Nidentity provider, except it does. So
Dialogue: 0,0:42:42.63,0:42:46.38,Default,,0000,0000,0000,,ideally, the identity provider should be\Nunable to tell whether user logs in. In
Dialogue: 0,0:42:46.38,0:42:55.42,Default,,0000,0000,0000,,fact, this is broken, because in the\Nbrowser, the following happens. If
Dialogue: 0,0:42:55.42,0:43:00.20,Default,,0000,0000,0000,,malicious identity provider wants to find\Nout whether a user is logged in at some
Dialogue: 0,0:43:00.20,0:43:05.50,Default,,0000,0000,0000,,specific relying party or not, then the\Nmalicious identity provider can just open
Dialogue: 0,0:43:05.50,0:43:13.93,Default,,0000,0000,0000,,iframe containing the website of that\Nrelying party he wants to probe. Now the
Dialogue: 0,0:43:13.93,0:43:19.33,Default,,0000,0000,0000,,following happens, the normal JavaScript\Nof BrowserID runs in this relying party
Dialogue: 0,0:43:19.33,0:43:25.34,Default,,0000,0000,0000,,because it has provided support,\Nobviously, and creates an iframe and
Dialogue: 0,0:43:25.34,0:43:32.03,Default,,0000,0000,0000,,inside this iframe, another iframe will be\Ncreated. But this innermost iframe will
Dialogue: 0,0:43:32.03,0:43:39.90,Default,,0000,0000,0000,,only be created if the user logged in at\Nthis RP before. Now, since the outermost
Dialogue: 0,0:43:39.90,0:43:43.73,Default,,0000,0000,0000,,and the innermost iframe, they come from\Nthe same source and of course they can
Dialogue: 0,0:43:43.73,0:43:50.26,Default,,0000,0000,0000,,collaborate and communicate. They can for\Nexample, just send postMessage saying: I,
Dialogue: 0,0:43:50.26,0:43:56.46,Default,,0000,0000,0000,,the user logged in at this ruling party\Nbefore. So an identity provider can easily
Dialogue: 0,0:43:56.46,0:44:02.61,Default,,0000,0000,0000,,probe whether a user logged in at some\Nrelying party or not. And this
Dialogue: 0,0:44:02.61,0:44:05.55,Default,,0000,0000,0000,,unfortunately cannot be fixed without a\Nmajor redesign of BrowserID, because they
Dialogue: 0,0:44:05.55,0:44:12.62,Default,,0000,0000,0000,,relied on all these iframes and so on.\NYeah. So I think this can be considered
Dialogue: 0,0:44:12.62,0:44:18.94,Default,,0000,0000,0000,,broken beyond repair. We also found some\Nvariants of these privacy attacks which
Dialogue: 0,0:44:18.94,0:44:26.30,Default,,0000,0000,0000,,rely on other mechanisms. But essentially.\NYeah, you get the idea right here. Privacy
Dialogue: 0,0:44:26.30,0:44:35.62,Default,,0000,0000,0000,,of BrowserID is broken. OK, so to sum up\NBrowserID, we found attacks, but we also
Dialogue: 0,0:44:35.62,0:44:44.85,Default,,0000,0000,0000,,were able to fix them with respect to\Nsecurity, and we also used our formal
Dialogue: 0,0:44:44.85,0:44:51.25,Default,,0000,0000,0000,,methods to improve the security of the\Nfixed BrowserID system. But privacy is
Dialogue: 0,0:44:51.25,0:44:55.00,Default,,0000,0000,0000,,broken beyond repair.
Dialogue: 0,0:44:55.00,0:45:00.65,Default,,0000,0000,0000,,Guido: OK, this leads us to the question,\Ncan we build a single-sign-on system that
Dialogue: 0,0:45:00.65,0:45:08.56,Default,,0000,0000,0000,,provides security and privacy on the Web?\NSo we thought a lot about this question.
Dialogue: 0,0:45:08.56,0:45:16.46,Default,,0000,0000,0000,,And then we used our formal model to\Ndesign such a single-sign-on system. And
Dialogue: 0,0:45:16.46,0:45:22.70,Default,,0000,0000,0000,,we could also then use the former model to\Nprove that these properties are actually
Dialogue: 0,0:45:22.70,0:45:30.94,Default,,0000,0000,0000,,fulfilled. So the basic principle of the\Nsystem is called SPRESSO for Secure
Dialogue: 0,0:45:30.94,0:45:37.71,Default,,0000,0000,0000,,Privacy Respecting Single-Sign-On is the\Nfollowing. We have the user with a
Dialogue: 0,0:45:37.71,0:45:44.15,Default,,0000,0000,0000,,browser. This user wants to log in at some\Nrelying party, for example, at Wikipedia.
Dialogue: 0,0:45:44.15,0:45:51.17,Default,,0000,0000,0000,,So here we have the same same idea as in\NBrowserID to use the email address and the
Dialogue: 0,0:45:51.17,0:45:58.25,Default,,0000,0000,0000,,e-mail provider as the identity provider.\NSo the user enters the email address and
Dialogue: 0,0:45:58.25,0:46:07.77,Default,,0000,0000,0000,,then the relying party asks for some proof\Nof this identity. So the user goes to her
Dialogue: 0,0:46:07.77,0:46:13.78,Default,,0000,0000,0000,,email provider, which is identity provider\Nin this case, authenticates there. And
Dialogue: 0,0:46:13.78,0:46:20.56,Default,,0000,0000,0000,,then this. The identity provider creates a\Ndocument that proves the Alice's identity
Dialogue: 0,0:46:20.56,0:46:25.54,Default,,0000,0000,0000,,and then forwards this document to the\Nrelying party. And the relying party can
Dialogue: 0,0:46:25.54,0:46:31.51,Default,,0000,0000,0000,,check if everything is all right and then\Nconsider the user to be loggged in. So
Dialogue: 0,0:46:31.51,0:46:37.01,Default,,0000,0000,0000,,let's have a closer look on how this\Nsystem works. So here again, we have
Dialogue: 0,0:46:37.01,0:46:45.09,Default,,0000,0000,0000,,Alice's browser, the window of the relying\Nparty. Alice enters her email address. The
Dialogue: 0,0:46:45.09,0:46:49.13,Default,,0000,0000,0000,,email address is sent to relying party.\NAnd now the relying party creates a
Dialogue: 0,0:46:49.13,0:46:55.63,Default,,0000,0000,0000,,document that contains the identity of the\Nrelying party itself. And this document is
Dialogue: 0,0:46:55.63,0:47:01.59,Default,,0000,0000,0000,,encrypted and we call this document the\Ntag. So now the tag is sent, along with
Dialogue: 0,0:47:01.59,0:47:06.51,Default,,0000,0000,0000,,the key that was used to encrypt this\Ndocument. So this is symmetric encryption
Dialogue: 0,0:47:06.51,0:47:16.09,Default,,0000,0000,0000,,with a fresh key sends it to the browser.\NAnd now in the browser, the SPRESSO code
Dialogue: 0,0:47:16.09,0:47:21.74,Default,,0000,0000,0000,,opens a new window of the identity\Nprovider that is given by the domain of
Dialogue: 0,0:47:21.74,0:47:33.81,Default,,0000,0000,0000,,the email address and sends the tag over\Nto this window. This login dialog prompts
Dialogue: 0,0:47:33.81,0:47:40.55,Default,,0000,0000,0000,,the user to authenticate, so the user now\Nenters her password. And this is sent
Dialogue: 0,0:47:40.55,0:47:47.30,Default,,0000,0000,0000,,along with the tag to the server and now\Nthe server creates this document I've just
Dialogue: 0,0:47:47.30,0:47:55.83,Default,,0000,0000,0000,,spoken of in the last slide and this\Ndocument, we call it the user certificate,
Dialogue: 0,0:47:55.83,0:48:02.21,Default,,0000,0000,0000,,user assertion, sorry, user assertion. We\Nsend it back to the window at the login
Dialogue: 0,0:48:02.21,0:48:10.13,Default,,0000,0000,0000,,dialog and now we have a problem. We could\Njust send it over to the Wikipedia window.
Dialogue: 0,0:48:10.13,0:48:16.75,Default,,0000,0000,0000,,But I show you in the minute why this is a\Nbad idea. So instead, now we have a third
Dialogue: 0,0:48:16.75,0:48:25.15,Default,,0000,0000,0000,,party, the forwarder which serves just a\Nsingle static JavaScript file, and this is
Dialogue: 0,0:48:25.15,0:48:32.97,Default,,0000,0000,0000,,loaded in an iframe and is login dialog.\NAnd this iframe gets the user assertion
Dialogue: 0,0:48:32.97,0:48:40.00,Default,,0000,0000,0000,,and it also gets the key and now it can\Ndecrypt the tag. Look who is the intended
Dialogue: 0,0:48:40.00,0:48:46.89,Default,,0000,0000,0000,,receiver and then it sends over the user\Nassertion through the window of the
Dialogue: 0,0:48:46.89,0:48:51.43,Default,,0000,0000,0000,,relying party which forwards it to the\Nserver of the relying party, who could
Dialogue: 0,0:48:51.43,0:48:56.99,Default,,0000,0000,0000,,then can check if everything is all right\Nand consider the user to be logged in. So
Dialogue: 0,0:48:56.99,0:49:03.57,Default,,0000,0000,0000,,why do we need this forward? So at first\Nit may look strange. So let's look what
Dialogue: 0,0:49:03.57,0:49:09.40,Default,,0000,0000,0000,,happens if we just don't have this\Nforwarder. So let's assume the user wants
Dialogue: 0,0:49:09.40,0:49:14.62,Default,,0000,0000,0000,,to log in at some malicious relying party\Nat attacker.com and there is an email
Dialogue: 0,0:49:14.62,0:49:19.23,Default,,0000,0000,0000,,address but the attacker wants to\Nimpersonate the user who wants to log in
Dialogue: 0,0:49:19.23,0:49:24.34,Default,,0000,0000,0000,,at some other relying party. Let's say to\NWikipedia, for example, and the attacker
Dialogue: 0,0:49:24.34,0:49:30.93,Default,,0000,0000,0000,,goes to Wikipedia, says, hi, I'm Alice. I\Nwant to log in. Wikipedia creates a tag.
Dialogue: 0,0:49:30.93,0:49:39.45,Default,,0000,0000,0000,,This is sent over to the attacker who just\Nrelays it to the user user. Protocol runs
Dialogue: 0,0:49:39.45,0:49:46.28,Default,,0000,0000,0000,,on, the user authenticates to her identity\Nprovider. And then we just sent the tag
Dialogue: 0,0:49:46.28,0:49:52.11,Default,,0000,0000,0000,,over as the identity provider does not\Nknow who is the intended receiver's
Dialogue: 0,0:49:52.11,0:49:58.43,Default,,0000,0000,0000,,because we want to have this privacy\Nfeature. This just went through and the
Dialogue: 0,0:49:58.43,0:50:03.24,Default,,0000,0000,0000,,attacker gets the user certificate and\Nuser assertion and forwards it to
Dialogue: 0,0:50:03.24,0:50:09.49,Default,,0000,0000,0000,,Wikipedia and then the attacker is\Nconsidered to be Alice. And this is that.
Dialogue: 0,0:50:09.49,0:50:16.57,Default,,0000,0000,0000,,So we need some mechanism to prevent that\Nthe user assertion is forwarded to some
Dialogue: 0,0:50:16.57,0:50:21.55,Default,,0000,0000,0000,,random party, but only to the intended\Nreceiver. And for this, we have this
Dialogue: 0,0:50:21.55,0:50:29.45,Default,,0000,0000,0000,,forwarder. Now, you can think this\Nforwarded may maybe be also malicious, but
Dialogue: 0,0:50:29.45,0:50:33.92,Default,,0000,0000,0000,,let's talk about about this in a second.\NSo let's just talk about the key forwarded
Dialogue: 0,0:50:33.92,0:50:42.47,Default,,0000,0000,0000,,to us so the forwarder gets the user\Nassertion and he gets the key to decrypt
Dialogue: 0,0:50:42.47,0:50:48.50,Default,,0000,0000,0000,,the tag. And now he can instruct the\Nbrowser to send a postMessage, but only to
Dialogue: 0,0:50:48.50,0:50:54.54,Default,,0000,0000,0000,,give it to a window of Wikipedia. So the\Nbrowser checks is the receiver of the
Dialogue: 0,0:50:54.54,0:51:00.27,Default,,0000,0000,0000,,window of Wikipedia or not. And if it's\Nnot, it doesn't deliver this message. So
Dialogue: 0,0:51:00.27,0:51:07.30,Default,,0000,0000,0000,,this protects the, um, the user assertion\Ncertain to be leaked. And now you may
Dialogue: 0,0:51:07.30,0:51:12.42,Default,,0000,0000,0000,,think this forwarder may be malicious and\Ndeliver some other script that does
Dialogue: 0,0:51:12.42,0:51:17.68,Default,,0000,0000,0000,,strange things like forwarding things att\Nstart to the attacker directly. But we can
Dialogue: 0,0:51:17.68,0:51:22.13,Default,,0000,0000,0000,,enforce that the correct script is running\Ninside that iframe using separate source
Dialogue: 0,0:51:22.13,0:51:29.90,Default,,0000,0000,0000,,integrity where you just tell the browser\Nand this window only this code may run.
Dialogue: 0,0:51:29.90,0:51:36.39,Default,,0000,0000,0000,,And in this case the forwarder cannot just\Nput some arbitrary or malicious code in
Dialogue: 0,0:51:36.39,0:51:41.44,Default,,0000,0000,0000,,this iframe. And also there is no\Ninformation that leaks back from the
Dialogue: 0,0:51:41.44,0:51:48.96,Default,,0000,0000,0000,,browser to the forwarder. So to sum this\Nup, as I just presented SPRESSO, it
Dialogue: 0,0:51:48.96,0:51:55.39,Default,,0000,0000,0000,,features privacy and authentication. It's\Nopen and decentralized. So you don't need
Dialogue: 0,0:51:55.39,0:52:02.51,Default,,0000,0000,0000,,any specific central party. It's compliant\Nto web standards. That's based on HTML5.
Dialogue: 0,0:52:02.51,0:52:09.85,Default,,0000,0000,0000,,And we have formal proof that all these\Nproperties we've talked at the beginning
Dialogue: 0,0:52:09.85,0:52:14.74,Default,,0000,0000,0000,,actually hold and you can find a demo and\Nmore information on spresso.me.
Dialogue: 0,0:52:14.74,0:52:26.18,Default,,0000,0000,0000,,Daniel: OK, now to conclude the talk, what\Nis the takeaway? First of all, w talked, I
Dialogue: 0,0:52:26.18,0:52:30.88,Default,,0000,0000,0000,,think most of the time about OAuth 2.0.\NMost of the results also translate to
Dialogue: 0,0:52:30.88,0:52:37.51,Default,,0000,0000,0000,,OpenID Connect. We have formally proven\Nthe security of the protocol of OAuth and
Dialogue: 0,0:52:37.51,0:52:47.04,Default,,0000,0000,0000,,also OpenID Connect. Which is a nice\Nresult, of course, if you're OK with
Dialogue: 0,0:52:47.04,0:52:53.21,Default,,0000,0000,0000,,having no privacy, because OAuth and\NOpenID Connect don't have any kind of
Dialogue: 0,0:52:53.21,0:53:00.65,Default,,0000,0000,0000,,privacy that we talked about. Regarding\NOAuth 1.0 and OpenID, I think that can be
Dialogue: 0,0:53:00.65,0:53:05.04,Default,,0000,0000,0000,,considered deprecated and shouldn't be\Nused. BrowserID, Mozilla Persona was a
Dialogue: 0,0:53:05.04,0:53:15.06,Default,,0000,0000,0000,,nice experiment. But is dead now and also\Nhas broken privacy. With SPRESSO we have
Dialogue: 0,0:53:15.06,0:53:19.36,Default,,0000,0000,0000,,shown, however, that you can achieve\Nprivacy on web single-sign-on using
Dialogue: 0,0:53:19.36,0:53:25.94,Default,,0000,0000,0000,,standard HTML5 features and standard web\Nfeatures. But of course for now it is a
Dialogue: 0,0:53:25.94,0:53:34.27,Default,,0000,0000,0000,,proof of concept. As you have seen, we\Ndon't even have a nice logo yet. Um, So
Dialogue: 0,0:53:34.27,0:53:39.92,Default,,0000,0000,0000,,and one target audience are certainly\Ndevelopers, developers, developers use
Dialogue: 0,0:53:39.92,0:53:47.24,Default,,0000,0000,0000,,libraries wherever possible. For example,\Nthe pyoidc is written even by members of
Dialogue: 0,0:53:47.24,0:53:56.89,Default,,0000,0000,0000,,the OAuth and OpenID working groups. So\Nthey know what they do. Hopefully. Also
Dialogue: 0,0:53:56.89,0:54:03.07,Default,,0000,0000,0000,,regarding RFC's, they are hard to read and\Ninformation is often spread across several
Dialogue: 0,0:54:03.07,0:54:08.97,Default,,0000,0000,0000,,documents. They are often not written\Nclearly and they are not always up to
Dialogue: 0,0:54:08.97,0:54:16.27,Default,,0000,0000,0000,,date, but they are still an important\Nreference. And I think it's a good advice
Dialogue: 0,0:54:16.27,0:54:23.13,Default,,0000,0000,0000,,to look at RFC's from time to time, even\Nif they are hard to read. So thank you
Dialogue: 0,0:54:23.13,0:54:27.94,Default,,0000,0000,0000,,very much for your attention. If you want\Nto talk to us, come to us at the
Dialogue: 0,0:54:27.94,0:54:33.75,Default,,0000,0000,0000,,Maschinendeck assemblyin hall 3 free or\Njoin us at the next Pi and More,shameless
Dialogue: 0,0:54:33.75,0:54:40.17,Default,,0000,0000,0000,,plug here, January 14 in Krefield or at\NUniversity of Stuttgart starting in
Dialogue: 0,0:54:40.17,0:54:46.71,Default,,0000,0000,0000,,January. Thank you very much.
Dialogue: 0,0:54:46.71,0:54:52.37,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:54:52.37,0:54:56.88,Default,,0000,0000,0000,,Presenter: Now we have eight minutes for\Nquestions, what do we have from the
Dialogue: 0,0:54:56.88,0:55:02.70,Default,,0000,0000,0000,,Internet?\NQuestion (internet): So we've got two
Dialogue: 0,0:55:02.70,0:55:10.79,Default,,0000,0000,0000,,questions from the Internet. You can you\Nhear me? So at the diagram you showed one
Dialogue: 0,0:55:10.79,0:55:16.37,Default,,0000,0000,0000,,of the first slides, why does the\Nauthentication follow authorization?
Dialogue: 0,0:55:16.37,0:55:21.84,Default,,0000,0000,0000,,Shouldn't it normally be the other way\Naround?
Dialogue: 0,0:55:21.84,0:55:32.53,Default,,0000,0000,0000,,Presenter: Can you try to repeat the\Nquestion?
Dialogue: 0,0:55:32.53,0:55:40.13,Default,,0000,0000,0000,,Internet: Yeah, sorry, at the diagram you\Nshowed in one of the first slides. Why
Dialogue: 0,0:55:40.13,0:55:46.10,Default,,0000,0000,0000,,does the why does the authentication\Nfollow authorization? Shouldn't it
Dialogue: 0,0:55:46.10,0:55:53.15,Default,,0000,0000,0000,,normally be the other way around?\NGuido: OK, so these are two concepts that
Dialogue: 0,0:55:53.15,0:56:03.65,Default,,0000,0000,0000,,are kind of orthogonal to each other. So\Nyou can either do authentication to ensure
Dialogue: 0,0:56:03.65,0:56:08.65,Default,,0000,0000,0000,,yourself of the user's identity or you can\Nact on the user's behalf at the identity
Dialogue: 0,0:56:08.65,0:56:14.33,Default,,0000,0000,0000,,provider, like posting on the user's\NFacebook timeline or doing different
Dialogue: 0,0:56:14.33,0:56:21.90,Default,,0000,0000,0000,,things there. But for authentication, you\Nneed to retrieve some unique user
Dialogue: 0,0:56:21.90,0:56:29.35,Default,,0000,0000,0000,,identifier. And this basically you make\Nuse of this authorization mechanism. So
Dialogue: 0,0:56:29.35,0:56:35.01,Default,,0000,0000,0000,,you get authorized to access this unique\Nuser identifier and you use this then for
Dialogue: 0,0:56:35.01,0:56:40.28,Default,,0000,0000,0000,,authentication.\NPresenter: Thank you. Questions from here.
Dialogue: 0,0:56:40.28,0:56:46.72,Default,,0000,0000,0000,,Question 2: So for the special protocol,\Nyou said you need the forwarding party to
Dialogue: 0,0:56:46.72,0:56:51.19,Default,,0000,0000,0000,,check whether this certificate was\Nactually from Wikipedia or not from
Dialogue: 0,0:56:51.19,0:56:55.07,Default,,0000,0000,0000,,attacker.com. But could Alice do this\Ncheck herself?
Dialogue: 0,0:56:55.07,0:57:02.21,Default,,0000,0000,0000,,Guido: You mean that you should present\Nthe user something and the user accepts
Dialogue: 0,0:57:02.21,0:57:07.41,Default,,0000,0000,0000,,this and or declines this in this sense?\NOr...
Dialogue: 0,0:57:07.41,0:57:11.92,Default,,0000,0000,0000,,Question 2: She has the challenge that is\Nsigned by her email provider and she has
Dialogue: 0,0:57:11.92,0:57:15.99,Default,,0000,0000,0000,,the key that encrypted Wikipedia's\Nidentity. So she could use that to decrypt
Dialogue: 0,0:57:15.99,0:57:19.24,Default,,0000,0000,0000,,it and check if it's Wikipedia or\Nattacker.com.
Dialogue: 0,0:57:19.24,0:57:23.23,Default,,0000,0000,0000,,Guido: Yeah, yeah. I mean, in principle,\Nyes.
Dialogue: 0,0:57:23.23,0:57:26.77,Default,,0000,0000,0000,,Daniel: So you mean the user?\NQuestion 2: Yeah, yes.
Dialogue: 0,0:57:26.77,0:57:30.30,Default,,0000,0000,0000,,Daniel: Yes. The user could, of course,\Ncheck. We could ask the user, did you
Dialogue: 0,0:57:30.30,0:57:35.95,Default,,0000,0000,0000,,really want to sign attacker.com or\Nwikipedia.com? But of course, we all know
Dialogue: 0,0:57:35.95,0:57:42.19,Default,,0000,0000,0000,,that users are better at making decisions.\NSo, yeah.
Dialogue: 0,0:57:42.19,0:57:47.28,Default,,0000,0000,0000,,Presenter: Thank you. Questions from here?\NQuestion 3: Hi, thanks for the informative
Dialogue: 0,0:57:47.28,0:57:51.62,Default,,0000,0000,0000,,talk, but I wanted to add a remark. It is\Nhighly unfair to call users stupid for
Dialogue: 0,0:57:51.62,0:57:55.15,Default,,0000,0000,0000,,falling victim to clickjacking and\Nphishing because they are working
Dialogue: 0,0:57:55.15,0:58:02.11,Default,,0000,0000,0000,,professionally on them on enabling\Nclickjacking and phishing. And if you need
Dialogue: 0,0:58:02.11,0:58:06.35,Default,,0000,0000,0000,,a 4K monitor just to see that there is\Nsome JavaScript edit that like thousand
Dialogue: 0,0:58:06.35,0:58:13.87,Default,,0000,0000,0000,,zero delimiters, it is impossible to blame\Nthe user for being stupid or falling
Dialogue: 0,0:58:13.87,0:58:19.85,Default,,0000,0000,0000,,victim to clickjacking.\NDaniel: Yes, that's correct. It also
Dialogue: 0,0:58:19.85,0:58:28.12,Default,,0000,0000,0000,,sometimes you just can't see it. So yes.\NPresenter: Thank you. Questions from down
Dialogue: 0,0:58:28.12,0:58:35.26,Default,,0000,0000,0000,,there? Sorry. Questions?\NQuestion 4: You talked about formal
Dialogue: 0,0:58:35.26,0:58:43.75,Default,,0000,0000,0000,,verification of both the OAuth and your\Nprotocol. I wanted to know what kind of
Dialogue: 0,0:58:43.75,0:58:49.85,Default,,0000,0000,0000,,program or whatever you used like ProVerif\Nor Tamarin or whatever. And also, I think
Dialogue: 0,0:58:49.85,0:58:56.56,Default,,0000,0000,0000,,you just proved the, you just verified a\Nsubset of OAuth?
Dialogue: 0,0:58:56.56,0:59:02.54,Default,,0000,0000,0000,,Daniel: Let's start with the second\Nquestion first. So for OAuth, we really
Dialogue: 0,0:59:02.54,0:59:07.50,Default,,0000,0000,0000,,tried to introduce as many options as we\Ncould find in the standard, so to say.
Dialogue: 0,0:59:07.50,0:59:13.87,Default,,0000,0000,0000,,OAuth is a very loose standard. So they\Ngive you a lot of options. In many ways.
Dialogue: 0,0:59:13.87,0:59:19.19,Default,,0000,0000,0000,,We had to exclude some of them for\Npractical reasons when modeling the stuff.
Dialogue: 0,0:59:19.19,0:59:25.54,Default,,0000,0000,0000,,But we included almost all of the options\Nthat are provided. And we also have a
Dialogue: 0,0:59:25.54,0:59:31.46,Default,,0000,0000,0000,,detailed write up of what the options are\Nand what we excluded and what we included.
Dialogue: 0,0:59:31.46,0:59:36.60,Default,,0000,0000,0000,,And now for the first part of the\Nquestion, our model currently is a manual
Dialogue: 0,0:59:36.60,0:59:44.04,Default,,0000,0000,0000,,model. So what we do is pen and paper\Nproves. The reasoning behind this is that
Dialogue: 0,0:59:44.04,0:59:51.06,Default,,0000,0000,0000,,if you have tools, they are always, in\Nsome sense, limiting you. And when we
Dialogue: 0,0:59:51.06,0:59:58.37,Default,,0000,0000,0000,,started out with this work, there was or\Nthere were two models, essentially already
Dialogue: 0,0:59:58.37,1:00:04.10,Default,,0000,0000,0000,,existing web models, former models so in\Nthe same area as we are. But they were
Dialogue: 0,1:00:04.10,1:00:11.67,Default,,0000,0000,0000,,both based on a model checker, so one on\NProVerif, one on another modeling tool...
Dialogue: 0,1:00:11.67,1:00:15.19,Default,,0000,0000,0000,,Guido: Alloy.\NDaniel: Alloy. And both were limited by
Dialogue: 0,1:00:15.19,1:00:19.86,Default,,0000,0000,0000,,the possibilities that you had in these\Nmodel checkers. So what we went the other
Dialogue: 0,1:00:19.86,1:00:24.75,Default,,0000,0000,0000,,way around, what we wanted to do was a\Nmanual model that includes, that models
Dialogue: 0,1:00:24.75,1:00:29.51,Default,,0000,0000,0000,,the web really precisely and\Ncomprehensively. And then as a second step
Dialogue: 0,1:00:29.51,1:00:35.51,Default,,0000,0000,0000,,what we are currently working on or\Ndiscussing about is to transfer this into
Dialogue: 0,1:00:35.51,1:00:38.91,Default,,0000,0000,0000,,some kind of tool.\NQuestion 4: Thank you.
Dialogue: 0,1:00:38.91,1:00:43.34,Default,,0000,0000,0000,,Presenter: Two more questions, questions\Nfrom the Internet?
Dialogue: 0,1:00:43.34,1:00:51.35,Default,,0000,0000,0000,,Internet: So I was wondering if you know\Nabout ND-Auth(?) and RealMe Auth and what
Dialogue: 0,1:00:51.35,1:00:57.30,Default,,0000,0000,0000,,you think about the question of using\Ndomain names vs. email addresses as the
Dialogue: 0,1:00:57.30,1:01:01.19,Default,,0000,0000,0000,,user identifier.\NDaniel: Could you repeat that a bit
Dialogue: 0,1:01:01.19,1:01:05.35,Default,,0000,0000,0000,,louder?\NInternet: So if you have any comments
Dialogue: 0,1:01:05.35,1:01:12.22,Default,,0000,0000,0000,,aboutND-Auth(?) and RealMe Auth which is\Nthe domain name as identifier rather than
Dialogue: 0,1:01:12.22,1:01:16.33,Default,,0000,0000,0000,,an email address.\NDaniel: So we didn't look at these
Dialogue: 0,1:01:16.33,1:01:21.23,Default,,0000,0000,0000,,systems.\NPresenter: Yes, last question.
Dialogue: 0,1:01:21.23,1:01:27.49,Default,,0000,0000,0000,,Question 5: The question regarding the\Nforwarder and the privacy protection, I
Dialogue: 0,1:01:27.49,1:01:32.34,Default,,0000,0000,0000,,realized with the forwarder as far as I\Nunderstand, the forwarder is used in its
Dialogue: 0,1:01:32.34,1:01:38.72,Default,,0000,0000,0000,,own iframe to prevent the IDP from taking\Ncontrol of the verification process,
Dialogue: 0,1:01:38.72,1:01:44.63,Default,,0000,0000,0000,,knowing that who is the the final system?\NGuido: Yes.
Dialogue: 0,1:01:44.63,1:01:50.25,Default,,0000,0000,0000,,Question 5: But what if the identity\Nprovider at the forward to collaborate,
Dialogue: 0,1:01:50.25,1:01:58.06,Default,,0000,0000,0000,,then the privacy would be broken? Yes. If\Nwe have these parties collaborating then
Dialogue: 0,1:01:58.06,1:02:03.75,Default,,0000,0000,0000,,of course they are broken. So we haven't\Nwe haven't shown all the details of the
Dialogue: 0,1:02:03.75,1:02:13.46,Default,,0000,0000,0000,,system. So this is really hard to prevent.\NBut in SPRESSO, the relying party is
Dialogue: 0,1:02:13.46,1:02:20.16,Default,,0000,0000,0000,,allowed to choose which forwarder has to\Nbe used. So line party, so choose water
Dialogue: 0,1:02:20.16,1:02:25.60,Default,,0000,0000,0000,,run by some trustworthy party. So this is\Nthe countermeasure to prevent
Dialogue: 0,1:02:25.60,1:02:30.79,Default,,0000,0000,0000,,collaboration. But if these parties\Ncollaborate, then you are screwed. Yes.
Dialogue: 0,1:02:30.79,1:02:35.44,Default,,0000,0000,0000,,Daniel: So I think it's also important to\Nadd some of the forwarder is kind of a
Dialogue: 0,1:02:35.44,1:02:42.37,Default,,0000,0000,0000,,semi trusted party, because on the one\Nhand, we can enforce that as it uses the
Dialogue: 0,1:02:42.37,1:02:49.55,Default,,0000,0000,0000,,correct code. Of course, the IDP then has\Nto enforce this. On the other hand, you
Dialogue: 0,1:02:49.55,1:02:53.83,Default,,0000,0000,0000,,still have some side channels like, for\Nexample, timing. So if you control the
Dialogue: 0,1:02:53.83,1:03:00.26,Default,,0000,0000,0000,,parties, then you could check which IP\Naddresses access for example, the
Dialogue: 0,1:03:00.26,1:03:06.76,Default,,0000,0000,0000,,forwarder and IDP at the same time or and\Nso on. So there are some side channels. So
Dialogue: 0,1:03:06.76,1:03:11.57,Default,,0000,0000,0000,,the idea that we have to minimize this\Nrisk is to provide a set of trusted
Dialogue: 0,1:03:11.57,1:03:20.48,Default,,0000,0000,0000,,forwarders that could be, for example,\Nprovided by some trusted parties like
Dialogue: 0,1:03:20.48,1:03:25.05,Default,,0000,0000,0000,,Mozilla or the EFF or something, so that\Nyou have a set of forwards to choose from
Dialogue: 0,1:03:25.05,1:03:29.12,Default,,0000,0000,0000,,and hopefully choose a trusted one.\NQuestion 5: Thank you.
Dialogue: 0,1:03:29.12,1:03:32.44,Default,,0000,0000,0000,,Daniel: You're welcome.\NPresenter: Guido Schmitz and Daniel Fett,
Dialogue: 0,1:03:32.44,1:03:48.65,Default,,0000,0000,0000,,thank you so much for the great talk.\NPlease give a great round of applause.
Dialogue: 0,1:03:48.65,1:03:53.97,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,1:03:53.97,1:03:57.31,Default,,0000,0000,0000,,{\i1}postroll music{\i0}
Dialogue: 0,1:03:57.31,1:04:05.00,Default,,0000,0000,0000,,Subtitles created by many many volunteers and\Nthe c3subtitles.de team. Join us, and help us!