#9202 Generated QR codes not being read by Android authentication apps
Opened 2 years ago by paniquelli. Modified a year ago

Issue

Hi all,

I'm having a hard time trying to make user accounts creation as friendly as possible. Once the OTP token is generated (usually TOTP), the QR code given cannot be scanned by any Android app, such as Aegis, Authy, FreeOTP and Google Authenticator. If you try to scan the QR code using Authy or GA on a iOS device the scan process goes without issues.

I tried to follow the steps in the documentation to fix this issue, even if it's for older versions, without any luck. It was reported on this closed issue once, but I'm not able to locate '/ipalib/plugins/otptoken.py'. All I can find greping for 'ipatokenotpalgorithm' was the following:

/usr/lib/python3.6/site-packages/ipaserver/plugins/otptoken.py
/usr/lib/python3.6/site-packages/ipaclient/plugins/otptoken_yubikey.py
/usr/lib/python3.6/site-packages/ipaclient/remote_plugins/2_114/otptoken.py
/usr/lib/python3.6/site-packages/ipaclient/remote_plugins/2_156/otptoken.py
/usr/share/ipa/ui/js/freeipa/app.js

Steps to Reproduce

  1. Create an OTP token
  2. Choose either TOPT or HOTP
  3. Try to scan the given QR code with any Authentication app on an Android device

Actual behavior

The QR code is not being read by any Android app, you must click on 'Show configuration uri' and extract the needed info from there to manually add an account into such applications.

Expected behavior

Just as it's happening on iOS devices, Android authentication apps should be able to read the QR code and add the account automatically.

Version/Release/Distribution

Server and replicas are running on AlmaLinux instances based on AWS latest official AMI image

[root]# cat /etc/os-release 
NAME="AlmaLinux"
VERSION="8.6 (Sky Tiger)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.6"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.6 (Sky Tiger)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"
$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.9.8-7.module_el8.6.0+2881+2f24dc92.x86_64
ipa-client-4.9.8-7.module_el8.6.0+2881+2f24dc92.x86_64
389-ds-base-1.4.3.28-6.module_el8.6.0+2734+1efaf02b.x86_64
pki-ca-10.12.0-2.module_el8.6.0+2764+9fc58d50.noarch
krb5-server-1.18.2-14.el8.x86_64

Additional info:

Generated URIs seems to have the protocol explicitly defined with upper case letter, here is an example:

otpauth://totp/{username}@{DOMAIN}:13da976b-bc86-4f16-90d5-7eea9f1cadaf?issuer={username}%40{DOMAIN}&secret={SECRET}&digits=6&algorithm=SHA1&period=30

Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html
Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting


I'll add some new info to see if it helps someone else.

I created a new OTP token using the CLI and the QR was perfectly recognized by Android apps (tested on FreeOTP and Aegis Authenticator).

[{user}@{replica_host} ~]$ ipa otptoken-add --desc="2022-08-17"
------------------
Added OTP token ""
------------------
  Unique ID: {hyphens-separated-strings}
  Type: TOTP
  Description: 2022-08-17
  Owner: {freeipa_user}
  Manager: {freeipa_user}
  Key: {string}
  Algorithm: sha1
  Digits: 6
  Clock offset: 0
  Clock interval: 30
  URI: otpauth://totp/{freeipa_user}@{domain}:{hyphens-separated-strings}?issuer={freeipa_user}%40{domain}&secret={string}&digits=6&algorithm=SHA1&period=30

I compared the generated URI with one generated by the UI: they have the same format:

CLI: otpauth://totp/{freeipa_user}@{domain}:{hyphens-separated-strings}?issuer={freeipa_user}%40{domain}&secret={string}&digits=6&algorithm=SHA1&period=30
UI: otpauth://totp/{freeipa_user}@{domain}:{hyphens-separated-strings}?issuer={freeipa_user}%40{domain}&secret={string}&digits=6&algorithm=SHA1&period=30

Then I noticed a white border around the image as the main difference between this one and those generated by the UI. This was key on solving the issue.

So, the problem was that I was using a dark mode on Brave: I migrated from the native experimental setting to the plugin/extension named 'Dark Reader'. These dark themes addons are very common these days as they force dark backgrounds on almost all sites (not to confuse with browsers' dark themes which only affects their UIs). I added an exception on the extension (Dark Reader) and the QR scanning worked as expected. I also confirmed this by trying scanning the generated QR on another browser (Firefox) without any dark mode extension. This issue seems to be only affecting MFA apps on Android, as iOS apps seems to be able to handle the QRs no matter the background.

Summarizing, the QR scanning functionality on Android devices strongly depends on the browser having a white/light color as background for the UI, while on the CLI the QR is surrounded by a white border by default and it works as expected on all cases, even on a terminal with a light background.

I would prefer if some of the main developers check on this and decide if this issue should be addressed before closing, by adding a white border to the QR on the UI (as CLI does) or maybe a related warning.

An excellent find, thanks!

I don't believe the qrcode javascript library we use provides a method to include a border by itself so we'd have to roll it ourselves I think. My js is really rusty though.

Metadata Update from @abiagion:
- Issue assigned to abiagion

2 years ago

This is the library used, apparently unmaintained.

There's a PR from 2015 adding the support to a border, there are some forks with that fix (and others). We can do the same, apply that patch, credit, minify and use it.

Another option is to add a simple css:

border: 20px solid rgb(255, 255, 255) !important;

!important is required, the "Dark Reader" extension overrides every possible white border/background/etc.

Metadata Update from @abiagion:
- Assignee reset

a year ago

Login to comment on this ticket.

Metadata