SQRL and EMAIL – Why anonymity isn’t practical

I want to say that I appreciate Steve Gibson’s effort. We really need an easy way to create new accounts while protecting our privacy. I would love it if SQRL succeeded. Thinking about new ways to provide privacy and anonymity is is critical for an Internet Society.

After some of the responses to my previous post, I felt I should elaborate on my first post about SQRL and email – and why it’s a problem. If I see a problem, it is my duty to speak up and encourage further discussion. That’s how technology improves.

This post elaborates on the first issue I raised – about SQRL and email. I’m going to start by including some of the original words by Steve:

Steve Gibson says in SecurityNow #424

There may be places where we really need anonymity or just places where it’s not important that we be known, like making a posting to some random blog. I mean, I know that sometimes I’ll see someone’s blog posting, and I’ll note some errors that’ll stimulate me to want to reply. And so I start to reply, and suddenly it’s like, oh, you have to create an account. And it’s like, oh, my goodness. Then they want my email address, and I have to send them – then I’m going to get a link and have to verify myself, and they’re going to want this information. And I just say forget it. It’s not worth the overhead of having to essentially decloak myself for this, just to make a posting to someone’s blog.

(Emphasis is mine). I wanted to point out this passage because it helps describe the goal of SQRL.  And in SecurityNow #425, Leo asks

It is a way of using either QR codes or some other secret that’s shared, authenticating yourself to web pages without giving – anonymously, effectively, without giving the web page any other information about you – right? – and not using a third-party service.

And Steve responds with “Right”.

And to make this point clear – SQRL lets you create an account without using an email address (a third-party provider) . It also lets you log in a second time using the same process. There are several advantages to SQRL when used this way:

  • An email is not necessary
  • You identity is hidden and your privacy is protected
  • You don’t have to worry about thinking up a  unique username
  • You don’t have to worry about picking a bad password
  • You don’t have to worry about account collisions (people with the same account name)
  • It’s easy and almost seamless (just a click) to create the account.

I love the idea! But first – let’s examine the practicality of such a mechanism. Let’s assume for the moment that the protocol as described by Steve is perfect.But to be practical, it has to be useful for both the client (the end user) and the server (the owner of the web site). Any technology that solely focuses on just one side of this balancing act won’t succeed.

You see, my primary concern is not with the technology, but with the usability – especially from the perspective of the web site owner. Here’s one of the important questions a web-site owner must consider:

“How can I distinguish between a human and a spambot?”

The trouble is – SQRL by itself does not prove that you are a human. You can be a piece of software used by a spammer who wants to flood your web site with web spam. In the blink of an eye, comments on a web blog can be filled with advertizements for Viagra, weight loss products,  etc. How can a web site owner prevent this? This topic came up in SecurityNow #425:

Leo: [SQRL] doesn’t change any of the stuff that a website would normally do. It could, or it doesn’t have to. Just as Facebook Connect, same thing. I mean, this is all – yeah. This is not new stuff. Now, I do find the spam question interesting. Is it possible, it would be, wouldn’t it, to robotically generate these logins?

Steve: Yes. So it does, yes, [SQRL] does nothing to defeat spam or spammers. You could just invent keys and just come in as a billion different individual people.

Steve admits that spambots is a problem for SQRL. Steve does say that website owners can use an email loop as a verification, or a CAPTCHA, if they want to prevent spammers. Problem solved right? Not really.  CAPTCHA systems can be defeated. Check the  wikipedia entry on defeating CAPTCHA.   But even more importantly, CAPTCHA systems can be defeated by low paying “data entry specialists” in 3rd world countries, earning $50 a weak typing in responses to prove to the web sites the new accounts have a human associated with it: ( See this Data Processing Job for an example.) In other words, CAPTCHA technology doesn’t eliminate spammers.  Ask yourself how many web sites ask for an email address to verify that you are human. In my experience, 95% of the web sites ask for an email instal of a CAPTCHA. There’s a very good reason for this – the web site uses a third party’s capability to detect and  eliminate accounts attached to a spambot.

And Steve and Leo agree with this because they said

Leo: Well, it allows anonymity. But it’s not a requisite. I mean…

Steve: Correct, correct. So, for example, it’s a token that never changes that represents a user. A forum could require nothing but it, or they could still require an email address loop confirmation, or, more probable, a CAPTCHA. I mean, you might still require a CAPTCHA. Or you might use a CAPTCHA just once per ID, per SQRL ID. And as long as it’s not abused, as long as there are not too many incoming posts, then you would, like, not require a CAPTCHA every time. What this does is it provides a secure assertion of who you are to a website. What they choose to do with it is up to them.

Sowe are all in agreement.  No problem, right?

Well, yes there is. Go back to the beginning of this post. The unique advantage to SQRL is anonymity – the ability to create new accounts without using a third party. If you wanted a seamless solution, we already have solutions – Facebook connect, Google+, etc. But there goes your anonymity. That’s why SQRL is great – it provides anonymity. But once you attach an email to the account – you don’t have anonymity any longer.  You might as well use Facebook or Google+, because they are seamless while SQRL with an email verification is not.

To summarize,  the main advantage (IMHO) of SQRL to a web site user is anonymity, yet web site owners need anti-spam solutions that are prevent this.

I summarized this in a table below, which describes eight different ways to create a new account. The ideal solution would have three “Yes’s” – but as you can see, there is no perfect solution. I wish there was. But nothing exists at this time.

  Seamless No Third Party involvement Prevents spambots
Username/Password No Yes No
Username/Password/Email No No Yes
Username/Password/Captcha No Yes Some
Google+ Yes No Yes
Facebook Yes No Yes
SQRL Yes Yes No
SQRL/Captcha No Yes Some
SQRL/Email No No Yes
This entry was posted in Hacking, Security and tagged . Bookmark the permalink.

11 Responses to SQRL and EMAIL – Why anonymity isn’t practical

  1. Pingback: The problem with SQRL | The Grymoire

  2. Anon says:

    You can have anonymity if email is required to sign up. You just use something like a mailinator.com address. Like I used to post this. Granted this is not seamless but still allow anonymity for the user.

    • grymoire says:

      Yes. You are right. Or you can use multiple email addresses. Or use extra Facebook/Google accounts.
      [Updated comment follows]
      But you are still using a third party, and the anonymity now depends on which third party, and how you use it. If you use mailinator, and there is a way to associate that identity with you, then you have no anonymity. The same holds true for Facebook and perhaps Google+. You can create a fake identity on Facebook and use that instead of mailinator. And if you can keep your real identity hidden, they you have solved the problem. So maintaining your privacy depends on HOW you use the third party identity, and how the third party protects your ID. It is not guaranteed.

  3. Catbeller says:

    I have to disagree with your assertion that SQRL’s unique advantage is anonymity. It isn’t: anonymity may not be supported by web sites, for reasons you go into. SQRL is unique in that it doesn’t require a user id or password to confirm that you are uniquely you. It solves the password problem, the need to store hundreds of passwords *somewhere*, usually in a third party’s server, and that the password has to travel over a network or through hardware that may be compromised. The anonymity problem isn’t solved, not if a website doesn’t want anonymous users. And your origin point is locatable with or without SQRL; the design of the internet tends to defeat anonymity.

    • grymoire says:

      If you want to solve the password problem, use Facebook or Google+. There is no need to store them on a third party server. But, as I said, you give up anonymity.

      • Mactrent says:

        While Facebook, G+, and other OpenID and/or OAuth providers solve one password problem, they leave the password of logging into your service provider in the first place, unless you use multi-factor authentication. That aside, what I like about SQRL is that it gives you back control of your own identity and its “metadata”, such as when and where you log in. This is, of course, taking that data away from the likes of Facebook, and is a much smoother experience than running your own OpenID provider.

      • grymoire says:

        In my first post, I discussed TLS and mutual authentication. If the web server was modified to accept self-signed certificates, then TLS w/mutual authentication provides most of the advantages of SQRL, and it is even more seamless than SQRL because client authentication occurs just by clicking on the HTTPS URL. (SQRL requires the user to perform an extra step – clicking on the SQRL URL after visiting the HTTPS URL).

        And as you mentioned, it’s desirable that the server never knows the user’s password, and we already have the technology to do this with Mutual TLS authentication. But as described above, a single private key and self-signed certificate is used for all sites, and that’s a problem.

        SQRL provides two advantages over mutual TLS authentication. The first is that servers cannot collaborate and identify someone using a common public key. One could address this by generating a unique certificate for each web site visited. However, this becomes a problem as all of these certificates would have to be stored, archived, etc.

        That’s the second advantage SQRL has – it can generate “self-signed certificates” on the fly, without having to store a database of multiple certificates. This is what I like most about SQRL.
        Who knows? Perhaps the crypto part of SQRL could be incorporated into the TLS suite.

    • Hugo says:

      I would not formulate it as “it solves the password problem”: As I understand it it solves the “you need to provide credentials to continue” problem: You do not need to provide an email address (that probably is used on many sites as login ID), a public key is generated for you as login ID, and you don’t need to provide another (unique!) password, the private key associated with the public key can prove that the public key belongs to you.

      I imagine you could implement the same with client certificates: For registration send a CSR to the server (after receiving requirements for the CSR from the server) and you get back a certificate for client authentication. For login you use magic to utilise what you got in your certificate store.
      A SQRL client seems to me like a reimplementation of a private certificate store with some fancy password derived password generation for certificate key passwords.

  4. Thor says:

    If you need an email, you ask the user before you allow them in.
    And mind you, Email verification has very little effect to prevent spam bots, neither does Captcha, so that point is moot.

    • grymoire says:

      As I quoted from the podcast, Steve’s initial idea for SQRL was as an easy way to create a NEW account WITHOUT providing an email address.
      As for blocking spambots, email verification works. You may have another opinion, but I don’t see a lot of evidence to support that opinion.

  5. Pingback: The problem with SQRL | The Grymoire

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.