Password protection / pin to enter the app #55
Comments
|
It's the second factor. You always need to know the account's password anyways. If a PIN is added to the application, you'll need
|
|
I understand, but I would LOVE to have that extra step of protection... |
|
So your threat model is that someone finds your lost phone, is able to break into it even though you have Android screen lock, and happens to know not only your email address, but also your password? Or is it that someone targets you, and not only has your account name and password, but also has enough physical access to you that they can steal your phone to get your second factor, and to do that before you change your password and/or revoke the second factor? In other words, this is not a random hacker in his/her basement, or someone in China, but someone who will travel to where you are in order to steal your phone? If you assume that they can take and access your phone, then assuming we're talking about a Google account, that account probably already has access via that phone. So could you clarify what attack you're trying to prevent? Or at least what type of adversary you are considering? |
|
So someone get access to my phone and able to get access through the screen lock (which I have seen many vulnerabilities in regards to gaining access to the device by passing screen locks OR via direct access to the drive). Next finding my primary email would be trivial. So he knows my email and my two factor auth. The only thing he doesn't know is my password. Passwords can be bruit forced... and in any case, the whole reason the app exists is to prevent someone from relying ONLY on password, but with my example above that's what we are left with, just the password. regards Sean |
|
I'm not against this feature, really. But there's a flaw in your description. You say that after the adversary has compromised one of your factors (the phone) only the other factor (password) remains. Well... yeah. That's how multifactor works. Also, brute-forcing a PIN on the app can be done offline. The real password has to be brute forced "online", meaning Google (or whoever) will see every attempt, and will probably captcha you to make the attack pretty infeasible. The PIN, however, you can put a cluster on and nobody will notice. Sure, it buys you some extra time to revoke the phone's second factor, but you don't really know how much. Because of this, I think in your described attack vector adding a PIN is almost snake oil. But again, it couldn't hurt. |
|
I could imagine SO many other scenarios. regards |
|
Like I said, I'm not really against this feature. But I'd say in most cases actually using it would be snake oil. If you have access to someone's unlocked Android phone then you essentially have full (Google) account access. Sure, if it's a LastPass account then that's not the same thing. I'm merely contesting that this is "very basic security", since the threat is so far fetched. So in conclusion: I won't implement this feature (mostly because I'm merely maintainer of the opensource branch from taking ownership of the PAM module), but will accept a well written pull request to add it. |
|
ok tx... |
Most of the entries I've set up in Google Authenticator have included the email address in the name/description. Yes I could edit them and remove, but with multiple accounts for services I need to know which entry is for which account. |
|
it could just add another level of security... some piece of mind |
|
Only just spotted this isn't the current version on Play Store - but haven't tracked down a feature request place for that. |
|
should I post elsewhere? |
|
Yeah. Standard disclaimer: -- I believe the Play Store version has the ability to file feedback from within the app. |
|
ok tx |
ThomasHabets
changed the title
|
drives my point, please add security pin... |
|
Nothing of that would have prevented by a PIN on the Authenticator. |
|
the article describes as of today a way for hackers to take over your device, a pin would seem like another layer of security that could only help... IMO! |
|
No, because the software just stole the auth-tokens directly. As |
|
word, the pin would need to encrypt the data as well.. seems important feature for such as a vital security app... |
|
The way I read that article the tokens were stolen, not the GA database, like capi said. And GA wouldn't be able to encrypt the system auth tokens, since it doesn't even have access to them. AND (most importantly), the malware had root! There's no protection against root. If nothing else it could simply wait until you opened GA again and sniff the PIN when you entered it. There is an attack vector that a PIN would help against, but that ain't it. |
|
Anybody who doubts the desirability of encrypting secrets with a PIN or password should read about the JPL scientist who was essentially forced to unlock his smartphone at the border. After he got it back, all his Google Authenticator secrets would need to be changed. http://www.cnn.com/2017/02/13/us/citizen-nasa-engineer-detained-at-border-trnd/ |
|
Physical access to a phone at the moment poses so much potential to access the content of the file-system (bugs, root-kits, etc.), I'd say it would be necessary to change the secrets after such an incident anyways. |
|
One worry is someone snatching my unlocked phone out of my hands while I'm in public. A hypothetical scenario is I'm in the middle of a crowded train, headphones on, browsing the internet, oblivious. Right before the train doors close, someone grabs my phone and escapes. I'm logged into my email on my phone so the attacker can do a password reset by email and then get into my accounts. In a way having 2FA in this case makes it worse because it gives the attacker a subset of places where I have accounts that the attacker might not otherwise know about. Even a random opportunistic criminal could do this, let alone a state actor who has arranged for someone to follow me. |
|
agreed! |
|
If you have access to phone (voice & SMS) and email (e.g. gmail app) after stealing someone's phone, then I'd say they don't even need GA. That said, that threat model is very realistic, and I would accept pull requests that added this feature. (but also see disclaimer about play store version, above) |
|
I'd like to voice my support for such a feature. I was using the app and was surprised when I didn't find a PIN setting in the option menu. |
|
I switched to Authy which has this |
|
thinking of switching to Authy as well... just because of the pin thing |
|
Stumbled upon this thread. Another reason to passcode-protect at the app-level rather than rely on device-level protection is that device-level protection is frequently poor for the sake of convenience. I'd prefer to live in a world where I could convince my family to eschew fingerprint and face recognition authentication because it's easily compromised (compelled by law enforcement without a warrant, duplicated onto silicon facsimile, or just taken while you're unconscious), but I don't. I can, however, get them to protect specific apps they don't use constantly with passcodes and PINs. |
|
+1 I agree this is needed it may not stop a hacker with a lot of knowledge and has a contract to get into your accounts but lets face it who the hell is a target of someone like that. But i think it will stop the honest thief from getting in to your accounts or a mate who watches you type your password for example. |
|
If you oversee several devices where you cant enforce the usage of screenlock then the app level PIN could be a solution. |
|
I don't believe these lock app thingies encrypt local data. As stated by the original poster, “We really need a password protection / pin to enter the app and save the local data as encrypted.” |
|
The lock app is also not really secure- I tested it and it looks like you can still get a glimpse of the codes before the lock screen shows up. |
|
+1 for a feature that can only help. I don’t see any downside to the feature if it’s opt in |
|
Since commenting on this originally, I've ditched Google Authenticator and moved over to Authy, who have a variety of convenience features that weren't deemed as being "snake oil". Give it a try. |
|
Snake oil comment was ridiculous. Authy it is. |
|
@capi You're just wrong. By default, browsers will remember passwords, even to Google. If I am incapacitated while using my laptop and phone in a public place, a bad actor can use my airpod unlock to access my phone and my laptop to access my Google account. This insistence to leave a security vulnerability is asinine. I want the convenience of trusted device unlock along with the security of a pincode where it really counts. |
|
@shea-hawkins In your scenario, the authenticator codes still fullfill the "something you have" property, since the attacker has the phone. You mix it together with another vulnerability of the "something you know" (stored passwords which the attacker gets access as well). I do agree, that a PIN lock (unlike a finger-print unlock) will better protect the "something you have" in your scenario. I stand by my statement above, that physical access to my phone opens such a huge attack surface that I'd need all my passwords and the seeds stored in authenticator as compromised. I also stand by my statement from another comment, that the root-based attack cited above would still compromise the 2FA, unless the PIN is used to encrypt the database. And to prevent brute-force attacks, you'd have to use a passphrase rather than a PIN to prevent an offline attack in this scenario. Don't get me wrong, I understand why the feature is requested. I just wanted to point out in the discussion above, that it also must not lead to a false sense of security. |
We really need a password protection / pin to enter the app and save the local data as encrypted.
I am very surprised this feature is not in the app, seems VERY basic security (you can't count only on the Android login passord for access security)
regards
Sean
The text was updated successfully, but these errors were encountered: