github twitter linkedin email rss
SQRL
Oct 10, 2013
4 minutes read

Steve Gibson recently announced his idea on how to solve the web login problem, SQRL. The page describing it is a bit of a sprawl at the moment, but here is my summary:

  • One master key to be kept secret by the user of the system
  • Per-domain keypairs are derived from the master key and domain by applying a SHA256 HMAC, and using this as a seed for the modern ed25519 PK crypto
  • The server provides a login request including a nonce for login
  • The user who wants to login signs the login request with their per-domain public key.
  • The login proceeds when the user sends a public key and a signed nonce request to the login server. The public key is considered the user id.
  • Crucially, the login request from the user does not have to originate from the same place as the session is, and this can be managed by a QR code for handoff to a mobile device. This QR-code handoff is touted as the main feature, but is IMO just a convenience for the handoff.

I implemented the basics of this in a few lines of Python here

The spec has been in flux, so it is not necesssarily following the latest developments. The basic mechanism seems unlikely to change though.

The basics features of this is quite nice, primarily that it has a mechanism for client-side handoff. I am however missing a lot of features that are standard issue in modern authentication protocols.

Pros:

  • Logon handoff is well-defined but optional
  • PK-based TNO-style authentication. No secrets are stored on the server you log on to or at a third party
  • Modern cryptos are chosen

Cons:

  • No reliable mechanizm for authenticating the originating site. The handoff part of the protocol makes this difficult, but for same-client logins, standard SSL should work and should be enforced.
  • Centralization of all authentication to one key is built in to the protocol, and encouraged by Steve. If your master key is compromised, all your sites become compromised.
  • The birthday problem needs to be carefully considered since this is intended to be used globally. It is quite likely it will come into play if there is any sort of vulnerability. Even if good RNGs when making the master key is shown to make this quite unlikely, it would be better if the protocol made this impossible.
  • No mechanizm for upgrading crypto algorithms
  • No expiry for the master key. This has proven to be a great feature of SSL certs that keeps them getting secured and cleans out old and potentially compromised ones.

All of these points are adressable, but it would be better if they were considered from the get-go, they are well-known problems in existing crypto systems and should be the first to be adressed. I am also not very convinced that having one global master key is such a great idea. Here are my suggestions:

  • Use SSL to verify that the site hosting the nonce is using the same cert as the login server. Logons can still be allowed, but it should at least give a hint that something could be amiss
  • For the hand-off case, provide an alternative mechanism for verifying the SSL cert, maybe build a graphical representation of the SSL cert of the site, or ask the user to look at the SSL cert fingerprint?
  • Encourage rather than discourage the use of multiple master keys, maybe one per device so that it is possible to just revoke them at the server side (or even better, globally)
  • Implement pluggable crypto algorithm support
  • Implement expiration dates on the master key to make sure they are renewed

SQRL is a good start of an idea, but as it stands now it requires some serious work to get it up to the level required for a good logon standard. I’m looking forward to see this thing evolve or metastasize so we can have a TNO, non-third-party secure logon system for everyone!


Back to posts


comments powered by Disqus