Android v0.9.0

[kalaspuffar]

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]

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.

 

[shanedk]

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

 

[kalaspuffar]

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]

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]

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]

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]

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]

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]

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::



Also, there seems to be some confusion regarding terminology. On this screen:

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):


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

Dave

P.S. Enjoy your vacation!!!

 

[Dave]

Say... if the QR Code scan fails, would you consider OCR'ing the text version?!?

 

[PHolder]

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]

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.

 

[shanedk]

Attached is what Steve's client shows when given either of my invalid links above.

 

[PHolder]

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]

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]

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.