Secure (QR)
Proposing a comprehensive, easy-to-use, high security replacement for usernames,
passwords, reminders, one-time-code authenticators . . . and everything else.
At this time it is being published for comment only. Please DO NOT RELY
upon it until this notice has been removed. (Which should be soon!)
SQRL QR code/hyperlink URL format

SQRL URLs may be encoded into graphical QR codes to enable multifactor cross-device authentication, or embedded into standard HTML links to enable local, same-device SQRL authentication. To afford maximum server-side design freedom, the SQRL URL format has minimal requirements:



SQRL authentication query format

In the odd and somewhat contrived operation of the web, a web client may use a “GET” query to send a web server data by asking the server for a standard web resource, where the data it wishes to send is appended to the end of the resource's name. This is the so-called “query tail”. A web client can also use a “POST” query to send additional data which might be too lengthy to fit into a URL, might be binary data, or otherwise unsuitable for a URL's environment. Since the SQRL login link URL received from the web server is augmented with additional data, then signed, we use the POST verb's natural division of data where the SQRL arguments to be signed along with the web server's URL are appended to the URL, and the signature of the resulting compound URL is provided in the body of the POST submission.

The URL's parameters are standard HTTP form-urlencoded parameters where name=value pairs are separated by ‘&’ characters:


The use of standardized HTTP GET and POST query syntax allows existing web query parsing, interpretation tools and libraries to be used without modification.

How the SQRL query string is formed:

Starting with the SQRL link URL contained in an optically scanned QR code or in a standard HTML link:
SQRL Client Parameters
Web Server Behavior

Support for the SQRL protocol generally imposes minimal requirements and burdens upon web servers. When signature verification is performed by compiled code, many hundreds of thousands of verifications can be performed per second per core on any contemporary processor. The elliptic curve public key cryptography chosen for use with SQRL (Bernstein's Ed25519) has been optimized for high performance, and is far less burdensome than traditional RSA-style “products of primes” cryptography. Elliptic curve crypto is faster because it uses much shorter keys which, in turn, are as safe or safer than longer RSA keys because the discrete logarithm problem used by elliptic curve crypto is believed to be much more difficult to solve, for a given key length, than the RSA prime factorization problem. Thus, faster-to-use shorter ECC keys deliver the same strength as longer slower-to-use RSA keys.

Although SQRL's cryptosystem design is believed to be unassailable, various man-in-the-middle spoofing-style attacks are possible if simple precautions and checks are not performed by the web server. The guidelines below will assist the developer in implementing an SQRL system to deliver the strongest web server authentication available.

Preparing the SQRL link URL for stateful or stateless login

Before a web server displays a visitor login page containing an SQRL QR code and link, it may establish some pre-login state information which is retained for some length of time (until the login page ages and expires), or it might not establish any pre-login state until a user submits their login form data or uses the SQRL code to identify and authenticate themselves. SQRL is adaptable to either scheme.

As was mentioned briefly above, SQRL QR code and link data is inherently exposed on the web site's login page. To protect itself from login-state-guess attacks, and to guarantee that SQRL clients have unique SQRL links to sign, SQRL-login websites must provide a cryptographic-strength unpredictable and never-repeating “nut” to assure that every link is unique. Depending upon whether the server's logic is stateless or stateful, the nut's value may be derived from a one-way cryptographic hash function such as SHA-1, or from a two-way reversible cryptographic cipher such as AES.

A server that creates some pre-login state when the user asks for a login page and an accompanying SQRL link URL is generated might simply obtain some random noise from the local system, hash it through SHA-1 to destroy any structure it might have. This 160-bit token would then be stored in the server's pre-login state and perhaps added to a list or otherwise made indexable so that it can be located when the matching SQRL query arrives. Since SQRL web servers must compare the initial login request IP to the authenticating IP, when both connections are over SSL, the pre-login state must also save the login requesting IP. That 160-bit data would then be passed through a base64url function to convert the resulting 160-bits into URL-friendly ASCII. (Remember to remove any trailing (“=”) equal signs padding the end of the string.) This ASCII would then form the server's “nut” added to the SQRL link URL after the “?” in order to render a unique link.

A server that does NOT create pre-login state will likely wish to encrypt some necessary connection IP and sanity-checking parameters into the server's nut:

 32 bits: user's connection IP address if secured, if non-secured.
 32 bits: UNIX-time timestamp incrementing once per second.
 32 bits: up-counter incremented once for every SQRL link generated.
 32 bits: pseudo-random noise from system source.
128 bits - AES encryption block size
Suggested data that might be encrypted in the server's nut.

The parameters described above are intended to serve as suggestions and guidelines only. They are certainly not hard and fast rules. Anything a web application might need can be accommodated by altering or expanding upon the concepts above.

Once a 128-bit block of parameters have been assembled, a 128-bit block cipher, such as AES, can be used to reversibly encrypt the block to yield the SQRL link's directly related, but indecipherable, 128-bit nut. The AES key could be made static or it could be chosen at random after each server boot, but it should remain secret and internal to the web server. The 128-bit binary nut should then be converted to ASCII using the base64url encoder and the two trailing (“==”) equal signs should be removed before it is added to the SQRL link URL, and later appended before the returned nut is decoded back into binary by a base64url decoder.

Once the ASCIIized value for the link's nut is generated, the value for the optional path-extending “d” parameter, if any, should be determined, and a SQRL login link can be created. The link URL could be fed into a QR code generator to create a PNG or GIF (not JPG) format QR code image. That image should be wrapped in a standard HTML clickable <a href="url">qrcode.png</a> HREF tag so that smartphones can optically scan the QR code for cross-device authenticated login, while users of smartphones, tablets, laptops and desktops can tap or click on the image to perform the same function.

On-the-fly generation of QR codes
An alternative to feeding the URL into a QR code generator, then linking to the resulting image file, would be to embed the entire link URL into the name of the QR code PNG image and arrange to have the web server generate and return the QR code image on-the-fly, from memory, in direct response to the user's web browser request for the image:

<img src="/sqrlcode/{url-encoded sqrl link}.png" alt="Click to Login" />

This is the approach I have taken for the generation of all charts and graphs throughout GRC's website. Examples are the DNS Spoofability Test (click the link at the bottom of the page to run the test and view the charts) and the Web Browser Cookie Statistics page. At no time do any of those images reside on disk. They are created in memory, served from memory, then immediately discarded once sent. The same can be done with QR code images.

Handling the SQRL client's authentication query

</////  Still working on this part . . .  /////>

Secure QR Login (SQRL) Documentation:

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2023 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: Oct 13, 2013 at 14:07 (3,785.92 days ago)Viewed 1 times per day