We\'ve incorporated two factor authentication into one of our applications using Google Authenticator. In QA, something really weird turned up. While I managed to fix it,
It is not only the key lenght that is important
Here is how a sample URI should look like: otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example
In your case, there is no "issuer" or "accountname" in the URI, both are recommended.
PS. just for your info , Google Authenticatior does not support very long keys as well.
I was having the same issue as above. It turns out that Google Authenticator doesn't like = signs in the IPhone App, but doesn't complain in Android.
In my case I increased the length of the string before encoding to base32 from 8 chars to 10 chars. This removed the three === at the end of the string. I found this online as to why = signs appear in base32 encoded strings:
The pad character (=) does not have a binary representation in BASE32; it is inserted into the BASE32 text as a placeholder to maintain 40-bit alignment
In your case above the same happened when you added the salt. The second secret you pasted doesn't have ='s at the end.
Hope this help.
5 years later... We can only get Google Authenticator to accept secret keys that are 16 digits long. Shorter and longer keys just fail with "Invalid barcode. The barcode ... is not a valid authentication token barcode." Lost a lot of time troubleshooting this, hope it helps.
I also have a problem with this.
This link is valid
otpauth://totp/xxx.yyy:usertest009%40xxx.yyy?secret=CC5FCZNWTKNTOVN6&period=30&digits=6&algorithm=SHA1&issuer=xxx.yyy
But with diff secret key will make it invalid
otpauth://totp/xxx.yyy:usertest009%40xxx.yyy?secret=PBUPKS3SLJAP9V2T&period=30&digits=6&algorithm=SHA1&issuer=xxx.yyy
I found out the problems The secret key must be base32 string. I am using NodeJS, so I use speakeasy to create secret String base32. It works now.