Events 1: The SQRL Story

Beep boop - this is a robot. A new show has been posted to TWiT…

What are your thoughts about today’s show? We’d love to hear from you!

1 Like

Just linking to this thread:
SQRL Event at the TWiT Studios

2 Likes

@Leo I’ll be honest, I didn’t watch the whole event. WAAAAY over my head. And if this is covered in the last 30 minutes just tell me…so here’s my question. What is the big picture with SQRL? Should I be excited about it? Should I start using it? Don’t all web sites need to start using it before it really matters?

Very interesting presentation. Good job Steve!

1 Like

You should be excited about the promise it offers when sites adopt it: SQRL gives a site no secret to protect. This means that if the site gets compromised, they will not get a password hash (or heaven forbid an actual password) to try and break and then use elsewhere.

You could start using it, but the number of sites you could use it at are still very low. It’s still in the early stages of adoption of SQRL, and there aren’t any major sites that are using it yet. You could still get experience using it by heading over to Steve’s forums for it:
https://sqrl.grc.com/

2 Likes

One of the other TWiT shows will need to follow up with a demo showing how to use SQRL from an end user experience. Leo wanted this demo toward the end of Steve’s presentation, but it quickly got passed over by Steve. After my own fumbling around in the dark with Test Flight, it was wise for Steve to brush off the idea of doing a live demo. The browser add-on “extensions” work fine but having on a mobile device so you can scan a QR code to login is where the WOW kicks in. Really not ready for prime time on iOS yet. I also installed the WordPress plugin, and it works fine too.

2 Likes

The iOS client really isn’t ready for prime time, I’m afraid. I mean it works, but it is still not on the store, and it is really lacking in a bit of spit and polish. There are some necessary features that are still yet to be implemented, such as changing the password on your identity. There is a strict limit on the number of participants in the TestFlight process also… I think it’s 10K people. So if everyone started using it, that would soon be an issue.

Discount what I say, because it’s way over my head too, but I think what we have here is concept and proof of concept.

Steve has extensively documented the concept, and from the overview he gave I think I can see bits of what could make it revolutionary, although I don’t think I’ll ever have the depth of understanding to grasp it fully. Then he has created an iOS proof-of-concept which allows it to be demonstrated. Finally we have publication, which is what the documentation and this TWiT Event achieve.

From here on it’s up to developers and people who commission apps to adopt this for the future. It will take time, and publicity about the viability of the method will need to keep happening for the developer community to start experimenting with it.

2 Likes

This is not a criticism… I just want you to consider that you probably understand it well enough, you just may not realize it yet.

Traditional passwords are one way encoded for storage on the server. You don’t need to understand the SHA hash used (or the PBKDF2 algorithm) to understand how logging in with a user ID and password works… right?

For SQRL, it does one extra step. (This is a massive over simplification, of course, but in order to understand what it does, I think it helps.) It takes a secret value (which acts like a large random password) and does that same hash process, and then converts it to a private key and the corresponding public key. The first time you visit, and establish an account, the site stores the public key in your user record. When you make return visits the client proves that it [exclusively] has corresponding private key that matches the public key stored with the account.

Public key cryptography is difficult to explain non-mathematically, but an over simplification is this: the public key is called public because you can publish it widely, it does not give an attacker an advantage. The private key can do things that the public key can undo. If you sign a message with the private key, it will be publicly readable, and the public key can verify the signature. In this way you can “sign” a proof (like signing a paper contract you will be bound to.) SQRL uses this idea… you sign a document saying you’d like to join a site, and the site stores the public key. When you return later, you sign a document saying “I’m back again” and the site verifies the signature with the public key.

Since only the correct private key can match a public key, and if you keep the private key truly and fully private (much as you do with your passwords of today) then having control of the private key can work as a proof of your identity in the same way that passwords are used for this today.

2 Likes

That’s the point, Steve hasn’t created an iOS proof-of-concept. The standard is completely open and a SQRL enthusiast, who happens to be an iOS developer, threw together the iOS app. The same for the Android app, and I’m assuming macOS.

Anybody who wants to, and understands enough about crypto, can take the definition and write their own application for this. LastPass, for example, could incorporate it into their apps and browser add-ins, if they wanted to.

Ah, I missed that. It’s going to depend on enthusiasts creating applications for specific implementations in the early days, until it gets taken up more widely.

1 Like

@PHolder @Clayton @big_D thanks for weighing in on this. You’ve all helped me understand this a bit more.

1 Like