barnabycolby / sqrlclient Goto Github PK

A set of issues describing each component of the new identity lock protocol functionality need to be created.

The secondary buttons are designed simply as black text on a transparent background. In practice, although this looks nice, it confuses users who do not know that it is a button.

A set of issues describing each component of the new identity import/export functionality need to be created.

Query parameter, x=6 type of thing

Assuming this is possible, it would be nice to have travis double check that the long running tests actually pass.

Currently the app has only been tested on a nexus 5. Other devices with different screen sizes, and different versions of Android should be tested.

For a local SQRL password lockout to occur on a user's smartphone, someone—presumably not the user—would have to fail several times to properly enter the correct password to unlock their identity. This might mean, for example, five failures, configurable by the user, and might also incorporate a “wrong guess” response delay during which the user-interface would be non-responsive. Since impersonation is considered a serious breach of security, once the count of successively incorrect passwords entered has hit its limit, the SQRL application will erase the user's master key by overwriting its entire 512-bits with all 1's. This special case can only occur in response to local password guessing. Subsequently, whenever the SQRL application sees that is has a master key of all 1's, the user interface will display a notice that the master key has been erased to protect the owner's identity due to excessive password guessing. Since this is a large inconvenience to the phone's owner, the mischievous guessing party will be notified when two, and one, guesses remain before the user's secure identity is erased from the device. The hope is that someone who is merely playing around (for example an innocent child) will cease guessing not wishing to cause the phone's owner undue trouble.
At the point of password lockout and secure deletion, the only recourse will be to allow the smartphone to re-scan a copy of the identity QR code and reenter the identity password. Since exported SQRL master key QR codes are securely encrypted, it would be safe to keep a copy in a wallet or purse if it seems likely that others might be tripping the security lockout frequently and/or being locked out until the identity could be reloaded would be a problem.

The SQRL protocol declares that the identity master key must never be written, even briefly, into non-volatile memory, only existing in RAM. Although the application never explicitly breaks this rule, some investigation needs to be carried out into whether Android breaks it. In particular, the unencrypted master key is passed between several Activities when the identity is first created, using the Parcelable interface to achieve this. It is possible that the master key could be written to disk as a side-effect. Better care could also be taken in regards to how long the decrypted key remains in RAM, as it currently exists until the garbage collector destroys it. Implementing a reference counter and forced delete of the key would be a much better and more secure solution.

As Android testing sucks.

Users were confused as to the purpose of the confirm site name activity, and in particular, what they were being asked to do and why. This could be solved with the addition of some explanation text.

Currently, almost all of the exceptions used are checked exceptions, meaning that if an exception is thrown, the caller is forced to handle it before the code will successfully compile. This regularly results in a large list of exceptions that callers must handle, some of which should never occur, unless as a result of programmer error. This leads to developer frustration and lazy exception handling, lowering the overall code quality. It would be far better to throw unchecked exceptions in these situations. Some thought should also be given as to whether the caller can actually do anything to recover from the exception. In some cases, recovery is impossible and therefore the code should throw a runtime exception. At the highest possible level in the code, a try catch clause should be added to handle these unchecked exceptions, and display friendly error message to the user.

On the create new identity activity, users were confused as to what the text box on this page was for. Adding some hint text to explain that their new identity name should go there would be useful.

Think docs are wrong, and this should be authorize or www-authenticate

If, for example, no password was encrypting an exported master key and an adversary was able to scan it in that state, the user identity represented by that key would be completely compromised.

The explanation text on the create new identity activity tells the user to shake and wave the phone until the progress bar turns green. The new colour scheme means that the progress bar no longer turns green. Either the explanation text should be updated to reflect reality or the bar should be updated to turn green.

The progress bar on the create new identity activity is replaced by a button once enough entropy has been collected. In practice, this happened so fast that users were confused by the explanation text as they couldn't see a progress bar. It would perhaps be better to show the progress bar in all green once it has finished and leave it on screen.

Almost all users experienced confusion in regards to the password strength meter. Its purpose was not obvious, and there was no textual content to inform the user that they needed the strength meter to completely fill before the application would allow them to proceed.

Listen to security now episodes for guidance, for example, wifi, gps and other data should be harvested as well as not relying on the user to input good camera data.

Allows the server to instruct the app to ask a question to the user.

Add a readme, describing the current state of the application as well as how to build and install it.

sqrlonly and hardlock