[Feature request] Tap to copy to clipboard

[pejakm]

[Feature request] Tap to copy to clipboard

[cornelinux]

I thought not being able to copy was a feature, so that this OTP generator is not used on the smartphone itself.

[0xbb]

Hi @pejakm!
It's great to hear that you like the App and also thanks for the feature request.

I agree we @cornelinux the copy to clipboard feature encourages bad security practices and therefore I left it out on purpose.

Importing from FreeOTP is a bit tricky, because I can't simply access FreeOTP's private data storage from this App.

I think you can give adb backup, like described here: https://stackoverflow.com/questions/19225467/backing-up-android-device-using-adb, a try.
Otherwise I think it's just easier to redo the coupling of your services once again.

[pejakm]

@0xbb I was hoping there is a way for a manual migration, but now I see OTP-authenticator uses two files (otp.key and secrets.dat) whereas FreeOTP uses only an xml file (tokens.xml), meaning it isn't possible. Probably how your app stores codes is more secure.

Regarding copying the code, I don't understand why is this a bad practice.

[0xbb]

On Android 4.3+ the secrets are encrypted by a hardware-supported key if you device supports that and that makes migration not so easy.

But there could be a workaround for you. If you already have access to the tokens.xml you can use an QR code generator or this site: https://daplie.github.io/browser-authenticator/ to quickly manually port over your old codes.

I assume if people want to copy the code they are also using the same phone the OTP Authenticator is running on to access the services. This effectively eliminates the second factor in the two-factor auth.

[pejakm]

But there could be a workaround for you.

Thank you very much!

I assume if people want to copy the code they are also using the same phone the OTP Authenticator is running on to access the services. This effectively eliminates the second factor in the two-factor auth.

Okay, I understand, but still, most of the time I need to log into Github (for example) using my phone. In those cases, it is more convenient just to tap and get the code copied. :)

Thank you, once again.

[strugee]

This effectively eliminates the second factor in the two-factor auth.

No, it doesn't. The two factors in 2-factor authentication are:

1. Something you know (password)
2. Something you have (phone)

If the authenticator app is installed on the same phone that you're authenticating to a service on, those two things are still required. The only difference is that the second factor is conveniently right in front of you. I don't understand how this compromises security. Sure, you can argue that the phone might be compromised or something but if that's your threat model, you have way, way bigger fish to fry.

And besides, people will do this anyway. Not allowing you to copy to clipboard won't seem to be there for a security reason, it'll just seem like an annoying feature omission - especially since there's nothing making the reason obvious in-app. I only figured it out because I thought to search the issues.

[strugee]

@0xbb can you respond to the above comment? This is ridiculously inconvenient for me, to the point where I'm considering maintaining a downstream fork of this app - but I'd really like to avoid that, since it'd be inconvenient for everyone involved.

[cornelinux]

Since when is inconvenience ridiculous?

If the authenticator app is installed on the same phone that you're authenticating to a service on, those two things are still required. The only difference is that the second factor is conveniently right in front of you. I don't understand how this compromises security. Sure, you can argue that the phone might be compromised or something but if that's your threat model, you have way, way bigger fish to fry.

If you are running the app on the phone and authenticating at lets say a computer, it is harder for an attacker, since he either

1. has to hack into your computer (to get the knowlegde) or do other meens of social engineering and
2. hack into your phone (to get the possession)

If you are using the app on the phone, which everyone with a security mind will tell you not to, the attacker only has to compromise your phone and he gets both, the knowledge and the possession.

(This security lesson was totally free of charge)

[0xbb]

Hi @strugee. I am very busy at the moment. I am still more leaning towards leaving this feature out at the moment.
If you really need this use case I would properly switch to a different App for now.

On 26 Feb 2016, at 07:11, Alex Jordan [email protected] wrote:

@0xbb can you respond to the above comment? This is ridiculously inconvenient for me, to the point where I'm considering maintaining a downstream fork of this app - but I'd really like to avoid that, since it'd be inconvenient for everyone involved.

—
Reply to this email directly or view it on GitHub.

[strugee]

Since when is inconvenience ridiculous?

@cornelinux Inconvenience does not generally imply ridiculousness. In this case, I was expressing the fact that I think there's very little gain here for a lot of annoyance. Also, I was using it as an expression of how annoying I find the omission. I would've thought this to be obvious, but apparently we're having fun nitpicking.

The fundamental issue here is that you are conflating the difficulty of compromising a password with the difficulty of compromising a host. The latter is orders of magnitude more difficult, especially on an Android device which actually has a pretty damn good security model (at least, compared to a desktop).

Yes, if your threat model is at the level where you would be worrying about someone compromising your Android device and then gaining root in order to read the protected files of a different app, absolutely you should be using Authenticator on a different device. But the vast, vast majority of people's threat models do not require this. And it doesn't make sense to optimize for the minority at the expense of the majority.

I'll also point out two things:

1. Google Authenticator, which is made by one of the most tech-savvy companies in existence, includes this feature.
2. You can preach all you want about what anyone "with a security mind" will tell you to do. You can say anything you want about what's needed for security. At the end of the day, users don't give a shit. They'll either switch to a different app, or they'll abandon 2FA altogether because it's too inconvenient.

(This security lesson was totally free of charge)

Arrogance and condescension are not useful in a technical discussion.

@0xbb OK, understood. I hope you'll consider the above arguments, but at the same time, believe me when I say I understand being busy. No worries.

[0xbb]

@strugee I totally get your annoyance and I also see your arguments. Thank you for staying reasonable (I have no intention of nitpickings)!

On 26 Feb 2016, at 09:47, Alex Jordan [email protected] wrote:

Since when is inconvenience ridiculous?

@cornelinux Inconvenience does not generally imply ridiculousness. In this case, I was expressing the fact that I think there's very little gain here for a lot of annoyance. Also, I was using it as an expression of how annoying I find the omission. I would've thought this to be obvious, but apparently we're having fun nitpicking.

The fundamental issue here is that you are conflating the difficulty of compromising a password with the difficulty of compromising a host. The latter is orders of magnitude more difficult, especially on an Android device which actually has a pretty damn good security model (at least, compared to a desktop).

Yes, if your threat model is at the level where you would be worrying about someone compromising your Android device and then gaining root in order to read the protected files of a different app, absolutely you should be using Authenticator on a different device. But the vast, vast majority of people's threat models do not require this. And it doesn't make sense to optimize for the minority at the expense of the majority.

I'll also point out two things:

• Google Authenticator, which is made by one of the most tech-savvy companies in existence, includes this feature.
• You can preach all you want about what anyone "with a security mind" will tell you to do. You can say anything you want about what's needed for security. At the end of the day, users don't give a shit. They'll either switch to a different app, or they'll abandon 2FA altogether because it's too inconvenient.
(This security lesson was totally free of charge)

Arrogance and condescension are not useful in a technical discussion.

@0xbb OK, understood. I hope you'll consider the above arguments, but at the same time, believe me when I say I understand being busy. No worries.

—
Reply to this email directly or view it on GitHub.

[cornelinux]

@strugee everything is right you are writing. But please let me also point out that you did not sound technically discussing but rather demanding in the first place. And be aware what you are given by @0xbb for free! And it is one thing to discuss technical stuff and another thing to demand features.

You are right that Google Authenticator is written by the most tech-savvy companies. But it is also true, that google itself uses yubikey as 2FA ;-)

[srguglielmo]

I'm probably beating a dead horse here, but I'd prefer NOT to have a copy-to-clipboard function. If it is implemented, I'd prefer it is not automatic. Something like a long press to copy or a setting to enable/disable it.

I haven't studied how exactly the TOTP algorithm works, but I would imagine if there's a malicious app on one's phone that can read the clipboard and constantly collects all these OTP codes, the malicious app could then learn enough to determine the seed and thus be able to generate successful codes itself. Again, I don't know if this is technically possible, as I haven't studied the TOPT algorithms, but it's something I'd be concerned with when using a copy-to-clipboard function.

Also, just to put this out there, is it really that hard to remember 6 digits for 15 seconds or so as you're swapping apps?

[0xbb]

@srguglielmo It's not possible to recover the seed from any number of collected OTP codes, because of the construction of the TOTP algorithm. An attacker would need to recover the key (in this case the seed) of the underlying HMAC which would be equivalent to an brute force attack. Knowing more OTP codes would give the attacker any benefit.

[srguglielmo]

@0xbb Ah, ok. Good to know.

[strugee]

@strugee everything is right you are writing. But please let me also point out that you did not sound technically discussing but rather demanding in the first place. And be aware what you are given by @0xbb for free! And it is one thing to discuss technical stuff and another thing to demand features.

I see what you're talking about now. My apologies - I didn't mean to come across as demanding features or anything like that. I only wanted to see if I could find a diplomatic solution before I did something serious like forking. Sorry again for seeming rude.

Also, just to put this out there, is it really that hard to remember 6 digits for 15 seconds or so as you're swapping apps?

No, it's not hard - just annoying.

Also, I'll point out that in that sentence, you're assuming that using the app on the same phone is reasonable, which defeats the whole point of this feature being omitted :)

[tjspann]

I'd like to also request this feature, if it is considered in the future.