On the Security and Privacy of Modern Single Sign-On in the Web (33c3)

33C3 preroll music

Presenter: So I think we're all set
without further ado, I would like to I

would like to introduce Guido Schmitz and
Daniel Fett, who are going to be having

this talk on a single-sign-on on the web.
Give them a big round of applause. And I

hope you're looking forward to the talk

Guido: OK, hello, everybody, welcome to
our talk on the security and privacy of

modern single-sign-on the web. So in this
talk, Daniel and me, we are going to

pretend not only just a OAuth and OpenID
Connect, but also some thoughts about

analysis of all these standards. So first,
a brief introduction who are. We are

researchers from the University of Trier,
but soon of University of Stuttgart. And

also we happen to be the founders of the
Maschinendeck, the hackerspace in Trier

and the Pi and More raspberry jam. If
you're interested in anything else, what

we are doing, you can just follow us on
Twitter. So what is the single-sign-on

about? What are we talking about? So
probably all of you have seen websites

like this, like TripAdvisor, that you can
use a lot of different methods to sign and

you can sign in with your Facebook
account, with your Google account, you can

register account at their page with the
email address and password, or you can use

your Samsung account or probably now even
more different systems. And if you click,

for example, on this login with Facebook
button and new window pops up, prompting

for your Facebook credentials, or if you
already signed into Facebook, just asks

for confirmation. So this is a setting we
are looking at and we have two parties

here. We have the we have TripAdvisor as
the so-called relying party and we have

Facebook as the so-called identity
provider. And the basic principle of how

this works is the following. So first you
go with your browser to the relying party.

You say, I want to log in that RP, then
you contact your identity provider,

authenticate there. And this identity
provider then issues some kind of token

and this token you give to the relying
party. And the ruling party can now use

this token to access some parts of your
account at the identity provider. And this

is called authorization, for example, the
ruling party can use this token now to

post on your Facebook timeline or reach
out your friends list from Facebook. And

it the ruling party can also retrieve some
unique user identifier and then consider

you to be locked in with that user
identifier. And then this is

authentication. And then RP can set, for
example, sensation Cookie and Mark. This

session belongs. Remember that this
session belongs to this user. So this is

the basic the basic principle. Why should
we use single-sign-on or why we shouldn't

use single-sign-on? So for users, it's
very convenient. You don't have to

remember which account you used where,
which password and so on. You just click

and login with Facebook and you're all
done. Of course, this comes with lack of

privacy because Facebook then always knows
where you log in. And also the identity

provider you choose is also the single
point of failure. If that one closes down

or changes its terms and conditions, then
you perhaps cannot log into your accounts

anymore at some third party web pages. So
relying parties, they need to store less

data. They don't have to care about
password databases that can leak. They

don't have to care about user
registration, password recovery on all the

hassle that comes with user accounts. But
they also have less control over this,

over the users accounts because they
outsource the authentication to this

identity provider and also hear the
identity provider as a single point of

failure. Far identity providers, the
advantage is clear. They get more user

data and they can provide some service for
their users, which makes, perhaps it makes

it more attractive for users to use that
identity provider. On the downside, they

also have to take care about more user
data. They have to store and protect it,

and they have to have the overhead of
implement, implementing and running the

single-sign-on system. So what are these
single-sign-on systems now? Now I will

show you some prominent examples, so there
is OAuth 1.0. So this is a not so modern

single-sign-on system, it's now 10 years
old. Many flaws are known for this system

and basically nobody uses it anymore
except for Twitter. So Twitter uses a

modified version of OAuth 1, which more or
less fixes all the known flaws. But in

general, we can say don't use OAuth 1.
There is also OpenID, which is also quite

old, nine years. It's not that user
friendly. It's a standard that's meant to

be super flexible for every corner use
case that they developers at that time

thought of. And this makes it also
extremely hard to use correctly because

you have a lot of things going on. Things
change during an OpenID running, and it's

not that nice to develop something for
OpenID. So also, OpenID, don't use this.

And now modern single-sign-on systems, for
example, OAuth 2, which is also used in

login with Facebook. This is completely
incompatible to OAuth 1 and OAuth 2 uses

the so-called Bearer token approach. The
old protocol is based on some random

values that are passed around. But there's
no crypto involved except for the

transport layer for HTTPS, for example,
and OAuth2 is used everywhere, almost. So

it's the most popular of these systems,
but it has never been developed for

authentication and really, it's not meant
for authentication. And if you google for

OAuth 2 and authentication, you have to
sometimes stumble upon the following

picture. So these two guys are members of
the OAuth working group and they are

really insist it's not meant for
authentication at all. It's just for

authorization. OK. Nonetheless, it is used
in practice also for authentication.

Facebook, for example, uses it for
authentication. And so the protocol is now

five years old. Many flaws have been
discovered. Most of them have been fixed.

I will talk about some of these flaws
later in the talk. So this is OAuth 2 and

there's also OpenID Connect. OpenID
Connect is quite new. It's from one and a

half years old and it's an authentication
layer on top of OAuth. So the first

definition or real definition on how you
should use of for authentication, but it

changes the standard also so it can be
seen as the protocol on its own, but

OpenID Connect, although despite the name,
it's also completely incompatible to

OpenID. And it has also some dynamic
features like IdP, Discovery and identity

provider Discovery and stuff like that. So
this leads us to the Web, single-sign-on

chart of confusion. So we have OAuth 1
which is the marketing predecessor off of

2, but completely incompatible to OAuth 2
and OAuth 2 serves as the foundation for

login with Facebook, for authentication
and also for OpenID Connect and OpenID

Connect, there is OpenID, which is the
marketing predecessor of OpenID Connect,

but also same here, it's not compatible to
each other. And OpenID Connect is used,

for example, by Google. So these are the
most commonly used single-sign-on systems.

There's also some others, for example,
Mozilla Persona. Who of you have heard

about Mozilla persona.? Oh, OK. Around
five percent, more or less. So, the

original name is BrowserID and there the
idea was that the email providers become

the identity providers. So this comes from
the thought that for classical website

where you have to register, they send you
emails with tokens you can click on to log

into your account and to reset your
password. So your identity, your e-mail

provider already is the kind of identity
provider. So why don't we just use it

directly in the Web? And Mozilla Persona
is the first single-sign-on system with

the goal that we have some kind of privacy
in the sense that the identity provider

does not learn where you use your
accounts. So we will talk about this also

later in this talk. So it was developed by
Mozilla and the first idea was to

integrate this protocol in the browsers,
which never happened. So they went from

the target to have a pure Web
implementation using just HTML5. And they

also built bridges to OpenID and OAuth 2
to get some big identity providers in the

system. But this this whole approach
failed. But it's still interesting if you

want to look for privacy. OK, there are
also some other protocols I haven't talked

about, and now I will hand over to Daniel.

Daniel Fett: So what is this talk all
about?

applause

Daniel: So what is all talk all about? So
what we want to do is we want to analyze

where the web mechanisms in this case
websites and protocols are secure when

they are implemented correctly. So this
means if we follow all the standards and

all the best practices, on other words:
Are the standards and protocols that

define the web secure? The current state
of the art is that we have a lot of

documents that define some locking
mechanism, for example, like OAuth, and we

have an expert or group of experts and
they look at this and after a while they

say, well, this seems kind of OK to me. So
they say it's secure. So this is the

current state of the art. And what we want
to do also is part of our research is to

change this. In a way that has been
already successful for other things in

Internet, for example, for TLS. We want to
create a model of the Web infrastructure

and of Web applications, the former model.
And these models, of course, they are also

always incomplete, but nonetheless useful,
as has been shown with TLS 1.3. So we

create this model and then we put a lot of
work into this. And finally, hopefully we

can create proofs of security for
mechanisms of our standards. So of course

the hard part is number 2 here, as always.
Some things our model cannot capture and

we don't want to capture this. So, for
example, phishing attacks or clickjacking

attacks or just stupid users. Let's send
that password to the attacker. These are

things that are out of the scope of the
stuff that we are looking at. In the same

manner, compromised browsers or
compromised databases and so on. When we

have this model for a Web application, one
important question and maybe the most

important question is what is security and
what is privacy if you want to look at

privacy as well? So we have to define this
and luckily we can define this if we have

a formal model like we have and a
following, of course, I'm not going to

present all the formal stuff, this is
boring. Therefore, I have a high level

overview of what authentication
properties, for example, look like.

Authentication in the Web single-sign-on
system means that an attacker that even

has full control over the network say NSA
should not be able to use a service of a

relying party as an honest user. So the
NSA should be unable to log into my

account at least. Yeah, if they're not
forcing the owner of relying party or

something. And this is an obvious property
there's a slightly less obvious property,

which says that an attacker should not be
able to authenticate an honest browser to

relying party as the attacker. So the
attacker should be unable to force Alice's

browser to be locked in under the
attackers identity. This is a property

that is often also called session fixation
or session swapping, because if the

attacker would be able to do this, he
could, for example, force me to be locked

in at some search engine. And if I then
search something with a search engine and

I'm locked into the attackers account,
then the attacker could be able to read

what I'm searching for in this search
engine. OK, so these are the

authentication properties. Then we also
have another property that is important,

namely session integrity . Session
integrity means that if the relying party

acts on Alice's behalf at the identity
provider or retrieves Alice's data at the

identity provider then Alice explicitly
expresses her consent to log in at this

ruling party. So. There's a session
integrity and a third property that we

have, is privacy and privacy in this case
means that a malicious identity provider

should not be able to tell whether the
user logs in at the wrong party A or party

B. So, for example, if OAuth would have
privacy, which it doesn't, then Facebook

would be unable to tell whether I log in
at, say, Wikipedia or myfavoritebeer.com.

There are also other notions of privacy,
which we, however, will not look at in

this talk.

Guido: OK. Let's start with a closer look
to OAuth when I say OAuth, I always mean

OAuth 2 not the older OAuth 1. So OAuth 2
is mainly defined in RFC6749 and also some

other RFC's and some other documents.
OAuth itself has four different modes it

can run. And so there is the Implicit
Mode, the Authorization Code Mode, the

Resource Owner Password Credentials mode,
the Client Credentials mode and all these

modes can have so options, which I won't
list here. And out of these four modes,

the first two Implicit Mode and the
Authorization Code Mode are the most

common ones. So let's have a closer look
at these modes. So the Implicit Mode works

like this. Here we have an example with
some random relying party and Facebook as

the identity provider. So first you say I
want to login with Facebook at your

relying party, then your browser gets
redirected to Facebook. Facebook prompts

you for your authentication data or for
some confirmation if you're already logged

in at Facebook. And then Facebook issues a
token that's called the access token. And

Facebook redirects your browser back to
the relying party and puts the access

token in the URI. And then for some
technical reasons, we need some additional

steps to retrieve the access token from
the URI because it's in the fragment part.

And then finally, the relying party gets
to retrieve this access token. And now

with this access token, an access token is
the same basically the same thing as in

the in this first high level overview when
I just talked about tokens an access token

is such a token, which gives the relying
party access to the user's account at

Facebook. And now the relying party can
retrieve data on the user's behalf at

Facebook or it can retrieve and user
identifier and then consider this user to

be logged in and issue, for example, some
cookie. So this is the Implicit Mode.

There is also the Authorization Code Mode
there. Things start similar. The user says

I want to login with Facebook, gets
redirected to Facebook, authenticates at

Facebook and then Facebook, instead of
issuing an access token, it issues the so-

called authorization code and the relying
party then takes the authorization code

and redeems it for an access token
directly at Facebook. So we have here some

one intermediate step for this
authorization code and then the access

token, the relying party retrieved, it can
then use to act on the user's behalf at

Facebook or consider the user to be logged
in. So let's talk about selected attacks

on OAuth. First, let's talk a bit about
known attacks, there are attacks like the

so-called cut and paste attacks where you
reuse some of these tokens like access

token, authorization code, or there are
also some other tokens, which I haven't

talked about. So I left out some details
before. It's about reusing these tokens

from different flows, mixing them into a
new flow and then break the system. So

there are a lot of cut and paste attacks
known. And there OAuth working group is

continuously giving tries on how to
prevent these cut-and-paste attacks.

Another problem is if you don't use HTTPS,
then you are screwed because a man in the

middle can easily read everything out, all
the tokens that are exchanged. So if you

are in some Wi-Fi and the guy next to you
is sniffing on the Wi-Fi, you log in and

don't use HTTPS because some developers
forgot that there is the something called

HTTPS, then basically the whole thing is
screwed. And also, if you just rely on

cookies, then you're also screwed because
cookies lack integrity. It's very easy to

just inject cookies into your browser over
HTTP, and then these cookies will later

also be used over HTTPS. So the cookies
are also not a good thing to rely on. So

let's talk about some attacks we have
found in our research. There is the 307

redirect attack and it works like this.
First, we have some regular OAuth flow. In

this OAuth flow, if you have a closer look
at what happens here and step two to four,

we have the user authentication. And after
this authentication, the user gets

redirected back to relying party. If you
look more into the details of these

requests, so first you have this request
where you go to your identity provider and

ask, I have started OAuth flow there. So
you just came from the relying party where

you want to log in and click on that
button, log in with this IP, you get

redirected and then your browser contacts
this identity provider here I have been

redirected to you in OAuth flow. Please
authenticate the user. So this is a step

2.a then your identity provider returns
some form where you have to enter your

username and password usually, and then
you enter username and password and these

are sent over to the identity provider.
And now if this identity provider

redirects you back to the relying party
and uses the wrong HTTP location redirect

method for this, namely the 307 method,
then the following happens. The browsers

instructed to just repost all of your
credentials. So if you're logging in that

some malicious relying party, that relying
party gets your username and password. So

this happens if you use 307, redirect.
Fortunately, we didn't find any identity

provider in the wild to actually use 307.
But you can never exclude that there is

some implementation which makes actually
use of this location redirect method.

Also, if you look at the standard, how
these are defined, it's not always clear

which redirects method has which details
and behavior. And also the OAuth working

group didn't think about this. So in their
standard, their write, you just use any

method. And surely the mitigation here is
don't use 307, for example, use 303

instead. So the next attack is the
identity provider mix-up attack. I will

present this in Implicit Mode and only one
variant of this attack. So here in this

attack, we have to have the following
setting. From step two on all these

requests are usually encrypted. But the
very, very first request there, we cannot

be sure it is encrypted because a lot of
relying parties when you go to the

website, you go over HTTP. And this the
very first information we just click I

want to use Facebook to log in there. You
could easily assume this is not a

sensitive information. So this a very
first request goes off an unencrypted or

if you, for example, consider other
attacks like TLS stripping, then you also

cannot guarantee that this request is
encrypted. So now for an attacker who, for

example, sits in a same Wi-Fi network as
you, so probably the guy next to you could

easily mount the attack as follows. So
when your browser sends this request to

relying party, login with Facebook, the
attacker can easily change this and change

its to just use the identity provider that
is run by the attacker. Remember, you can

have a lot of different options of
identity providers and with some

extension, this can also be extended
dynamically just by entering some domains.

And then the relying party thinks, OK,
that user wants to use the attacker

identity provider. It answers with the
redirect to the attackers web page. But

now the as the attacker attackers still
sits in the middle, he can just change it

back to Facebook. So the old dance
continues as usual. You go to Facebook,

authenticate there, you get redirected
back. There's probably some access token

and then eventually the relying party
retrieve this access token and wants to

use this access token. So what happens? It
won't use this access token at Facebook,

but at the relying at the attacker
instead, because it still thinks that the

attacker is for the identity provider that
is used here. So in practice, if you want

to mount this attack, then you have to
take care of more details, like when you

want to break authentication instead of
authorization. So in the version I just

presented, the attacker gets the token can
act on the user's behalf at Facebook or at

some other identity provider that he was
off. So this is not limited for Facebook,

but for authentication of the relying
party. There are some other further steps

needed. But there's also there are also
some other details that have to be taken

care of, like client identifiers, which
are used by relying parties to identify

themselves to identity providers, the same
for client credentials, which are

optional, by the way, and an OpenID
Connect the layer on top of OAuth. If this

is used, then you need to take care about
some other stuff, like the switching of

some signatures or exchanging some
signatures and so on. But it's still

possible so that we successfully attacked
real world applications. And this

definitely works. And there are also some
variants that do not rely on that first

request going over HTTPS. But explaining
all the variance would take a whole talk

on its own, so we now skip this and talk
about mitigation. So the mitigation we

propose is quite simple. So the the one
problem is you're in step three. This

access token is just some opaque string.
Relying party cannot see who issued that

access token. So it needs some further
information carried along with this

system. And that is who is the identity
provider, which issued this access token.

And if you have this information carried
along and then the relying party can

easily detect this attack and see that
there is a mismatch between step five to

the one in step 1.a, where relying line
party received the message the attacker's

identity provider is to be used and in
five it gets the message she has access

token and it's from Facebook. So there's a
mismatch and this whole flow can be

aborted without the attack being
successful. So this is the mitigation we

talk to the OAuth working group at the
IETF, so they invited us to a kind of

emergency meeting to discuss this attack
and we scheduled public disclosure of

these attacks. So at the beginning of this
year, in June, we had a district at

security workshop which took place in
June. New RFC, with this service the

mitigations is in preparation. And also
the working group is interested in the

kind of formal analysis we do to this, we
carry out for these kind of standards. So

to sum up, the security for OAuth 2 these
fixes applied and there are no

implementation errors, then we can say
that in terms of security OAuth 2 is quite

good. We have formal proof in our model
for this, but regarding privacy OAuth 2

does not provide any privacy at all.

David: Speaking about privacy, we
mentioned earlier already that there was a

single-sign-on system that tried to
provide privacy, namely BrowserID alias

Mozilla Persona. So as we already said
before, this is a Web based single-sign-on

system with design goals of having no
central authority and provide better

privacy. Spoiler alert: they failed at
both. So how does BrowserID work? So let's

have a look at this on a very high level
first. So like Guido already said in

browser I.D., the mail provider is the
identity provider. So we have a user,

Alice, [e-mail] and in the
first phase when using BrowserID, she does

the following, she goes to her identity
provider and first creates a

public/private keypad. And then she sends
the public key in a document with an

identity to the mal provider and the mail
provider then signs this document. And

this creates the so-called user
certificate. And this certificate is then

sent back to Alice. Now, in the second
phase, if Alice wants to actually log in

that some website and then she does the
following she creates and another document

containing the identity of the website
where she wants to log in, say Wikipedia,

and to do so, she signs the identity of
Wikipedia with her own private key. And

this creates the so-called identity
assertion. Now, Alice sends both documents

to Wikipedia and Wikipedia can then, of
course, check these documents, because

Wikipedia can check first it can retrieve
the public key of the mail provider, can

check the user certificate, and then also
can check the identity assertion. And

yeah, then Wikipedia can consider Alice to
be logged in. So this was the basic idea

of BrowserID, which is quite nice and
clean and simple. And then they started to

implement this using just the browser
features, including all the workarounds

for the Internet Explorer and so on and so
on. And they ended up with a quite

complicated system. So here we have on the
left side Alice's browser two Windows,

namely Wikipedia and the login dialog,
which is provided by a central authority

which they try to avoid login.persona.org
and inside both of these windows and other

iframes and inside one of these iframes,
that's another iframe. And on the right we

have the servers. So the relying party,
the identity provider and the central

authority login.persona.org. And just to
give you an idea of how complex the system

ended up, they all talk to each other
using HTTP requests, but also using

postMessages and also using XML-HTTP
requests. And as you can see, the system

became quite complex. To add even more
complexity, they did the following. They

thought, well, some users, they are
already using Gmail or Yahoo! So let's

provide some nice. Yeah. Interface for
them. They provided the so-called identity

bridge specifically for Gmail and Yahoo!
Which at the time supported OpenID

authentication only. And they created two
new servers, the so-called bridging

servers, one for Gmail called Sideshow and
the other one for Yahoo! Called BigTent.

Now, the user authenticates, authenticates
to the bridging server, using OpenID and

then a bridging server has an interface to
the standard BrowserID interface. So one

problem was that OpenID identities, they
are not email addresses. And so in OpenID

you add an attribute, which is called the
email attribute. And, um, we're talking

about this email attribute in a minute. So
let's have a look at how these identity

breaches work. We are not going into all
the details of the BrowserID or Persona

protocol because this would be too
complicated. But the identity bridge is

interesting and also important for some of
the attacks that we found. So in the

identity bridge the following happens, so
here on the left, we have Alice's browser

and in the middle we have Sideshow service
identity bridge and on the right side, we

have Gmail, which could also be Yahoo in
this case. But let's say it's Gmail. So

first, the user says that she wants to log
in at Sideshow and then Sideshow sends an

OpenID request requesting the email
attribute signed from Gmail. This request

is then forwarded to Gmail. Gmail sees the
request, the user logs in a Gmail for

authentication. And then Gmail creates
this OpenID assertion, which contains the

signed email address attribute for Alice
and as you can see, this is all in the

green box. So all properly signed. Nice.
And now Alice's browser redirects this

document to Sideshow. Now Sideshow doesn't
check the contents of this decision for

itself. Instead, it sends these things to
Gmail, Gmail checks everything that is

signed. And Tells Sideshow, yes, this
document looks correct to me, everything

that was signed was signed by me and was
not tampered with. Then Sideshow looks at

the document and sees Alice wanted to log
in. So this must be the user, must be

Alice now and provides a cookie because
the user is now logged in as Alice. So

far, simple. Now for some of the attacks
that we found. First attack, identity

forgery. So here we have essentially the
same that we saw before, the same setting,

except now we don't have Alice's Browser
on the left. We have the attackers browser

on the left. The attacker can go to
Sideshow and say, I want to sign in. Now

Sideshow, sends this OpenID request to the
attacker and it can change this request,

the attacker can just remove the request
for the email attribute from this request.

Which is still a valid OpenID request.
Gmail sees this request, and now the

attacker logs in. The attacker doesn't
have Alice's user data so the attacker

just logs in with his own credentials. And
now Gmail creates an automatic assertion

containing the signed attribute, which was
requested, which was nothing. So

essentially, the document is empty, at
least without any email address. Now, the

attacker can simply add a new attribute to
this document containing an email address

that he has chosen arbitrarily. This, of
course, is not signed, which is not a

problem because this document can be
partly signed and this document is

forwarded to Gmail. Gmail now analyzes
this document and sees whether there is a

signed part in this document. So I check
this signed part. The signed part doesn't

contain anything useful, but it is
correct. It's not the wrong signature. So

it sends back to Sideshow: there I checked
this document looks fine to me. Now

Sideshow looks at a document, sees that as
an email attribute, uses this email

attribute and the attacker is signed into
any Gmail account that he likes with using

BrowserID. OK, so this is bad, as you can
imagine. And we told the Mozilla guys

about this and they were quite fast. So we
were really surprised. They were really

quick. So I think it was in the middle of
the night for most of them, but they

scrambled in the back and they wrote some
patches and so on and so on. And I think

it wasn't 24 hours later that it was all
deployed and fixed. So that's what was

quite good. But then we took another look
at the system and we found identity

forgery number two, which is actually
remarkably similar to works as follows. So

the attacker, since the authentication
requests, you know this part at Sideshow

once the signed e-mail attribute and the
attacker now doesn't change anything, the

attacker just forwards this request to
Gmail, Gmail, ask for the credentials, the

attacker signs and and sends back the
OpenID assertion containing the signed

email address of the attacker. So no
attack to up to this point. But now the

attacker can do the following. The
attacker adds another attribute, another

email attribute. And yeah, you can guess
what happens. The document is forwarded to

Gmail. Gmail checks the signed part of the
document, which is still fine, sends back

to Sideshow that everything is fine with
this document. And Sideshow selects the

wrong email address. Yeah, and now the
user, the attacker signed into any user

account again. OK, so this was the second
identity forgery attack. We also found

another attack, which is not very
spectacular. And we also looked so this

was all, of course, authentication. And we
also took a look at privacy so as to

remember privacy says that, in the words
of Mozilla, the browser ID protocol never

leaks tracking information back to the
identity provider, except it does. So

ideally, the identity provider should be
unable to tell whether user logs in. In

fact, this is broken, because in the
browser, the following happens. If

malicious identity provider wants to find
out whether a user is logged in at some

specific relying party or not, then the
malicious identity provider can just open

iframe containing the website of that
relying party he wants to probe. Now the

following happens, the normal JavaScript
of BrowserID runs in this relying party

because it has provided support,
obviously, and creates an iframe and

inside this iframe, another iframe will be
created. But this innermost iframe will

only be created if the user logged in at
this RP before. Now, since the outermost

and the innermost iframe, they come from
the same source and of course they can

collaborate and communicate. They can for
example, just send postMessage saying: I,

the user logged in at this ruling party
before. So an identity provider can easily

probe whether a user logged in at some
relying party or not. And this

unfortunately cannot be fixed without a
major redesign of BrowserID, because they

relied on all these iframes and so on.
Yeah. So I think this can be considered

broken beyond repair. We also found some
variants of these privacy attacks which

rely on other mechanisms. But essentially.
Yeah, you get the idea right here. Privacy

of BrowserID is broken. OK, so to sum up
BrowserID, we found attacks, but we also

were able to fix them with respect to
security, and we also used our formal

methods to improve the security of the
fixed BrowserID system. But privacy is

broken beyond repair.

Guido: OK, this leads us to the question,
can we build a single-sign-on system that

provides security and privacy on the Web?
So we thought a lot about this question.

And then we used our formal model to
design such a single-sign-on system. And

we could also then use the former model to
prove that these properties are actually

fulfilled. So the basic principle of the
system is called SPRESSO for Secure

Privacy Respecting Single-Sign-On is the
following. We have the user with a

browser. This user wants to log in at some
relying party, for example, at Wikipedia.

So here we have the same same idea as in
BrowserID to use the email address and the

e-mail provider as the identity provider.
So the user enters the email address and

then the relying party asks for some proof
of this identity. So the user goes to her

email provider, which is identity provider
in this case, authenticates there. And

then this. The identity provider creates a
document that proves the Alice's identity

and then forwards this document to the
relying party. And the relying party can

check if everything is all right and then
consider the user to be loggged in. So

let's have a closer look on how this
system works. So here again, we have

Alice's browser, the window of the relying
party. Alice enters her email address. The

email address is sent to relying party.
And now the relying party creates a

document that contains the identity of the
relying party itself. And this document is

encrypted and we call this document the
tag. So now the tag is sent, along with

the key that was used to encrypt this
document. So this is symmetric encryption

with a fresh key sends it to the browser.
And now in the browser, the SPRESSO code

opens a new window of the identity
provider that is given by the domain of

the email address and sends the tag over
to this window. This login dialog prompts

the user to authenticate, so the user now
enters her password. And this is sent

along with the tag to the server and now
the server creates this document I've just

spoken of in the last slide and this
document, we call it the user certificate,

user assertion, sorry, user assertion. We
send it back to the window at the login

dialog and now we have a problem. We could
just send it over to the Wikipedia window.

But I show you in the minute why this is a
bad idea. So instead, now we have a third

party, the forwarder which serves just a
single static JavaScript file, and this is

loaded in an iframe and is login dialog.
And this iframe gets the user assertion

and it also gets the key and now it can
decrypt the tag. Look who is the intended

receiver and then it sends over the user
assertion through the window of the

relying party which forwards it to the
server of the relying party, who could

then can check if everything is all right
and consider the user to be logged in. So

why do we need this forward? So at first
it may look strange. So let's look what

happens if we just don't have this
forwarder. So let's assume the user wants

to log in at some malicious relying party
at attacker.com and there is an email

address but the attacker wants to
impersonate the user who wants to log in

at some other relying party. Let's say to
Wikipedia, for example, and the attacker

goes to Wikipedia, says, hi, I'm Alice. I
want to log in. Wikipedia creates a tag.

This is sent over to the attacker who just
relays it to the user user. Protocol runs

on, the user authenticates to her identity
provider. And then we just sent the tag

over as the identity provider does not
know who is the intended receiver's

because we want to have this privacy
feature. This just went through and the

attacker gets the user certificate and
user assertion and forwards it to

Wikipedia and then the attacker is
considered to be Alice. And this is that.

So we need some mechanism to prevent that
the user assertion is forwarded to some

random party, but only to the intended
receiver. And for this, we have this

forwarder. Now, you can think this
forwarded may maybe be also malicious, but

let's talk about about this in a second.
So let's just talk about the key forwarded

to us so the forwarder gets the user
assertion and he gets the key to decrypt

the tag. And now he can instruct the
browser to send a postMessage, but only to

give it to a window of Wikipedia. So the
browser checks is the receiver of the

window of Wikipedia or not. And if it's
not, it doesn't deliver this message. So

this protects the, um, the user assertion
certain to be leaked. And now you may

think this forwarder may be malicious and
deliver some other script that does

strange things like forwarding things att
start to the attacker directly. But we can

enforce that the correct script is running
inside that iframe using separate source

integrity where you just tell the browser
and this window only this code may run.

And in this case the forwarder cannot just
put some arbitrary or malicious code in

this iframe. And also there is no
information that leaks back from the

browser to the forwarder. So to sum this
up, as I just presented SPRESSO, it

features privacy and authentication. It's
open and decentralized. So you don't need

any specific central party. It's compliant
to web standards. That's based on HTML5.

And we have formal proof that all these
properties we've talked at the beginning

actually hold and you can find a demo and
more information on spresso.me.

Daniel: OK, now to conclude the talk, what
is the takeaway? First of all, w talked, I

think most of the time about OAuth 2.0.
Most of the results also translate to

OpenID Connect. We have formally proven
the security of the protocol of OAuth and

also OpenID Connect. Which is a nice
result, of course, if you're OK with

having no privacy, because OAuth and
OpenID Connect don't have any kind of

privacy that we talked about. Regarding
OAuth 1.0 and OpenID, I think that can be

considered deprecated and shouldn't be
used. BrowserID, Mozilla Persona was a

nice experiment. But is dead now and also
has broken privacy. With SPRESSO we have

shown, however, that you can achieve
privacy on web single-sign-on using

standard HTML5 features and standard web
features. But of course for now it is a

proof of concept. As you have seen, we
don't even have a nice logo yet. Um, So

and one target audience are certainly
developers, developers, developers use

libraries wherever possible. For example,
the pyoidc is written even by members of

the OAuth and OpenID working groups. So
they know what they do. Hopefully. Also

regarding RFC's, they are hard to read and
information is often spread across several

documents. They are often not written
clearly and they are not always up to

date, but they are still an important
reference. And I think it's a good advice

to look at RFC's from time to time, even
if they are hard to read. So thank you

very much for your attention. If you want
to talk to us, come to us at the

Maschinendeck assemblyin hall 3 free or
join us at the next Pi and More,shameless

plug here, January 14 in Krefield or at
University of Stuttgart starting in

January. Thank you very much.

applause

Presenter: Now we have eight minutes for
questions, what do we have from the

Internet?
Question (internet): So we've got two

questions from the Internet. You can you
hear me? So at the diagram you showed one

of the first slides, why does the
authentication follow authorization?

Shouldn't it normally be the other way
around?

Presenter: Can you try to repeat the
question?

Internet: Yeah, sorry, at the diagram you
showed in one of the first slides. Why

does the why does the authentication
follow authorization? Shouldn't it

normally be the other way around?
Guido: OK, so these are two concepts that

are kind of orthogonal to each other. So
you can either do authentication to ensure

yourself of the user's identity or you can
act on the user's behalf at the identity

provider, like posting on the user's
Facebook timeline or doing different

things there. But for authentication, you
need to retrieve some unique user

identifier. And this basically you make
use of this authorization mechanism. So

you get authorized to access this unique
user identifier and you use this then for

authentication.
Presenter: Thank you. Questions from here.

Question 2: So for the special protocol,
you said you need the forwarding party to

check whether this certificate was
actually from Wikipedia or not from

attacker.com. But could Alice do this
check herself?

Guido: You mean that you should present
the user something and the user accepts

this and or declines this in this sense?
Or...

Question 2: She has the challenge that is
signed by her email provider and she has

the key that encrypted Wikipedia's
identity. So she could use that to decrypt

it and check if it's Wikipedia or
attacker.com.

Guido: Yeah, yeah. I mean, in principle,
yes.

Daniel: So you mean the user?
Question 2: Yeah, yes.

Daniel: Yes. The user could, of course,
check. We could ask the user, did you

really want to sign attacker.com or
wikipedia.com? But of course, we all know

that users are better at making decisions.
So, yeah.

Presenter: Thank you. Questions from here?
Question 3: Hi, thanks for the informative

talk, but I wanted to add a remark. It is
highly unfair to call users stupid for

falling victim to clickjacking and
phishing because they are working

professionally on them on enabling
clickjacking and phishing. And if you need

a 4K monitor just to see that there is
some JavaScript edit that like thousand

zero delimiters, it is impossible to blame
the user for being stupid or falling

victim to clickjacking.
Daniel: Yes, that's correct. It also

sometimes you just can't see it. So yes.
Presenter: Thank you. Questions from down

there? Sorry. Questions?
Question 4: You talked about formal

verification of both the OAuth and your
protocol. I wanted to know what kind of

program or whatever you used like ProVerif
or Tamarin or whatever. And also, I think

you just proved the, you just verified a
subset of OAuth?

Daniel: Let's start with the second
question first. So for OAuth, we really

tried to introduce as many options as we
could find in the standard, so to say.

OAuth is a very loose standard. So they
give you a lot of options. In many ways.

We had to exclude some of them for
practical reasons when modeling the stuff.

But we included almost all of the options
that are provided. And we also have a

detailed write up of what the options are
and what we excluded and what we included.

And now for the first part of the
question, our model currently is a manual

model. So what we do is pen and paper
proves. The reasoning behind this is that

if you have tools, they are always, in
some sense, limiting you. And when we

started out with this work, there was or
there were two models, essentially already

existing web models, former models so in
the same area as we are. But they were

both based on a model checker, so one on
ProVerif, one on another modeling tool...

Guido: Alloy.
Daniel: Alloy. And both were limited by

the possibilities that you had in these
model checkers. So what we went the other

way around, what we wanted to do was a
manual model that includes, that models

the web really precisely and
comprehensively. And then as a second step

what we are currently working on or
discussing about is to transfer this into

some kind of tool.
Question 4: Thank you.

Presenter: Two more questions, questions
from the Internet?

Internet: So I was wondering if you know
about ND-Auth(?) and RealMe Auth and what

you think about the question of using
domain names vs. email addresses as the

user identifier.
Daniel: Could you repeat that a bit

louder?
Internet: So if you have any comments

aboutND-Auth(?) and RealMe Auth which is
the domain name as identifier rather than

an email address.
Daniel: So we didn't look at these

systems.
Presenter: Yes, last question.

Question 5: The question regarding the
forwarder and the privacy protection, I

realized with the forwarder as far as I
understand, the forwarder is used in its

own iframe to prevent the IDP from taking
control of the verification process,

knowing that who is the the final system?
Guido: Yes.

Question 5: But what if the identity
provider at the forward to collaborate,

then the privacy would be broken? Yes. If
we have these parties collaborating then

of course they are broken. So we haven't
we haven't shown all the details of the

system. So this is really hard to prevent.
But in SPRESSO, the relying party is

allowed to choose which forwarder has to
be used. So line party, so choose water

run by some trustworthy party. So this is
the countermeasure to prevent

collaboration. But if these parties
collaborate, then you are screwed. Yes.

Daniel: So I think it's also important to
add some of the forwarder is kind of a

semi trusted party, because on the one
hand, we can enforce that as it uses the

correct code. Of course, the IDP then has
to enforce this. On the other hand, you

still have some side channels like, for
example, timing. So if you control the

parties, then you could check which IP
addresses access for example, the

forwarder and IDP at the same time or and
so on. So there are some side channels. So

the idea that we have to minimize this
risk is to provide a set of trusted

forwarders that could be, for example,
provided by some trusted parties like

Mozilla or the EFF or something, so that
you have a set of forwards to choose from

and hopefully choose a trusted one.
Question 5: Thank you.

Daniel: You're welcome.
Presenter: Guido Schmitz and Daniel Fett,

thank you so much for the great talk.
Please give a great round of applause.

applause

postroll music

Subtitles created by many many volunteers and
the c3subtitles.de team. Join us, and help us!