phoerious
commented
1 week ago Thanks for your input, but there is no point in creating a new issue just for this.
My main point stands: Many QR scanning apps maintain a history which over time accumulates your passwords on your device. iOS may be different, but Android still has no proper built-in QR code scanner, unless you count Google lens as one, which probably sends the entire QR code into the cloud.
I do see the point of easy transfer of passwords, but it's not as trivial as you suggest.
I just read seven year old issue #675, which is – I've been IT security engineer for over 30 years – just a document of ignorance and technically simply wrong.
Nowadays, there are at least three major applications where secret data need to be transferred to mobile devices, i.e. TOTP, WIFI, and Wireguard.
KeepassXC therefore should have a way to display a random secret string as a QR code, and it shouldn't be big deal to implement, since the QR code already exists for TOTP.
A comment of phoerious was
which is not correct from a security point of view. First, because it is not keepassxc's task to maintain security on other devices. Second, because it is based on wrong assumptions, since e.g. Wireguard does scan it's QR code itself.
But the most important mistake is, that there is no simple, reliable, and for elderly or handycapped people available alternative to using QR codes. How many people are able to correctly enter a wireguard configuration through the mobiles touchscreen keyboard?
The major fallacy is to believe, that avoiding unencrypted QR codes would maintain security. It doesn't. On the contrary. Because, and to the best of my professional knowledge, people would not do it without QR codes, but without KP. They would store the QR code in an insecure way, and not do it without QR, because some KP architect personally hates QR. Eleminating keepassxc from the work flow does not strengthen, but significantly weaken the security.
Also, the argument, that this can be watched by third parties, doesn't hold. Because the alternative, displaying the QR without using KP, isn't any better. On the contrary, KP could issue a warning to beware of spectators, and limit the time to display the QR, as it does with TOTP.
So the arguments to not implent this are actually counterproductive and based on a limited understanding of practical IT security.
I do strongly agree with hcharbonnier, who pointed out, that opening a keepass database on a mobile phone is severely insecure, since it reveals all contents of the database, and even worse, the database password, on an inherently insecure device, as mobile devices are. Furthermore, it simply wouldn't work to interfere with other applications QR scanning processes, such as wireguard.
The best, most robust, und especially most secure way to transfer a secret to a mobile phone without using complicated and expensive hardware devices still is a QR code directly going into the target app, if the user makes sure, that nobody is watching (which, most of the time, is the case anyway).
I therefore strongly propose to have a secret type consisting of a random string (maybe with support forms for particular types such as Wifi), wich can be displayed as a QR.
It is a severy security flaw to not be able to keep Wifi and Wireguard secrets inside a keepass database and use it directly from there to pass them to a mobile. The reality is that users do keep the QRs completely unencrypted on their machine and do display them as a normal image, which generates thumbnail copies in the cache and other problems.