You know what I hate? I mean really hate? Passwords is one of the things I hate. There are too many of them. They're hard to keep up with. I'm losing them all the time. I'm going to go out on a limb, probably not very far, and suggest that you probably don't like them either.
Well, what if I told you there was a way that we could get rid of these things without compromising security? In fact, a way that allows us to improve usability of the system while also improving security, which is something that's hard to do, both of these at the same time.
That would be interesting, right? What's the name of the technology that lets us do this? This technology is called Fast Identity Online (FIDO).
- F - Fast
- ID - Identity
- O - Online
What does FIDO do?
FIDO is a protocol that allow us get rid of passwords by replacing them with something we call passkeys. And it's not something brand new, even though you may not have heard of it before. It's been around since 2013, the FIDO Alliance, this industry consortium that put together the standard. In fact, there are more than 250 organizations that are using the FIDO standard and are part of this alliance.
There's a newer version of FIDO called FIDO2, which incorporates two new elements that are particularly important.
One of this element is hardware-based authentication. With hardware-based authentication, I can use biometrics or hardware-based tokens, think a phone that is something I have, and then using my face to unlock the phone, something that I am, that we can do that sort of thing.
The second element FIDO2 have is support for web browsers, which now extends the use cases and the possibility of all the different places where we can use FIDO.
How Does FIDO Works
How does all this magic work? Well, let's start with a quick review of cryptography. Some of these concepts are going to be important in understanding how this could be possible. First of all, we have two main different classes of cryptographic algorithms.
- Symmetric Cryptography Algorithm
- Asymmetric Cryptography Algorithm
With the symmetric algorithm, I have a single key, a symmetric key, and that key is used to encrypt as well as decrypt. So if I encrypt a message, I use this key, I want to decrypt it, I use the very same key. So that means both sides have to have that key and know what it is. That's how symmetric cryptography works, its called symmetric because it's the same key on both sides.
However, when we go over to asymmetric cryptography, it's a different situation. We have two mathematically related keys that share this unique property that whatever I encrypt with one can only be decrypted with the other, and vice versa. If I encrypt with this, then I can decrypt only with that. So, these are related, but they are not equal.
Now, we're going to use that special quality in order to do the magic that we're going to do with these passkeys. For instance, in fact what we do, we refer to these, one of them as a public key and the other as a private key.
So, let's take an example of how we would use these. Assuming we have a users who wants to login to particular website. First of all, they need to register. How does the registration flow work? Well, it's sort of like this, user is going to send some registration information over to the web server. And as they're doing that in this process of registration, the user on their device is going to generate both a public key and a private key.
The private key is going to stay on user's device and never leave it. And its going to be locked down with some sort of biometric or other strong authentication capability. So the private key stays on the device.
The public key, however, we share with the web server, the web server takes that public key and puts it in a database and associates it with this user. Now that's the registration phase.
Now what do we do next is, let's say, the user wants to log into the system. So what we need to be able to do is authenticate. The authentication flow is going to work like this; the user is going to send information to the web server, for instance, they're going to put in their username and say, hey, this is me, I'd like to log in.
The web server says, oh yeah, I remember you because you registered with me before. I'm going to pull in your public key because you shared that with me previously. (And by the way, there's never a problem with sharing a public key. That's why we call it a public key. The only problem is if you share a private key).
So, we take the public key that's beens shared in advance, and we're going to then calculate a challenge of some sort, CNAL. That is a specially designed message that's going to have some information, probably a timestamp and other things like that, that are unique. And we're going to encrypt it with that user's public key.
This is where we start getting the real security capabilities. He sends the challenge over to the user. The user decrypts it with their private key, and then if they're able to read it, they're to see what's the challenge message and they can then respond to the web server encrypting the response that proves that they have read the challenge message and they will encrypt that again with their private key and send that back to the web server.
The web server then is going to take that, and we do the final step, that is verification. Verification means the web server now is going to take this response message that we got, We're going to decrypt it with the public key and we're going to compare it and see if it works.
If the challenge we sent matches the message we got back, then we can prove that this user is in fact who they claim to be and we will allow them to log in. Notice what was not ever happening in this case. There were no passwords. At no time did you see a password come out of my hands.
In this case, we stored the private key on the device always, we keep the public key, share it with the web server, the web server associates that with the user, and then we just do a series of challenges. So for this user, all they have to do in order, when this challenge comes across, unlock their device, indicate maybe on the device that this is the website I want to log into, approve that, and the rest of it happens automatically.
Conclusion
Let's review really quickly what we've talked about. So with FIDO, we keep the private key on the device itself, and we guard it with multi-factor authentication. So that way, nobody else can see it, it remains private, and therefore only that user can decrypt and encrypt with that key. The public key, however, is shared. That's why we call it public.
We share that with the service provider, with the website, or what have you. And that's okay, because of the mathematical relationship between these two. Having one doesn't allow you to figure out what the other is, which is nice.
Now, one of the things that's really nice about this, not only do I get to get rid of passwords, but there's some downstream effects that occur from that. For instance, it resists phishing attacks. So the phishing issue often occurs because someone is able to coax you out of your credentials. You click on a website and log into a bogus website and you give the attacker your login, your user ID and password.
If there's no password, in other words only pass keys in the form of these challenges and crypto mechanisms, then there really is no password for the phisher to gather in the first place. So we resist a lot of those phishing attacks. That's a nice side effect.
Another thing is it resists replay attacks. So, a replay attack is one where a user or an attacker might sit on a network and see the information that you're sending. When you go to send your password over the network, maybe it's in an encrypted form, in the form of a hash, and they take that hash and they don't even have to know what it says, they just need a copy of it, and then they replay it and send it to the web server as if they were you. In this case, we've got a system of challenges. They wouldn't know what to send because they'd have to see what was coming in the first place. So we resist replay attacks.
And finally, it gets rid of passwords for us. those things that we hate, the things that are hard to keep up with, the things that can be forgotten, the things that people write down, the things that people are not very creative at coming up with in the first place. In this kind of a situation, there's no passwords involved. The past keys are all based upon information with these public and private keys, which are automatically generated, and they're complex and strong, and the user doesn't have to keep up with it. And you know what, this has been around for a while.
In fact, IBM has been supporting FIDO2 since 2018. And there's a lot of other vendors that are jumping on board as well, as I told you to begin with. So, this is something that I believe is going to be the future of logins and authentication and the beautiful thing is, the future is free of passwords. Thanks for reading. If you found this post interesting and would like to learn more about cybersecurity, please remember to share this post and follow the Blueguard.
Print this post
.png "Instagram")
0 Comments