SQRL (Secure Quick Reliable Login)

[Mark0]

What about this?
I admit I am not very fond of Mr. Gibson (mainly due to the tecnobabble about Spinrite and the whole personal firewall thing), but this seems interesting.

Secure Quick Reliable Login
Proposing a comprehensive, easy-to-use, high security replacement for usernames,
passwords, reminders, one-time-code authenticators . . . and everything else.

Gibson Research Corporation - Secure Quick Reliable Login

Another information site about it:
SQRL - An Illustrated Guide

[mouser]

Thanks for posting this Mark0 -- I am just getting ready to write a new blog entry for my Mewlo web framework about website registrations+logins, and this is useful.

[mouser]

Just read through SQRL -- I like it.

[ewemoa]

Obligatory Wikipedia page.


A ghacks.net article too.

[Mark0]

A brief video that show it in action:

https://www.youtube.com/watch?v=UQAUVLpb1pU

[Stoic Joker]

I find paradigm shift of responsibility a bit troubling in that while seeming more secure it affords the option of quietly snatching the info off someone's phone, where passwords have to be rather noisily beaten out of someone.

Not to mention that I'd love to know where SG found a PCI compliant tattoo shop for his QR code backup suggestion. ...Actually I'm betting he doesn't actually have any tattoos or he'd know better because 20 years from now it ain't gonna scan right.

Hacker mentality of reflexively trying to shoot holes in things aside. It'll definitely be something to watch for ...  While (shoulder surf) scanning the sticky notes that are invariably taped to the edge of peoples' monitors.

[MilesAhead]

This is starting to remind me of a sci/fi story(can't remember the title offhand) where the secure physical lock took a thumbprint. But it didn't stop there.  It scraped a tiny layer of skin and performed a DNA analysis to determine the owner was the one opening the lock(similar to Gattaca but predates it I think.)  Anyway the author stated the big drawback to this "key" is that you cannot give it to someone else.  "Here, go fetch my stuff out of my locker" doesn't work. 

As it goes on I think more people will end up locked out of their own accounts.  The true break-in pros will likely go to a deeper level to get in.  (Everything has some kind of diagnostic mode.)

[mwb1100]

quietly snatching the info off someone's phone,  where passwords have to be rather noisily beaten out of someone.

Currently passwords are quietly snatched off of servers - by the millions at a time.  Something needs to change (not that I'm sure that SQRL will or should be that change).

As far as quietly snatching something off a phone, the idea is that the SQRL key on the phone will be protected by a password so there will still need to be a noisy beating to steal the SQRL key off the phone.  What the SQRL protocol changes as far as web authentication goes is that the password never has to be sent anywhere else.

[Stoic Joker]

Anyway the author stated the big drawback to this "key" is that you cannot give it to someone else.  "Here, go fetch my stuff out of my locker" doesn't work. 

As it goes on I think more people will end up locked out of their own accounts.  The true break-in pros will likely go to a deeper level to get in.  (Everything has some kind of diagnostic mode.)

Yepper! ...That's where I'm coming from.

quietly snatching the info off someone's phone,  where passwords have to be rather noisily beaten out of someone.

Currently passwords are quietly snatched off of servers - by the millions at a time.  Something needs to change (not that I'm sure that SQRL will or should be that change).

SQRL will have zero impact on that end of the problem. Disgruntled employees and poorly coded customer data security will always be an entirely different animal. If someone does a SQL injection attack on a corporate db that allows them to dump the user table containing name, address, CC, security question responses, etc. ...What actual value does the password column have?? None ... It's completely useless/delete-able because "the juice" it may have had has already been squeezed.


It's all about risk reward. What is gained, what is lost. So if the uber secure (ish...) scheme effectively makes it impossible for ones spouse to pickup the dry-cleaning ... Then we're not really fixing anything.

It's much like the security theater requirement of having to enter a zip code when using a CC at a gas pump. Unless you happen to be out of town...the answer is obvious. Net effect = completely pointless.

Sure it seems like a cool technology, but what are we giving up on the process?

[mwb1100]

f someone does a SQL injection attack on a corporate db that allows them to dump the user table containing name, address, CC, security question responses, etc. ...What actual value does the password column have??

The value is that the person who dumped the database doesn't get passwords.

Just because a proposal doesn't fix every problem doesn't mean it has no value.

I agree that fixing the password storage problem doesn't necessarily fix stolen databases with CC data.  However, it does fix the problem of a password database being stolen from a 'low value' site (such as one that doesn't store CC data) to be used as a userid/password database against high value sites.  For example, using a password database stolen from a simple forum to be used as way to possibly gain access against banking site (because users tend to use the same password for multiple sites).

As far as the zip code entry at gas stations - I don't know how effective it is. But in the area that I live in there must be more than 40 zipcodes - I imagine that if the system detects someone trying to guess zipcodes for a particular card a security flag must get raised at some point that disables the card. But I'm just guessing.