Android v0.9.0


Status
Not open for further replies.

kalaspuffar

Well-known member
May 19, 2018
296
106
Sweden
coderinsights.com
Hi again.

Now my vacation starts and I wanted to get a new version out as soon as possible now that many things have improved.

Special thanks to everyone who gives suggestions, critics and helps me test. Your work is really valuable to me.

Thanks for your time.

Changelog:
-------------------------------------------------------------------

Features
* Text import can be done as a new user
* New identity available in advanced options
* Use the new error dialog for all errors.

Bugfixes
* Handle enlarged text better
* More robust QRCode read
* Error when an incorrect path is encoded in QRCode

Improvements
* Change to use activities for most functions.
 

shanedk

Well-known member
May 20, 2018
421
113
When I go to log in to Steve's demo site using the QR code, it logs in fine, but the phone hangs on "Decrypting Identity - Time Left: 00:00:00". It does the same thing with the QuickPass, too.

It works fine when I tap the link locally on the phone.
 

kalaspuffar

Well-known member
May 19, 2018
296
106
Sweden
coderinsights.com
When I go to log in to Steve's demo site using the QR code, it logs in fine, but the phone hangs on "Decrypting Identity - Time Left: 00:00:00". It does the same thing with the QuickPass, too.

It works fine when I tap the link locally on the phone.
Hi Shane.

Thanks for the report. I can't reproduce the problem on my Nexus 6P or Galaxy 3S which are my test phones.

Anything specific you do to get this problem.
Seems that the progress popup is not hidden when done in some edge case.

Best regards
Daniel
 

kalaspuffar

Well-known member
May 19, 2018
296
106
Sweden
coderinsights.com
I also can't get the bad link errors to show up. I created QR codes for:

sqrl://www.grc.com/sqrl?nut=ThisIsABadNut

and

sqrl://www.grc.com/ThisIsAVeryBadLink

And I don't get an error code for either of them. By all appearances, it works (although of course there's no browser session logged in).
Hi Shane.

I'm not looking at the composition of the link and error out on them if they are sqrl:// links. It's just if you scan another URL, for instance, a commercial link for some brand or something or a QRcode without any data at all.

If it contains a correctly formatted link that uses the right protocol I will allow it. You can't log in but that edge case I think is a bit more uncommon.

I could change it if you feel that the links above are wrong, then what is considered a correct link? A nut could be just any string, the server decides what it wants to put into it if I understood the specification correctly. Might be wrong there though.

Best regards
Daniel
 

shanedk

Well-known member
May 20, 2018
421
113
If it contains a correctly formatted link that uses the right protocol I will allow it. You can't log in but that edge case I think is a bit more uncommon.
SQRL is supposed to alert the user when they click on an invalid link, or a valid link with a bad nut. This is a security issue as it could be used to hijack a session.

If you click a QR code, but unbeknownst to you someone is shoulder-surfing and logs in to your screen before you do, then the SQRL client needs to let you know that it failed. The way you have it, it would appear to work, and the user would be unwittingly using a website while logged in as the attacker. Stale or invalid nuts, or other bad links, need to fail visibly.
 

kalaspuffar

Well-known member
May 19, 2018
296
106
Sweden
coderinsights.com
SQRL is supposed to alert the user when they click on an invalid link, or a valid link with a bad nut. This is a security issue as it could be used to hijack a session.

If you click a QR code, but unbeknownst to you someone is shoulder-surfing and logs in to your screen before you do, then the SQRL client needs to let you know that it failed. The way you have it, it would appear to work, and the user would be unwittingly using a website while logged in as the attacker. Stale or invalid nuts, or other bad links, need to fail visibly.
Ha, interesting.

Never even considered validating the nut. I thought it was a random blob. Need to investigate this further.

What I've read earlier it was important to display the site to the user so that the user knew where they were login into a server would then inform the user if the nut was stale or invalid depending on the servers information. Never thought that was a responsibility of the client.

Best regards
Daniel
 

AlanD

Well-known member
May 20, 2018
128
23
Rutland, UK
My understanding is that the server should validate the nut, but if it is not valid for any reason, the client should visibly inform the user. The client cannot validate the contents of a new nut, because it does not know how that server composes a nut. All it can do is check that the nut is consistent between request and reply.
BICBW, others will have a better understanding of this level of detail.
 

shanedk

Well-known member
May 20, 2018
421
113
In such a situation, the server is supposed to respond with the 0x40: Command Failed TIF set. If no way of continuing is given (such as the server issuing a fresh nut), then the client should inform the user that the login failed.
 

Dave

Well-known member
May 19, 2018
487
99
Gardner, MA
Hi again.

Now my vacation starts and I wanted to get a new version out as soon as possible now that many things have improved.
There still seems to be a minor issue with text sizing. After scanning a QR Code, the text version is displayed truncated at the bottom::

1531953686920.png

Also, there seems to be some confusion regarding terminology. On this screen:
1531953905078.png
You ask for the "rescue text" and seem to be expecting text as shown in the image above, based on the statement that each row will be verified separately.

I don't think of that as "rescue text". That is the text version of the QR Code and it IS the identity.
Granted, the prose on the page does say "As an additional recovery measure", but it is still just the same information presented in a different way.

This is a "rescue code" (from a test identity):
1531954395388.png

I fear that "Rescue text" and "Rescue Code" are too close.

Dave

P.S. Enjoy your vacation!!!
 
Last edited:

PHolder

Well-known member
May 19, 2018
1,227
205
Never even considered validating the nut. I thought it was a random blob. Need to investigate this further.
My humble opinion:

@Steve or the eventual spec needs to define what chars are allowed in the nut. (Are Emoji allowed, I assume not, but someone needs to clearly state was is allowed.) Steve seems to be Base64 encoding the nut for his server, but I don't know that this is a requirement... I am not doing that with my server code, and it has been working for me so far.

You should then verify the URL is a valid QRL or SQRL.(Which you are now doing, thanks to my bug ;-) ) Then you should validate that all the characters are valid URL characters, and that a valid nut (however it is eventually defined) is present. And that's about all you can do for validation. I believe somewhere in Steve's docs he states anything extra in the parameters are allowed, and should be "ignored" but passed through.

There is probably also a maximum length for URI's and URL's and that should be checked and enforced.
 

shanedk

Well-known member
May 20, 2018
421
113
My humble opinion:

@Steve or the eventual spec needs to define what chars are allowed in the nut.
The nut is Base64URL encoded, so it's really up to the server. The client won't be decoding it, so it's not a client issue.

and that a valid nut (however it is eventually defined) is present.
Only the server can tell if a nut is valid. If the nut is invalid but the process can continue, the server will provide the client with a fresh nut.
 

PHolder

Well-known member
May 19, 2018
1,227
205
The nut is Base64URL encoded, so it's really up to the server. The client won't be decoding it, so it's not a client issue.
Only the server can tell if a nut is valid. If the nut is invalid but the process can continue, the server will provide the client with a fresh nut.
You have conflated two different issues. The validity of a nut for the server is not the same as the nut being a valid expression of what a nut can be. If the rules [eventually] state that a nut can only be the valid characters of a Base64 encoding (upper and lower alpha, the 10 digits and two other chars, underscore and dash) then any other character being present means the client should reject even trying to send it to the server. This mitigates an attack on the client by feeding it invalid data (and thus, by extension, so protects the server also.)

From your two bad links, the first has a potentially valid Base64 encoded nut, so should reach the server, where it will do a lookup and reject it. The second one, which has no nut at all, should not pass validation by the client and should be rejected before even getting to the point of being sent to the server.
 

shanedk

Well-known member
May 20, 2018
421
113
If the rules [eventually] state that a nut can only be the valid characters of a Base64 encoding
That is indeed what the docs say, at least from the client's point of view. The semantics page says:

"[The nut] is a never-repeating opaque cryptographically strong nonce which may, at the server's discretion, contain reversibly encrypted data used to associate and maintain state. It MUST be included with every response to guarantee uniqueness and prevent reuse/replay. As with all of SQRL's use of base64 encoding, any trailing equals signs used for padding must be removed."

And the server page says:

"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."

This is absolutely stating that the nut should be Base64URL encoded. Although it doesn't say specifically anywhere, a client should reject any nut composed of any additional characters, if for no other reason than those characters are not guaranteed to be URL-safe.

then any other character being present means the client should reject even trying to send it to the server.
Right, because the client would know that not only is this nut not valid, it was never valid and never could be valid.

From your two bad links, the first has a potentially valid Base64 encoded nut
Right, but it's not a valid nut that the server created. The login will fail, and as I showed Steve's client will alert the user of this. The Android client behaves as if everything went just tickity-boo, and that is dangerous for reasons I gave and have been discussed at length on the newsgroup.

The second one, which has no nut at all, should not pass validation by the client and should be rejected before even getting to the point of being sent to the server.
And again, the client should notify the user of the login failure (as again Steve's client does), but the Android client acts as if everything happened fine.
 

shanedk

Well-known member
May 20, 2018
421
113
Another invalid link would be this:

sqrl://www.grc.com/sqrl?nut=This.Isnt~Valid

Here, the nut is composed entirely of URL-safe characters, but includes characters not in the Base64URL set, so you know it isn't properly generated by the server. In such a case, the client should visibly fail, and IMO should fail before attempting to authenticate with the server.
 
Status
Not open for further replies.