In the article Two-Factor Authentication for OpenSSH and OpenVPN, a simple way was presented to increase the security of PAM-enabled services through two-factor authentication. With the TOTP method used, a time-limited one-time password is generated based on a shared secret.
Depending on the method and encoding, the shared secret consists of 32 or even 40 characters that must be communicated to the user. QR codes have become established as a convenient and fault-tolerant solution for this, which can be read with suitable apps. However, these QR codes often contain additional, superfluous information that allows conclusions to be drawn about the account.
This article takes a look at the structure of the content of such QR codes and how they can still be used securely.
In his article Why you shouldn’t scan two-factor authentication QR codes, Sam Aiken constructs interesting scenarios and advises against the thoughtless use of QR codes for transmitting the shared secret in 2FA.
In addition to the shared secret, most QR codes also contain information about the service provider, the service itself, and usernames. If an attacker obtains this information – be it through the QR code itself or because the app used stores its data unsecured locally or in the cloud, or loses it otherwise – he only needs to obtain the account password to use the service under a false name.
The user is, of course, free to delete or modify this additional information, but according to Aiken, this is not possible in all apps: some apps did not allow changes, while others offered the possibility to make changes but remembered the originally read values, so that unnecessary information could be disclosed here as well. Aiken also criticizes that many services only displayed QR codes, but not the shared secret as a string, which would give the user full control over the data entered into an app.
In addition to using a recommended app in this regard, such as andOTP, whose use admins can influence but not always prescribe, it would therefore be desirable if QR codes contained only the essential information from the outset anyway.
The content of such a QR code ultimately corresponds to a URI, as Google, for example, has defined it for its Authenticator app on Github:
otpauth://TYPE/LABEL?PARAMETERS
The placeholder TYPE indicates whether the method used is HOTP or, as in our case, TOTP; LABEL, according to the specification, should contain information about the issuer and user account; PARAMETERS can contain additional information besides the required secret.
Parameter | Description | Default |
---|---|---|
secret | Shared Secret in Base32 encoding | – |
counter | Counter value for HOTP | – |
issuer | Issuer | – |
algorithm | Used Hash Algorithm | SHA1 |
digits | Length of the generated OTP | 6 |
period | Validity period for TOTP | 30 |
Of all the options listed, according to the specification for TOTP, only TYPE, LABEL, and the PARAMETER secret are required.
With this information, we can now create a URI for the shared secret generated for user Alice in the last article. For data economy, only the service is specified here in the label. Should Alice require further information about the service, it can be communicated to her through other means.
otpauth://totp/OpenVPN?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75
The information contained in this URI does not allow any conclusions to be drawn about the operator, the address, or the username used for the specified service. This should be sufficiently secure for most use cases.
Furthermore, tests with andOTP showed that the LABEL section of a URI can also be left completely empty and still be read without problems:
otpauth://totp/?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75
To convert the URI just generated into a QR code, the command-line tool qrencode is suitable. The codes can be written to an image file or displayed directly as ASCII art on the command line:
$ qrencode -t ANSI 'otpauth://totp/OpenVPN?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75'
Strictly speaking, -t ANSI
ANSI art is generated here by the argument, because so-called border characters are used in the output, which do not appear in the original ASCII character set. Although an output in true ASCII art can be generated using -t ASCII
, the graphic consists only of #
and spaces, which is much harder to recognize and thus unnecessarily complicates reading with a smartphone.
If an image file is to be generated instead, the output format is set to PNG with -t PNG
and the name of the output file is specified using -o qr-alice.png
:
$ qrencode -t PNG -o qr-alice.png -s 10 'otpauth://totp/OpenVPN?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75'
The argument -s 10
is optional here and serves only to increase the size of a dot in the output file from three to ten pixels:
Should Alice want to record further information about her OTP, she can now enter this herself manually in her app or record it otherwise. Here too, data economy does not have to be sacrificed: for example, to distinguish between two VPN entries, it is sufficient to assign them different Issuers, such as Work and Club. In the case of andOTP, this also changes the icon, which now uses the first letter of the issuer.
QR codes are still best suited for transmitting shared secrets to end-users. However, before blindly copying the practices of others, it is worthwhile to look behind the scenes of the standards used and to consider what information really needs to be transmitted and to practice data economy when creating your own QR codes.
By using a flexible command-line tool like qrencode, the creation of custom QR codes could even be automated quite easily for a larger number of users.
If you require support with the configuration or use of two-factor authentication, our Open Source Support Center is at your disposal – if desired, also 24 hours a day, 365 days a year.
Categories: | HowTos |
---|---|
Tags: | 2FA OpenSSH OpenVPN OTP QR SSH |
About the author
about the person
Jan arbeitet seit 2020 an Projekten des Support–Teams und der Internen IT, nachdem er bereits sein Praktikum im Rahmen seines Informatikstudiums bei credativ absolvierte und auch seine Bachelorarbeit zum Thema Einmalpasswörter, Zwei–Faktor–Authentisierung und OpenVPN bei credativ schrieb. Bereits zu Schulzeiten interessierte er sich für Freie Software, Netzwerke und Telekommunikation und richtete zusammen mit Mitschülern ein Internetcafé ein, auf dessen Server und Clients Debian GNU/Linux seinen Dienst verrichtete.
You are currently viewing a placeholder content from Brevo. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from Turnstile to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Turnstile. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information