Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I have a suggestion, wouldn't it be nice if (mobile) KeePass could read off an NFC tag or a QR-code for the pass phrase of a data base so that this code would not have to be entered manually?
I understand that this poses a security risk, but the big security risks today are with digitally stolen passwords, so here is a solution where one has a hardware object to decrypt the db which could be stored e.g. on ones key chain.
I was about to suggest exactly this. I'm glad I decided to search first and find this discussion.
In fact, I'm already using QRCodes for a similar purpose, but via QRDroid. The problem with this approach is that it requires use of the clipboard....almost the worst place to put any password.
I'll be watching this space.
That would need to be done via a plug-in - which you are welcome to write.
I had the exact same idea and went looking around the web for a program to do this and found none as you probably know. Do you think you would make that plugin? And would you want to collaborate on it?
Would you know where to start in order to create such plug-in?
Thanks for your consideration!
Robert, in a related development, I'm planning on supporting QRCodes on iOS, as an alternative to key-files that's 100% compatible with existing usage.
Desktops normally use USB thumb drives to store the key file. Together with the master password it's a good form of two-factor authentication.
The problem for iOS (iPhone/iPad) users is that the OS doesn't allow easily mounting a thumb drive. (There are some workarounds, but I won't go into that.) Instead what makes more sense is to generate a QRCode from the key file, and have the user scan the QR code along with the master password. The original key file continues to work with the desktop version, while the QR Code allows for the same two-factor authentication on a mobile platform.
The existing implementations of key files on iOS completely miss the point of two factor authentication -- going so far as to have renaming schemes that automatically search for the "correct" keyfile, and by doing so reduce the implementation to a password-only solution.
As for NFC, I think this remains problematic for security. The older NFC standard hasn't gained much traction: two years after my Nexus had it, NFC remains a curiosity. The newer Bluetooth LE standard allows access up to 100 meters away, and is already more widely available. However, if your friends want to play games with your passwords at the bar, they just need you to leave your phone while you're out of the room -- you can even take your Bluetooth "dongle" with you, you won't even know it's being accessed. (Same issue at closer distance with traditional NFC.)
John L. Galt
@Olav - that sounds like a wonderful idea. I currently only use a PW to secure my database as adding a keyfile to my mobile (Android-based) devices can be problematic, especially when I tend to wipe and reinstall the OS on a regular basis (due to ROMing and / or upgrading the OS itself).
I do like the idea of a second step for authentication particularly on mobile devices - for now I've been actually hiding and PW-restricting the Android KP apps that I use to prevent access, but your approach sounds like a better method of accomplishing TFA without using an additional app.
I'd love to test your plugin as soon as you have it ready :D