markmcavoy
Long base32 keys are not correctly parsed
I am using the f-droid build. I was migrating my setup from Google
Authenticator's database file.
When manually importing seeds in base32, I have encountered that
16-character-long seeds work correctly, but 26-character-long ones (e.g.,
mt.gox) do not. The tokens displayed are different to those of Google
Authenticator (those expected by the website).
Workaround: I converted the code to hex using the base32tohex function from
http://gauth.apps.gbraad.nl/ in a JS console. When importing the hex seed to
androidtoken, the right codes get displayed.
Simplified example: Test the base32 seeds:
ABABABABABABABAB
vs
ABABABABABABABABAB
The first one (16 bytes) works, while the second one does not.
Original issue reported on code.google.com by [email protected] on 20 Aug 2014 at 6:00
I want to confirm this. This is the case with the Base32 Google Authenticator codes. I had to HEX it for it to work, which is a security concern in its own right in users being driven to webpages that do this conversion in javascript on a SECRET $#@!ING KEY (I checked the source first in my case)!
In my opinion, this issue should count as a high priority break. You are losing users who do not come here to vent but simply uninstall thinking "Google must do something special" or "Android Token is crap" (which, this issue being 9 months old without resolution, is starting to look like the case to me anyway).
Sorry to be so abrasive, but I spent over 6 hours fighting this dang thing until I found this bug, where I became even more annoyed it's 9 months old while issues over #12 are resolved! I almost chucked Android Token!
Seriously, if I controlled F-Droid I'd mark the latest version of Android Token, as of my complaint here, broken until long Base32 is fixed.
So apparently this bug is fixed on the latest version, but this bug was not marked as closed or fixed (so far as I can tell). I didn't realize f-droid required manual repo upgrades when I had installed Android Token, therefore I ended up with a pre-October 2015 version.
Disregard my wild rantings, and accept my apologies.
I suspect this "bug" might still be present based on the current ("2.10") version on f-droid.
Google Authenticator does not output the padding characters (== for example) when displaying the secret key. It does not include them in the URL it generates either. Either way, strictly speaking the base32 value is incorrect since it does not contain 128 bits. (Tested with libpam-google-authenticator version 20160607-2 in Debian/testing.)
It would be nice if Android Token was able to parse this incorrect Base32.
In the meantime, if you are using Linux, to generate a proper base32 value, try to add = signs to the secret string until the base32 program no longer complains about invalid input. You will then have a valid base32 string, which Android Token might be able to parse (I haven't tested).
echo GAH...AJH====== | base32 -d -i
(replace GAH...AJH with your secret key as printed by Google Authenticator).
You can also obtain the hexadecimal string (I tested this):
echo GAH...AJH====== | base32 -d -i | hexdump -e '8/1 "%02x"'
This issue is still present in version 2.10 available on f-droid. Could the version on f-droid please be fixed?
