How should the /pag.sqrl endpoint work?

  • New Wordpress Plug-In Forum
    Guest:

    Just a note that we have a new forum to contain discussions relating to the Wordpress plug-in which Daniel Persson originated and has been making great progress on. You'll find it under "Server-Side Solutions."

    /Steve.

ScottWhite

Active member
Jul 7, 2019
25
11
I'm confused on how this endpoint is supposed to function securely in conjunction with the QR code. It appears that on the demo page, the browser starts querying that endpoint immediately using the same nut as is in the QR code. It seems like I'm supposed to "trust" that nut to return final authentication once the SQRL client has associated a identity with that nut.

The problem is that I think the original QR code nut is a little insecure since it would be easy to snoop (like from a webcam). What's to prevent an attacker from seeing the QR code and starting to query the pag.sqrl endpoint in a parallel race and getting authenticated instead of the real user?

FYI, I plan to use SQRL on a public kiosk-like device (not browser-based). I'd like users to be able to walk up and scan the QR code to get logged in to their account. So there's no physical security and I can't really make assumptions about network security (like the attacker could be on public WiFi in the same location) so an IP check doesn't help.

I feel like there needs to be a second secret returned to the client that isn't exposed visually that is associated with the nut and sent along with the nut to the server to make sure only the original requestor gets logged in. Or is there something else in the spec I'm missing?
 
  • Like
Reactions: Simon9

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
Hey Scott...
It appears that on the demo page, the browser starts querying that endpoint immediately using the same nut as is in the QR code.
Righto.
It seems like I'm supposed to "trust" that nut to return final authentication once the SQRL client has associated a identity with that nut.
Ah, that would be a good concern. However, the only thing the /pag.sqrl?nut={...} endpoint query does is instruct the browser's current sign-in page to reload itself. In the cross-device authentication mode, the user's authentication device (smartphone) will have established its owner's identity with the server. Once it does that the web server will validate the associated browser session ... and the browser's periodic query to pag.sqrl?nut={...} will then return a different value than it originally did, and the javascript performing the querying will reload the page to show that the user is logged-in. :)
 

ScottWhite

Active member
Jul 7, 2019
25
11
Hey Scott...

Righto.

Ah, that would be a good concern. However, the only thing the /pag.sqrl?nut={...} endpoint query does is instruct the browser's current sign-in page to reload itself. In the cross-device authentication mode, the user's authentication device (smartphone) will have established its owner's identity with the server. Once it does that the web server will validate the associated browser session ... and the browser's periodic query to pag.sqrl?nut={...} will then return a different value than it originally did, and the javascript performing the querying will reload the page to show that the user is logged-in. :)
Let me see if I understand correctly: The original nut gets associated with a session cookie on the page which is kept secret so that only the browser that got the nut gets successfully authenticated.

Here's what I tried on the sqrl demo page:
1. Load the page and get a valid QR code
2. Kill the pag.sqrl polling in the js (just to make my attack 100%)
3. curl /pag.sqrl with snooped nut: I get the expected 404
4. Authenticate with the SQRL client
5. curl /pag.sqrl with snooped nut: I get a 200 with a https://sqrl.grc.com/auth.test?<key>
6. curl https://sqrl.grc.com/auth.test?<key> I get a 302 (with no location)

Since there's no location, it appears that you thwarted my attempt to hijack the login , but I'm not clear on exactly how. Also I was able to deny the login to the original page which can be a denial of service attack. I feel that optimally I should get denied at step 3.

In the case of the multiple service scenario, the sqrl service only knows about the nut and the idk so that's all it can pass on the backend to the other web server. That means the web server has to have some preexisting association with the original requestor to the nut but I only see an association in the javascript code.

Can you confirm exactly how only the browser that requested the nut is allowed to login?
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
Let me see if I understand correctly: The original nut gets associated with a session cookie on the page which is kept secret so that only the browser that got the nut gets successfully authenticated.
That's true in cross-device mode. In that mode, another authenticator (smartphone) asserts the identity associated with the nut's QR code, and that nut is related back to the browser session that originally requested the nut, thus logging that user onto the initial browser session.

But in the same-device mode with CPS, the web server provides a token to the SQRL client, which it provides to the user's local web browser, which then provides it to the web server to logon the authenticated user.

Here's what I tried on the sqrl demo page:
1. Load the page and get a valid QR code
2. Kill the pag.sqrl polling in the js (just to make my attack 100%)
3. curl /pag.sqrl with snooped nut: I get the expected 404
4. Authenticate with the SQRL client
5. curl /pag.sqrl with snooped nut: I get a 200 with a https://sqrl.grc.com/auth.test?<key>
6. curl https://sqrl.grc.com/auth.test?<key> I get a 302 (with no location)

Since there's no location, it appears that you thwarted my attempt to hijack the login , but I'm not clear on exactly how. Also I was able to deny the login to the original page which can be a denial of service attack. I feel that optimally I should get denied at step 3.

In the case of the multiple service scenario, the sqrl service only knows about the nut and the idk so that's all it can pass on the backend to the other web server. That means the web server has to have some preexisting association with the original requestor to the nut but I only see an association in the javascript code.

Can you confirm exactly how only the browser that requested the nut is allowed to login?
Scott... This is complicated by the fact that there are two distinct modes of SQRL login.

In step #4 you wrote: "Authenticate with the SQRL client." I'm assuming that you used GRC's client for Windows? In that case, it would have been CPS mode (same-device) and the authentication URL would have been passed back to GRC's client for forwarding to the user's local browser. So the /pag.sqrl query, which is only valid in cross-device mode, would not return the logged-in redirection URL to the caller. :)
 

ScottWhite

Active member
Jul 7, 2019
25
11
That's true in cross-device mode. In that mode, another authenticator (smartphone) asserts the identity associated with the nut's QR code, and that nut is related back to the browser session that originally requested the nut, thus logging that user onto the initial browser session.

But in the same-device mode with CPS, the web server provides a token to the SQRL client, which it provides to the user's local web browser, which then provides it to the web server to logon the authenticated user.
How does the nut get related to browser session? do you save the cookie when sent to the nut.sqrl endpoint? or to the pag/png endpoints? is it somehow serverside?

In any of these cases, I think it's actually a bad idea to delegate tying the nut to the session token to the web server. Adding an extra session secret that isn't exposed in the sqrl url is a typical way of solving this issue. It creates a few benefits, first is that the spec is explicit about how the session and nut get tied together and handled securely. Second, it handles non-browser based situations like pure API login situations as are typical in mobile apps. Third, is that it's better encapsulation of the authentication process which will make integrations easier which means there's less things to screw up. I think the web server can even be completely stateless for operations like a single post to a forum like this (though I'm not far enough into the implementation to know for sure).

In my implementation, I tried adding a second nut with the parameter "pag" to the /nut.sqrl endpoint that is to be used as the "session" token. This parameter does not appear in any sqrl urls because the expectation is that only the original requestor will have access to it. Both the nut and pag parameters are required for the pag.sqrl endpoint to return a valid value and I can additionally reject requests that don't include the correct pag even though an attacker may have snooped the nut.

Scott... This is complicated by the fact that there are two distinct modes of SQRL login.

In step #4 you wrote: "Authenticate with the SQRL client." I'm assuming that you used GRC's client for Windows? In that case, it would have been CPS mode (same-device) and the authentication URL would have been passed back to GRC's client for forwarding to the user's local browser. So the /pag.sqrl query, which is only valid in cross-device mode, would not return the logged-in redirection URL to the caller. :)
Sorry, I should have been more specific. I am using the Android client and I have a mac so I haven't been able to get the Windows client to work. If I have some time today I'm going to try one of the VMs from microsoft. I also have the browser plugin but I'm mostly using the QR Code cross-device mode. I think the cps mode will be much less common because mobile platforms don't really have a "secure and private means" of IPC.
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
One of the nifty things about SQRL is that the spec is minimal and that leaves ample room for extension and accommodation to other uses and scenarios.

How does the nut get related to browser session? do you save the cookie when sent to the nut.sqrl endpoint? or to the pag/png endpoints? is it somehow serverside? In any of these cases, I think it's actually a bad idea to delegate tying the nut to the session token to the web server. Adding an extra session secret that isn't exposed in the sqrl url is a typical way of solving this issue.
Yes. That's what I'm doing. The SSP API, which stands outside of the web server, maintains its own browser session association which is separate from the web server's session. This is actually required, since the SQRL SSP API may be located at a different, through likely related domain -- sqrl.example.com -- for example.

The authentication is initiated by the browser's request for a nut through /nut.sqrl. That creates the pending auth object which captures a bunch of information. Here's the definition of my Pending_Auth object:

484

If I have some time today I'm going to try one of the VMs from microsoft.
Scott... You are absolutely welcome to have the Windows VM I already have prepared and running. If you can run a VMWare VM, you'll be good to go. That VM has the SSP API and test server (that's at /demo and /msa) a SQRL client and it's able to authenticate both inside and outside. I'll privately message the VM's link in case it would be useful to you. :)

I think the cps mode will be much less common because mobile platforms don't really have a "secure and private means" of IPC.
I believe you'll find that this is incorrect. RIGHT NOW, all SQRL clients support CPS and CPS is =vastly= more secure than cross-device authentication. All of these clients use the platform's built-in network stack which provides sufficiently secure and private IPC... and that's what we use. :)
 

Alan M Cameron

Well-known member
Feb 7, 2019
92
6
alancameron.net
One of the nifty things about SQRL is that the spec is minimal and that leaves ample room for extension and accommodation to other uses and scenarios.


Yes. That's what I'm doing. The SSP API, which stands outside of the web server, maintains its own browser session association which is separate from the web server's session. This is actually required, since the SQRL SSP API may be located at a different, through likely related domain -- sqrl.example.com -- for example.

The authentication is initiated by the browser's request for a nut through /nut.sqrl. That creates the pending auth object which captures a bunch of information. Here's the definition of my Pending_Auth object:



Scott... You are absolutely welcome to have the Windows VM I already have prepared and running. If you can run a VMWare VM, you'll be good to go. That VM has the SSP API and test server (that's at /demo and /msa) a SQRL client and it's able to authenticate both inside and outside. I'll privately message the VM's link in case it would be useful to you. :)


I believe you'll find that this is incorrect. RIGHT NOW, all SQRL clients support CPS and CPS is =vastly= more secure than cross-device authentication. All of these clients use the platform's built-in network stack which provides sufficiently secure and private IPC... and that's what we use. :)
Thanks for the early release of this data it will come in useful for my various PHP projects. Is there any chance of an early release of the server spec document you are working on (not to be published by me anywhere)?
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
Thanks for the early release of this data it will come in useful for my various PHP projects. Is there any chance of an early release of the server spec document you are working on (not to be published by me anywhere)?
Hi Alan. The documentation project has ended up breaking into three pieces. The "Explainer", the "Implementation" and the "Protocol." Each one takes a successively more detailed look at the details of how SQRL works, and each relies upon the preceding documents. I think that what you actually want is the third and final "Protocol" document which is mostly written on the web site but needs importing and checking.

However... the data structure that I posted and shared with Scott would never be part of any of this documentation since it's just a particular implementation of the SQRL specification. Paul Farrer has finished creating a direct duplication of my original SSP API in portable "C" -- and it will have that same data structure. So it could be used as a reference for an implementation of the SQRL specification.
 

ScottWhite

Active member
Jul 7, 2019
25
11
One of the nifty things about SQRL is that the spec is minimal and that leaves ample room for extension and accommodation to other uses and scenarios.

Yes. That's what I'm doing. The SSP API, which stands outside of the web server, maintains its own browser session association which is separate from the web server's session. This is actually required, since the SQRL SSP API may be located at a different, through likely related domain -- sqrl.example.com -- for example.
Flexibility is a good thing, but not if it makes it harder to get the security right.

It seems like mistakes managing the session can easily compromise the security of the system. Especially since the "session" for the SQRL service can have a more limited lifecycle that can/should end at authorization.

I also think it would be advantageous to not have the SQRL API service rely on cookies. Cookies tend to not be used in HTTP APIs because the cookie spec is complicated and requires a lot of extra state management. Managing cookies from programmatic HTTP clients can be a security risk if not done correctly since it requires manually implementing all the cookie caching and rules.

Using a response parameter makes the importance and usage more clear and I think will improve security overall by having a single well-defined way to securely tie the nut to the original requestor. It also adds more flexibility since the API will work well for both full browsers and simpler HTTP clients typical of mobile.
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
It wasn't my intention to tell you how you should implement your client session binding, Scott. I was simply explaining what I'm doing. You are, of course, encouraged to solve those problems in any way that makes you most comfortable. :)
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
Whoa!!! I totally forgot that I had previously abandoned all cookie usage by the SSP API. I no longer clearly recall the rationale, though I'm sure it's posted in the grc.sqrl newsgroup since I would have talking about it at the time. I was once using a cookie named "sqrlapi" but I just verified that I had abandoned that some time ago... clearly it wasn't needed. :)
 

ScottWhite

Active member
Jul 7, 2019
25
11
I'm not blocked on this issue, but I'm really curious how you tie the nut back to the original session if you're not using a cookie. In cross-device mode having the nut restricted seems very necessary to keep someone from snooping. Any secret that the browser knows but doesn't expose in the QR code should work.

Looking at Chrome dev tools, there does seem to be a cookie sent in the /pag.sqrl request called "demosession" that appears to contain a nut.

FYI, I've got a pretty feature-complete solution working:


I've tested all the basic functionality: query, ident, disable, enable, remove and pids support (at least a single pid) with the windows client. I've got a laundry list of questions about small implementation details, but I'll likely start a new thread for those once I get them organized.
 
  • Like
Reactions: Gristle