SQRL - Secure Quick Reliable Login

I just wish there was a hardware solution, these days having a phone as a second factor is not safe enough.
Infecting from your laptop to your phone while charging is becoming a popular vector.

Rather than Trezor I think Fido U2F much more robust.

I believe, Trezor firmware is going to support FIDO standards soon! Check https://github.com/trezor/trezor-mcu/tree/u2f/firmware/u2f

2 Likes

I was so hoping it had to be pronounced “squirrel” :joy_cat: And look!

Sounds like a cool idea; I can’t think a way to integrate it with the way SAFE login works, though…

My hdd encryption password is a random sentence of about 10 words. Zxcvbn guessed it to be about 180 bits strong, which sounds reasonable. As for the 12 letters, here’s a classic:

4 Likes

The client takes your credentials and generates a request to the network for your account “files” so why not have the device challenged by the closed group and the response decrypted by the closed group and your account details returned. The key derived from SQRL replaces the response from the client for login. Maybe insert a pin still so that if you walk away from your desk someone else cannot just use your device.

Of course if you use a h/w device (usb?) then all the authorities have to do is take your device and guess your pin. At least with a name/passphrase/pin you have to remember then the authorities have to make you reveal it. And to defeat that you have previously created a account that is plain vanilla files and use it occasionally. Even if the two accounts are only different by its pin.

1 Like

I suppose the Xkcd cartoon is assigning 11 bits of entropy to each word because he’s selecting from a list of 2^11 words = 2,048 words. Sounds reasonable. I read somewhere that one can get by in any language, spoken and written, by learning the most common 5,000 words, and you wouldn’t want to use words that some people might not have encountered.

Aren’t account details just another opaque blob though? In other words, this mechanism is required for all blocks or none… But I may be wrong.

I’d say each account either has sqrl OR name/pass/pin as each will result in different blob addresses

But I’d say you could encode the blob address in the SQRL challenge response so that the two could be tied together. But that would require more code for the closed group to process but could be done.

1 Like

I for one want a U2F device with a screen that can display what I’m authenticating, so this is great. I want the screen so I know I’m not authenticating my bank (or worse, my SAFE account :smile:) when I’m signing in to some random site.

Safe login is not “authentication” in the usual sense of the word; it’s just a deterministic way to address and decrypt an otherwise nondescript block, and it’s one of the things I really like about it :smiley_cat:

We could of course do a public key based challenge/response thing, where by signing a challenge one would prove they own the key. That would require an extra block to connect the key to the login block, and SD blocks that contain login credentials to be differentiated from other stuff (and also from “normal” login block) so that they would not be returned without a challenge/response round; idk if that’s how things work currently.

That is what I was trying to say. The SQRL gives an address too, if you want. Just the closed group sends a challenge and the response is the address embedded in it. The challenge/response-wrapper is to prevent replay attacks.

And this is the issue to allow both name/pass/pin to result in the same address as the SQRL and is why the resulting address from the name/pass/pin might have to be embedded into the SQRL response.

Then the “nondescript” block is returned to the client. Job done. Just extra code in the nodes and the client to understand that a SQRL interaction has occurred and to expect the “nondescript” block of account info.

SQRL is finally finished :kissing_heart: best login ever

5 Likes

Had a look at the video explaining it. Sounds like what SAFE is providing by one login and hold the keys for accessing sites.

Either SAFE could implement it for SAFE sites as credentials/ID or SAFE could store in the account blob a set of usernames and key for the sites rather than handshaking.

But this sounds good for the current web. When Fleming comes out it might be good to contact mr GRC and see what thoughts he would have on an implementation for SAFE since SAFE removes some of the restrictions/problems caused by the current web.

3 Likes

I think he’d be pleased to make some connections. As far as I can see the only website compatible with SQRL at the moment is the SQRL site itself.

I like the way he’s worked through many of the edge cases around lost passwords, multiple IDs, shared IDs etc. It’s an interesting video.

3 Likes