* What led up to the situation?
When using Android Token, one notices that the base32 tokens printed
out by the `google-authenticator` program are not valid.
The issue has been previously reported against Android Token
but it appears authenticator do not generate a proper base32 string when
it displays the secret or generates the QR code.
* What exactly did you do (or not do) that was effective (or ineffective)?
Use `google-authenticator` to generate a new code. (I only tried with
* What was the outcome of this action?
The secret key is printed out with missing `=` (equal) signs at the end.
The QR code embeds the same key and is improperly parsed.
* What outcome did you expect instead?
The secret key should contain any number of trailing `=` (equal) signs
at the end in order to be valid base32.
The QR code should embed the secret with the proper number of `=`
(equal) signs at the end in order to be valid base32.
Experimentally one observes that six (6) equal signs appear to be
missing in most cases. (This is because google-authenticator outputs 26
characters, for 130 bits, while Base32 "represents 40-bits groups on
input bits as output strings of 8 encoded characters"(*), so padding must
be extended to 32 characters.)
indicates that the `secret` field should be encoded in Base32 according
RFC6238 (TOTP) references RFC4226 (HOTP) which specifies a minimal
length of 128 bits for the secret key, with 160 bits preferred.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (900, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libpam-google-authenticator depends on:
ii libc6 2.23-5
ii libpam0g 1.1.8-3.3
ii libqrencode3 3.4.4-1+b1
libpam-google-authenticator recommends no packages.
libpam-google-authenticator suggests no packages.
-- no debconf information