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. ![smiley :)](https://www.donationcoder.com/forum/Smileys/fun/smile.gif)
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.)-MilesAhead
Yepper! ...That's where I'm coming from.
![cheesy :D](https://www.donationcoder.com/forum/Smileys/fun/biggrin.gif)
quietly snatching the info off someone's phone, where passwords have to be rather noisily beaten out of someone.
-Stoic Joker
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).-mwb1100
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?