SQRLSQRL
100x100 SQRL Logo   Secure Quick Reliable Login
A highly secure, comprehensive, easy-to-use replacement
for usernames, passwords, reminders, one-time-code
authenticators . . . and everything else.
divider
THIS PRELIMINARY SPECIFICATION IS SUBJECT TO
CHANGE AT ANY TIME (AND IT HAS BEEN!!)
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!)
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 employed 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.

A few SQRL server-side implementation thoughts

Mitigating “phishing” man-in-the-middle (MITM) attacks:
Although the SQRL identity authentication login system does not promote itself as an anti-phishing solution, observers have hoped that, in addition to everything else it does, it might also be able to provide some relief from this classic Internet problem. As it turns out, the SQRL authentication architecture does present a significant opportunity for thwarting phishing attacks when SQRL is used in its “same-machine” login mode. Please see the Anti-phishing countermeasures page for a full examination of SQRL's anti-phishing countermeasure capabilities.

The value of SSL/TLS encrypted & authenticated SQRL link URLs:
Imagine for a moment the scenario of a SQRL-equipped web server that always posts exactly the same SQRL code to every login page. It just shows the one code over and over to every visitor who logs in. Although individual users would be uniquely identified as themselves, the same SQRL link URL would always generate the same SQRL ID query to identify its user. Therefore, if a malicious third-party were ever to obtain one of those queries, they could readily impersonate the compromised user at any time in the future simply by replaying the previously obtained query. That's not good.

This method of compromise is well known as a “replay attack” and it is something that cryptographic protocol designers are always careful to consider and guard against. The SQRL system actively prevents replay attack exploitation by (a) keeping bad guys from snooping and (b) never using the same SQRL link URL twice.

The SQRL protocol strongly recommends that all SQRL client login queries be performed over SSL connections which offer both privacy through strong encryption, and authentication of the destination web server. As with standard SSL login using a username and password, SSL provides very strong protection against an eavesdropper obtaining a SQRL login query. However, SQRL stops short of making SSL a hard requirement so that websites having lower security requirements, and lacking the ability to receive SSL connections, may still utilize SQRL login. (Note that such sites don't provide their visitors any login security and protection even without SQRL.)

Unpredictability of the server's “nut”:
In addition to preventing eavesdropping on the user's SQRL login query, the web server can render eavesdropping replay attacks less effective by generating unique SQRL link URLs that never repeat. These will, in turn, generate unique SQRL client login queries that also never repeat. And not only should SQRL link URL's by non-repeating, they should also be highly unpredictable to prevent a highly sophisticated attacker from guessing (or calculating) any future value of the link. (Even though it's not completely clear what such a hypothetical attacker would do with that knowledge. It's comforting to know they can't determine what it would be.)

The sample strategies provided below achieve these goals easily, cleanly, and securely:

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, 0.0.0.0 if non-secured.
 32 bits: UNIX-time timestamp incrementing once per second.
 32 bits: up-counter incremented once for every SQRL link generated.
 31 bits: pseudo-random noise from system source.
   1  bit: flag bit to indicate source: QRcode or URL click
----------
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 (Rijndael), 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. (Note that this same secret key can be used to salt the IPv6-to-IPv4 converter hash function.) The 128-bit binary nut should then be converted to ASCII using a base64url encoder, and the two trailing (“==”) equal signs should be removed before it is added to the SQRL link URL. Those two trailing (“==”) equal signs should be 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 need for the optional path-extending “|” vertical bar character 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

Revocation:
It is expected that all SQRL-supporting websites would continue to offer traditional out-of-band (probably eMail, perhaps telephone) fallback mechanisms for account maintenance and management. And just as traditional password recovery systems operate using eMail-loop fallback, a similar means would be provided to allow users who had completely lost their SQRL IDs to revoke and replace the old with the new. Even so, the small increment in complexity required to allow SQRL users to replace their own identities, at will, made sense.

</////  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) 2016 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: Aug 02, 2015 at 14:17 (812.30 days ago)Viewed 9 times per day