WEBVTT
00:00:04.870 --> 00:00:12.799
33C3 preroll music
00:00:12.799 --> 00:00:17.840
Presenter: So I think we're all set
without further ado, I would like to I
00:00:17.840 --> 00:00:23.779
would like to introduce Guido Schmitz and
Daniel Fett, who are going to be having
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
00:00:29.980 --> 00:00:37.360
hope you're looking forward to the talk
00:00:37.360 --> 00:00:46.270
Guido: OK, hello, everybody, welcome to
our talk on the security and privacy of
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
00:00:53.340 --> 00:01:01.500
pretend not only just a OAuth and OpenID
Connect, but also some thoughts about
00:01:01.500 --> 00:01:10.310
analysis of all these standards. So first,
a brief introduction who are. We are
00:01:10.310 --> 00:01:18.210
researchers from the University of Trier,
but soon of University of Stuttgart. And
00:01:18.210 --> 00:01:24.369
also we happen to be the founders of the
Maschinendeck, the hackerspace in Trier
00:01:24.369 --> 00:01:31.950
and the Pi and More raspberry jam. If
you're interested in anything else, what
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
00:01:38.799 --> 00:01:45.320
about? What are we talking about? So
probably all of you have seen websites
00:01:45.320 --> 00:01:52.020
like this, like TripAdvisor, that you can
use a lot of different methods to sign and
00:01:52.020 --> 00:01:55.930
you can sign in with your Facebook
account, with your Google account, you can
00:01:55.930 --> 00:02:00.640
register account at their page with the
email address and password, or you can use
00:02:00.640 --> 00:02:09.030
your Samsung account or probably now even
more different systems. And if you click,
00:02:09.030 --> 00:02:13.020
for example, on this login with Facebook
button and new window pops up, prompting
00:02:13.020 --> 00:02:18.470
for your Facebook credentials, or if you
already signed into Facebook, just asks
00:02:18.470 --> 00:02:25.700
for confirmation. So this is a setting we
are looking at and we have two parties
00:02:25.700 --> 00:02:31.410
here. We have the we have TripAdvisor as
the so-called relying party and we have
00:02:31.410 --> 00:02:39.250
Facebook as the so-called identity
provider. And the basic principle of how
00:02:39.250 --> 00:02:44.630
this works is the following. So first you
go with your browser to the relying party.
00:02:44.630 --> 00:02:52.530
You say, I want to log in that RP, then
you contact your identity provider,
00:02:52.530 --> 00:02:58.120
authenticate there. And this identity
provider then issues some kind of token
00:02:58.120 --> 00:03:03.750
and this token you give to the relying
party. And the ruling party can now use
00:03:03.750 --> 00:03:11.560
this token to access some parts of your
account at the identity provider. And this
00:03:11.560 --> 00:03:15.910
is called authorization, for example, the
ruling party can use this token now to
00:03:15.910 --> 00:03:24.150
post on your Facebook timeline or reach
out your friends list from Facebook. And
00:03:24.150 --> 00:03:31.210
it the ruling party can also retrieve some
unique user identifier and then consider
00:03:31.210 --> 00:03:35.500
you to be locked in with that user
identifier. And then this is
00:03:35.500 --> 00:03:42.970
authentication. And then RP can set, for
example, sensation Cookie and Mark. This
00:03:42.970 --> 00:03:49.310
session belongs. Remember that this
session belongs to this user. So this is
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
00:03:55.439 --> 00:04:01.980
use single-sign-on? So for users, it's
very convenient. You don't have to
00:04:01.980 --> 00:04:07.340
remember which account you used where,
which password and so on. You just click
00:04:07.340 --> 00:04:10.700
and login with Facebook and you're all
done. Of course, this comes with lack of
00:04:10.700 --> 00:04:18.140
privacy because Facebook then always knows
where you log in. And also the identity
00:04:18.140 --> 00:04:22.360
provider you choose is also the single
point of failure. If that one closes down
00:04:22.360 --> 00:04:28.669
or changes its terms and conditions, then
you perhaps cannot log into your accounts
00:04:28.669 --> 00:04:36.560
anymore at some third party web pages. So
relying parties, they need to store less
00:04:36.560 --> 00:04:41.400
data. They don't have to care about
password databases that can leak. They
00:04:41.400 --> 00:04:44.419
don't have to care about user
registration, password recovery on all the
00:04:44.419 --> 00:04:49.930
hassle that comes with user accounts. But
they also have less control over this,
00:04:49.930 --> 00:04:54.949
over the users accounts because they
outsource the authentication to this
00:04:54.949 --> 00:04:59.450
identity provider and also hear the
identity provider as a single point of
00:04:59.450 --> 00:05:05.139
failure. Far identity providers, the
advantage is clear. They get more user
00:05:05.139 --> 00:05:12.120
data and they can provide some service for
their users, which makes, perhaps it makes
00:05:12.120 --> 00:05:19.160
it more attractive for users to use that
identity provider. On the downside, they
00:05:19.160 --> 00:05:23.340
also have to take care about more user
data. They have to store and protect it,
00:05:23.340 --> 00:05:27.130
and they have to have the overhead of
implement, implementing and running the
00:05:27.130 --> 00:05:36.560
single-sign-on system. So what are these
single-sign-on systems now? Now I will
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
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
00:05:50.870 --> 00:05:56.070
and basically nobody uses it anymore
except for Twitter. So Twitter uses a
00:05:56.070 --> 00:06:04.669
modified version of OAuth 1, which more or
less fixes all the known flaws. But in
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
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
00:06:18.919 --> 00:06:25.120
be super flexible for every corner use
case that they developers at that time
00:06:25.120 --> 00:06:31.260
thought of. And this makes it also
extremely hard to use correctly because
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
00:06:39.130 --> 00:06:46.750
not that nice to develop something for
OpenID. So also, OpenID, don't use this.
00:06:46.750 --> 00:06:52.790
And now modern single-sign-on systems, for
example, OAuth 2, which is also used in
00:06:52.790 --> 00:07:02.480
login with Facebook. This is completely
incompatible to OAuth 1 and OAuth 2 uses
00:07:02.480 --> 00:07:12.539
the so-called Bearer token approach. The
old protocol is based on some random
00:07:12.539 --> 00:07:18.580
values that are passed around. But there's
no crypto involved except for the
00:07:18.580 --> 00:07:27.139
transport layer for HTTPS, for example,
and OAuth2 is used everywhere, almost. So
00:07:27.139 --> 00:07:31.699
it's the most popular of these systems,
but it has never been developed for
00:07:31.699 --> 00:07:38.240
authentication and really, it's not meant
for authentication. And if you google for
00:07:38.240 --> 00:07:45.360
OAuth 2 and authentication, you have to
sometimes stumble upon the following
00:07:45.360 --> 00:07:50.580
picture. So these two guys are members of
the OAuth working group and they are
00:07:50.580 --> 00:07:54.909
really insist it's not meant for
authentication at all. It's just for
00:07:54.909 --> 00:08:03.310
authorization. OK. Nonetheless, it is used
in practice also for authentication.
00:08:03.310 --> 00:08:10.539
Facebook, for example, uses it for
authentication. And so the protocol is now
00:08:10.539 --> 00:08:15.139
five years old. Many flaws have been
discovered. Most of them have been fixed.
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
00:08:22.340 --> 00:08:27.629
there's also OpenID Connect. OpenID
Connect is quite new. It's from one and a
00:08:27.629 --> 00:08:34.840
half years old and it's an authentication
layer on top of OAuth. So the first
00:08:34.840 --> 00:08:39.330
definition or real definition on how you
should use of for authentication, but it
00:08:39.330 --> 00:08:45.350
changes the standard also so it can be
seen as the protocol on its own, but
00:08:45.350 --> 00:08:49.830
OpenID Connect, although despite the name,
it's also completely incompatible to
00:08:49.830 --> 00:08:57.220
OpenID. And it has also some dynamic
features like IdP, Discovery and identity
00:08:57.220 --> 00:09:03.010
provider Discovery and stuff like that. So
this leads us to the Web, single-sign-on
00:09:03.010 --> 00:09:09.529
chart of confusion. So we have OAuth 1
which is the marketing predecessor off of
00:09:09.529 --> 00:09:16.580
2, but completely incompatible to OAuth 2
and OAuth 2 serves as the foundation for
00:09:16.580 --> 00:09:21.470
login with Facebook, for authentication
and also for OpenID Connect and OpenID
00:09:21.470 --> 00:09:26.420
Connect, there is OpenID, which is the
marketing predecessor of OpenID Connect,
00:09:26.420 --> 00:09:33.180
but also same here, it's not compatible to
each other. And OpenID Connect is used,
00:09:33.180 --> 00:09:43.269
for example, by Google. So these are the
most commonly used single-sign-on systems.
00:09:43.269 --> 00:09:49.250
There's also some others, for example,
Mozilla Persona. Who of you have heard
00:09:49.250 --> 00:09:59.090
about Mozilla persona.? Oh, OK. Around
five percent, more or less. So, the
00:09:59.090 --> 00:10:06.340
original name is BrowserID and there the
idea was that the email providers become
00:10:06.340 --> 00:10:12.320
the identity providers. So this comes from
the thought that for classical website
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
00:10:17.089 --> 00:10:23.970
into your account and to reset your
password. So your identity, your e-mail
00:10:23.970 --> 00:10:28.810
provider already is the kind of identity
provider. So why don't we just use it
00:10:28.810 --> 00:10:35.040
directly in the Web? And Mozilla Persona
is the first single-sign-on system with
00:10:35.040 --> 00:10:40.899
the goal that we have some kind of privacy
in the sense that the identity provider
00:10:40.899 --> 00:10:45.870
does not learn where you use your
accounts. So we will talk about this also
00:10:45.870 --> 00:10:51.149
later in this talk. So it was developed by
Mozilla and the first idea was to
00:10:51.149 --> 00:10:58.959
integrate this protocol in the browsers,
which never happened. So they went from
00:10:58.959 --> 00:11:05.250
the target to have a pure Web
implementation using just HTML5. And they
00:11:05.250 --> 00:11:13.870
also built bridges to OpenID and OAuth 2
to get some big identity providers in the
00:11:13.870 --> 00:11:19.450
system. But this this whole approach
failed. But it's still interesting if you
00:11:19.450 --> 00:11:27.780
want to look for privacy. OK, there are
also some other protocols I haven't talked
00:11:27.780 --> 00:11:32.820
about, and now I will hand over to Daniel.
00:11:32.820 --> 00:11:36.079
Daniel Fett: So what is this talk all
about?
00:11:36.079 --> 00:11:40.399
applause
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
00:11:45.540 --> 00:11:50.750
where the web mechanisms in this case
websites and protocols are secure when
00:11:50.750 --> 00:11:55.880
they are implemented correctly. So this
means if we follow all the standards and
00:11:55.880 --> 00:12:01.010
all the best practices, on other words:
Are the standards and protocols that
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
00:12:11.400 --> 00:12:17.690
documents that define some locking
mechanism, for example, like OAuth, and we
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
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
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
00:12:35.190 --> 00:12:41.780
change this. In a way that has been
already successful for other things in
00:12:41.780 --> 00:12:48.430
Internet, for example, for TLS. We want to
create a model of the Web infrastructure
00:12:48.430 --> 00:12:53.470
and of Web applications, the former model.
And these models, of course, they are also
00:12:53.470 --> 00:13:02.360
always incomplete, but nonetheless useful,
as has been shown with TLS 1.3. So we
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
00:13:08.279 --> 00:13:17.680
can create proofs of security for
mechanisms of our standards. So of course
00:13:17.680 --> 00:13:27.079
the hard part is number 2 here, as always.
Some things our model cannot capture and
00:13:27.079 --> 00:13:32.449
we don't want to capture this. So, for
example, phishing attacks or clickjacking
00:13:32.449 --> 00:13:37.209
attacks or just stupid users. Let's send
that password to the attacker. These are
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
00:13:42.750 --> 00:13:53.220
manner, compromised browsers or
compromised databases and so on. When we
00:13:53.220 --> 00:13:59.540
have this model for a Web application, one
important question and maybe the most
00:13:59.540 --> 00:14:04.769
important question is what is security and
what is privacy if you want to look at
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
00:14:10.631 --> 00:14:15.500
a formal model like we have and a
following, of course, I'm not going to
00:14:15.500 --> 00:14:20.779
present all the formal stuff, this is
boring. Therefore, I have a high level
00:14:20.779 --> 00:14:25.089
overview of what authentication
properties, for example, look like.
00:14:25.089 --> 00:14:30.889
Authentication in the Web single-sign-on
system means that an attacker that even
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
00:14:36.250 --> 00:14:41.370
relying party as an honest user. So the
NSA should be unable to log into my
00:14:41.370 --> 00:14:48.170
account at least. Yeah, if they're not
forcing the owner of relying party or
00:14:48.170 --> 00:14:57.399
something. And this is an obvious property
there's a slightly less obvious property,
00:14:57.399 --> 00:15:01.871
which says that an attacker should not be
able to authenticate an honest browser to
00:15:01.871 --> 00:15:09.649
relying party as the attacker. So the
attacker should be unable to force Alice's
00:15:09.649 --> 00:15:14.100
browser to be locked in under the
attackers identity. This is a property
00:15:14.100 --> 00:15:18.790
that is often also called session fixation
or session swapping, because if the
00:15:18.790 --> 00:15:22.759
attacker would be able to do this, he
could, for example, force me to be locked
00:15:22.759 --> 00:15:28.139
in at some search engine. And if I then
search something with a search engine and
00:15:28.139 --> 00:15:32.589
I'm locked into the attackers account,
then the attacker could be able to read
00:15:32.589 --> 00:15:37.149
what I'm searching for in this search
engine. OK, so these are the
00:15:37.149 --> 00:15:42.420
authentication properties. Then we also
have another property that is important,
00:15:42.420 --> 00:15:49.970
namely session integrity . Session
integrity means that if the relying party
00:15:49.970 --> 00:15:54.621
acts on Alice's behalf at the identity
provider or retrieves Alice's data at the
00:15:54.621 --> 00:16:02.940
identity provider then Alice explicitly
expresses her consent to log in at this
00:16:02.940 --> 00:16:12.019
ruling party. So. There's a session
integrity and a third property that we
00:16:12.019 --> 00:16:19.000
have, is privacy and privacy in this case
means that a malicious identity provider
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
00:16:25.980 --> 00:16:33.899
B. So, for example, if OAuth would have
privacy, which it doesn't, then Facebook
00:16:33.899 --> 00:16:36.670
would be unable to tell whether I log in
at, say, Wikipedia or myfavoritebeer.com.
00:16:36.670 --> 00:16:46.000
There are also other notions of privacy,
which we, however, will not look at in
00:16:46.000 --> 00:16:59.270
this talk.
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
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
00:17:21.839 --> 00:17:30.650
other RFC's and some other documents.
OAuth itself has four different modes it
00:17:30.650 --> 00:17:35.360
can run. And so there is the Implicit
Mode, the Authorization Code Mode, the
00:17:35.360 --> 00:17:41.870
Resource Owner Password Credentials mode,
the Client Credentials mode and all these
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,
00:17:50.900 --> 00:17:55.820
the first two Implicit Mode and the
Authorization Code Mode are the most
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
00:18:02.880 --> 00:18:08.799
like this. Here we have an example with
some random relying party and Facebook as
00:18:08.799 --> 00:18:13.610
the identity provider. So first you say I
want to login with Facebook at your
00:18:13.610 --> 00:18:20.669
relying party, then your browser gets
redirected to Facebook. Facebook prompts
00:18:20.669 --> 00:18:25.429
you for your authentication data or for
some confirmation if you're already logged
00:18:25.429 --> 00:18:36.880
in at Facebook. And then Facebook issues a
token that's called the access token. And
00:18:36.880 --> 00:18:41.210
Facebook redirects your browser back to
the relying party and puts the access
00:18:41.210 --> 00:18:49.530
token in the URI. And then for some
technical reasons, we need some additional
00:18:49.530 --> 00:19:00.179
steps to retrieve the access token from
the URI because it's in the fragment part.
00:19:00.179 --> 00:19:05.400
And then finally, the relying party gets
to retrieve this access token. And now
00:19:05.400 --> 00:19:13.290
with this access token, an access token is
the same basically the same thing as in
00:19:13.290 --> 00:19:19.090
the in this first high level overview when
I just talked about tokens an access token
00:19:19.090 --> 00:19:25.090
is such a token, which gives the relying
party access to the user's account at
00:19:25.090 --> 00:19:31.909
Facebook. And now the relying party can
retrieve data on the user's behalf at
00:19:31.909 --> 00:19:37.809
Facebook or it can retrieve and user
identifier and then consider this user to
00:19:37.809 --> 00:19:44.870
be logged in and issue, for example, some
cookie. So this is the Implicit Mode.
00:19:44.870 --> 00:19:52.880
There is also the Authorization Code Mode
there. Things start similar. The user says
00:19:52.880 --> 00:19:58.010
I want to login with Facebook, gets
redirected to Facebook, authenticates at
00:19:58.010 --> 00:20:02.680
Facebook and then Facebook, instead of
issuing an access token, it issues the so-
00:20:02.680 --> 00:20:09.299
called authorization code and the relying
party then takes the authorization code
00:20:09.299 --> 00:20:14.820
and redeems it for an access token
directly at Facebook. So we have here some
00:20:14.820 --> 00:20:21.830
one intermediate step for this
authorization code and then the access
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
00:20:29.390 --> 00:20:37.710
Facebook or consider the user to be logged
in. So let's talk about selected attacks
00:20:37.710 --> 00:20:50.920
on OAuth. First, let's talk a bit about
known attacks, there are attacks like the
00:20:50.920 --> 00:20:57.800
so-called cut and paste attacks where you
reuse some of these tokens like access
00:20:57.800 --> 00:21:02.809
token, authorization code, or there are
also some other tokens, which I haven't
00:21:02.809 --> 00:21:10.390
talked about. So I left out some details
before. It's about reusing these tokens
00:21:10.390 --> 00:21:18.380
from different flows, mixing them into a
new flow and then break the system. So
00:21:18.380 --> 00:21:26.000
there are a lot of cut and paste attacks
known. And there OAuth working group is
00:21:26.000 --> 00:21:33.830
continuously giving tries on how to
prevent these cut-and-paste attacks.
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
00:21:39.480 --> 00:21:45.510
middle can easily read everything out, all
the tokens that are exchanged. So if you
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
00:21:51.490 --> 00:21:59.059
don't use HTTPS because some developers
forgot that there is the something called
00:21:59.059 --> 00:22:08.150
HTTPS, then basically the whole thing is
screwed. And also, if you just rely on
00:22:08.150 --> 00:22:15.210
cookies, then you're also screwed because
cookies lack integrity. It's very easy to
00:22:15.210 --> 00:22:22.460
just inject cookies into your browser over
HTTP, and then these cookies will later
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
00:22:33.640 --> 00:22:40.440
let's talk about some attacks we have
found in our research. There is the 307
00:22:40.440 --> 00:22:54.520
redirect attack and it works like this.
First, we have some regular OAuth flow. In
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,
00:22:59.730 --> 00:23:05.049
we have the user authentication. And after
this authentication, the user gets
00:23:05.049 --> 00:23:11.840
redirected back to relying party. If you
look more into the details of these
00:23:11.840 --> 00:23:20.669
requests, so first you have this request
where you go to your identity provider and
00:23:20.669 --> 00:23:26.799
ask, I have started OAuth flow there. So
you just came from the relying party where
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
00:23:32.140 --> 00:23:38.100
redirected and then your browser contacts
this identity provider here I have been
00:23:38.100 --> 00:23:47.390
redirected to you in OAuth flow. Please
authenticate the user. So this is a step
00:23:47.390 --> 00:23:53.520
2.a then your identity provider returns
some form where you have to enter your
00:23:53.520 --> 00:23:58.350
username and password usually, and then
you enter username and password and these
00:23:58.350 --> 00:24:03.690
are sent over to the identity provider.
And now if this identity provider
00:24:03.690 --> 00:24:10.779
redirects you back to the relying party
and uses the wrong HTTP location redirect
00:24:10.779 --> 00:24:18.630
method for this, namely the 307 method,
then the following happens. The browsers
00:24:18.630 --> 00:24:23.900
instructed to just repost all of your
credentials. So if you're logging in that
00:24:23.900 --> 00:24:31.059
some malicious relying party, that relying
party gets your username and password. So
00:24:31.059 --> 00:24:36.880
this happens if you use 307, redirect.
Fortunately, we didn't find any identity
00:24:36.880 --> 00:24:43.000
provider in the wild to actually use 307.
But you can never exclude that there is
00:24:43.000 --> 00:24:49.730
some implementation which makes actually
use of this location redirect method.
00:24:49.730 --> 00:24:54.970
Also, if you look at the standard, how
these are defined, it's not always clear
00:24:54.970 --> 00:25:02.409
which redirects method has which details
and behavior. And also the OAuth working
00:25:02.409 --> 00:25:07.460
group didn't think about this. So in their
standard, their write, you just use any
00:25:07.460 --> 00:25:16.350
method. And surely the mitigation here is
don't use 307, for example, use 303
00:25:16.350 --> 00:25:22.190
instead. So the next attack is the
identity provider mix-up attack. I will
00:25:22.190 --> 00:25:30.770
present this in Implicit Mode and only one
variant of this attack. So here in this
00:25:30.770 --> 00:25:38.690
attack, we have to have the following
setting. From step two on all these
00:25:38.690 --> 00:25:44.289
requests are usually encrypted. But the
very, very first request there, we cannot
00:25:44.289 --> 00:25:50.399
be sure it is encrypted because a lot of
relying parties when you go to the
00:25:50.399 --> 00:25:57.250
website, you go over HTTP. And this the
very first information we just click I
00:25:57.250 --> 00:26:02.720
want to use Facebook to log in there. You
could easily assume this is not a
00:26:02.720 --> 00:26:10.480
sensitive information. So this a very
first request goes off an unencrypted or
00:26:10.480 --> 00:26:16.049
if you, for example, consider other
attacks like TLS stripping, then you also
00:26:16.049 --> 00:26:25.460
cannot guarantee that this request is
encrypted. So now for an attacker who, for
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
00:26:31.760 --> 00:26:37.360
easily mount the attack as follows. So
when your browser sends this request to
00:26:37.360 --> 00:26:44.370
relying party, login with Facebook, the
attacker can easily change this and change
00:26:44.370 --> 00:26:51.370
its to just use the identity provider that
is run by the attacker. Remember, you can
00:26:51.370 --> 00:26:56.030
have a lot of different options of
identity providers and with some
00:26:56.030 --> 00:27:04.529
extension, this can also be extended
dynamically just by entering some domains.
00:27:04.529 --> 00:27:09.179
And then the relying party thinks, OK,
that user wants to use the attacker
00:27:09.179 --> 00:27:17.919
identity provider. It answers with the
redirect to the attackers web page. But
00:27:17.919 --> 00:27:21.530
now the as the attacker attackers still
sits in the middle, he can just change it
00:27:21.530 --> 00:27:28.990
back to Facebook. So the old dance
continues as usual. You go to Facebook,
00:27:28.990 --> 00:27:33.710
authenticate there, you get redirected
back. There's probably some access token
00:27:33.710 --> 00:27:40.840
and then eventually the relying party
retrieve this access token and wants to
00:27:40.840 --> 00:27:47.019
use this access token. So what happens? It
won't use this access token at Facebook,
00:27:47.019 --> 00:27:51.880
but at the relying at the attacker
instead, because it still thinks that the
00:27:51.880 --> 00:27:57.549
attacker is for the identity provider that
is used here. So in practice, if you want
00:27:57.549 --> 00:28:03.321
to mount this attack, then you have to
take care of more details, like when you
00:28:03.321 --> 00:28:08.299
want to break authentication instead of
authorization. So in the version I just
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
00:28:13.779 --> 00:28:20.470
some other identity provider that he was
off. So this is not limited for Facebook,
00:28:20.470 --> 00:28:26.510
but for authentication of the relying
party. There are some other further steps
00:28:26.510 --> 00:28:31.760
needed. But there's also there are also
some other details that have to be taken
00:28:31.760 --> 00:28:37.961
care of, like client identifiers, which
are used by relying parties to identify
00:28:37.961 --> 00:28:44.159
themselves to identity providers, the same
for client credentials, which are
00:28:44.159 --> 00:28:50.990
optional, by the way, and an OpenID
Connect the layer on top of OAuth. If this
00:28:50.990 --> 00:28:56.710
is used, then you need to take care about
some other stuff, like the switching of
00:28:56.710 --> 00:29:02.990
some signatures or exchanging some
signatures and so on. But it's still
00:29:02.990 --> 00:29:08.470
possible so that we successfully attacked
real world applications. And this
00:29:08.470 --> 00:29:12.390
definitely works. And there are also some
variants that do not rely on that first
00:29:12.390 --> 00:29:19.730
request going over HTTPS. But explaining
all the variance would take a whole talk
00:29:19.730 --> 00:29:28.260
on its own, so we now skip this and talk
about mitigation. So the mitigation we
00:29:28.260 --> 00:29:35.230
propose is quite simple. So the the one
problem is you're in step three. This
00:29:35.230 --> 00:29:41.750
access token is just some opaque string.
Relying party cannot see who issued that
00:29:41.750 --> 00:29:46.580
access token. So it needs some further
information carried along with this
00:29:46.580 --> 00:29:51.909
system. And that is who is the identity
provider, which issued this access token.
00:29:51.909 --> 00:29:58.909
And if you have this information carried
along and then the relying party can
00:29:58.909 --> 00:30:05.390
easily detect this attack and see that
there is a mismatch between step five to
00:30:05.390 --> 00:30:11.661
the one in step 1.a, where relying line
party received the message the attacker's
00:30:11.661 --> 00:30:15.970
identity provider is to be used and in
five it gets the message she has access
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
00:30:20.830 --> 00:30:31.140
aborted without the attack being
successful. So this is the mitigation we
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
00:30:36.250 --> 00:30:43.429
emergency meeting to discuss this attack
and we scheduled public disclosure of
00:30:43.429 --> 00:30:50.429
these attacks. So at the beginning of this
year, in June, we had a district at
00:30:50.429 --> 00:30:55.240
security workshop which took place in
June. New RFC, with this service the
00:30:55.240 --> 00:31:02.559
mitigations is in preparation. And also
the working group is interested in the
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
00:31:10.929 --> 00:31:19.240
to sum up, the security for OAuth 2 these
fixes applied and there are no
00:31:19.240 --> 00:31:27.460
implementation errors, then we can say
that in terms of security OAuth 2 is quite
00:31:27.460 --> 00:31:36.559
good. We have formal proof in our model
for this, but regarding privacy OAuth 2
00:31:36.559 --> 00:31:41.799
does not provide any privacy at all.
00:31:41.799 --> 00:31:48.470
David: Speaking about privacy, we
mentioned earlier already that there was a
00:31:48.470 --> 00:31:54.419
single-sign-on system that tried to
provide privacy, namely BrowserID alias
00:31:54.419 --> 00:31:59.750
Mozilla Persona. So as we already said
before, this is a Web based single-sign-on
00:31:59.750 --> 00:32:04.889
system with design goals of having no
central authority and provide better
00:32:04.889 --> 00:32:14.210
privacy. Spoiler alert: they failed at
both. So how does BrowserID work? So let's
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
00:32:19.870 --> 00:32:25.440
browser I.D., the mail provider is the
identity provider. So we have a user,
00:32:25.440 --> 00:32:32.210
Alice, alice@mailprovider.com and in the
first phase when using BrowserID, she does
00:32:32.210 --> 00:32:37.880
the following, she goes to her identity
provider and first creates a
00:32:37.880 --> 00:32:43.830
public/private keypad. And then she sends
the public key in a document with an
00:32:43.830 --> 00:32:50.660
identity to the mal provider and the mail
provider then signs this document. And
00:32:50.660 --> 00:32:56.070
this creates the so-called user
certificate. And this certificate is then
00:32:56.070 --> 00:33:02.221
sent back to Alice. Now, in the second
phase, if Alice wants to actually log in
00:33:02.221 --> 00:33:09.620
that some website and then she does the
following she creates and another document
00:33:09.620 --> 00:33:14.350
containing the identity of the website
where she wants to log in, say Wikipedia,
00:33:14.350 --> 00:33:24.230
and to do so, she signs the identity of
Wikipedia with her own private key. And
00:33:24.230 --> 00:33:28.200
this creates the so-called identity
assertion. Now, Alice sends both documents
00:33:28.200 --> 00:33:34.059
to Wikipedia and Wikipedia can then, of
course, check these documents, because
00:33:34.059 --> 00:33:39.870
Wikipedia can check first it can retrieve
the public key of the mail provider, can
00:33:39.870 --> 00:33:46.500
check the user certificate, and then also
can check the identity assertion. And
00:33:46.500 --> 00:33:52.769
yeah, then Wikipedia can consider Alice to
be logged in. So this was the basic idea
00:33:52.769 --> 00:33:58.309
of BrowserID, which is quite nice and
clean and simple. And then they started to
00:33:58.309 --> 00:34:04.350
implement this using just the browser
features, including all the workarounds
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
00:34:10.260 --> 00:34:18.679
complicated system. So here we have on the
left side Alice's browser two Windows,
00:34:18.679 --> 00:34:23.599
namely Wikipedia and the login dialog,
which is provided by a central authority
00:34:23.599 --> 00:34:29.820
which they try to avoid login.persona.org
and inside both of these windows and other
00:34:29.820 --> 00:34:34.919
iframes and inside one of these iframes,
that's another iframe. And on the right we
00:34:34.919 --> 00:34:39.800
have the servers. So the relying party,
the identity provider and the central
00:34:39.800 --> 00:34:46.300
authority login.persona.org. And just to
give you an idea of how complex the system
00:34:46.300 --> 00:34:53.320
ended up, they all talk to each other
using HTTP requests, but also using
00:34:53.320 --> 00:34:59.990
postMessages and also using XML-HTTP
requests. And as you can see, the system
00:34:59.990 --> 00:35:08.370
became quite complex. To add even more
complexity, they did the following. They
00:35:08.370 --> 00:35:11.880
thought, well, some users, they are
already using Gmail or Yahoo! So let's
00:35:11.880 --> 00:35:19.290
provide some nice. Yeah. Interface for
them. They provided the so-called identity
00:35:19.290 --> 00:35:25.050
bridge specifically for Gmail and Yahoo!
Which at the time supported OpenID
00:35:25.050 --> 00:35:31.210
authentication only. And they created two
new servers, the so-called bridging
00:35:31.210 --> 00:35:38.620
servers, one for Gmail called Sideshow and
the other one for Yahoo! Called BigTent.
00:35:38.620 --> 00:35:45.650
Now, the user authenticates, authenticates
to the bridging server, using OpenID and
00:35:45.650 --> 00:35:54.819
then a bridging server has an interface to
the standard BrowserID interface. So one
00:35:54.819 --> 00:35:59.120
problem was that OpenID identities, they
are not email addresses. And so in OpenID
00:35:59.120 --> 00:36:06.109
you add an attribute, which is called the
email attribute. And, um, we're talking
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
00:36:11.640 --> 00:36:17.520
breaches work. We are not going into all
the details of the BrowserID or Persona
00:36:17.520 --> 00:36:21.280
protocol because this would be too
complicated. But the identity bridge is
00:36:21.280 --> 00:36:28.910
interesting and also important for some of
the attacks that we found. So in the
00:36:28.910 --> 00:36:32.631
identity bridge the following happens, so
here on the left, we have Alice's browser
00:36:32.631 --> 00:36:38.250
and in the middle we have Sideshow service
identity bridge and on the right side, we
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
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
00:36:51.800 --> 00:36:59.310
OpenID request requesting the email
attribute signed from Gmail. This request
00:36:59.310 --> 00:37:05.230
is then forwarded to Gmail. Gmail sees the
request, the user logs in a Gmail for
00:37:05.230 --> 00:37:12.250
authentication. And then Gmail creates
this OpenID assertion, which contains the
00:37:12.250 --> 00:37:17.790
signed email address attribute for Alice
and as you can see, this is all in the
00:37:17.790 --> 00:37:25.680
green box. So all properly signed. Nice.
And now Alice's browser redirects this
00:37:25.680 --> 00:37:31.849
document to Sideshow. Now Sideshow doesn't
check the contents of this decision for
00:37:31.849 --> 00:37:39.329
itself. Instead, it sends these things to
Gmail, Gmail checks everything that is
00:37:39.329 --> 00:37:45.200
signed. And Tells Sideshow, yes, this
document looks correct to me, everything
00:37:45.200 --> 00:37:51.670
that was signed was signed by me and was
not tampered with. Then Sideshow looks at
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
00:37:56.780 --> 00:38:04.290
Alice now and provides a cookie because
the user is now logged in as Alice. So
00:38:04.290 --> 00:38:12.040
far, simple. Now for some of the attacks
that we found. First attack, identity
00:38:12.040 --> 00:38:18.630
forgery. So here we have essentially the
same that we saw before, the same setting,
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
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
00:38:30.530 --> 00:38:37.790
Sideshow, sends this OpenID request to the
attacker and it can change this request,
00:38:37.790 --> 00:38:43.960
the attacker can just remove the request
for the email attribute from this request.
00:38:43.960 --> 00:38:51.790
Which is still a valid OpenID request.
Gmail sees this request, and now the
00:38:51.790 --> 00:38:56.050
attacker logs in. The attacker doesn't
have Alice's user data so the attacker
00:38:56.050 --> 00:39:03.329
just logs in with his own credentials. And
now Gmail creates an automatic assertion
00:39:03.329 --> 00:39:10.560
containing the signed attribute, which was
requested, which was nothing. So
00:39:10.560 --> 00:39:16.430
essentially, the document is empty, at
least without any email address. Now, the
00:39:16.430 --> 00:39:23.800
attacker can simply add a new attribute to
this document containing an email address
00:39:23.800 --> 00:39:31.330
that he has chosen arbitrarily. This, of
course, is not signed, which is not a
00:39:31.330 --> 00:39:37.740
problem because this document can be
partly signed and this document is
00:39:37.740 --> 00:39:43.640
forwarded to Gmail. Gmail now analyzes
this document and sees whether there is a
00:39:43.640 --> 00:39:49.530
signed part in this document. So I check
this signed part. The signed part doesn't
00:39:49.530 --> 00:39:59.950
contain anything useful, but it is
correct. It's not the wrong signature. So
00:39:59.950 --> 00:40:05.400
it sends back to Sideshow: there I checked
this document looks fine to me. Now
00:40:05.400 --> 00:40:09.630
Sideshow looks at a document, sees that as
an email attribute, uses this email
00:40:09.630 --> 00:40:18.250
attribute and the attacker is signed into
any Gmail account that he likes with using
00:40:18.250 --> 00:40:25.300
BrowserID. OK, so this is bad, as you can
imagine. And we told the Mozilla guys
00:40:25.300 --> 00:40:30.960
about this and they were quite fast. So we
were really surprised. They were really
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
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
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
00:40:46.850 --> 00:40:54.369
quite good. But then we took another look
at the system and we found identity
00:40:54.369 --> 00:41:02.569
forgery number two, which is actually
remarkably similar to works as follows. So
00:41:02.569 --> 00:41:06.270
the attacker, since the authentication
requests, you know this part at Sideshow
00:41:06.270 --> 00:41:12.570
once the signed e-mail attribute and the
attacker now doesn't change anything, the
00:41:12.570 --> 00:41:18.370
attacker just forwards this request to
Gmail, Gmail, ask for the credentials, the
00:41:18.370 --> 00:41:25.800
attacker signs and and sends back the
OpenID assertion containing the signed
00:41:25.800 --> 00:41:31.690
email address of the attacker. So no
attack to up to this point. But now the
00:41:31.690 --> 00:41:37.381
attacker can do the following. The
attacker adds another attribute, another
00:41:37.381 --> 00:41:47.250
email attribute. And yeah, you can guess
what happens. The document is forwarded to
00:41:47.250 --> 00:41:53.690
Gmail. Gmail checks the signed part of the
document, which is still fine, sends back
00:41:53.690 --> 00:41:57.849
to Sideshow that everything is fine with
this document. And Sideshow selects the
00:41:57.849 --> 00:42:04.880
wrong email address. Yeah, and now the
user, the attacker signed into any user
00:42:04.880 --> 00:42:14.410
account again. OK, so this was the second
identity forgery attack. We also found
00:42:14.410 --> 00:42:19.230
another attack, which is not very
spectacular. And we also looked so this
00:42:19.230 --> 00:42:26.589
was all, of course, authentication. And we
also took a look at privacy so as to
00:42:26.589 --> 00:42:34.170
remember privacy says that, in the words
of Mozilla, the browser ID protocol never
00:42:34.170 --> 00:42:42.630
leaks tracking information back to the
identity provider, except it does. So
00:42:42.630 --> 00:42:46.381
ideally, the identity provider should be
unable to tell whether user logs in. In
00:42:46.381 --> 00:42:55.420
fact, this is broken, because in the
browser, the following happens. If
00:42:55.420 --> 00:43:00.200
malicious identity provider wants to find
out whether a user is logged in at some
00:43:00.200 --> 00:43:05.500
specific relying party or not, then the
malicious identity provider can just open
00:43:05.500 --> 00:43:13.930
iframe containing the website of that
relying party he wants to probe. Now the
00:43:13.930 --> 00:43:19.330
following happens, the normal JavaScript
of BrowserID runs in this relying party
00:43:19.330 --> 00:43:25.340
because it has provided support,
obviously, and creates an iframe and
00:43:25.340 --> 00:43:32.030
inside this iframe, another iframe will be
created. But this innermost iframe will
00:43:32.030 --> 00:43:39.900
only be created if the user logged in at
this RP before. Now, since the outermost
00:43:39.900 --> 00:43:43.730
and the innermost iframe, they come from
the same source and of course they can
00:43:43.730 --> 00:43:50.260
collaborate and communicate. They can for
example, just send postMessage saying: I,
00:43:50.260 --> 00:43:56.460
the user logged in at this ruling party
before. So an identity provider can easily
00:43:56.460 --> 00:44:02.609
probe whether a user logged in at some
relying party or not. And this
00:44:02.609 --> 00:44:05.550
unfortunately cannot be fixed without a
major redesign of BrowserID, because they
00:44:05.550 --> 00:44:12.619
relied on all these iframes and so on.
Yeah. So I think this can be considered
00:44:12.619 --> 00:44:18.940
broken beyond repair. We also found some
variants of these privacy attacks which
00:44:18.940 --> 00:44:26.300
rely on other mechanisms. But essentially.
Yeah, you get the idea right here. Privacy
00:44:26.300 --> 00:44:35.619
of BrowserID is broken. OK, so to sum up
BrowserID, we found attacks, but we also
00:44:35.619 --> 00:44:44.849
were able to fix them with respect to
security, and we also used our formal
00:44:44.849 --> 00:44:51.250
methods to improve the security of the
fixed BrowserID system. But privacy is
00:44:51.250 --> 00:44:55.000
broken beyond repair.
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
00:45:00.650 --> 00:45:08.559
provides security and privacy on the Web?
So we thought a lot about this question.
00:45:08.559 --> 00:45:16.460
And then we used our formal model to
design such a single-sign-on system. And
00:45:16.460 --> 00:45:22.700
we could also then use the former model to
prove that these properties are actually
00:45:22.700 --> 00:45:30.940
fulfilled. So the basic principle of the
system is called SPRESSO for Secure
00:45:30.940 --> 00:45:37.710
Privacy Respecting Single-Sign-On is the
following. We have the user with a
00:45:37.710 --> 00:45:44.150
browser. This user wants to log in at some
relying party, for example, at Wikipedia.
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
00:45:51.171 --> 00:45:58.250
e-mail provider as the identity provider.
So the user enters the email address and
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
00:46:07.770 --> 00:46:13.780
email provider, which is identity provider
in this case, authenticates there. And
00:46:13.780 --> 00:46:20.560
then this. The identity provider creates a
document that proves the Alice's identity
00:46:20.560 --> 00:46:25.540
and then forwards this document to the
relying party. And the relying party can
00:46:25.540 --> 00:46:31.510
check if everything is all right and then
consider the user to be loggged in. So
00:46:31.510 --> 00:46:37.010
let's have a closer look on how this
system works. So here again, we have
00:46:37.010 --> 00:46:45.089
Alice's browser, the window of the relying
party. Alice enters her email address. The
00:46:45.089 --> 00:46:49.130
email address is sent to relying party.
And now the relying party creates a
00:46:49.130 --> 00:46:55.630
document that contains the identity of the
relying party itself. And this document is
00:46:55.630 --> 00:47:01.590
encrypted and we call this document the
tag. So now the tag is sent, along with
00:47:01.590 --> 00:47:06.510
the key that was used to encrypt this
document. So this is symmetric encryption
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
00:47:16.089 --> 00:47:21.740
opens a new window of the identity
provider that is given by the domain of
00:47:21.740 --> 00:47:33.810
the email address and sends the tag over
to this window. This login dialog prompts
00:47:33.810 --> 00:47:40.550
the user to authenticate, so the user now
enters her password. And this is sent
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
00:47:47.300 --> 00:47:55.830
spoken of in the last slide and this
document, we call it the user certificate,
00:47:55.830 --> 00:48:02.210
user assertion, sorry, user assertion. We
send it back to the window at the login
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.
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
00:48:16.750 --> 00:48:25.150
party, the forwarder which serves just a
single static JavaScript file, and this is
00:48:25.150 --> 00:48:32.970
loaded in an iframe and is login dialog.
And this iframe gets the user assertion
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
00:48:40.000 --> 00:48:46.890
receiver and then it sends over the user
assertion through the window of the
00:48:46.890 --> 00:48:51.430
relying party which forwards it to the
server of the relying party, who could
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
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
00:49:03.569 --> 00:49:09.400
happens if we just don't have this
forwarder. So let's assume the user wants
00:49:09.400 --> 00:49:14.620
to log in at some malicious relying party
at attacker.com and there is an email
00:49:14.620 --> 00:49:19.230
address but the attacker wants to
impersonate the user who wants to log in
00:49:19.230 --> 00:49:24.339
at some other relying party. Let's say to
Wikipedia, for example, and the attacker
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.
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
00:49:39.450 --> 00:49:46.280
on, the user authenticates to her identity
provider. And then we just sent the tag
00:49:46.280 --> 00:49:52.109
over as the identity provider does not
know who is the intended receiver's
00:49:52.109 --> 00:49:58.430
because we want to have this privacy
feature. This just went through and the
00:49:58.430 --> 00:50:03.240
attacker gets the user certificate and
user assertion and forwards it to
00:50:03.240 --> 00:50:09.490
Wikipedia and then the attacker is
considered to be Alice. And this is that.
00:50:09.490 --> 00:50:16.569
So we need some mechanism to prevent that
the user assertion is forwarded to some
00:50:16.569 --> 00:50:21.550
random party, but only to the intended
receiver. And for this, we have this
00:50:21.550 --> 00:50:29.450
forwarder. Now, you can think this
forwarded may maybe be also malicious, but
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
00:50:33.920 --> 00:50:42.470
to us so the forwarder gets the user
assertion and he gets the key to decrypt
00:50:42.470 --> 00:50:48.500
the tag. And now he can instruct the
browser to send a postMessage, but only to
00:50:48.500 --> 00:50:54.540
give it to a window of Wikipedia. So the
browser checks is the receiver of the
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
00:51:00.270 --> 00:51:07.300
this protects the, um, the user assertion
certain to be leaked. And now you may
00:51:07.300 --> 00:51:12.420
think this forwarder may be malicious and
deliver some other script that does
00:51:12.420 --> 00:51:17.680
strange things like forwarding things att
start to the attacker directly. But we can
00:51:17.680 --> 00:51:22.130
enforce that the correct script is running
inside that iframe using separate source
00:51:22.130 --> 00:51:29.900
integrity where you just tell the browser
and this window only this code may run.
00:51:29.900 --> 00:51:36.390
And in this case the forwarder cannot just
put some arbitrary or malicious code in
00:51:36.390 --> 00:51:41.440
this iframe. And also there is no
information that leaks back from the
00:51:41.440 --> 00:51:48.960
browser to the forwarder. So to sum this
up, as I just presented SPRESSO, it
00:51:48.960 --> 00:51:55.390
features privacy and authentication. It's
open and decentralized. So you don't need
00:51:55.390 --> 00:52:02.510
any specific central party. It's compliant
to web standards. That's based on HTML5.
00:52:02.510 --> 00:52:09.849
And we have formal proof that all these
properties we've talked at the beginning
00:52:09.849 --> 00:52:14.740
actually hold and you can find a demo and
more information on spresso.me.
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
00:52:26.181 --> 00:52:30.880
think most of the time about OAuth 2.0.
Most of the results also translate to
00:52:30.880 --> 00:52:37.510
OpenID Connect. We have formally proven
the security of the protocol of OAuth and
00:52:37.510 --> 00:52:47.040
also OpenID Connect. Which is a nice
result, of course, if you're OK with
00:52:47.040 --> 00:52:53.210
having no privacy, because OAuth and
OpenID Connect don't have any kind of
00:52:53.210 --> 00:53:00.650
privacy that we talked about. Regarding
OAuth 1.0 and OpenID, I think that can be
00:53:00.650 --> 00:53:05.040
considered deprecated and shouldn't be
used. BrowserID, Mozilla Persona was a
00:53:05.040 --> 00:53:15.060
nice experiment. But is dead now and also
has broken privacy. With SPRESSO we have
00:53:15.060 --> 00:53:19.359
shown, however, that you can achieve
privacy on web single-sign-on using
00:53:19.359 --> 00:53:25.940
standard HTML5 features and standard web
features. But of course for now it is a
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
00:53:34.270 --> 00:53:39.920
and one target audience are certainly
developers, developers, developers use
00:53:39.920 --> 00:53:47.240
libraries wherever possible. For example,
the pyoidc is written even by members of
00:53:47.240 --> 00:53:56.890
the OAuth and OpenID working groups. So
they know what they do. Hopefully. Also
00:53:56.890 --> 00:54:03.070
regarding RFC's, they are hard to read and
information is often spread across several
00:54:03.070 --> 00:54:08.970
documents. They are often not written
clearly and they are not always up to
00:54:08.970 --> 00:54:16.270
date, but they are still an important
reference. And I think it's a good advice
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
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
00:54:27.940 --> 00:54:33.750
Maschinendeck assemblyin hall 3 free or
join us at the next Pi and More,shameless
00:54:33.750 --> 00:54:40.170
plug here, January 14 in Krefield or at
University of Stuttgart starting in
00:54:40.170 --> 00:54:46.710
January. Thank you very much.
00:54:46.710 --> 00:54:52.369
applause
00:54:52.369 --> 00:54:56.880
Presenter: Now we have eight minutes for
questions, what do we have from the
00:54:56.880 --> 00:55:02.700
Internet?
Question (internet): So we've got two
00:55:02.700 --> 00:55:10.790
questions from the Internet. You can you
hear me? So at the diagram you showed one
00:55:10.790 --> 00:55:16.369
of the first slides, why does the
authentication follow authorization?
00:55:16.369 --> 00:55:21.839
Shouldn't it normally be the other way
around?
00:55:21.839 --> 00:55:32.530
Presenter: Can you try to repeat the
question?
00:55:32.530 --> 00:55:40.130
Internet: Yeah, sorry, at the diagram you
showed in one of the first slides. Why
00:55:40.130 --> 00:55:46.099
does the why does the authentication
follow authorization? Shouldn't it
00:55:46.099 --> 00:55:53.150
normally be the other way around?
Guido: OK, so these are two concepts that
00:55:53.150 --> 00:56:03.650
are kind of orthogonal to each other. So
you can either do authentication to ensure
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
00:56:08.650 --> 00:56:14.329
provider, like posting on the user's
Facebook timeline or doing different
00:56:14.329 --> 00:56:21.900
things there. But for authentication, you
need to retrieve some unique user
00:56:21.900 --> 00:56:29.349
identifier. And this basically you make
use of this authorization mechanism. So
00:56:29.349 --> 00:56:35.010
you get authorized to access this unique
user identifier and you use this then for
00:56:35.010 --> 00:56:40.280
authentication.
Presenter: Thank you. Questions from here.
00:56:40.280 --> 00:56:46.720
Question 2: So for the special protocol,
you said you need the forwarding party to
00:56:46.720 --> 00:56:51.190
check whether this certificate was
actually from Wikipedia or not from
00:56:51.190 --> 00:56:55.069
attacker.com. But could Alice do this
check herself?
00:56:55.069 --> 00:57:02.210
Guido: You mean that you should present
the user something and the user accepts
00:57:02.210 --> 00:57:07.410
this and or declines this in this sense?
Or...
00:57:07.410 --> 00:57:11.920
Question 2: She has the challenge that is
signed by her email provider and she has
00:57:11.920 --> 00:57:15.990
the key that encrypted Wikipedia's
identity. So she could use that to decrypt
00:57:15.990 --> 00:57:19.240
it and check if it's Wikipedia or
attacker.com.
00:57:19.240 --> 00:57:23.230
Guido: Yeah, yeah. I mean, in principle,
yes.
00:57:23.230 --> 00:57:26.770
Daniel: So you mean the user?
Question 2: Yeah, yes.
00:57:26.770 --> 00:57:30.300
Daniel: Yes. The user could, of course,
check. We could ask the user, did you
00:57:30.300 --> 00:57:35.950
really want to sign attacker.com or
wikipedia.com? But of course, we all know
00:57:35.950 --> 00:57:42.190
that users are better at making decisions.
So, yeah.
00:57:42.190 --> 00:57:47.280
Presenter: Thank you. Questions from here?
Question 3: Hi, thanks for the informative
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
00:57:51.619 --> 00:57:55.150
falling victim to clickjacking and
phishing because they are working
00:57:55.150 --> 00:58:02.109
professionally on them on enabling
clickjacking and phishing. And if you need
00:58:02.109 --> 00:58:06.349
a 4K monitor just to see that there is
some JavaScript edit that like thousand
00:58:06.349 --> 00:58:13.869
zero delimiters, it is impossible to blame
the user for being stupid or falling
00:58:13.869 --> 00:58:19.849
victim to clickjacking.
Daniel: Yes, that's correct. It also
00:58:19.849 --> 00:58:28.119
sometimes you just can't see it. So yes.
Presenter: Thank you. Questions from down
00:58:28.119 --> 00:58:35.260
there? Sorry. Questions?
Question 4: You talked about formal
00:58:35.260 --> 00:58:43.750
verification of both the OAuth and your
protocol. I wanted to know what kind of
00:58:43.750 --> 00:58:49.849
program or whatever you used like ProVerif
or Tamarin or whatever. And also, I think
00:58:49.849 --> 00:58:56.559
you just proved the, you just verified a
subset of OAuth?
00:58:56.559 --> 00:59:02.540
Daniel: Let's start with the second
question first. So for OAuth, we really
00:59:02.540 --> 00:59:07.500
tried to introduce as many options as we
could find in the standard, so to say.
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.
00:59:13.870 --> 00:59:19.190
We had to exclude some of them for
practical reasons when modeling the stuff.
00:59:19.190 --> 00:59:25.540
But we included almost all of the options
that are provided. And we also have a
00:59:25.540 --> 00:59:31.460
detailed write up of what the options are
and what we excluded and what we included.
00:59:31.460 --> 00:59:36.599
And now for the first part of the
question, our model currently is a manual
00:59:36.599 --> 00:59:44.039
model. So what we do is pen and paper
proves. The reasoning behind this is that
00:59:44.039 --> 00:59:51.059
if you have tools, they are always, in
some sense, limiting you. And when we
00:59:51.059 --> 00:59:58.369
started out with this work, there was or
there were two models, essentially already
00:59:58.369 --> 01:00:04.099
existing web models, former models so in
the same area as we are. But they were
01:00:04.099 --> 01:00:11.670
both based on a model checker, so one on
ProVerif, one on another modeling tool...
01:00:11.670 --> 01:00:15.190
Guido: Alloy.
Daniel: Alloy. And both were limited by
01:00:15.190 --> 01:00:19.859
the possibilities that you had in these
model checkers. So what we went the other
01:00:19.859 --> 01:00:24.750
way around, what we wanted to do was a
manual model that includes, that models
01:00:24.750 --> 01:00:29.510
the web really precisely and
comprehensively. And then as a second step
01:00:29.510 --> 01:00:35.510
what we are currently working on or
discussing about is to transfer this into
01:00:35.510 --> 01:00:38.910
some kind of tool.
Question 4: Thank you.
01:00:38.910 --> 01:00:43.340
Presenter: Two more questions, questions
from the Internet?
01:00:43.340 --> 01:00:51.349
Internet: So I was wondering if you know
about ND-Auth(?) and RealMe Auth and what
01:00:51.349 --> 01:00:57.300
you think about the question of using
domain names vs. email addresses as the
01:00:57.300 --> 01:01:01.190
user identifier.
Daniel: Could you repeat that a bit
01:01:01.190 --> 01:01:05.350
louder?
Internet: So if you have any comments
01:01:05.350 --> 01:01:12.220
aboutND-Auth(?) and RealMe Auth which is
the domain name as identifier rather than
01:01:12.220 --> 01:01:16.329
an email address.
Daniel: So we didn't look at these
01:01:16.329 --> 01:01:21.230
systems.
Presenter: Yes, last question.
01:01:21.230 --> 01:01:27.490
Question 5: The question regarding the
forwarder and the privacy protection, I
01:01:27.490 --> 01:01:32.339
realized with the forwarder as far as I
understand, the forwarder is used in its
01:01:32.339 --> 01:01:38.720
own iframe to prevent the IDP from taking
control of the verification process,
01:01:38.720 --> 01:01:44.630
knowing that who is the the final system?
Guido: Yes.
01:01:44.630 --> 01:01:50.250
Question 5: But what if the identity
provider at the forward to collaborate,
01:01:50.250 --> 01:01:58.059
then the privacy would be broken? Yes. If
we have these parties collaborating then
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
01:02:03.750 --> 01:02:13.460
system. So this is really hard to prevent.
But in SPRESSO, the relying party is
01:02:13.460 --> 01:02:20.160
allowed to choose which forwarder has to
be used. So line party, so choose water
01:02:20.160 --> 01:02:25.599
run by some trustworthy party. So this is
the countermeasure to prevent
01:02:25.599 --> 01:02:30.789
collaboration. But if these parties
collaborate, then you are screwed. Yes.
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
01:02:35.440 --> 01:02:42.369
semi trusted party, because on the one
hand, we can enforce that as it uses the
01:02:42.369 --> 01:02:49.550
correct code. Of course, the IDP then has
to enforce this. On the other hand, you
01:02:49.550 --> 01:02:53.829
still have some side channels like, for
example, timing. So if you control the
01:02:53.829 --> 01:03:00.260
parties, then you could check which IP
addresses access for example, the
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
01:03:06.760 --> 01:03:11.569
the idea that we have to minimize this
risk is to provide a set of trusted
01:03:11.569 --> 01:03:20.480
forwarders that could be, for example,
provided by some trusted parties like
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
01:03:25.050 --> 01:03:29.119
and hopefully choose a trusted one.
Question 5: Thank you.
01:03:29.119 --> 01:03:32.440
Daniel: You're welcome.
Presenter: Guido Schmitz and Daniel Fett,
01:03:32.440 --> 01:03:48.650
thank you so much for the great talk.
Please give a great round of applause.
01:03:48.650 --> 01:03:53.970
applause
01:03:53.970 --> 01:03:57.309
postroll music
01:03:57.309 --> 01:04:05.000
Subtitles created by many many volunteers and
the c3subtitles.de team. Join us, and help us!