hpr-knowledge-base/hpr_transcripts/hpr2999.txt

Episode: 2999
Title: HPR2999: SQRL - Secure Quick Reliable Login
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2999/hpr2999.mp3
Transcribed: 2025-10-24 14:39:16

---

This is Hacker Public Radio Episode 2999 for Thursday 30 January 2020.
Today's show is entitled, SQRL, Secure Quick Reliable Login. It is hosted by Daniel Persson
and is about 24 minutes long
and carries an explicit flag. The summer is.
In this podcast, we talk about what SQRL is and how it works.
This episode of HPR is brought to you by archive.org.
Support universal access to all knowledge by heading over to archive.org forward slash donate.
www.hacker.org
Music
Good morning hackers and welcome to another podcast by Daniel Persson.
Today I'm going to talk about an open source concept.
There are a lot of open source projects that implement this and it's called Squirrel,
like the little furry creature, but it's actually spelled SQRL.
And it stands for Secure Quick Reliable Login.
Usually today when we are logging into sites, we are using passwords, we are using usernames,
and we perhaps use a second factor of some sort in order to be secure on the internet.
And this is something that we have been using for many years.
And it is quite good as a simple implementation to get you online and get you authenticated.
Because you always have this thing with you, you always have your memory,
you always have usernames and passwords.
You can get a password manager because having multiple usernames and passwords that you are required to remember can be a hassle.
And reusing passwords between sites are not good because if one site is tampered with,
so your password will get out there, then that password could be reused on another site to gain access,
which is not good.
Squirrel is a solution to this and how do we actually solve this problem?
Squirrel's main core thing is that you actually have something on a site
that tells you, gives you some flexibility, and then you give that site a secret to keep,
but there is nothing that ties you to that secret.
In this case, it's a public key, and if you have that private key and can actually sign a message to that public key,
the site can check that you are the correct owner of that public key.
So it's pretty simple in its first implementation, but we had to do a lot of work to actually get all the edge cases fixed and looked at.
Things that you could, for instance, be worried about is replay attacks.
What if somebody uses this protocol and sends the same message again?
The thing that we use to handle this is called a nut.
It's actually a nuns book because we are talking about squirrels here, we are calling it a nut.
And this nut or nuns is a number only used once.
When you retrieve this number, you will push that into your package that you are signing in order to ensure that this is a unique message.
But how can you actually get that nut into your application?
Well, it's a part of the URL scheme that you are using when you are logging in.
How can you get started using squirrel?
Well, there is clients implemented for all the major platforms.
We have a Windows client that runs very well under wine, written by Steve Gibson.
We have an Android client that I wrote that works well on most Android phones after version 16, so that should cover most of the Android phones.
And we have an iOS client that Jeff wrote and that should also be usable for all the iPhones.
And we have a browser extension from a guy called JAP or with a handle JAP.
And all of these implementations are for the clients.
And the clients are a little bit more advanced.
They have a lot of crypto in them in order to save your secret and your keys and make it secure in the connection to a website.
The clients are a little bit more involved.
I spent, I believe, six months of my first implementation of the client.
The protocol and the Windows client have been in the works for five years.
But that was the first prototype and the reference client.
So, of course, that took a bit longer to do.
These clients, they are a little bit more involved and they have a lot more both functionality and complexity.
The good thing is that the service side, the things that everybody needs to implement because you don't need that many clients.
But the service side is quite simple because what you need to do on the service side is take a message, check the signature, look up the user,
and make the user log in.
So, that's pretty much it on the service side.
There are service side implementations, of course, there are a few libraries in different languages,
PHP, C, JavaScript libraries there are out there.
And we also have a WordPress plugin that I was involved in writing.
And also a Drupal plugin.
We have some service solution for OAuth.
And there is also a backend server that Steve Gibson wrote in ASP that you can start up.
And it actually does all the squirrel magic and you just need to implement endpoints to that.
Against that service.
So, there are a couple of different ways of going about it and actually get it working on your server or your solution.
And there will be many more implemented in the future because this is totally open source.
I know that my Android client is on GitHub and it's totally open.
Jeffus iOS client will probably be open in the future.
The browser extension is open source.
The Windows client is written in assembler.
So, that one is not open source just because there isn't that many that can read assembler or can actually have any use for it.
But Steve has said that if anyone wants to look at any of the source code, he can provide that for the specific parts that people are interested in.
They don't want to share all the code if there were.
So, that somebody would create a similar client to his and perhaps have the issue of the false clients that are saying that they are the reference clients.
I'm not really having any problem with that and as I'm totally open client and I sign that client and put that on Google Play.
I can ensure that there is no client for Android that people can't find that are an implementation of my open source code.
So, I'm fine with that.
But you might think that if you have a private key on your phone, for instance, and you need to log into site, can that be problematic if you're sitting in front of a computer?
And you want to log in on that computer but you only have the Android client?
Well, you can actually use your camera on your phone and scan a QR code and gain access that way.
So, we have a solution that you either log in on the same device or you log in on different device using a client.
And the good part about that kind of log in is that you actually are sidestepping the man in the middle because if you are on one device and try to log in and that device might be compromised or might be computer on a library, for instance.
Then if you scan a QR code and do the log in on a totally different network, then there is no chance for a man in the middle to actually follow that communication or it's very hard.
Another thing that you might want to think about is but if I have a secret on my phone, how do I keep that safe?
Well, built into the technology in the clients is that we encrypt all the secrets.
There are no secrets that are in the open.
We only put them into memory in order to do the actual signing and then we will remove them directly after that.
So, we encrypt on the phone and to ensure this encryption and the correctness of this encryption, we will use a password, we can use face-on-lock, we can use fingerprints, and the encryption on the device is also built in a way that we use memory hard encryption function.
You are required to have a bit of memory so that means that you can't actually accelerate it easily with these purpose-built computers that will decrypt passwords or create password hashes and so on.
That will be much harder with this memory hard encryption standard and we also encrypt your password multiple times or we will run it through the encryption process multiple times and we will do that in a way that we actually ensures the number of seconds it takes for the encryption takes for your device.
So, for instance, if you are running on a really good computer, we can do this encryption so many times so it will take five seconds for your password to be decrypted.
The reason we do that is just to make brute forcing very hard or unfeasible for the attacker but this can be a bit cumbersome both writing the password and waiting these five seconds so we have a quick pass solution where you only type a number of characters in the beginning of the password
and we decrypt or encrypt with just one second interval but this quick pass is only used the second time you try to log in or all these times of that of course.
So, when you decrypt your store once then you will have an encrypted quick pass that you can reuse but if you ever do anything wrong with your password entry so if you have a type or for instance have a quick pass of five characters or four characters or you have a fingerprint as your quick pass.
If you ever show it the wrong fingerprint or do the wrong characters in we will wipe that quick pass and require you to type in the long password so it's just for convenience.
Another thing that you can for instance be unsure of is if you are encrypted something on your device with the password and you forget that password you change it someday and then you come back to your device and you have forgotten it.
Well, that is something that we needed to think about and find a solution for and the way that we have solved it is we created a rescue code and that rescue code is something that you print out for instance on paper, write down on paper or any other solution that you store it out of the device.
You are really sure that this rescue code is not on your device and we will wipe it and forget it and never store it anywhere near the device and this rescue code is something that we use to encrypt the super secret encryption key.
This encryption key can create your device key that you use with your password and in that way you can actually use your rescue code and give a new password for your device.
This is what we have for this rescue code is that you can lock your account using your password and then you are only able to unlock your account on any site using your rescue code and that can be if you are out and about and you lose contact with your phone and you feel unsafe.
Then you can lock all your accounts and when you get back home with your rescue code you can unlock them again so you can use them or if you have for instance if somebody takes a phone or you don't have your access anymore and you think that somebody might have your password as well so they could actually log in as you.
That is another thing that we wanted to solve. Then the rescue code comes in handy as well because you can lock your account with your password so nobody can log in and they don't have your rescue code so they can't use it.
Then you can re-key your current account so you get a new rescue code and so on and we will save the old login information so we can actually authenticate to say that this account that is locked I know it's locked but I have re-keyed it now so I can use it again but with this new key because I can
assure you that I am the rightful owner of this account and then we can switch you over to a new key which is under your password and under your control again.
These extra features that have been added to the Squirrel login makes it more or hopefully will make you feel more secure about using the service.
These are not only convenience factors there to make you feel safe with taking control of your authentication again because when we have used the name and password we actually give a secret to the website to keep and now we are taking that control back.
We give the website no secrets to keep just a key, some gibberish that they keep and this gibberish is only interesting to them because the signing and the key is actually derived from their domain name.
So if you log into another site your public key on that site will be a totally different public key.
So the website even if it gets compromised that key that you have given that public key that you have on that site is only interesting for that site and only for the purpose of checking signatures of Squirrel login.
So the hacker doesn't really have anything to gain with getting this password database or this key database because it doesn't really matter.
So that's another thing that makes this secure and safe.
So this is pretty much what I wanted to cover today.
It has been a part of this project for part of these five years. I've been away a bit as well but at least the last two years have been heavily evolved in this project.
I know pretty much all about it or I know very much about it.
So if you have any questions at all about Squirrel don't hesitate to reach out either to my email or leave a comment here or anywhere you can find me and I'll try to answer your questions.
If you find this interesting, engaging or so on you can actually download the client and try it out.
Just search for Squirrel login on your Android device for instance and you will find my client you can go to grc.com and find the windows slash wine client.
Jeff has iOS client I think still is in alpha so if you go to the squirrel forums at squirrelsqrl.grc.com you can actually talk to him there and get access to the iOS client.
You can also find JAPs browser extension there if you want to try it out.
There are a couple of sites that are using Squirrel already. One of them is of course this forum site at squirrel.grc.com.
The forums at twit are using Squirrel at the moment and Brian of London has a blog where he uses Squirrel.
There are a couple of servers out there that are using Squirrel and hopefully there will be many more to come.
I just picked a few that I could remember of my head.
I have some demo servers as well that you can try out.app where you can try it out as well but those are only for testing.
So I hope that you found this interesting. I hope that you are trying Squirrel out later on and I hope to hear from you and that you are listening to my next podcast.
Bye.
You've been listening to Hecker Public Radio at HeckerPublicRadio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HBR listener like yourself.
If you ever thought of recording a podcast, then click on our contribute link to find out how easy it really is.
Hecker Public Radio was founded by the digital dog pound and the infonomicon computer club and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly, leave a comment on the website or record a follow-up episode yourself.
Unless otherwise stated, today's show is released under a creative comments, attribution, share a like, 3.0 license.