you
you
has anybody use your past keys as your 2FA method on GitLab? Oh cool, oh awesome, awesome.
I should talk after the talk. Anyway, so here's more of the talks. I talk about past keys in the RubyConf
Thailand, RubyConf Taiwan, and today I'm going to try to talk, there's going to be a mix of what I've talked
before, but the things that I spent more time talking in the other conferences, I'm going to talk less here, and
I'm going to talk about some more stuff that I have not talked in the other talks. So what is past keys?
Past keys are replacement for passwords. It's part of a wide authentication standard. It was designed to
replace or to reduce the over reliance of passwords. Internally, it's a public and private key pair used for
challenge-based authentication. It uses public key cryptographic, which has been around since the 70s. Sometimes it's
protected by your device biometrics, sometimes it's discoverable, and sometimes it's bound to your device. That's an
interesting scenario, it's an interesting use case, but I'm not going to talk about that today here. These are
centers that I kept in all my slides and all the presentations, and the reason why I kept these centers when I was
learning about what past keys is about a year ago, these centers helped me wrap my head around what past keys were. When I
read these, I was like, oh yeah, these make sense. And it says, a password is something that can be remembered and typed, and
a past key is a secret stored in one's device in a locked biometrics. That sentence comes from the website, the source is
there, past keys are there, there's a lot of interesting stuff in there. These centers have some caveats, not exactly I
can remember all my passwords, but it's a good definition. This is one that I like. Past keys is a public and private key pair
protected by a device biometrics and used for a challenge-based authentication. So let's break that down into sentences. Public and
private key pair, like I said, is used public key cryptographic, and the idea that you have a public and a private key, and if you
keep your private key private, and keep your public key public, you give to the world, and if you need it to encrypt some data and send
some data over the world, over the web, you encrypt and use your private key, and then whoever wants to read that can decrypt
that data with your public key. So that's kind of what this is about. And it's protected by a device biometrics. According to
the standards, according to the standards, to use your past keys, you need to first do your biometrics verification. I don't think that's
going to be the case all the time, but it's one of the important aspects of past keys. And used for a challenge-based authentication.
Again, this goes back to the public and private key encryption. When you go to a website and you're going to sign in for a website, you just
don't present your credentials. You do a private and public key encryption. The website is going to send you some data, like, hey,
HILU, oh, you're HILU. So in order for you to prove that you're HILU, I want you to encrypt these data with HILU's private key. And then,
okay, all right, I'm going to get my private key. I'm going to encrypt these data. I'm going to send it back to you. And then the site is your
application. When you're signing in, it's going to look at that encrypted data, that digital signature. Oh, there is this gentleman here pretending to be
HILU, and he gave me a digital signature supposedly encrypted with HILU's private key. And then I'm going to use HILU's public key to the
crypt. And if I get my data back, then voila, it's your HILU or someone who owns, who have access to HILU's private key. And that's what a
challenge-based authentication looks like. So like I said, this is a past key, this is part of a web authentication standard.
There's a W2C standard. This is a screenshot for the first public working draft that was created in 2016 by folks from Knock Knock Labs,
Microsoft, PayPal, and Google. Basically, several years ago, all the big tech companies, they got together in trying to create a standard for a better,
more secure web authentication. And from that, they created an alliance called FIDU Alliance, which is just a group of companies with a goal of
promoting a more secure web authentication. And this also is like that I like, that I have in all my presentations. This talk here today is that small little thing there.
And just to give you guys a little bit of a perspective that when you're using your web developer hat and you're adopting your
support to past key to web application, you're all the way at the top of the iceberg. But there's a lot of things that it goes behind the scenes that
for past keys to be a reality and be a more secure, more intuitive replacements for passwords. And anyway, there's a lot of stuff in there.
I'm going to talk just a little bit. 2FA or not 2FA? This is one question that has been kind of banging my head for the past couple of months.
So this is a screenshot from the FIDU Alliance website from the FAQ section. And they have a question there. Are past keys considered multi-fact authentication?
So let me read that for you guys and we'll talk a little bit more about it. So past keys are kept on users device, someone the user has.
And if the relying party requests user verification, RP is relying party, is your web application, can only be exercised by the user with a biometric or pinning something the user is or something the user knows.
Thus, authentication with past keys embodies the core principle of multi-factor security. That's kind of the beginning of the answer.
There's a middle here that I'm going to skip that and then let's go to the end. At the end it says this, note that some regulatory regiments still have to evolve to recognize past keys as one of the officially listed forms of multi-factor.
This is an area of active engagement for FIDU Alliance. Just for your information, I've been learning and studying what past keys is for about one year and this note, it's since last year, exactly like that.
So I don't know exactly what active engagement means for FIDU, not what regulatory regiments they are talking about, but for the past year that sentence is still there.
So these are reminding for me, these are reminding for me, just to remember what two FAM means, right? Something the user has, something the user knows and something the user is.
If you have two of those, then you have two facts authentication, if you have more, you have multiple facts authentication.
So past keys, past keys is kept on your user device, on your phone, on your USB stick. Sometimes, maybe most of the time, it's going to be replicated to your cloud account, right?
It goes to Apple, Google, Microsoft account. This is something that I have, the user has. And past keys can only be used after biomedical pain verification, something the user is.
Again, there are some cases where I think you're going to be using your past keys without those things. And that's where one thing that I was going to mention in the previous slide is that when I talk about these FAQ, I tend to say the FIDU Alliance make a soft claim that past keys are two FA.
Because these words, me here, that was not, it was probably written for a lawyer, I'm sure it wasn't an engineer. So, but anyway, so that's what I mentioned that sometimes in a couple of forums, in a couple of discussions, I mentioned that FIDU makes a soft claim that past keys is two FA.
But we're seeing here that in some situations, some scenarios is going to be two FA. And I think there are some situations that is not going to be two FA. I was going to remember the sentence, right? Some regulatory regimens still have to evolve. And this is an area of active engagement.
But if you are using past keys, you have your phone, a USB stick, and you need to use those to authenticate with past keys. And I am my face, my finger, and I need to use those things if you're doing the biomedical verification.
And I know my USB stick pin, if you're using a hardware key, and I know that I think now some USB sticks, they now validate your fingerprint. So there are a couple good, strong arguments that you're using at least two of those three things, right?
But they still, some regulatory regimens has to evolve somehow.
Password managers.
So just for information, the demo that I want to show at the end of the presentation, I hope I have time and I need to kind of speed up a little bit, maybe.
The demo that I want to show was created before all the password managers had support to past keys. This is a new technology.
And way before password managers were able to do past keys, to support past keys, you had to have native support on your Macs, Windows laptops, iPhones, androids, the three browsers, major browsers, right?
Safari, Chrome, and Edge. Firefox took forever to work finally on the Mac.
Finally, last week or two weeks ago, they finally released a version, I think it was 122, that now works on Mac.
Firefox worked on my iPhone before it worked on my Mac.
So maybe there's some regulatory regimens that explain some role somewhere.
But password managers. Should they become past keys managers?
Can password managers have access to our device biometrics? Your cell phone, Touch ID, Face ID, your laptop, Touch ID.
Should they have access?
Password managers necessary in these world of past keys.
By the way, these demo that I want to show you, a couple weeks ago, I was trying on doing some, updating some dependencies.
And I was doing some tests and doing some manual tests before deployment.
And it stopped working on Safari when I was logged in on my vault, on my password manager vault.
So I had to log out from my password manager to be able to use the native support that Safari and Mac has for past keys.
But yesterday when I was rehearsing this talk, it was working again, and then it was broken, it was a little bit buggy, but it looks good.
It's nice when I do have the option to be logged in on my password manager on Safari.
And I can decide whether I use my password manager or use my native support on Safari and Mac.
When I can't do that reliably and not buggy, that's going to look good.
But I think I brought about this conversation on password managers because this is one thing that I've been wanting to dig a little further,
because I think this plays back to the 2FA not 2FA.
Because when you create your password, your past keys to your password manager, you're not doing your biometric.
But this is an area also that I still need to study and learn a little bit more.
Maybe some past keys, some password managers, they are worth sniffing their way out of not using your biometrics, but it's still 2FA.
But anyway, this is still something that is still a little bit in the gray area that I don't know how this is going to play out.
Alright, now let's get down to some more how it works and under the hood.
So this is the area of the talk that I talk in more extensive details in the other talks.
So I'm going to go a little faster here today.
There is something here that you feel like you want to listen to me talking more about it.
You'll find some the recordings of the other talks online.
So okay, I'm going to talk about registration authentication.
Remember, this is replacing passwords.
So these are about sign up, signing in and re-authentication.
Re-authentication is just authenticating you one more time.
So just going to the signing in again.
I'm not going to talk too much about it here today.
Alright, so registration.
So you're a user, you're a new browser, you go to a website and you want to sign up, right?
So RP is a relying party, it's your web application, Ruby, Radio's app or whatever stack.
And then the site is going to ask you a public key.
Now I need your public key.
So the user is going to defer to your device.
This can be your cell phone, this can be your laptop, this can be your USB stick where you're going to create that pass keys.
I'm using the phone for simplicity.
And it's going to do your face ID, create your pass keys.
It's going to sync your private key to your cloud account.
And it's going to send back your public key.
And then the relying party is going to do some verification, create your account, alright, you're signed up, right?
So now let's take a look inside.
So in order to look one level down from that diagram, I'm going to use this application.
This is a web of Rails demo app created by those folks from set-up code.
And I'll talk about the initiation phase, what happens in the browser and verification phase.
So remember, these days like that we saw in the last one.
So that's the registration, all the steps.
So this is the initiation phase, this is what happens in the browser, and this is the verification phase.
So now let's look down one level down on these blocks and see how they look like.
So for this particular application, when you're trying to sign up, that's the JSON that goes back to the server.
And then here the server, the server is going to do four things.
I'm going to generate a web offer and user ID.
I'm going to load the web offer and settings.
It's going to create a challenge and then it's going to return a JSON back to the server.
So, and here's what the JSON looks like.
I'm not going to talk, get into much details.
I'm talking more details about these things in the other talks.
So today I'm going to go a little faster here.
So this is the JSON.
The bar there shows that at the top is just static data application settings.
And at the bottom it's based on user session.
Whatever username you want to create and the ID that was created in random and the challenge that was created in random for your sign up, for your registration process, for that particular user registration process.
So here is a documentation straight out of the gem, web offer and Ruby gem.
And this is a configuration that you need to do in your application.
Basically here you put your origin, your name, and then there's a bunch of other fields here.
Just to keep a little bit of what's happening in the world, let's look at GitLab, right?
So GitLab is so good, GitLab is open source, right?
So just go look at this source code and study and read and see how they're doing and maybe help a little bit.
So they basically use the exact same basic version from the gem, but they do change one default.
So the encoding, the default value is base 64 and they use base 64.
The base 64 you are when they use base 64.
This is as of my last conference talk, last December.
I'm not sure if we change it, but that's the URL you can guys go to and see if we change it since last December.
Anyway, here is just one little detail.
So the user ID is one of the things that gets created for your session.
And then look at that.
It's just a user ID, web offer and user ID that got created is just a key random bytes.
The same thing happens with the challenge.
So these are two things that got created by the server in the beginning of the registration phase.
It's also another secure random.
So both your web offering user ID and the challenge just random bytes.
So, okay, then we saw that block.
So now let's look into what happened in the browser.
So when the JSON happens and comes back to the browser, your code in the application is going to call the browser API.
And then when you call that your browser and your OS is going to default to your device.
And then your device is going to create your pass keys.
Remember, it's going to sync a private key to the cloud to keep your device and then sends back your public key.
Oops, sorry, wrong arrow.
And then here's your credential and then here's your public key.
Okay, so that's everything that's going to happen in the browser.
And this is a JSON.
That's a JSON that gets back to your server.
There is some duplication there, I'm sure of it.
I'm not sure if it's a bug or a feature.
And this whole block here is duplicated here.
I didn't have a time to kind of look into what that is.
But anyway, that's what's coming for this particular application.
But I think this is generated by the browser API.
I don't know where that comes from, but anyway, one day I'll try to figure out.
So anyway, that's kind of what happened here in the browser.
So now let's look at what happened at the verification phase.
So now that that whole JSON that we saw is going to be sent to the server, and the server is going to do these four things.
And remember, here, note one thing here.
These are two separate HTTP requests, completely independent for each other, with a shared context.
You need to run one HTTP request to get user ID and challenge, and a second one that you do a bunch of stuff and then you send back the result.
So the first step that is going to do here is a series of verifications.
And then if your pass key, if your data is verified, then you're going to get your pass keys created.
You use it to get created and you get a JSON back, a simple response back to the browser.
So I'm running a little bit out of time, but you can just check one of my talks online.
I talk in more details about these things, but here we're looking at the gem, what the gem actually does, what your application.
This is your first step in your application to create your user and your pass keys.
And then these are all the stock trades that happen inside the gem to verify your data.
There's a bunch of stuff here.
This is the one that does the most, a bunch of verifiers.
And here's the one that verifies your challenge based on the expected challenge.
These two here, two interesting features of your pass keys, user presence and user verification.
And these are the one interesting thing that I put in here.
The valid challenge is just an open SSL secure compare based on what came to the server in the second request and unexpected challenge.
I didn't look into details what actually these expected challenges, but part of these verifications is a bunch of secure compare on open SSL to make sure that the data is, everything's good.
There's no many in the middle, nothing is getting the middle of those two HTTP requests.
And then this is another one.
And then if your data is verified, your pass keys is valid, then you're going to create your record.
This is what the, then it's going to get back to your application.
And now you finalize the user creation and create the credential.
When you use this application, that's what your pass keys in your database looks like.
And then we're done.
Right. So we finish the whole process here and look into all these JSONs, HTTP requests in response to what happens during the registration.
So authentication.
Now we have an account.
I'm going to sign in, right?
This is the challenge based on indication, right?
So the application is answering, hey, here's some dummy data, signed the data with your private key.
I'm going to defer to my device.
I'm going to do my first ID.
I'm going to access my private key and creep that data and send the data back to the server.
And the server is going to do a verification.
The creep using my public key.
And if the creeps are good, voila, this is Hilo, your Hilo authenticated.
Right.
So authentication works.
Shall we look inside?
We shall not.
We're not going to have time here, but you should need in the other conference that the goal of the talk was pop into pass keys only looking under the hood.
I didn't have time to do this.
I stick only to the registration.
But anyway, that's an application on GitHub and you can go check it out.
And pop the hood on the pass keys.
All right. Live demo.
We are running out of time.
You guys want to see a live demo localhost 3000 or the actual product name.
I'm going to do localhost.
I'm not going to risk the Wi-Fi here.
Anyway, so this is an application that I created.
It's a Rails app that I created for hackathon.
And just basically what I want to show here is pass keys.
What I just showed you guys sign up, sign up, sign in and reauthentication.
So this is, you see it's running on my localhost.
The logs are here.
It is running.
This is how I was rehearsing my talk.
So I create a Ruby dev for him.
So I'm going to log out here.
I'm going to log in again.
And so unfortunately I'm going to do, I'm going to create an account, right?
So Ruby dev room at 4th then 2024.
And this is a pass keys label.
This is an application that I created for hackathon.
So there's nothing here.
I'm just going to show pass keys, sign up, sign in and reauthentication.
And I only collect an email for sign up.
And don't even use password.
There's no password in this application.
Only pass keys.
I'm going to put here Safari, which I'm creating.
And then if I do that, it's going to be presented by your,
you can do your biometrics.
These are the options.
I'm interested in one.
I'm not going to have time to show today,
but if I put the right finger here, you get authenticated.
And they are always unique for website.
They're always strong.
They're efficient resistant and rich in resistance.
There's a lot of marketing things that goes down behind the scenes
that makes pass keys a lot more secure than passwords.
So this there will be authentication, right?
I already, I'm already authenticated.
And I'm going to make some sensitive transaction with authenticating again.
And basically what he does is the same thing.
If I put the wrong finger, it doesn't authenticate.
If I put the right finger that I have configured on my laptop, boom,
I'm there authenticated.
So now if I sign out, I'm going to sign in again.
This is kind of the auto discoverable on pass keys,
where when the browser detects a device that supports pass keys,
it shows you, oh, I have five minutes.
I'm not going to talk too much.
Anyway, so let's move on.
That last one.
So that's the one that I create today.
All the other ones are attached account that I have and rehearsing the talk.
And then if I put here, then you're authenticated.
Everything that you show here is, is this app that I created for this hackathon.
Summer last year.
All right.
Hello Ruby.
Pass keys in the Ruby community.
I want to give a shout out to the trailblazers in the past,
the past keys trailblazers in the Ruby community.
Gonzalo Braulio from CELACode, Pete Lavica, Thomas Cannon.
CELACode is a web agency in Uruguay.
And they're the creators of the web offering Ruby Jam.
According to the Jam spec, the authors are Gonzalo Rodriguez and Braulio Martinez.
If you're doing pass keys on a Ruby, on a Rails Ruby app,
this jam is going to be on your Jam file or Jam file lock.
And the first version was created in 2018.
The last one is in December last month, two months ago.
Peter Lavica.
Peter Lavica, I'm sorry for the pronunciation.
He's a Ruby on Rails developer.
And in 2021, he wrote this article,
multi-factual authentication with Rails and Web Off-In and Device.
It was originally published at Honey Badger blog.
And he also wrote Rails app that goes along with his blog.
This article is really nice.
I really enjoyed reading it.
I strongly suggest you do so.
And at last but not least, Thomas Cannon.
He's the creator of Ruby, pass keys GitHub organization.
He also created the warden, Web Off-In, Ruby and Device pass keys Jam.
And he also have a Rails template app,
Device pass keys template.
You can run it on your laptop if you want to.
Thomas is the one person that makes a huge difference for me
because I was reading about pass keys.
All the pass keys were popping up here and there.
And then I was like, okay, I need to read what pass keys are.
I don't know what it is.
And then I went out with my life and I'm busy.
And then one day, Thomas sent a message,
posted a message on his social media saying,
hey, I just released this Jam, Device pass keys.
Hey, it's a public, first public better version of one art or something like that.
Go check it out, send some feedback.
And I'm like, okay, I've been here about these pass keys.
No, that is a Jam that I can put in my Rails app.
And is it Device pass keys?
I'm like, okay, all right, damn, that was all the motivation
that I needed to learn about these.
And this was literally about a year ago,
like January, February last year.
And so anyway, so that's Thomas.
If you weren't for him, for his message, or if I was,
I don't know if I would be here today.
Anyway, just one single message on his social media.
That's it for today.
And I have two slides about questions.
These are folks, if I have any question.
If you only have pass keys on your site for your application,
how do you now log into the application from the device?
So the question is, if you only have pass keys in your application,
how do you log in your application from our device?
That's that other device options.
So you can log in from an external device.
I can actually show that real quick here.
So if I am signing up here, there is this other option.
And so when you pick that other option, you can,
there is an option here, you can use your iPhone.
Because I created this account on my Apple,
and my pass keys got replicated to my Apple account,
I can actually do this from my phone.
So when you do that from our device, that's what happens.
So let me see if I can do this here.
So in your browser, I'm going to show this,
and then I'm going to do the pass keys validation,
the first idea on my phone now, instead of doing the touch ID.
So if I do that, so, okay, I need to turn on Bluetooth.
Bluetooth, okay, let me see now, the camera.
So, not photo, pass keys, come on.
All right, the operation could not proceed, please try again.
No, no, it's not local host.
I think it's the camera, and the Bluetooth,
sometimes the Bluetooth gets messed up.
But you can do that, I tested these, and oh my gosh, it should work.
It works.
Oh, why, anyways, maybe it's more Bluetooth here.
Why do you use Bluetooth?
Maybe I need, yeah, so it's not going to work here,
but you can do that.
With that QR code, you can scan your QR code here,
and then your device is going to communicate with Bluetooth
with the laptop, and then it does the face ID here,
and then you finish your flow on the authentication.
I would like to ask if you can use this kind of pass keys
on all sort of proteins such as maybe SSH connection.
So the question is if you can use pass keys in an SSH connection.
In an SSH, you already use authentication with PEM files
and certificates that's strong.
This was created for web authentication.
You can store your pass keys in your hardware device,
but I don't think you're going to be using pass keys in CLI,
in any command line, or SSH or anything.
There's already strong mechanisms for authentication
that are authenticating in that, I think.
Let's consider this computer, not biometric way.
Can I add a USB dongle because it can have fingerprint sensor?
Can I consider it as a way to connect with a pass key?
Yeah, so the question is if in his laptop that doesn't have biometrics,
if he can put some USB dongle to do the biometrics.
I do, I remember I read some information, some news show up in my radar
saying that I think Google or maybe UB key, I don't know,
they're creating some hardware keys now that validates your fingerprint.
So it's like a typical UB key, but instead of using PEM,
which is the traditional use of UB keys,
you actually validate your fingerprint.
But those things cost 30 dollars a piece and I lose them all the time.
I think I can add on this fingerprinting biometrics if you don't mind.
So there is a parameter in the user verification from RelayBuddy,
which could be required, I think preferred and discouraged.
So potentially the verification biometric is not needed at all,
depending on the relay party, this first.
And second is up to password manager or the system to verify the user.
It could be a password, pin code, it could be Windows Hello, it could be whatever.
And there are devices you can plug in and use Windows Hello for example.
Windows Hello is the Microsoft solution that's equivalent to the Apple keychain,
where that's where your application is going to be stored, your pass is going to be stored.
In the user verification, yeah, you have these three options.
But I think that's one thing that I wanted to try to do for this conference and talk to you today,
is about the password manager in these two FA.
I'm trying to kind of get to the bottom of this and understand and see how this is going to play out.
Because when you require the user verification, you're going to create your pass keys
and your password manager has to do something.
In the test that I did with password manager in this demo application, it doesn't ask anything.
I'm already logged in on my vault, but I'm logged in on my vault on my laptop,
but there isn't a second layer and then that's all the words, words, myth there.
But anyway, there's some words, mything around 2FA and not 2FA.
I'm not concerned about words, mything.
I was just curious to see which factors are going to be used when you are doing password managers.
And if there is some relation to that soft claim from Fido Alliance about 2FA, regulatory regimens and whatnot.
But I don't think that, and I saw people complaining that they don't want to use biometrics in pass keys.
In one of the other talks, I mentioned that maybe six months from now,
we're going to have to differentiate what pass keys are from biometric pass keys.
Because biometric pass keys, I have a strong feeling that that's a 2FA.
It does use two factors.
But if you don't use the biometrics, you only use the pass keys, public-private key encryption,
then maybe you're not using two factors.
But anyway, that's kind of something that I still need you to say a little bit more.
Sorry, we don't have more time.
We can, okay, if we're going to have questions later on.
Thank you.
Thank you.