Option to display data as QR code

[sowbug]

Sometimes it's useful to transfer secrets via QR code, and it would be nice if KeePassXC offered that feature. It could be another button icon next to the eye icon that shows a passphrase.

Use cases

• transferring a strong passphrase to a mobile phone (hard to type because it's mobile and because the passphrase is strong).
• transferring information from an offline instance of the application, where you don't want to risk inserting a USB drive.

[phoerious]

That would require a safe scanner app on the phone, though, i.e., one that doesn't store the plaintext password in its history.

[sowbug]

Yes, that's right. The way I look at it, the more you facilitate using very strong passphrases, the more people will be willing to use strong passphrases. And the easier you make it to export specific passphrases to not-necessarily-safe environments such as a mobile phone, the more likely you are to be willing to adopt an overall safer passphrase store, such as an offline and/or completely trusted machine running a KeePass variant.

If it's a pain in the neck to get passphrases out without connecting safe and unsafe devices, or laboriously retyping 30-character passphrases, you'll tend to use weaker passphrases on the unsafe devices.

[phoerious]

I feel your pain. It gets especially hard when your password contains non-ASCII characters. We just need to make sure users don't shoot themselves in the foot with this.

[TheZ3ro]

It has been already discussed here #96

[adolfogc]

I was thinking on this lately. What do you think of developing a minimal mobile app for this using Qt? Maybe we could use callback-urls (URL schemes) and encrypt the passwords, so that it doesn't matter which app is used when reading the QR code. For instance, iOS 11 users could read the QR code using the native Camera app and Android users could read them using the Barcode Scanner app. The keepassxc mobile app will then decrypt the password and administer it.

[VinArt]

A friend of mine was asking for this feature, to display a password as QR code because of exactly having to type a strong password on mobile. So I implemented in entry edit widget a button that toggles a pixmap (200x200px) with a QR of plain-text password that can be scanned by any reader. Does anyone want this feature to be here?

I can also extend this to showing a QR of encrypted password if someone would write an app that would decrypt it =)

[adolfogc]

I'm curious about how you encoded the password into a QR code. Which library did you use for this project? Please see the approach I'm trying in PR #1001 for implementing something related using Libqrencode.

Also, can you share a screenshot of the interface you're describing?

Another use-case I was thinking about is displaying QR codes for WiFi passwords using this format that is supported by both Android and iOS11. This is useful for connecting mobile devices quickly to WiFi, especially when you use complicated/long passwords. What do you think is a good way to implement this in the UI?

One potential issue I see is the QR encoding library leaking information through freed memory. Initially, I was thinking on zeroing the buffer passed to Libqrencode using C11's memset_s (see this link for more info.), but came across two potential problems:

• I'm not sure C11's memset_s is implemented in the all the possible target platforms;
• a quick inspection of libqrencode's source gave me the impression that it is copying the data we give it to other internal buffers that we can't zero from our C++ code.

[adolfogc]

Another thought: maybe we can ask some of the most popular open source KeePass mobile implementations, e.g. MiniKeePass, to support the Android/iOS part of this?

[affinityv]

I've used QrCodeGenerator.plgx [1] in Winblows.

Today I use qrencode from Linux CLI, but it is messier.
For example (on Linux):
qrencode -t utf8 'test password'

It would definitely be better to be able to do this the KP2 (using that plugin).
[1] https://keepass.info/plugins.html#qrcodegen

[affinityv]

The plugin also works with KP2 (under mono) with Linux. Right click on an entry and display the QR code.

[VinArt]

So my UI looks like this, when you open the entry:

and when you hit Show/hide QR like this:

I used a tiny QR implementation from https://github.com/mrdeveloperdude/OctoMY/tree/master/src/libs/libqr/qr which in turn is a version of this https://github.com/nayuki/QR-Code-generator/tree/master/cpp or maybe even exactly that.

I have not though of the security point of view yet, this is just to show how it can look like, but I think that after generation of Qr it is possible to zerofill memory.

[affinityv]

It would be better to have the QR code outside in it's own "window" so that it can be resized easily (sometimes it is useful to resize QR codes, especially if they are complex).

[VinArt]

I think I could do right click-> show QR and make a modal popup with QR code. Allthough I tested with up to 128 characters [0-9a-zA-Z/*...]+extended ASCII and with 200x200 I had no problem scanning the code.

But yes, having a context-menu entry to show QR makes total sense. Especially with a hot-key and closing with ESC.

I will work further on this (also security-wise) and post after having some progress.

[adolfogc]

@VinArt Thanks for bringing Nayuki's QR code library to my attention, it seems like a nice alternative to use. I'll try to update my PR to use this library instead. Regarding the UI, I don't like how the empty white box looks and agree with you and @affinityv on using a modal window as an alternative.

[adolfogc]

@VinArt Please review PR #1167. I think we can group all QR code functionality under the same option: WITH_XC_QRCODE.

[phoerious]

Do we really need yet another compile-time parameter?

[adolfogc]

@phoerious Do you mean QR code functionality should be enabled by default?

[phoerious]

I don't see why not. Yes, technically it's another dependency, but nothing big.

[adolfogc]

Ok, I'll modify PR #1167 to reflect this change.

[adolfogc]

@phoerious I've removed the compile-time flag as per your request.

[VinArt]

@adolfogc I was not on this for a while, did you implement QR code display for all passwords as discussed or only for one-time? Is there something I could/should do?

[adolfogc]

@VinArt Sorry for my late reply as well; this has been a busy week at work.

...did you implement QR code display for all passwords as discussed or only for one-time?

So far, I've adapted Project Yakuyi's qrcodegen for use with KeePassXC and implemented the functionality for the TOTP part.

Is there something I could/should do?

Sure. The remaining functionality we've discussed in this thread remains to be implemented. IMHO, further discussion remains to be had in order to reach consensus on which will be the way to implement the part of displaying a password as a QR code to enable transfering it to a mobile device, so I think a next step could be implementing the part of displaying WiFi passwords in the special format supported by both iOS and Android. This could be done using the URL field of an entry and the placeholder funcionality of KeePassXC, for example, in the URL field we could write:

WIFI:T:WPA;S:mynetwork;P:{PASSWORD};;

Then, we can just look at an entry's URL field to check if it starts with "WIFI:" and, if so, show a little QR code button next to it that, when clicked, shows a modal with the URI rendered as a QR code. What do you think of this approach? And, would you like to work on this?

Before working on this, though, we should wait to hear what others think of implementing this new feature.

[VinArt]

@adolfogc No problem =)
I would like to work on this. A couple of remarks:

1. Putting template for QR in URL field might be not very nice, since there is a possibility that that field will be in use already.
2. Maybe we should think of fields in settings where the user could input their templates. Maybe someone would like to QR just {PASSWORD}. Here we can provide a number of pre-defined templates, for example.
3. In the entry we can create a checkbox (enable QR) with a dropdown to select a template to use with this entry.

[adolfogc]

@VinArt

Putting template for QR in URL field might be not very nice, since there is a possibility that that field will be in use already.

You're right. I was thinking merely on entries for WiFi passwords. I guess that using {PASSWORD} as the sole placeholder text would provide a means for users to accomplish what was originally requested on this issue. It would also require explicit intent from the user; using it that way would be sort of a "at your own risk" feature for power users.

Maybe we should think of fields in settings where the user could input their templates. Maybe someone would like to QR just {PASSWORD}. Here we can provide a number of pre-defined templates, for example.

In the entry we can create a checkbox (enable QR) with a dropdown to select a template to use with this entry.

Instead of creating new settings and using a checkbox, would it be better to just define a new attribute for each entry and use the placehoders there? We could agree on a convention to use. For instance, looking for an attribute using the special name of qrcode. For each entry, the QR button would be shown only if such an attribute exists.

For the button, I was thinking on a representative QR code icon, like the ones shown here: https://tagliala.github.io/vectoriconsroundup/#qrcode

[TheZ3ro]

What about following the TOTP method?
When right-clicking an entry you have the QR Code menu where you can Show the QR or setup QR.

Setup QR will be a dialog where user can set a placeholder string or whatever he wants to display in the QR (like WIFI:T:WPA;S:mynetwork;P:{PASSWORD};; or {S:WiFi}) and then save this information in a additional attribute named QR_string

Show QR will be a dialog displaying the QR_string

[adolfogc]

@TheZ3ro I like your proposal. It makes this feature more usable for all users in general (not just power users) while at the same time keeping it from being a "hidden feature".

Edit: in the "Setup QR" dialog, we could provide a predefined set of templates like @VinArt was suggesting above. Initially, I would go with just:

• WIFI:T:WPA;S:{USERNAME};P:{PASSWORD};;
• WIFI:T:WEP;S:{USERNAME};P:{PASSWORD};;

Using the username field for the network's SSID.

Also, a warning symbol could show-up if it appears that the user is trying to render a non-WiFi password as a QR code.

[TheZ3ro]

I think we should drop the WEP one 😅

Anyway yes, a preset for WiFi-format password, password only ({PASSWORD}) and username-password ({USERNAME}{TAB}{PASSWORD}). This string should also be editable so advanced users can insert whatever they want

[IPv777]

+1 for the feature request :)
I use https://f-droid.org/fr/packages/de.markusfisch.android.binaryeye/ and this feature would be very useful to me :D

[Insoleet]

I'd love this feature, so that I could migrate from Keepass to Keepass XC.

[almariah]

Actually it a very good feature, I need this for sharing strong passwords with my mobile/tablets, etc. I have written something for Linux/macOS which is very basic to have another tool for me to add this feature

https://github.com/pharmatics/qr-secret

Also, keep in mind that installing keepassxc is easier than keepass (with QR plugin) in macOS and other distros like CentOS.

[almariah]

For scanning part, the Kaspersky QR scanner has a feature of disabling scanning history

https://www.kaspersky.de/qr-scanner

[iromeister]

As I've started using a smartphone only lately, I'm also late to this discussion... But I'd really like to have such a feature for the few occasions where for now I have to type in 20 random characters on my smartphone.

[moerkey]

+1 for this feature. It is not your responsibility to choose which app the user should use to read the QR code securely.

[noraj]

Some OTP client mobile app have an embedded QR code scanner without history & all of course so maybe some android implementation of keepass also have some embedded QR code scanner too.
Anyway that's not the point, it's up to the user to evaluate it's own risk because it seems less risky to swan a qr code with a local QR code app even if it store it than copy/paste it on an email to yourself and syncing it on a third party cloud forever + it is also stored on the email client app unless too you remove it manually as you can remove the qr code scanner history manually too.

By the way you can also disable the history on SecScanQr open-source app.

[jvalrog]

+1
I absolutely detest having to manually type a 20+ random characters password on my phone/tablet from the keepassxc app on desktop. This is a major issue for me to the point of looking for another app that already supports it.

QR would be awesome. If bitcoin wallets have it, why can't this one?

[droidmonkey]

KeePassDX and KeePass2Android are two excellent apps that open kdbx databases and are fully compatible with KeePassXC. There is no reason not to use one of these apps. Transfer your database with your favorite cloud storage or manually with network shares/USB device. If you are on iOS device then use Stongbox or Keepassium.

Regarding users evaluating their own risk... the vast majority of users have no idea what the risk is. Offering the option allows them to make bad decisions and expose information unknowingly. That is the exact opposite of our application's goals.

[moerkey]

@droidmonkey On which data are you referring on when you speak of "vast majority"?

Can we pay you to get the feature in a easter egg way and useable only by a special flag? ;)

[Ceaus]

Regarding users evaluating their own risk... the vast majority of users have no idea what the risk is. Offering the option allows them to make bad decisions and expose information unknowingly. That is the exact opposite of our application's goals.

We've been through this so many times by now. You don't know what my risk profile is. And you also don't know if my decision is a bad one. Please stop this line of reasoning. If you insist in knowing it better, then simply put a big warning box next to the QR code to tell them it's not safe.

[droidmonkey]

Just going to leave this here https://arstechnica.com/information-technology/2021/02/android-barcode-scanner-with-10-million-downloads-infects-users/

[phoerious]

Reminds me of the Stylish browser extension which suddenly went from useful app to full spyware with an ostensibly innocuous update.

[rocketraman]

Just going to leave this here https://arstechnica.com/information-technology/2021/02/android-barcode-scanner-with-10-million-downloads-infects-users/

At the end of the day keepassXC could also suddenly include malware (either the developers go rogue :-) or more likely a scenario like Solarwinds that affects the distribution chain) and send all my passwords to a malicious actor -- a far more damaging scenario then this. The barcode scanner, as far as I can tell from the article, did not send the content of the stuff it was scanning out into the wild -- it just set up adware on the user's browser. Not great, but not the end of the world either.

If I was that paranoid, I wouldn't trust KeepassXC either.

[droidmonkey]

Just caught my attention and related to the discussion, that is all

[Ceaus]

Op 08-02-2021 om 22:43 schreef Jonathan White:

Just going to leave this here https://arstechnica.com/information-technology/2021/02/android-barcode-scanner-with-10-million-downloads-infects-users/ <https://arstechnica.com/information-technology/2021/02/android-barcode-scanner-with-10-million-downloads-infects-users/>

I think this news is distorting the discussion of this github issue. There will always be rogue applications and libraries. To me, in this particular case, the issue is why the KeepassXC devs are on their high horse to tell us what's good for us. And what we can use or not. And how they are deciding for us what our risk profile is.

[rocketraman]

To me, in this particular case, the issue is why the KeepassXC devs are on their high horse to tell us what's good for us. And what we can use or not. And how they are deciding for us what our risk profile is.

I wouldn't go this far. The devs can get on whatever horse they want -- they are the ones putting their time and effort into building it. You aren't going to convince them to implement this feature this way. Use rational arguments (as I believe many have in this issue), and if those don't work, then fork it and build it yourself or use another tool.

Note that its pretty easy to work around the lack of this feature -- for example, this script will generate a QR code for the content you copied from KeepassXC on your Linux terminal -- I'm sure equivalents can be found for every OS:

xclip -selection clipboard -o text/plain | qrencode -s 6 -l H -t ANSIUTF8

If the devs are totally opposed to this, they can always lock this issue / limit it to contributors and/or close it and move on. The fact that they haven't tells me its less about a philosophical objection to the feature (despite the posts above) and more about just the time and effort to build something they don't need themselves, or think is very secure. If is issue is now closed and locked, we'll know otherwise :-).

[phoerious]

As a more general example: My barcode scanner app had a hidden history feature logging all the stuff I had ever scanned without me really realising. Fortunately, I never use it for anything sensitive except perhaps temporary tokens, which expire after use. I doubt average Joe will ever care to check their scanner for a history feature, so over time they build a silent unencrypted copy of their password database on their phone. If you are an expert user who is aware of all the implications, there are plenty of other ways to get your password to your phone like the one suggested above (an even easier way would be to use keepassxc-cli directly).

Unless we build support for encrypted QR codes via KeePass app on the phone, this will not be implemented.

[hcharbonnier]

I think maybe just allow to export data as QR Code is not the right solution, but there is definitely a need to easily transfer data to a smartphone. Smartphones are rarely up to date, full of vulnerabilities and infected apps. So opening a Keepass database on a smartphone is definitly not a secured solution. Maybe a solution could be to allow exporting encrypted data through a QR code, and add a feature on the android app to decrypt this data

[phoerious]

Maybe a solution could be to allow exporting encrypted data through a QR
code, and add a feature on the android app to decrypt this data

That is what I was referring to. But that would need support in the mobile apps.

[borg1622]

As a more general example: My barcode scanner app had a hidden history feature logging all the stuff I had ever scanned without me really realising. [..]

Unless we build support for encrypted QR codes via KeePass app on the phone, this will not be implemented.

Because there are some Smartphone Apps with hidden history features, you deny to implement that feature at all? And ignoring the fact that there are many others with "disable history" options build in?

Please think about this: Isn't it the same if users are allowed to copy passwords from KeePassXC to the clipboard?
From my point of view it's exactly the same. KeepassXC cannot guarantee that the user has installed another clipboard managing software, which creates a history.

Therefore I would be happy if you would reconsider your decision.