SQRL - Replacement for usernames and passwords

https://www.grc.com/sqrl/sqrl.htm

by richardjs • 13 years ago

205 131 13 years ago

yogo• 13 years ago

Very interesting solution. I haven't listened to Security Now in a while but it's good to see Steve Gibson thinking about these things.

nfoz• 13 years ago

How does this compare to OpenID? Seems similar except with the premise that a user is their own identity provider, which is a QR-code-reading app on their smartphone.

I like!

y0ghur7_xxx• 13 years ago

How does this compare to OpenID?

It's completely different. You don't need to remember an url, you don't need to remember a password, there is no third party involved in the authentication process, ... I could go on, but it's really a completely different authentication mechanism.

tptacek• 13 years ago

How is this better than any other phone-based 2-factor auth scheme?

__david__2• 13 years ago

Well, it's not really 2-factor is it? It's just the phone part of a 2-factor login and no web form part. Presumably the screen shot that showed a login form was for people without the phone app.

lstamour3• 13 years ago

Though for security, it doesn't preclude one from entering a password as a second factor, I suppose.

roc2• 13 years ago

"Well, it's not really 2-factor is it?"

Whatever you use to unlock/authenticate to the device would be the other factor.

elliottcarlson2• 13 years ago

It's not - it's really just a password manager. The "something I know and something I have" is completely removed by only requiring you to have the phone. If it's a password manager, then that is what it is; if it's meant for security, then it comes back to the recent article on fingerprints not being a password.

lstamour3• 13 years ago

I dunno about the fingerprints analogy, that's still more boneheaded -- I mean, I can change digital secrets a lot easier than I can change my fingerprints ;-)

richardjs7• 13 years ago

It's not really a password manager--there's no shared secrets. The site identifies you by a public key. For authentication, it gives you a nonce, and you sign it with the corresponding private key. All the secrets are kept on your device.

I've wondered about the "something I know" dimension as well. Perhaps a passphrase could be used (it already is used to secure the master key). It'd still be a major improvement, as only your local device would need it, and you wouldn't have to have a separate password for each site.

veesahni2• 13 years ago

It's 1 step. Just scan a code.

Con: requires internet connectivity, unlike some 2-factor implementations

lstamour3• 13 years ago

Beyond that there's no explicit second-factor here, if you don't have Internet, what are you proving your identity to? If local, then run a local server...

gbhn• 13 years ago

2-factor can be done in the post-password sense (require the second factor after this SQRL step), or alternatively, the algorithm the phone does could use a second factor at that point.

eximius• 13 years ago

Well, theoretically you could make an implementation which reads the QR code then displays what would have been posted to the server. Via a web-browser extension, you could then type this into a form field and have that log you in. You could base<something> encode it to make it a little easier.

So, it seems feasible offline with online required only for convenience.

jonny_eh• 13 years ago

Isn't access to the internet already required to log into any internet site?

richardjs7• 13 years ago

That's a question I have. One potential answer is that it moves authentication out-of-band, in case there's a keylogger or other malicious mechanism of the machine you're using. Also, it removes the need to remember a separate password for every site. Your master key is secured with a password, but that's it. It also removes the need to have a shared secret with a site, and doesn't require any third-party involvement.

He spends a good chunk of the latest episode of Security Now [1] describing it's advantages over current schemes. The episode isn't up yet (I listened to it on the the site's live stream), but it should be soon.

[1] http://twit.tv/sn

juhanima• 13 years ago

Not exactly a new idea. Here is some prior art

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/14761/6...

http://www.computer.org/csdl/proceedings/ares/2009/3564/00/3...

As far as I know, QR-TAN is being used in Germany for authentication by a number of banks.

phpnode3• 13 years ago

drivebyacct2 - your account has been dead for about 100 days and 200 posts, basically no one can seen your messages unless they have showdead on. Here's the "offending" post that you were banned for https://news.ycombinator.com/item?id=5982741 (hint - the ban is completely unjustified)

DanBC3• 13 years ago

Ahem.

(https://news.ycombinator.com/item?id=5974604)

veesahni2• 13 years ago

Interesting - so you generate a key pair on your phone (this is your identity and can be backed up to a printable QR code). Then, to login to any site, you scan a QR code displayed beside a login form and your phone can verify it''s identity (i.e. proves that it's the holder of the key pair). Perhaps on the first sign-in, the site will ask for an email address or some details to create an account for you.

umsm• 13 years ago

This is an interesting concept.

The authentication should be safe to be transmitted on the same network... What about if the phone and computer are on the same (i.e. WiFi) network?

dsl2• 13 years ago

http://attrition.org/errata/charlatan/steve_gibson/

Steve Gibson is somewhat of a "fringe" charlatan. In some professional security circles, he is not considered a reputable security professional, rather more of a snake oil salesman peddling third-rate software with bold claims. While many of his claims are a bit outlandish or bold, few, if any, are demonstrably false. However, when asked to speak on security topics, Gibson is getting adept at putting his foot in his mouth. A single amusing quote may be laughable, but a series of them begin to paint a picture of someone who doesn't really understand security. Rather, he seems to know enough buzzwords and ideas to be dangerous to his clients.

richardjs7• 13 years ago

Not to use a debate cliché, but isn't this a ridiculously shameless ad hominem? He's published the protocol and disavowed any intellectual property claim to it. Let's focus on critiquing the protocol.

dsl2• 13 years ago

An ad hominem attack would be attacking him for unrelated traits, i.e. "we can't trust people with blue eyes!"

I believe his history as a snake oil salesman is highly relevant to his current "security" work.

anateus3• 13 years ago

There are a few types of ad hominem but they all involve using some property of a person that is only tangentially related. This note about how the majority of the security community sees Steve Gibson speaks directly to an assessment of his ability in this field.

hamburglar2• 13 years ago

Personally, even if the design is ok, I don't care to give this chucklehead any publicity. Maybe the blind squirrel found a nut (see what I did there? SQRL?) by getting a design right. Doesn't mean it's anything particularly clever, or that we should use it and give him something to base his incessant self-promotion on for the next 20 years.

chj2• 13 years ago

His idea as it is now is new (at least to me) and practical. Most people don't have the time to care what he said or did before.

BarryGrw• 13 years ago

Looks more like a simple character attack than anything. Steve is prolific, experimental, and has been around a while, so it's understandable he hasn't done everything right, but I haven't found any other instances where he is considered a "charlatan" by other security professionals.

jccalhoun• 13 years ago

Gibson is prone to hype and proclaiming that the sky is falling which is why I rarely listen to his show. However, a lot of these are nitpicks where he either gave the wrong meaning of an acronym or oversimplified something while trying to explain it.

B-Con• 13 years ago

I can't make him out to be a buzzword slinger. I've listened to quite a bit of his show (although admittedly very little from the past year or so) and he definitely demonstrates good knowledge. Listening to him talk, my impression is that he brings the security mindset[1] to the table, rare among snake-oil peddlers or charlatans.

I think one of the main problems is that people in a field are generally critical of people who translate that field to a wide audience. You see that play itself out over and over. And that's what Steve does with his show, he tries to explain security to, more or less, laymen. And he only has an audio medium, which adds some difficulty. So, yes, he simplifies some things and this no doubt troubles a lot of security gurus.

Of course he's made mistakes on the show. I can recall a few, but most of them were caught and corrected later. He doesn't script it, so I'm sure you can find many examples of poor word choices or incorrect acronyms over the 300+ shows he's done.

I do think he's over-played the practical usefulness of some security products that he advertises on the show. I have experience with none of them (to my knowledge), but some of them just sound, to the trained ear, minimally useful. But, sadly, that's audio content advertising for you.

From the link, we have statements like:

For whatever reason, Gibson tries to explain the Metasploit project as a "malware exploitation framework"

OK, that's a bad description. But he was describing Metasploit in passing using a description of Metasploit as it pertained to the subject at hand. And, if you read the actual transcript that they linked to, it was being used for malware exploitation. Seems like a silly nit-pick.

You can't simply raise the spectre of global spying and hidden rootkits planted by Microsoft without either proving or disproving the allegation

No. If you see something alarming, you totally can. He didn't panic either.

Steve said SSL connections are not susceptible to man-in-the-middle (MiTM) attacks? This is absolutely false.

Please. SSL/TLS has had vulnerabilities that allowed MITM attacks. They're ad-hoc and eventually get fixed. You can't just expect to MITM a random SSL connection. SSL is designed to be MITM-resistent, and saying "SSL prevents MITM attacks" is not in any way a bad description, especially when you're communicating to laymen.

Further, having a switch does not absolutely prevent sniffing traffic. The popular Dsniff tool lets you do this.

Yep, he got that wrong.

Close Steve, CSMA stands for Carrier Sense Multiple Access.

Yep, he got that acronym wrong. But I decided to check the next show[2]...

[Steve] Also, I mangled an acronym, and I hate when I do that, especially acronyms that I know so well. I talked about CSMA, and I called it Collision Sense Multiple Access instead of Carrier Sense Multiple Access. And it has a CD on the end which stands for Collision Detection. [...] So the real acronym for Ethernet is CSMA/CD, which is Carrier Sense Multiple Access with Collision Detection

So he switched a word in an acronym, then corrected it next episode. But they complained anyway. I couldn't have scripted it any better to what I said above.

Those examples were skimmed from the first three links. The authors came across like they had a vendetta to nit-pick everything they could. They've blown their own credibility already as far as needless nit-picking, missing the forest for the trees, and not checking to see when he corrects his own mistakes (aka, doing their homework).

I'd hardly summarize all that as a "fringe charlatan". He may be a bit fringe-ish, but I don't see how he's a charlatan.

[1] https://www.schneier.com/blog/archives/2008/03/the_security_...

[2] https://www.grc.com/sn/sn-017.txt

mixologic• 13 years ago

"because the private key required to create the signature never leaves your smartphone."

Sure. People never get their phones stolen, never buy new phones, people never irreplaceably destroy their phones dropping them in a toilet.

bargl3• 13 years ago

He points this out himself under "Among the problems we have solved to create a practical solution, are:". It is toward the bottom.

richardjs7• 13 years ago

He described a local password (basically a passphrase) on the "The user's view of the application" page[1].

[1] https://www.grc.com/sqrl/userview.htm

artjumble• 13 years ago

This all sounds interesting, but I was just thinking this would be a great way to unlock a computer. Scan the 'lock' screen with your phone. Probably not good for an office environment (too easy to grab someone else's phone), but I would use it at home.

derefr• 13 years ago

The thing this is most similar to is Twitter's recent 2FA implementation. Except, instead of the site automatically pinging the app to open on your phone (and then you ACKing or NAKing the ping), it requires you to open it yourself and scan a code on the screen (thus implicitly ACKing it.) Everything else happens the same.

donmcronald2• 13 years ago

It seems like the basic idea isn't unique. I was thinking of something similar a while back and found https://tiqr.org while looking for similar ideas.

asgentile• 13 years ago

Thinking about the user experience for this. I want to authenticate, so I hunt down my phone, launch an app, scan a code, press a button in the app to submit. This seems to me like quite a long process versus the traditional typing in a username and password. What about the implications of a stolen phone?

richardjs7• 13 years ago

With the traditional username/password system, you have to remember a unique, secure password for each site--or else you use a password manager, which involves more steps as well. He's also mentioned that this could be adapted into a browser plugin, so that would streamline use on a trusted machine.

As for losing the phone, he suggests a passphrase-like "local password" on "The user's view of the application" page [1].

[1] https://www.grc.com/sqrl/userview.htm

jimueller• 13 years ago

Seems similar to the discontinued Google Sesame. http://www.zdnet.com/open-sesame-googles-no-password-log-in-...

It would be interesting to know why Google didn't pursue it. Maybe a 20% project? https://plus.google.com/101935995649723391317/posts/P94xEz9D...

seldo• 13 years ago

How do you log in to a mobile site if you have to use your phone to scan the code?

donmcronald2• 13 years ago

A mirror and a front facing camera :-)

jensenbox• 13 years ago

Wouldn't you need at least 2 mirrors to correct the image?

teleclimber2• 13 years ago

I assume that in addition to the QR code there would be a link that would trigger an intent to open the authentication app with the necessary data. At least on Android that's how it could work.

chj2• 13 years ago

A minor problem is that auth app has to return back to the browser with a new link which the browser may not be able to open within the original login tab.

Groxx• 13 years ago

Currently: heh, good point.

Future: bookmarklet / plugin / browser support that detects the code on the page.

brokenparser• 13 years ago

Obligatory XKCD: http://xkcd.com/1237/

rebelde• 13 years ago

With your computer's webcam!

josephwegner2• 13 years ago

So, this is essentially a less cool version of getclef.com , right?

rpledge• 13 years ago

This is very similar to my project at http://qrauth.com

lisper• 13 years ago

Another replacement for usernames and passwords:

http://dswi.net/

Note: the SSL certificate on the demo server has expired. I'm working on getting it renewed, but this is just a demo anyway.

habosa• 13 years ago

This looks like a much less polished version of Clef (https://getclef.com/). Clef is a really awesome app and they're already powering this type of integration for a few hundred websites. One of the founders is an HN regular, although I can't remember his username (Jesse, reply if you see this).

jessepollak9• 13 years ago

That's me, thanks! We're glad you think we have a little more polish, but to be honest, we're really excited about any replacement to passwords making waves in the tech world. Ultimately, no single group is going to be able to tackle this problem alone, so the more critical thought we have, the better off we all are.

If anyone has any questions about Clef, I'd be happy to answer them, but I also don't want to distract from the discussion going on around this proposal.

Mithaldu4• 13 years ago

One question: What's keeping you from developing a desktop client, so i can login without needing my phone around? From what i can see on your website, Clef simply uses a key stored on the phone to generate a password† that is then sent to the website to be logged in behind the scene. There shouldn't be anything stopping a user from using a program for this on any os, as long as it has the ability to obtain the nonce‡ from the website and the user-unique key.

† password used here in the loose sense of being a user identificator including both the identity of the user and a secret unique to the user

‡ which is even more simple than a QR, as it's simply a barcode, albeit an animated one (the animation doesn't factor into the value at all, right?)

nly5• 13 years ago

Technical crypto spec?

victorf• 13 years ago

That looks awesome. It works everywhere that OAuth does? Can it be used with a password as a 2FA?

abcd_f• 13 years ago

You should really make a "Show HN" post. Just make sure to mention it on Twitter ;)

frezik2• 13 years ago

How does this work for mobile sites? This looks great for using your phone to login on the desktop, but how do you use your phone to login on the phone? I'd love to push this where I work, but I don't think it will fly if it doesn't work on the mobile site.

khalstvedt• 13 years ago

Indeed, and the polish is what makes Clef awesome and a pleasure to use. Their Wordpress plugin is a great way to drive adoption, but I find myself wishing more sites supported it.

pbreit2• 13 years ago

Using this type of technique (Clef and SQRL) on every login sounds like a particularly evil version of hell.

city41• 13 years ago

I have found 1Password to be pretty hellish, and I don't even consider not using a password manager an option anymore. So clef and SQRL sound great to me.

jessepollak9• 13 years ago

any particular reason why? I'd love to hear more of your thoughts...jesse @ our domain (if you have a second).

Rafert• 13 years ago

That is looking great! I saw something similar called http://www.computingobjects.com/qrauthinfo/ but Cleft is looking much nicer.

blibble• 13 years ago

google did this last year: http://www.zdnet.com/googles-open-sesame-login-ditches-passw...

Mithaldu4• 13 years ago

This is functionally the same thing as https://github.com/habnabit/passacre , only tied to a cellphone in exchange for sparing the user the burden to remember their login. It would be interesting if the SQRL website code would also display the nonce under the QR and the user could download a desktop program to paste the nonce in. Even if it weren't open source, as long as both windows/linux binaries are available, people could even set it up on a server of their own so they'd just paste the nonce at a private url.

jaequery• 13 years ago

i love the site's design

peterwwillis2• 13 years ago

Here's why this is stupid: This is 1-factor authentication, but it's actually LESS secure than a username and password.

A password is something you know - it's in your head, so it can only be stolen if you save it somewhere, or if there's malware on your computer sniffing it.

The tokens in the phone are saved in the phone, so if you lose the phone, you've just lost your password/set of keys. On top of that, malware in the phone can extract the keys.

With malware on your phone, your accounts can be pilfered without your knowledge, at any time. Or if your phone is stolen. This is different from 2-factor, where you have to both know a secret AND have access to a device.

(If the prospect of malware on your phone doesn't phase you, consider that news articles over three years old reported hundreds of thousands of malware installs found by various security companies)

patrikr• 13 years ago

The key on the phone is of course encrypted with a password.

DanBC3• 13 years ago

Malware on the phone isn't covered by their attacks and weaknesses page. (https://www.grc.com/sqrl/attacks.htm)

The Userview page seems to miss that point as well: (https://www.grc.com/sqrl/userview.htm)

In other words, only the smartphone's owner can use the system to assert their identity, and nothing will prevent them from asserting their identity whenever they wish to.

I think they mean "only the person currently in possession of the smartphone" ...

except they go on to say that whoever has the phone has to identify themselves to the phone using a strong password.

The SQRL system was specifically designed to eliminate username and password authentication to remote websites. But controlling access to SQRL authentication itself requires the smartphone's owner to prove their identity to their own phone.
And to that end, “a secret only the user knows” is still the best technique for users to repeatedly, quickly, easily and privately prove their identity to their own smartphone.
The cryptographic design of the SQRL system inherently provides identification security for every website it contacts. In that sense the system itself is fully secure without any password protection. We refer to the SQRL password as a “local password” because it is only used to prevent others from using the SQRL smartphone app to impersonate its owner.

santosha• 13 years ago

Mobile malware is overrated. People have been making a lot of noise for a long time, there's hardly any actual infections observed in the real world. http://chazlever.com/publications/traffic-ndss13.pdf

nly5• 13 years ago

No, it's two factor.

If you look at the crypto page the scheme he proposes uses an 'identity password' in combination with a strong KDF (scrypt). The resulting hash is XOR'd against the masked master device key.

peterwwillis2• 13 years ago

Do you enter the identity password each time you scan a qr code? If not, it's still one factor. Even if you can enter it each time you scan, it's still only on the phone, making it the same if not less secure than doing it all on your desktop.

ds9• 13 years ago

The user is vulnerable, not only to "malware" but also to the phone vendor (and anyone the vendor enables, notably government). The degree of control one can attain over a phone or tablet is much less than on a general-purpose PC, and the latter is hard enough to relatively secure. Smartphones are captive, remote-controllable devices and as such are not trustworthy for secure communications or any important secrets.

This fact, together with grc's implications that the scheme is novel, important or secure, supports the derisive view of the author in the sub-thread above. Also check out the stylistic buffoonery on his site.

gcr5• 13 years ago

If you have ever typed your password into your phone, your password is vulnerable to the exact same attacks (keyloggers, caching, ...) you mention.

note that i am not affiliated with grc; my name is permuted :)

DanBC3• 13 years ago

They don't offer a reference implementation.

The documentation provided is a bit rambling and jumps around; it has stuff people don't need and doesn't have some stuff people do need.

It's a bit scary to think that people are going to implement some crypto stuff based on just this and release it into the wild as a secure solution.

There's a similar problem with password safes - some of them seem secure enough, but there are many and who knows whether those are any good or not.

EugeneOZ• 13 years ago

I feel is something missing in that algorithm of check. And... Not all services are web, not all web services are public (so mobile app will not be able to open url), and U don't understand why bots will not scan that QR.

nly5• 13 years ago

I think you can MITM this by presenting legitimate (proxied) ycombinator.com QR codes on e.g. ycombigator.com.

The app would still authenticate to the legitimate site and then 'activate' the session, and ycombigator.com could have at it. HTTPS won't help either. The problem is there's no way for the phone app to transfer additional secure session cookies back to your desktop browser, so this has to be the case.

Sure, the app will display the legitimate domain or URL but the user probably thinks that's what they're viewing on their desktop anyway, so will likely accept.

Requires mutual authentication.

gcr5• 13 years ago

This attack can be stopped by referer checking. A site that hosts a QR code should display a warning instead of the QR code if the referer doesn't match.

nly5• 13 years ago

The malicious site in the middle can download the legit QR server side (e.g. using PHP) and simply spoof the referer, then present it to the visitor. Where will a referer check help?

phpnode3• 13 years ago

https does not expose referrer, and you are logging in through https, right?

e12e• 13 years ago

Nice system - but there's not even a proof of concept? Or am I missing something?

ijansch• 13 years ago

Have a look at http://tiqr.org for an existing implementation of this same idea. Complete with open source server implementation and android/ios apps (which are open sourced too).

Sami_Lehtinen• 13 years ago

Quick + / - analysis:

- "But no two visitors will ever have the same ID". - How is that confirmed, generating random 512 bit keys do not guarantee never having same ID. It's just quite unlikely.

- SQRL lacks strong web-site identification, that's a bad thing. Domain name isn't strong authentication. I would like to include strong site identity with within the QR-key. (Evil website attack, NS spoofing / MITM)

+ No shared secrets is a real bonus. Except, if the attacker has full access to the site already and steals password, they can steal everything else. Therefore if password hashes are stolen, it's major breach of security, and all passwords should be immediately reset. Of course nobody's using same password for separate sites. So, site was breached and thats it anyway.

/ Out-of-band authentication, well, in some cases yes, in some cases no. I wouldn't call this true out of band solution. Especially when using mobile browser, or shared WLAN connection. Fact that authentication data is also routed on same internet route at the server end sounds quite likely. Of course this can be fixed by service provider if they really want to do it.

+ No third-party, that's the only way to go. In anycase when there's a third-party, the solution already sucks badly. That's one of the main reasons why I hate most of SSO solutions. (Single Sign On)

- Mobile (nor desktop) devices aren't secure, having keys in mobile device isn't considered to be secure and those can be extracted. Default mobile device protection isn't good enough for password / identity protection. Most of people aren't even using simple 4 digit pin. Real + would come form completely separate authentication device.

- Using long password with mobile is horrible. My GPG private key password is 20+ chars including tons of special chars. Try typing that with mobile, repeatedly. If shorter passphrases / keys are used, not enough entropy is included.

- "A password lockout system". Eh? Same method should prevent any web-site password hacks too. ;) Anyway, with proper password, guessing should still be futile, read my statement about password earlier. If the password got even 128+ bits of entryopy, it's going to be long guessing marathon. I don't really care even if you try to guess 1 or 10000 pwd/seconds.

/ "such as a personal safe deposit box" - Is not truly secure, what a joke stament.

- Document doesn't describe how identity authentication is linked to the actual client logging in. Basically this would mean that there has to be cookie version of cryptoraphic challenge, or some other data linked to that, which has to be stored for a while at web-servers end. Could this be used to create resource consumption DDoS attack on the service? That's one of the reasons why I don't like solutions which require web-server to maintain state for non-logged in users.

spikels• 13 years ago

You are incorrect on your first point. This is an example of the birthday paradox[1].

With 2^512 possible keys (~10^154) even if everyone on earth (~10^9 people) got a billion new IDs every second (~10^18 per person per year) it would be more than a hundred thousand billion billion billion billion billion years (~10^50 year) before there was an even chance of a single ID collision (~10^77 IDs => 50% chance of 1 collision). So I think we can safely assume there will not be a collision.

In fact it is almost always the case in cryptography that there will be some risk of failure but as long as that risk is very small the system is considered secure. This is way way way beyond the normal standards of security (say 10^30 or so).

Many of your other points are a matter of opinion. There will be always tradeoffs between usability and security. This system appears to offer similar or perhaps even improved usability to existing two-factor systems with enhanced security in some respects but similar weaknesses in other respects. I would love to hear the opinions of cryptographers and security experts.

[1] http://en.wikipedia.org/wiki/Birthday_attack#Mathematics

maaku4• 13 years ago

generating random 512 bit keys do not guarantee never having same ID. It's just quite unlikely.

Truly random 512 bit keys will never repeat, ever, under any circumstances. Seriously, they won't.

sigkill3• 13 years ago

I'd be careful if I were you. Cryptography and cryptographers are an odd bunch. "Never" literally means never, while in your comment "never" means not in our life times, or a thousand, or billions of years. In case of infinite time, 512-bit RNG'ed numbers have to repeat at some point in time.

You may consider this pedantism, but it's this pedantism and conservativeness that calls AES broken today.

joetech• 13 years ago

I don't like this as standalone authentication, but as part of a 2-stage scenario, I would use it.

dlucci• 13 years ago

Correct me if I'm wrong, but couldn't this still be susceptible to DNS Spoofing? This goes under the assumption that the URL has not been tampered with, if I'm not mistaken?

jbert• 13 years ago

I think this is pretty the same thing as storing a secure cookie?

Except the 'cookie' is the private key on the phone, so it's tied to the phone not to a particular browser.

Other than that, I don't see a difference between the two?

I think this is basically a long-lived session cookie, stored out-of-band.

I also don't see how the public/private keypair changes anything. Why not just store the nonce on the phone? If the nonce has only ever gone over https to the user, no-one else will know it.

SQRL - Replacement for usernames and passwords

Related Stories