Okay, so yeah, my name is Matthew Wilde and I'm going to talk about, it's a, hopefully
not too technical talk, but the topics are technical, but I'm trying to keep it general.
So who am I? I founded the Prosody XMPP server. XMPP is an open chat protocol, so the idea
is you can choose the software that you use to chat with, you can choose your service
provider, or the providers federate using a server-to-server protocol, so this is like
some other open federated networks. There's email, which we're all familiar with, where
you can choose your provider, choose your software, there's the phone network, which
kind of works, and many of you here have probably heard of Matrix, and that's another very similar
like goals to XMPP, where we have an open protocol, and we're doing federation, and we're bridging
to proprietary networks. So Prosody is an XMPP server that you can self-host, it's all open
source. Snicket is a newer thing, which is kind of an all-in-one XMPP setup, it's kind
of more like a self-hosted WhatsApp, I actually created it for my family, because they were
still using WhatsApp, even though I'd been working on XMPP for a long time. And so yeah,
so Snicket has apps and stuff, that's all just working out of the box with voice and
video calls and things. As part of this, I worked on a modern XMPP, which is a set of
guidelines, UI guidelines, because the XMPP Standards Foundation, of which I'm one of
the directors, we publish protocols, and we say, this is how you send a file, this is
how you send a chat message or make a call, but we don't say this is how you should structure
the UI. So I wanted to bring some consistency and some good guidelines and help developers
with that. So yeah, I'm also part of the XMPP Standards Foundation, I'm the executive
director, I work on the board, but I've also been on the technical council, and so yeah,
I'm involved in a lot of XMPP things. So this talk is focusing on something that I had a
grant for from NGI Assure via NLNet, and it was to work on modernizing XMPP authentication
and authorization. So, authentication, you start out connecting to the server, and you
then have to prove your identity to the server. You can't just say, hey, I'm Matthew, because
every TCP connection has to be authenticated somehow. So how do we do that? Traditionally,
you make the connection, and you send a username and your password, and the server tells you
if it's correct, and then you can proceed to do authenticated stuff. This is actually
how the web works, pretty much. So you have this HTML form, you put in your username,
you put in your password, your password gets sent to the web server, and the server verifies
it, and usually on the server side, the password is hashed, which means, I mean, if it's a good
place, then it's hashed on the server side, so then they hash the incoming password, and
they compare it with the hash that they have stored. So XMPP uses a standard authentication
protocol called SASL. It's actually used by a bunch of different protocols, and there's
currently work to try and implement it in HTTP as well. And so SASL defines a bunch
of mechanisms, and the mechanism says what you send. And so the simplest one probably
is plain, and this is exactly what we just saw with the, you know, the Hi, I'm Matthew,
my password is, and the web is very similar. You're just sending a username and your password.
And so sending passwords across the wire is absolutely fine because of all these reasons,
and nobody ever reuses passwords, and they are, you know, frequently rotated and updated,
and they never contain personal information, so if they're leaked, then, you know, no bad
consequences. And, yeah, they're never also reused across services, which means this is
just great because if passwords ever do get leaked, and those hashes maybe, you know, brute
forced, then, you know, no one gets access to any other service than the compromised
one, which was already compromised anyway. Okay. Yeah, that was just a joke. So in XMPP,
we don't really use plain. We use another SASL mechanism that someone defined called
Scram. It's not just, hey, my password is, it's a challenge response thing, so there's
a bit of magic going on with hashing, and it has some really nice features. It does involve
multiple round trips, so, yeah, you're going backwards and forwards, but these by you that
the client and the server can only store hashes, so previously, we couldn't have the client
store a hash because it has to send the raw password for the server to hash. If you only
send a hash, then the hash becomes your password, which is kind of weird. So Scram has multiple
iterations of hashing. It allows the client to store a hash. It allows the server to still
store a hash, and only hashes exchanged over the wire. It's pretty magic, and the mutual
authentication part means that at the end of the authentication exchange, both the server
has authenticated the client and proven, yes, this person originally had the password, and
they are who they say they are, but importantly, it allows the client to verify that the server
also knows the original password, which in the past, with the plain mechanisms and like
the web, the server can just lie and say, yeah, I have your password, carry on, send
me more sensitive information, and so we have this mutual authentication, so when you connect
over XMPP and you use Scram, you have this verification that also the server you're
connecting to is the right one, and yes, we do have this with TLS, obviously, but there
are certain cases where TLS isn't always reliable, and that's where channel binding comes in,
which is a bit more magic, and this binds your authentication, that mutual authentication
stuff to your TLS channel, and so if you reach the end and the mutual authentication checks
out, but you find a little mismatch, this TLS magic can tell you that actually there
is someone listening in on your TLS connection, and that can be because, for example, your
certificate authority was compromised or whatever, so someone installed a different trust route
on your system without you knowing, and so we can actually detect this, and it's pretty
smart, all this security comes at a cost, obviously we just talked about why it's necessary,
but it's also still password based, so what can we do?
So there's been a lot of interesting development on the web ecosystem in recent years, they're
trying to, they've tried fixing stuff, and it's basically hard, users are always going
to be users, they're always going to choose memorable passwords, and there has been some
progress, there are password managers and so on, but although they're best practice,
they're not widely used, I mean amongst normal people, probably everyone here, I hope has
a password manager, so WebOrthN 502, it's basically a combination of things, they allow the browser
to do some special stuff and help with the authentication, you can do that with an external
hardware token, but these days also browsers are supporting TPM chips inside the hardware,
which allows you to link that authentication securely to a single device, and pass keys
are like Apple's thing that they're really pushing, which is based on all this, and allows
you to basically create an account without a password, and authenticate using this special
key that is only on your device, except it's also synchronized via iCloud, and so you
can access your account from all your devices without ever needing a password, which is
as long as you can access your iCloud account, now that's just one implementation, there
are other things, WebOrthN 502, and it's all based on open standards, but XMPP uses Sassel,
which is focused on passwords, so what can we do, I've been working on this new mechanism
in XMPP, which is token based, and it builds on some earlier work, which introduces a new
Sassel mechanism, or a family of mechanisms, which allow you to exchange a hash of the
token over the wire, so we're not sending the raw token, so it's a bit scram-like in
that sense, it still provides mutual authentication, and it still supports channel binding, so
you still have all those nice features of scram, it is a single round trip, so there's
no back and forth like with scram, the things that we are weakening in that sense don't
matter because the tokens are not passwords, and so although there is a slightly reduced
level of security around the token compared to scram, the tokens are temporary, so if
they get leaked, then you can easily revoke them, rotate them, and they are unique to
that service, and I would hope that if a service is compromised, you know, they're obviously
going to revoke all their tokens straight away, it's harder to get users to reset all
their passwords straight away, so there's many benefits to using tokens, and we still
get all the nice features of scram, but users aren't going to generate tokens and enter
them themselves, so this opens the door to two-factor authentication in XMPP as well,
previously we've had this problem where you can kind of do two-factor authentication,
but every time you drive through a tunnel, then your XMPP app is re-authenticating on
the other side because it's reconnecting to the server and has to re-prove who it is,
if it uses the password, then the server is going to say, well, you know, you have the
password, but the whole point of two-factor authentication is to make the password not
enough because of all the weaknesses that passwords entail, so if you authenticate
with a token instead, then the server knows it issued this token once, it issued it to
that device, and it knows who you are, and there's a higher security guarantee around
that.
So by using the new Sassel mechanism, servers won't, they'll see that you're authenticating
with a secure token, and they won't send the two-factor authentication prompts that
they usually send.
This is basically how two-factor auth on the web already works.
You provide that web form or whatever, maybe you're using pass keys, but once you do that
initial authentication step, the web service is going to send back a cookie that gets stored
in your browser in plain text, and with every request, yes, it's going over HTTPS, but it's
still sending that, you know, plain text string, and it doesn't have all the protections of
the channel binding and the mutual authentication that the FAST and Sassel mechanisms are supporting.
So in this sense, using FAST over, for example, the new HTTP Sassel stuff would be an interesting
security improvement for many secure web applications.
And so the other thing is it opens the door to having passwordless accounts.
So instead of exchanging your password for a token, you could exchange your password
plus a two-factor auth for a token, or you could do something entirely different, something
came up just at the real-time stand downstairs, someone wants to do SMS authentication, so
they verify SMS, kind of like how WhatsApp or Signal work, and then you will just be
given a FAST token, and then you can reconnect to the server using that.
And that will last for as long as you keep your device active.
If you have an inactive device, then that token will stop being refreshed, it will eventually
expire, and you will have to reauthenticate using SMS or maybe some recovery mechanism.
And once you've breached up this passwordless account, then obviously you can add other
recovery mechanisms as a backup if you need to.
And yeah, that was kind of the summary of my talk.
I hope there's still time for many questions if you are interested.
So this talk is kind of a complement to a blog post that I wrote on the Presley blog
about all this stuff, but the blog post focus mostly on the performance optimizations because
that matters to people, they want to be reconnected to the server as quickly as possible because
responsiveness and all this.
And so the blog post focus on the optimization aspects of this, today the talk focuses on
the security aspects.
And yeah, there's some more XMPP talks coming up later on, I am downstairs also in the real
time lounge, which is just down around the corner, and you can reach me on XMPP or email
and yeah, happy to answer any questions.
Can you tell us where they overlap, where they differ, can fast be used in scenarios where
JSON web tokens already exist as something better, or is it more divergent as a difference?
It's pretty different.
Yeah, sorry, so the question is ultimately, are JWT, JSON web tokens similar overlapping
with fast tokens?
Fast tokens are essentially opaque random strings of a good length for security reasons.
JSON web tokens, they are also embedding stuff inside that token.
A server could do similar, and when it issues the token, use a JWT instead.
There's not really much benefit to that.
JSON web tokens, they are still useful for some cases, definitely, but they have a bad
reputation with regards to security.
Yeah, it's complicated, but there's not really much overlap.
They can be kind of used in the same situation, but not entirely.
If you were doing a distributed network where you didn't really necessarily want to have
a backend communication, could you authenticate a fast token against one service, and then
that contains information that could authenticate with a trusted system that's not sharing a
backend?
Yeah, absolutely.
Any way that the server can verify the token is valid?
Sorry, the question is, if you were working on a decentralized system where the authentication
system is separate to the place where the user is logging in, then can you use JWT in
that situation?
The answer is yes, you could use it.
Two questions, are you attempting to standardize fast within the standards body, and second,
do you set the tokens that are disused, decayed by what mechanism?
The first question was, are we attempting to standardize fast?
Yes, so the sassel mechanism that it is based on is already a draft at the IETF, it's been
going a while.
We had a meeting with the sassel working group at the IETF just last month, and they agreed
that this is stuff that is interesting and they want to move forward with, because it
is also useful for other protocols, the email ecosystem and many others.
So yes, we are the XMPP layer of this, the whole fast stuff.
That is being standardized at the XMPP Standards Foundation, so that layer, if another protocol
wanted to use it, they would have to define their own, because the fast stuff specifically
is XMPP specific.
They can copy how we have done it, but it has to be translated to a different protocol.
The second question was, how do disused tokens decay?
That is basically up to the server, there is an algorithm in the fast specification,
which is linked from the blog post, which tells you how to implement the server in a
way that is going to securely rotate tokens, without having to check every possible token
on the server, because we don't necessarily know the user's identity until we verified
the token.
So it can be a bit complex, but essentially it's just the server knows the expiry time
of a token when the token was last seen, and some interesting stuff came up with how to
refresh tokens, because if the client authenticates and then you provide it with a new token
and immediately expire the old one, so that's one way of doing the rotation, there are
cases where the client actually reconnected, used the old token, and then did not receive
the new token, got disconnected, and then it gets logged out, basically, because it
can no longer access.
So the server has to store the last token that the client used, and also the new replacement
token, it's expecting it to use next.
And if the client never uses that token, then it will eventually issue a new one and work
out.
And that's the moment you see it authenticate with the new token.
That's when you expire the old one completely, and obviously there is a time limit to that,
because otherwise someone can carry on using the old one indefinitely, and we don't want
that either.
So there's kind of two timeouts built in, okay, excellent.
Thank you.