Extra parameters in sqrl:// link


Status
Not open for further replies.

JJasonClark

Well-known member
Jul 1, 2019
56
11
github.com
Are extra parameters supported in the SQRL protocol link? For example…

Code:
sqrl://sqrl.example.com/stuff?x=5&nut=abc123&state=private
I know x and nut are supported, but what about state? Is there any parameter supported for extra data if its not named state?
 

jurgenhaas

Active member
Jun 8, 2018
42
10
www.lakedrops.com
The http protocol does allow any number of query arguments in an URL, there may be a URL max length constraint though. AFAIK that constraint is not strictly imposed by browsers.

With regard to SQRL clients I would imagine that they look into the relevant query arguments for them and they should just ignore any others.
 

Paul F

Well-known member
Apr 11, 2019
97
29
Toronto
Are extra parameters supported in the SQRL protocol link? For example…

Code:
sqrl://sqrl.example.com/stuff?x=5&nut=abc123&state=private
I know x and nut are supported, but what about state? Is there any parameter supported for extra data if its not named state?
An earlier version of the SQRL Spec ( https://www.grc.com/sqrl/protocol.htm ) states the following:
  • Any OTHER server data: Due to the fact that login session-state information is being placed onto a web page where it is then taken up by an SQRL authenticator, the value of any other token the web server might use for session identification must also be completely unpredictable or encrypted. If, for example, a simple session number counter were used, an attacker might examine the SQRL link, predict a future session ID, then trick the user into signing a modified SQRL link for the attacker to use in impersonating the user. Any session tokens should therefore be generated by a cryptographically strong cipher under a secret key or a strong secretly salted hash function.

    SQRL clients return and sign the entire unmodified SQRL link URL, exactly as it was received. So websites are free to include any additional information they choose so long as they remain mindful of possible attack implications.
 

shanedk

Well-known member
May 20, 2018
421
113
What PaulF said about the link still applies: SQRL clients must sign and return the entire unmodified link. It's also in the spec that any name=value pairs the client or server doesn't recognize are ignored; this allows for the creation of "extensions" which are beyond the standard spec. I would imagine these would apply to any variables in the URL that aren't part of the spec as well.
 

JJasonClark

Well-known member
Jul 1, 2019
56
11
github.com
SQRL clients return and sign the entire unmodified SQRL link URL, exactly as it was received
I was really hoping this was the case. I've been thinking about the IOT uses for the SQRL protocol. Most of the things I can come up with would be easier with at least 1 other generic parameter to be included in the initial request to the SQRL server.

For example: Imaging a vending machine with no way to accept money. All it has is QR codes shown for each product. Scanning the product with your SQRL client takes you to a pay + confirm page for that product. Once completed the item comes out of the vending machine.

This kind of thing would be easier to create if the SQRL link could include the information about where the vending machine is and which product was selected. Example:

Code:
sqrl://sqrl.example.com/stuff?x=5&nut=abc123&vendor=123&upc=abc
The only other way I could think of to include more contextual information in a SQRL login is to have the server side do something different based on a known nut value. For the example above, maybe the nut value abc123 means the customer wants to buy chips from vending machine 1. The initial SQRL message to the server would be rejected with a 0x20 (transient nut error) but could record that this chain of nuts is for the customer to buy the request product. The next SQRL message would use the new valid nut given in the response to continue the normal login.

There are many other examples too. How about a for pay parking lot that uses SQRL QR codes with the parking space in the code?

Code:
sqrl://parking.lot.com/location2?x=9&nut=abc123&space=4
 

shanedk

Well-known member
May 20, 2018
421
113
For example: Imaging a vending machine with no way to accept money. All it has is QR codes shown for each product. Scanning the product with your SQRL client takes you to a pay + confirm page for that product. Once completed the item comes out of the vending machine.
SQRL's ASK facility is perfect for this. "Are you sure you want to buy a Diet Pepsi for $1.50?"

This kind of thing would be easier to create if the SQRL link could include the information about where the vending machine is and which product was selected.
Theoretically, it should know it from the nut, but yes, the ability to put extra stuff in the URL could be beneficial. You're not connecting to the vending machine, you're connecting to a website which is in control of the machine, so all sorts of other info might be needed.

Of course, another alternative would be to encode it into the nut, which would make the nut longer, but you're making the URL longer anyway. Something like:

Code:
nut = base64url_encode(random(8)+machineID+upc, padding=False)
The developer would be free to choose whichever way works best. The advantage of the separate URL variables that I can think of right now is that it makes it easier if the nut needs to be refreshed.

The only other way I could think of to include more contextual information in a SQRL login is to have the server side do something different based on a known nut value. For the example above, maybe the nut value abc123 means the customer wants to buy chips from vending machine 1. The initial SQRL message to the server would be rejected with a 0x20 (transient nut error) but could record that this chain of nuts is for the customer to buy the request product. The next SQRL message would use the new valid nut given in the response to continue the normal login.
I don't like this. It's like you're deliberately giving out invalid nuts. They're made unique and unpredictable for very good reasons.

There are many other examples too. How about a for pay parking lot that uses SQRL QR codes with the parking space in the code?

Code:
sqrl://parking.lot.com/location2?x=9&nut=abc123&space=4
Or maybe even:

Code:
sqrl://parking.lot.com/location2?x=9&nut=abc123&space=4&timein=20200113T13:15EST
The SQRL client having signed that will verify the time that you parked so they can charge by the quarter hour or whatever.
 
  • Like
Reactions: JJasonClark

PHolder

Well-known member
May 19, 2018
1,228
205
SQRL's ASK facility is perfect for this. "Are you sure you want to buy a Diet Pepsi for $1.50?"
How are we going to know that hacker FooBar hasn't overlaid his own SQRL barcodes on the machine? If it's not a machine you use often, you may not know it's supposed to be VendCo and not VendCom.
 

Dror Harari

Active member
Aug 10, 2019
26
6
A nut is a cryptographic nonce. Trying to put a structure on it is a very bad idea. Using of other parameters make sense and is the way to go.

Anyhow, it is a very nice idea and one that could catch on as a vending device standard.
 

Dror Harari

Active member
Aug 10, 2019
26
6
@PHolder I was thinking that it was a dynamically generated SQRL once you chose the item to buy - you capture it with the phone and pay. Then the ASK would be appropriate.
 

PHolder

Well-known member
May 19, 2018
1,228
205
@Dror Harari But if you've got a bad QR Code you will be doing business with a bad company (a man in the middle.) The security of SQRL RELIES on the user to validate that the prompt for an authentication to be allowed matches with the URL of the site. If this case, you would be expecting a customer to know the correct URL for a random vending machine.
 

shanedk

Well-known member
May 20, 2018
421
113
If the hacker has compromised the vending machine, you're screwed no matter what.
 

PHolder

Well-known member
May 19, 2018
1,228
205
Wut? They don't have to compromise the vending machine. All the have to do is replace the QR Code with an attack one. (In order for QR Codes to work, it's going to have to be either very larger or very near the front of the machine (such as stuck to the inside of the glass.) An attacker would just stick their replacements to the outside of the glass and assume that most people wouldn't know the difference and be duped.
 

shanedk

Well-known member
May 20, 2018
421
113
Wut? They don't have to compromise the vending machine. All the have to do is replace the QR Code with an attack one.
The vending machine in this scenario displays the QR code. So how are they going to replace it without compromising the vending machine?

(In order for QR Codes to work, it's going to have to be either very larger or very near the front of the machine (such as stuck to the inside of the glass.) An attacker would just stick their replacements to the outside of the glass and assume that most people wouldn't know the difference and be duped.
It would need to be displayed on an LCD screen. Otherwise, how are you going to get a valid nut?
 

PHolder

Well-known member
May 19, 2018
1,228
205
Otherwise, how are you going to get a valid nut?
You're not? The intention, as I understood it, was to use stale nuts:
All it has is QR codes shown for each product.
The initial SQRL message to the server would be rejected with a 0x20 (transient nut error) but could record that this chain of nuts is for the customer to buy the request product. The next SQRL message would use the new valid nut given in the response to continue the normal login.
Perhaps I've misunderstood, but I read it as multiple QR Codes, one for each product. The idea was to simplify the vending machine to remove product selection buttons or even a display, because now you have a cell phone involved to be the display.
 

shanedk

Well-known member
May 20, 2018
421
113
But as I pointed out, deliberately giving out invalid nuts is A Very Bad Idea. The reason why you'd have multiple QR codes for each product is so you'd get the extra variable names in there, but they wouldn't have to be placed on the product. You could select the product as normal (press "B" "2" or whatever), and it would display a QR code with a fresh nut with the product info in separate URL variables.

SQRL wasn't designed to use printout QR codes. If we wanted to do that, we'd have to design an extension that would allow them to be done securely since they would, indeed, be using stale nuts (and, as you pointed out, someone else could come along and stick their own QR over the top).
 

JJasonClark

Well-known member
Jul 1, 2019
56
11
github.com
I think Steve said that would be fine.
Yep. As far as I can tell there are no new security issues. A stale nut returns 0x20 and a used nut returns 0x20. Both still create a new return nut value that includes the hmac of the previous (stale/used nut) request. Also Steve's client properly handles this case and is still able to identify.
 

JJasonClark

Well-known member
Jul 1, 2019
56
11
github.com
Perhaps I've misunderstood, but I read it as multiple QR Codes, one for each product. The idea was to simplify the vending machine to remove product selection buttons or even a display, because now you have a cell phone involved to be the display.
Yes, this is what I was thinking of. And I would assume that you would want to use a known vending machine company. I admit I don't know much about vending machines outside my own area. The ones around here are mostly from the same companies. Good security practices are still needed. People can make the bad choice to use a super sketchy vending machine. Or not check that the QR code is on the outside of the glass.

I would liken this to be the same thing as using an unknown ATM machine. Or not checking before you put in your card in that the card reader hasn't been replaced with a card scam scanner.
 

ramriot

Well-known member
May 24, 2018
133
15
Yes, this is what I was thinking of. And I would assume that you would want to use a known vending machine company. I admit I don't know much about vending machines outside my own area. The ones around here are mostly from the same companies. Good security practices are still needed. People can make the bad choice to use a super sketchy vending machine. Or not check that the QR code is on the outside of the glass.

I would liken this to be the same thing as using an unknown ATM machine. Or not checking before you put in your card in that the card reader hasn't been replaced with a card scam scanner.
A couple of observations that came out of our previous deliberations on using SQRL for home security may be of use here:-

If we use static printed QR-Code stickers to authenticate ourselves to an access point then it becomes possible for an attacker to overlay the intended valid sticker with one removed or duplicated from another place. The result of this for access control could be you scanning at one door of a building & having another door or the same or different building ( to which you have access rights ) pop open. The mitigation of this was to use an ASK returned to the first loop QUERY that enumerates the intended action. This of course requires the user to be observant.

For the above Vending Machine use case it becomes potentially worse because unless the returned ASK parameter identifies the specific machine as well as the product being purchased AND the user is cognizant of all of this then the attacker can jackpot any selected vending machine by spreading duplicate stickers around town on similar machines. Plus if they are smart they will only replace one or two stickers on any given machine so users may put it down to machine failure instead of deliberate theft.

Mitigations to the above use cases can include placing stickers in places an attacker is unable or unlikely to be able to place them (inside a secured zone visible through glass), but again that requires a level of user security training that we perhaps should not credit.

In all cases I am thinking that having a QR-Code generated dynamically & displayed within its validity period is a far better solution.
 
Status
Not open for further replies.