yubioath-flutter
yubioath-flutter copied to clipboard
Hide codes until one is selected
Other two factors applications on Android let you obfuscate all the codes by default, showing a code for a few seconds, only when you "tap" on it. This feature minimizes the risk of an Android screen scrapping.
For this reason, I don't want to use the Yubico authenticator, as I am not comfortable to see all my TFA codes displayed when I just want to see one.
Please, could you fix this.
You are able to do this by clicking "Require Touch" when adding a code. This will 'hide' the codes until you 'touch' the YubiKey.
Unfortunately, I don't believe it is possible to edit this setting after the code has been added (as you are not able to see/edit the secret key unlike other apps because this is the most secure way of storing the secret keys).
However, you can enable this by adding the key again (requires a unique name I believe), ticking the "Requires Touch" button, and then once you have confirmed it is working, delete the old key.
Hope this helps.
I have attached the image, so you see what I am talking about.
I don't think this would be a big issue to implement.
Since OTPs are used as a second factor, are single use, and generally only valid for 30 seconds, we are not likely to implement this change unless there is significant demand for it.
As @del-leehopper mentioned, if you have a credential set to require touch (unfortunately this does have to be set when initially adding the credential, it cannot be done afterward), the code will not be generated unless you explicitly activate it, so that is an option you have.
@arodier Did you try what I suggested? It is basically what you asked for, but even more secure.
Just obfuscating the codes is only useful if someone is sitting over your shoulder and is able to input one of your codes within 30 seconds. If someone has remote access to your view the screen on your device, it's likely they will also have control over that device, and therefore they can "tap" (as you say) in the app in the same way you can (same applies for Desktop/Mobile, etc.)
By using the "require touch" function, someone must physically have access to the YubiKey to view/generate a code. I do this for all my codes.
If someone has remote access to your view the screen on your device, it's likely they will also have control over that device
You may be right, or not. Some applications, with the "Display Over Other Apps" permissions, don't need root access, but are just able to read the screen content. All they'd need is a code.
By using the "require touch" function, someone must physically have access to the YubiKey to view/generate a code. I do this for all my codes.
Thanks, I just tried, it is good, albeit slightly less convenient — which is absolutely normal and expected — to use.
I am happy to close this ticket, albeit other open source applications are doing this fine.
To be honest, I also find this more readable.
You are right that they may be able to read the contents of the screen without having access to control the device. My point was that if security was important to you, then there is a trade off with convenience.
For example all other "apps" store the secret key within the application. This means (in theory) someone could get access to that security key without even needing to open the application and "tap". The YubiKey stores the key and the device requests a code, which is much more secure but slightly less convenient - a trade-off I am happy with.
The future is FIDO which is both convenient and secure (at least more secure than TOTP). I just can't wait for others to jump on board as I currently have 3 in-use YubiKeys because of the TOTP limit per key (32).
Glad you are happy in the end (I think?).
This means (in theory) someone could get access to that security key without even needing to open the application and "tap".
Yes, I know, this is why I wanted to use the Yubikey I have.
Glad you are happy in the end (I think?).
I think it would be a nice improvement (both in terms of security and readability), but I understand you may be limited in resources. You can close it if you don't have the time to implement it.
With regards to "time to implement it", that's a question for @dainnilsson
However, with regards to if it should be implemented - I will put my 2 pence in and suggest it isn't. I think 'most people' will assume that by hiding the codes, they are somehow much more secure (granted they are slightly more secure but not considerably). Plus it confuses the difference between hiding the codes and hiding them plus requiring a touch. However, again, this is more of a decision for @dainnilsson and will probably park it unless others request it.