This subtitle is not finished yet. If you are able to, please support us and watch the talk in amara for the last changes: https://c3subtitles.de/talk/695 Thanks!
*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, alice@mailprovider.com 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!