
SQRL - Replacement for usernames and passwords - richardjs
https://www.grc.com/sqrl/sqrl.htm
======
habosa
This looks like a much less polished version of Clef
([https://getclef.com/](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).

~~~
jessepollak
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.

~~~
Mithaldu
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?)

~~~
jessepollak
Nothing is stopping us from a technical standpoint. Multiple devices is
something we plan on adding, but we're being really careful about it because
it increases complexity and introduces more vectors of attack. We also think
that a phone is tied to a user's identity more than a computer or a tablet, so
that's what we're really focusing on. Give the flow a shot and let me know
what you think.

~~~
Mithaldu
As a counterpoint: It's far more likely i might be mugged for the easy cash
scored by a phone that has a 500€ market price, than to have my desktop
stolen. ;)

One more question:

How about sites which don't have clef implemented? Can i enter a URL into the
clef app (or use some kind of JS scriptlet to generate a QR code on the fly)
and have it generate me the password for that, so i can type it in manually?
Maybe even store usernames for such sites?

Right now Clef has zero use for me, as i've never even seen a website that
implemented it. But something like that would at least add some use.

(Also i'm sad that you didn't confirm or deny the footnotes.)

~~~
jessepollak
Right now, sites need to explicitly integrate with us. We've thought a lot
about creating something that manages passwords to bridge the gap. We've
actually been working on this with some community members (Joe is here
somewhere) and are hoping to roll something out in the next few weeks. Sorry
for not addressing the footnotes!

1\. exactly, we generate a digital signature similar to SQRL

2\. right. from a technical perspective, the barcode is simpler than a QR
code; however, it's actually proven really important from a usability
standpoint. by animating the interaction, we have more control of the user's
mental model of what's going on and can provide a much more intuitive user
experience.

~~~
Mithaldu
Thanks for the answers. I'll be looking forward to see it hit hackernews.† :)

I've mentioned it elsewhere here, but i'd suggest you also look into
[https://github.com/habnabit/passacre](https://github.com/habnabit/passacre) ,
since its creators put a LOT of value in getting the crypto parts right and
its main creator is very responsive online.

And thanks for answering the footnotes. It is an interesting thought that
users can be helped by the wiggling animation of the barcode and its inherent
suggestion. (That would be worth a trip report on how you got there.)

† I'd prefer to follow an rss feed, but your blog seems to be 90% marketing
and only 10% user-relevant posts with no categories.

~~~
jessepollak
We're working on the blog :D

I'll definitely make sure to look over passacre; it seems great.

And no problem on the footnotes, if you ever have any more questions don't
hesitate to email me at jesse at our domain name!

------
dsl
[http://attrition.org/errata/charlatan/steve_gibson/](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.

~~~
richardjs
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.

~~~
dsl
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.

~~~
diminoten
It's still an ad hominem - the merits of his argument should stand independent
to who he is or his history on _any_ topic.

Doesn't mean it's not worth talking about, though. After all, science is
entirely founded on a kind of inductive reasoning, so logical fallacies aren't
crazy to consider.

~~~
anateus
Note: [https://yourlogicalfallacyis.com/ad-
hominem](https://yourlogicalfallacyis.com/ad-hominem)

Gibson's personality isn't the thing in question here, the quotation above is
specifically about his history in security. If the comment was about how he's
a major asshole (just an example, I'm not saying that) in conferences or
something like that, it would be an ad hominem, as that sort of information
would not be relevant.

~~~
gcr
How is the quote about his history? It provides none of the following:

\- Examples of Gibson's previous ideas that have been proven fake

\- Examples of Gibson's previous projects that have security flaws

\- Examples of projects that Gibson is purported to "peddle" through his
"snake oil salesmanship"

\- A quotable, referrable, expert opinion of Gibson's standing, or lack
thereof, in the broader security community

The post includes none of those things. It is no better than saying "$NAME is
a bad person!"; it merely uses more words to say so.

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

~~~
anateus
OK, mild correction, the quote itself doesn't really contain those, but the
link from which it was taken does.

Attrition is itself the "expert opinion" of Gibson's standing, here's their
Wikipedia page for more information:
[http://en.wikipedia.org/wiki/Attrition.org](http://en.wikipedia.org/wiki/Attrition.org)

------
peterwwillis
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)

~~~
nly
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.

~~~
peterwwillis
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.

------
jimueller
Seems similar to the discontinued Google Sesame. [http://www.zdnet.com/open-
sesame-googles-no-password-log-in-...](http://www.zdnet.com/open-sesame-
googles-no-password-log-in-1339329832/)

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

Another similar system [http://corp.galois.com/blog/2011/1/5/quick-
authentication-us...](http://corp.galois.com/blog/2011/1/5/quick-
authentication-using-mobile-devices-and-qr-codes.html)

------
juhanima
Not exactly a new idea. Here is some prior art

[http://openaccess.uoc.edu/webapps/o2/bitstream/10609/14761/6...](http://openaccess.uoc.edu/webapps/o2/bitstream/10609/14761/6/dpintorTFM0612memoria.pdf)

[http://www.computer.org/csdl/proceedings/ares/2009/3564/00/3...](http://www.computer.org/csdl/proceedings/ares/2009/3564/00/3564a578-abs.html)

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

~~~
phpnode
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](https://news.ycombinator.com/item?id=5982741)
(hint - the ban is completely unjustified)

~~~
DanBC
Ahem.

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

~~~
phpnode
didn't see that, but even so, this is still a horrible punishment

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

~~~
teleclimber
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.

~~~
chj
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.

~~~
teleclimber
I don't think that is the case. After the auth app communicates with the
server you just need to click the login button on the original page. I don't
think the auth app needs to load a specific url.

------
Mithaldu
This is functionally the same thing as
[https://github.com/habnabit/passacre](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.

------
nly
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.

~~~
gcr
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.

~~~
nly
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?

~~~
gcr
That's a great point. I didn't think of that.

------
yogo
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.

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

~~~
veesahni
It's 1 step. Just scan a code.

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

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

~~~
imrehg
Meaning Internet access for your phone.

The example in the article being login at the library - the library computer
has Internet access, but your phone has to also connect to a wifi (if there is
one), or the mobile network (if you are 3G subscriber and there's reception).
Then factor in that you might go abroad, I don't know many places where they
just give free internet access to anyone with a smartphone...

------
veesahni
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.

------
derefr
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.

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

------
artjumble
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.

------
umsm
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?

------
asgentile
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?

~~~
richardjs
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](https://www.grc.com/sqrl/userview.htm)

------
mixologic
"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.

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

------
blibble
google did this last year: [http://www.zdnet.com/googles-open-sesame-login-
ditches-passw...](http://www.zdnet.com/googles-open-sesame-login-ditches-
passwords-3040094830/)

------
jbert
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.

------
DanBC
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.

------
nfoz
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
> 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.

------
ijansch
Have a look at [http://tiqr.org](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).

------
EugeneOZ
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.

------
lisper
Another replacement for usernames and passwords:

[http://dswi.net/](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.

------
dlucci
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?

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

------
rpledge
This is very similar to my project at [http://qrauth.com](http://qrauth.com)

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

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

------
Sami_Lehtinen
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.

~~~
maaku
> 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.

~~~
sigkill
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.

~~~
ryanthejuggler
I think, from a practical standpoint, if "never" means "never before the heat
death of the universe" then I'd be pretty satisfied. Pure math is truly
wonderful (I love theoretical stuff) but at some point it does have to shift
back to the practical realm.

~~~
sigkill
I agree with you. I was just informing the parent poster how differently
cryptographers see the world as compared to us normal people.

Although, in some respects, I do get where they're coming from. New algorithms
and computing paradigms develop that make the previous one broken. I'm just
guessing here, but it maybe possible that probabilistic computers and awesome
algorithms a few decades down the line are able to recover states of a CSPRNG
by applying statistical techniques. Obviously, I'm way over my head here but
this is a possibility.

If you say that the OP was talking about TRNGs then all bets are off. It could
so happen that two consecutive 512-bits are exactly the same. The probability
is extremely low (birthday low) but since it's a TRNG there's still a chance
that it will happen.

------
jaequery
i love the site's design

