Hash being overwritten if identificators have the same name

[Jaohammed]

While scanning a QR code to help my friend setup an account for a service we both use, the authenticator simply overwrote my previous hash and put his in it's place, instead of either creating another entry or simply giving me a prompt asking me if I confirm the operation.

As a side note, now I can't recover my acess to said service anymore, since I don't possess the unlock code and seemingly there's no google account linked to that hash. I can't believe such a thing really wasn't thought about, it's a basic security flaw.

I'm using Android 4.4.2 and latest version of the authenticator from playstore.

[ThomasHabets]

Sounds more like a usability problem than a security flaw. It won't make it easier for anyone to hack your account. I'll look into it though.

[Jaohammed]

I think it is a security flaw because that can keep people from using their services, maybe indefinitely like it seems to be my case. I basically lost an account (not a google account) I had for 3 years because of this problem, and so far I didn't manage to get it back.

This is a huge deal that could've been avoided by a simple prompt asking for confirmation of the overwrite, or the ability of having 2 entries with the same identificators, with one of them having a (1) on it just to tell one from the other.

[ocdtrekkie]

@Jaohammed It can be a "huge deal" without being a "security flaw". A security flaw is one that makes it easier for someone who shouldn't be able to access your stuff to access your stuff.

[capi]

I tend to agree that this is a usability problem and can/could cause DoS. It also brings up the issue on backups, which we already discussed a lot and we agreed on that are currently a no-go. Basically the damage of this is limited to what would happen if you "just" lost your phone.

[ThomasHabets]

I've filed internal bug b/31464764 for the closed source Play Store version.

[ThomasHabets]

Either the iOS behaviour or "confirm before overwriting" would be good solutions. I'd prefer the latter.

[capi]

What is the iOS behavior?

[ThomasHabets]

It creates duplicates.

[ThomasHabets]

This bug was first filed here, which is where the iOS behaviour was mentioned: google/google-authenticator#566

[Jaohammed]

Either option is fine, but yesterday I was testing if this would happen when inputting the hash + ID manually (not through a QR Code), and the app created a duplicate, so I think this solution would at least be more consistent with what's already working.

[x-ji]

Is this still not fixed? I just encountered this problem today and it's really frustrating. Now I have to go through the whole account recovery process with the website even though everything was in control. I can't believe such a basic problem is never fixed. Why would a very important security code simply be overwritten and lost forever if I didn't manually confirm such an operation?

[ThomasHabets]

I can confirm that the internal bug is still not closed.

I am a bit curious why you need account recovery. Can't you just continue with the signup and use the new OTP setup?

[x-ji]

The website design was also a bit idiotic in that even though I was signed in, I still needed to provide my old code in order to set up a new one... and now that the old code is gone I apparently can never do so.

I wanted to set up a new one because accidentally I didn't save my generation key for the old code. No sensible website should design such a procedure. But yeah, a series of unfortunate events occurred together this time for me I guess.

[badrinathlondon]

Hi I am having the same problem, what is the solution my secret key is overwritten and now i have to go through the whole process which i really do not want to do. How to recover my old secret code. Please help asap. thanks.

[RichardSilveira]

Any news on it? Is there some kind of fix for it?

[x-ji]

If I'm not mistaken this seems to have already been fixed in some version of the Authenticator during these two years, i.e. something like Name(1) would be generated. I could be wrong though.

[plasmatech8]

This issue has still not been fixed and old codes will still be overwritten without prompt.

[ThomasHabets]

No news.