Comment #1 originally posted by adhintz@google.com on 2011-02-26T23:40:51.000Z:

<empty>

Comment #2 originally posted by markus@google.com on 2011-03-09T20:17:37.000Z:

<empty>

Comment #3 originally posted by joanna.m.griffin on 2011-04-06T23:33:20.000Z:

I second this as it would enhance the level of security of the system. I also would like to see it remove the ability to use the authenticator if the wrong pass code has been entered a certain amount of times.

Comment #4 originally posted by luke.handle on 2011-04-07T00:00:00.000Z:

That could work, at least if you recieved an alert if it had 3 failed attemts. Whether by email or sms.

Comment #5 originally posted by markus@google.com on 2011-04-07T00:32:24.000Z:

This all really depends on your threat model. For the threat model of a remote attack on your phone, I don't believe encrypting the secret key on the phone actually improves security.

Either you trust that the security of the phone is not compromised; and you trust that the phone's security model adequately protects the application's data from being accessed by any rogue application, in which case encryption is superfluous. Or you believe that the phone's security is already compromised, in which case rogue applications can just as easily read the user's pin as they can read the secret key.

In either case, encryption of the secret key does not make any difference to the attacker.

Or maybe, you are arguing that you want to protect from an attacker who can temporarily gain physical access to your device. That is a valid point, but access control for your locked device (as already provided by Android phones) takes care of this. Just make sure you have configured a secure pin for your phone's lock screen.

In general though, there is no such thing as a security panacea. While Android based two-step verification is a great option for many users, there will always be users who have a very specific risk profile that is incompatible with this approach. If you are one of these users, please do not rely on code that you know is inappropriate for your specific use case or threat model.

Comment #6 originally posted by guillaume@paralint.com on 2011-04-07T02:38:57.000Z:

As for "this is similar to how some SecurID devices work", it is not so. SecurID tokens on which you type in your PIN simply adds it to the next token code like this :

token_code + pin = bundled_token_code

The server knowns the token_code, it can retreive your pin when it receives your bundled_token_code. But since an attacker (in the form of a key logger on a PC) does not, your pin is safe.

It coulnd't be otherwise : how would you update your pin in the SecurID token anyway ?

To test : enter 0000 as a pin and generate a bundled_token_code. Now, in the same minute or so, entre 0001 as a pin and generate a new bundled_token_code, it will be 1 bigger thant the first. If the last digit was 9, you will see a carry.

Now back to the phone. The only security you can hope to get is to have cryptographic operations done by an authenticated tamper proof hardware, like a TPM on a PC.
And even then, remember that tamper proof really means "tampering is quite expensive, but doable if the target is valuable enough".

Your security dollar is better spent if you streamline the process of replacing a lost phone a getting a new key.

Comment #7 originally posted by jay@slushpupie.com on 2011-04-07T19:39:59.000Z:

Re: Comment # 5:

I agree that there is no panacea. My thought was by adding an option to wrap the key with a PIN we allow an intermediate security level on the phones. In my particular case, I like to leave my phone unlocked so my wife, kids, etc can use my phone without a problem. But that means my token is wide open. Adding pin protection to the authenticator is just that in-between step. I can see what you mean by the actual encryption though- perhaps just adding an "unlock code" option without the encryption would be sufficient for most.

Encrypting it in this case would prevent the token from being useful if the phone were stolen (since they dont know the pin they cant extract the key) but I guess in 99% of those cases the token would just be revoked because the user knows of the theft. That small case where someone steals the phone specifically for the token, then returns it, is going to be small. People concerned with that type of attack need true hardware authenticators like smartcards.

Re: Comment # 6:

Actually, I was referring to the seed, not the generated output. If I remember right the software tokens seed is wrapped in some (unknown/proprietary) encryption tied to the MEID or some other factor of the device it is provisioned to. That prevents the seed from being extracted easily. I had an old Palm version years and years ago and I thought part of the provisioning was the pin couldnt change, because that was apart of the seed protection for the seed protection. I might be misremembering too, it was a long time ago. Also, as I said above, the idea is to add an intermediate protection level between wide open phone and locked-down phone. I think it could be achieved with just a pin and not needing to encrypt the token itself.

Comment #8 originally posted by bkgoodman on 2011-05-05T16:02:40.000Z:

Re: Comment # 7

If I remember right the software tokens seed is wrapped in some
(unknown/proprietary) encryption tied to the MEID or some other factor of the
device >> it is provisioned to. That prevents the seed from being extracted easily.

No - With Google Authenticator (at least the PAM and Apache modules)are Open-Source - so the encryption is public knowledge. They keys are simple, and not tied to an MEID or anything. Thus, it would be simple to somehow encrypt the key using a PIN or something to further protect it.

In fact, with the code open-sourced, it would be easy for someone two write a third-party app just like this project - that did some sort of key encryption or PIN protection.

Comment #9 originally posted by phuoclh on 2012-11-05T04:15:00.000Z:

Dear all,

I think that we must add PIN for the second factor to make Google Authenticator is a real Two factor authentication

Regards,
Dacosta

Comment #10 originally posted by lenharo on 2013-01-27T07:42:32.000Z:

Hi,

I applied a patch to the android code providing such functionality.
Could you guys take a look on it?
Changes can be found under http://code.google.com/r/lenharo-google-authenticator/source/detail?r=e5f33b1c83915c15aff1be9ebdb077c1a487f7b0

Thank you,
Marcos

Comment #11 originally posted by sixcorners on 2013-04-21T06:35:15.000Z:

So.. We need something in our head, the password. Then we need the device, our phone.

Now we will need another password in our head, for our phone.. Plus the password we use to unlock our phones in the first place..

So.. four-factor authentication? Where 3/4 of them are different passwords?

Comment #12 originally posted by kexianbin@diyism.com on 2013-04-23T09:28:05.000Z:

# 7 j...@slushpupie.com is very correct:

...In my particular case, I like to leave my phone unlocked so my wife, kids, etc can use my phone without a problem. But that means my token is wide open...

Comment #13 originally posted by kexianbin@diyism.com on 2013-04-23T09:41:38.000Z:

Please merge the code from # 10 lenh...@gmail.com

pull request:

https://code.google.com/r/lenharo-google-authenticator/

Comment #14 originally posted by lenharo on 2013-06-01T02:57:53.000Z:

I received a request to make a binary from my branch available here.

Please, keep in mind that this code is based on GA V2.21.
After that Google decided to make all changes proprietary and I am no longer able to merge my changes to the newer code, neither did they show interest in pushing my changes to their official (and not-public) repository.

Anyway, here it is.

Comment #15 originally posted by kexianbin@diyism.com on 2013-06-01T07:41:08.000Z:

Thanks to Marcos(lenharo@gmail.com).

I've install lenharo-google-authenticator2.apk and move my google account to use it("Move to a different phone" in https://accounts.google.com/b/0/SmsAuthSettings), it works well.

Comment #16 originally posted by zan@zansstuff.com on 2014-07-24T23:16:31.000Z:

Marcos (lenh...@gmail.com), is there any way you could write a similar patch for FreeOTP, which is an open sourced authenticator based on Google Authenticator that is still being actively developed by Red Hat?

https://fedorahosted.org/freeotp/

Adding encryption is on their roadmap, but at a fairly low priority for the developers. They do say that they accept code contributions.

Comment #17 originally posted by lenharo on 2014-07-25T00:37:27.000Z:

I would love to but time is something really scarce on my day since last year.

Sorry.