SQRL database entries?

[knarvik97]

While I'm propably going to wait until the SQRL documentation is updated before I try to implement SQRL into my website's login and registration system, I'm working on redesigning my database and would like to prepare it for SQRL. I have several subdomains which authenticate against a set subdomain, and set a cookie for the main domain and all subdomains. From what I understant, SQRL won't have any problems with the sites sharing the account as long as they all authenticate against the same (sub)domain on their login pages.
Each user would need their public key stored, which according to the documentation is 256-bit, base64url encoded string without padding. Would that be a CHAR(42), since the last "=" is omitted?
Is there anything else which needs to, or should be, stored for the implementation of the SQRL protocol on the server-side?

 

[Steve]

The #1 recommendation I have is that you use the SSP (SQRL Service Provider) API for anything you do:

https://www.grc.com/sqrl/sspapi.htm

This is the API that Rasmus and using for his XenForo add-on and it's the API I have used for the https://sqrl.grc.com/demo and https://sqrl.grc.com/msa demonstration pages. Paul F is working to translate / reimplement my assembly language code into 'C', and my code could be used under 32-bit Apache for Windows. It is my intention and hope that any eventual PHP and Java server-side libraries will also implement the SSP API.

If you do that, all you need in your database is space for a 12-character SQRL user identifier... and the API handles all the rest. If your site is going to honor the additional features such as requests by SQRL users for SQRL-only authentication and disabling all SQRL and non-SQRL account recovery, then you would also need to retain some flags for those.

But DEFINITELY checkout the SSP API. It should become the standard means for SQRL server-side support since it is feature complete, libraries will exist, and I will be pushing for that every chance I get.

 

[knarvik97]

The #1 recommendation I have is that you use the SSP (SQRL Service Provider) API for anything you do:

It seems using the API is a lot easier to set up, once an implementation supporting my server gets released.
Should I just prepare to use the API (write necessary javascript and php), and push the necessary website code once a pre-packaged version of the API is available for my system? I'm running my sites on Apache for Raspbian, so I can't use the version currently released.

 

[Steve]

Yes. The API abstracts away ALL of the SQRL details:

A visitor goes to your site's logon page...

1. To display the page, your server's logon page asks the SSP API for a nut using /nut.sqrl.
   

   > The SSP API returns a fresh nut.

2. The logon page embeds the nut in a /png.sqrl?nut={nut} image to display the QR code.
   

   > The SSP API returns a QR code image.

3. The user authenticates with their SQRL client.
4. The user's browser is redirected to your server with a URL carrying a CPS authentication nonce it received from their client.
5. You query the SSP API with /cps.sqrl? providing the nonce.
   

   > The SSP API replies with a 12-character token representing the user who is authenticating.

That's all there is to it...

• Some JavaScript querying the API to setup the logon page.
• You receive a redirect from the user's browser, take the CPS nonce from it, query the API and receive a unique ID for the user.

 

[knarvik97]

@Steve So these are all the SQRL-specific fields needed, for full functionality, since the API takes care of the rest?



So, tell me if I understand the SQRL registration process correctly:

1. A user authenticates, and sends the server a 24 character authentication token
2. The web server sends this token to the SSPAPI to receive a 12 character unique user identifier (the 12 character unique identifier is created if the user has not authenticated before)
3. The web server then sends the 12 character identifier to /add.sqrl together with an existing, or just created, arbitrary identifier used by the website to identify a user (it also adds the 12 character identifier to its own database). The arbitrary identifier will be returned next time /cps.sqrl is called with the same 24 character authentication token, so the server can log in the correct user.

And more or less the same thing happens when a user adds sqrl to their account.

If the API returns the web server account id for a registered account (when calling /cps.sqrl), and that identifier can be used for all API calls, in which cases does one use the SQRL identifier from the webserver's database? It seems it's never explicitly required since the web server account id can be used instead.

If one does not plan to use MSA, can the username handle be omitted at all times? I let a user change their name at any time, and one account only has one username, so it doesn't seem like my accounts are compatible with MSA or the way the SSP API sees usernames. Or is the username used by MSA different from a user displayname?

 

[PHolder]

these are all the SQRL-specific fields needed

No, I don't think so.

I'm unfamiliar with the details of his Server Side API... so I don't know it comes along with it's own database or not. If it does not, then someone needs to store the server unlock key (SUK) and the previous identity might be good to store also, for safety, though not strictly useful if no failures occur.

 

[knarvik97]

No, I don't think so.

I'm unfamiliar with the details of his Server Side API... so I don't know it comes along with it's own database or not. If it does not, then someone needs to store the server unlock key (SUK) and the previous identity might be good to store also, for safety, though not strictly useful if no failures occur.

SSPAPI Documentation:
"The API also maintains a database that can be used to associate SQRL users to the web server's accounts. When this is done, a SQRL authentication of any previously associated user will return the web server's account directly, eliminating the need for a web server's database to be altered to accommodate SQRL authentication."
Also:

If you do that, all you need in your database is space for a 12-character SQRL user identifier... and the API handles all the rest. If your site is going to honor the additional features such as requests by SQRL users for SQRL-only authentication and disabling all SQRL and non-SQRL account recovery, then you would also need to retain some flags for those.

 

[PHolder]

Yeah, no. I'm not having TWO databases to run one service. GL trying to figure your one source of truth, and I don't know if Steve's code comes with any means (i.e. user interface) to maintain the database.

 

[shanedk]

Yeah, no. I'm not having TWO databases to run one service.

Then, to put it bluntly, and with all respect due you as a regular and valid contributor, you're an idiot. (Hey, we all are, from time to time.) Designers of secure systems learned a long time ago to separate out your authentication database (username, password, etc.) from the user account database (birthday, SSN, etc.). It's the most secure way of doing things. Even without the API, you'd still want a separate database for the SQRL keys etc. I don't know of any expert that would recommend doing it all in a single database.

I would be INCREDIBLY surprised if this forum ran in a single database even without the SQRL extension. I run an SMF forum, and it actually created 51 different ones!

 

[PHolder]

created 51 different ones

I assume you are confusing tables in a database with databases? I have no problem with as many tables as necessary... but I'm not storing them in different database engines.

 

[shanedk]

Then we're talking about two different things again. I don't see any requirement that the SQRL server piece be in a separate engine, and I don't see anyone here saying it must be. (Although it could be, if someone decided they wanted to do it that way for some reason.) But it does need to be its own table. Whether that table is in the same or a different database would appear not to affect the function either way.

 

[Dave]

Whether that table is in the same or a different database would appear not to affect the function either way.

Other than, of course, the need for XA / two-phase commit to ensure transactionality across multiple coordinated databases.

 

[PHolder]

And backup restore... who wants to worry whether they might be able to restore a consistent view of two different datasets when the backups cannot be made at the same time.

 

[Steve]

@Steve So these are all the SQRL-specific fields needed, for full functionality, since the API takes care of the rest?

Yes, exactly. The SSP API creates a clean abstraction of SQRL protocol and interaction with SQRL clients.

So, tell me if I understand the SQRL registration process correctly:

1. A user authenticates, and sends the server a 24 character authentication token
2. The web server sends this token to the SSPAPI to receive a 12 character unique user identifier (the 12 character unique identifier is created if the user has not authenticated before)
3. The web server then sends the 12 character identifier to /add.sqrl together with an existing, or just created, arbitrary identifier used by the website to identify a user (it also adds the 12 character identifier to its own database). The arbitrary identifier will be returned next time /cps.sqrl is called with the same 24 character authentication token, so the server can log in the correct user.

And more or less the same thing happens when a user adds sqrl to their account.

Yes. You have that right. But I can offer a bit of clarification.

For his XenForo/SQRL add-on, Rasmus chose to use the 12-character SQRL user ID returned by the SSP API directly, since the existing XenForo system already contained provisions for 3rd-party identification through its "Connected Accounts" provision.

However, in order to accommodate use by a website that may not have such provision, the SSP API also allows the website to provide whatever sort of account identifier it already uses, which the API will store and return to subsequently identity the website's account whenever the user authenticates.

So, in your point #3 above, while you could do both -- store the 12-char SQRL user ID provided by the API, and also provide the API the website's user account identifier for it to store -- you would normally choose one or the other depending upon the features available for your web server. The API is fully flexible in its abstraction and allows either or both.

If the API returns the web server account id for a registered account (when calling /cps.sqrl), and that identifier can be used for all API calls, in which cases does one use the SQRL identifier from the webserver's database? It seems it's never explicitly required since the web server account id can be used instead.

Exactly right.

If one does not plan to use MSA, can the username handle be omitted at all times? I let a user change their name at any time, and one account only has one username, so it doesn't seem like my accounts are compatible with MSA or the way the SSP API sees usernames. Or is the username used by MSA different from a user displayname?

Right again. The API off-loads all of the responsibility it can from the web server. Since it's necessary to somehow identify users for shared access, it provides that mechanism, too. But the user names are only there for MSA management and, again, only if the webserver wishes not to provide its own naming.