First - thanks for a great application.
My question is really about the security of using keefox/passifox ( or indeed any such browser extension) as opposed to the basic keepass auto-type.
The Ctrl-Alt-A hotkey in KeePass can be a bit fiddly to use especially where different parts of a website might have different window titles . Sites with very simple window titles can also be problematic - eg SignIn / Log-in etc.
Keefox/Passifox eliminate some of these issues and also make the whole experience more streamlined ( e.g. auto-adding new logins/passwords etc) but at the cost of adding an extension to Firefox. My gutfeeling tells me that the more complex a setup is ( need to add plugin to KeePass/Passifox and an browser extension to Firefox) the more scope there then exists for problems and vulnerabilities.
There is also the issue that KeeFox only works with FireFox / Passifox (KeePasshttp plugin) with Firefox/Chrome. I also use IE9 ( which despite all the negative blogging seems to me to be a fairly good browser) and for that I can only use the KeePass auto-type. If I am going to have to use auto-type anyway why not just use it across browsers ?
See also the following thread at Wilders Security http://www.wilderssecurity.com/showthread.php?t=329627 where one of the suggested strongpoints about KeePass is the fact that it does not integrate into the browser
Look foward to any comments / guidance
I only use Auto-Type because I want the flexibility of using different browsers and different machines - I use 3 machines normally and when I holiday in Oz I use a friend's machine. If I used a plug-in it would just be a nuisance.
If I only had one machine and wasn't very tech savvy then a browser plug-in would be perfect.
Personally, I find KeeFox to be a convenience. In general, any additional piece of software you install increases the opportunities for vulnerabilities to exist - every time you install something new it's a trade-off between security and convenience.
The specific issue with browser extensions, as far as I can make out following those links, was that if a malicious extension were installed, or a vulnerability in a non-malicious extension which allowed it to be taken over by malicious code, then that extension (any extension, not related to KeePass at all) could spy on values entered into forms on web pages, and report them to the bad guys controlling it. It doesn't seem to me, though, that adding a specifically KeePass extension makes any difference.
If anything, it's less of a security risk than installing some other unrelated extension as you'd figure that someone writing a KeePass extension would at least be trying to make it secure, and be more likely to be aware of how to do so.
Once any vulnerable or malicious extension is installed, it doesn't really matter how you are getting your passwords into the web forms, by an extension, by clipboard, by auto-type or by typing them in by hand, they can equally easily be snooped on.
In general, I'd go with these guidelines. If your database is locked, and you've used a strong key, then your passwords are safe. You can't use them, but they are safe. If your database is unlocked, then passwords you use are only as safe as the user account of the application you are using them in (the browser, for example). Passwords you don't use can be a bit safer - depending on how you have KeePass configured, it may be that they are as safe as the user account KeePass is administered under. If a bit of malicious software can elevate itself to root/Administrator, and you database is unlocked, then that's game over and your passwords can be regarded as compromised.
I am not a security professional, however, so if there's some angle I've missed, I'd be happy to hear about it.
The most likely vulnerability on computers these days is malware that targets the browser. These are very sophisticated and will collect anything you enter into a browser session. If you have one of these KeePass is of no value, except for convenience of storage.
Thanks to both of you for your comments and assistance.
@Paul: I think perhaps with some practice I can get the auto-type to work better for me - maybe I will change the auto-type settings in the advanced settings to "an entry matches if the host component of its URL is contained in the target window title" and then for websites use whatever.com as the entry title. This would help to avoid multiple entries/log-ins matching on Ctrl-Alt-A.
Alternatively I could probably get a lot of the functionality of the browser extensions by using the KeePass main window to double click on the entry URL to call up the website, click into the username field, Alt-Tab to get back to KeePass entry , then Ctrl-V on the entry to return to the browser and apply the username /password. This sounds "long-winded" when written down but is not so in actual usage.Adapted slightly from Bruce Gowans sequences at https://sourceforge.net/p/keepass/discussion/329220/thread/deccac80/#bd1b
@Alex: Thank you for the detailed and considered reply and for following the links . Yes it is really a question of trade-off between convenience and security. Incidentally you mention that when unlocked the database is exposed - my understanding from the KeePass security help-page was that even when the database is unlocked the passwords etc are encrypted in memory so that unless the malware was specifically targeting KeePass the passwords within the database (as opposed to items copied or otherwise entered into the browser) would still be reasonably secure ? ( I am certainly not an expert so I may be wrong in this). Otherwise the safest approach would be to only allow the database to remain unlocked for a minimum time and then autolock but this would meant re-entering the master password multiple times during a browsing session - which would substantially reduce the practicality /user-friendliness of KeePass.
A KeePass developer might want to weigh in further with the details on the in-memory protection, but my understanding is:
Yes, passwords are not stored in plain-text in memory, even when the database is unlocked. Yes, this will prevent malware that is not aware of KeePass to read the passwords simply by scouring memory for interesting strings. I'm not sure how practical a random trawl of memory space for strings would be, without any idea of which process's memory to look in or what sort of format to look for them in, but I guess you might stumble across something.
In any case, it is a form of security through obscurity. If no in-memory protection is the equivalent of keeping your passwords stored in plain text mixed in with your recipe collection and hoping no-one thinks to look there, then in-memory protection is the equivalent of keeping you passwords as a picture inside a graphics file in an obscure format. An automated scan won't find them, but it's not secure as such, if the attacker knows what to look for and how they can still get at them.
So, is it worth keeping your database locked when not in use? I guess you'll have to weigh up your personal preference on the balance. For me, I choose to have the database unlocked when I am physically present at the PC, and to lock itself on inactivity. The only case you are aiming to avoid is the case where you notice your computer become infected with malware while your database is unlocked. If you don't notice becoming infected, then your database is potentially compromised next time you unlock it, so it doesn't matter whether it was unlocked at time of infection or not.
I guess one possible strategy, then, would be to lock your database before performing any higher-risk actions, like visiting an unknown website, plugging in a USB stick, opening an email attachment, etc. Then once you are are confident you didn't catch anything, you can unlock again.
Passwords in memory are encrypted and are secure, if you have that option turned on - default is on.
Yes, I read that, and the code. Passwords are not stored in memory in plain text, but they are still in memory, as is the code and keys necessary to decrypt them (the KeePass process itself). That means that an attacker not specifically targeting KeePass won't find them.
However, an attacker executing under privileges at least equal to the KeePass process would be able to get at them, if they were specifically attacking it. For example, you could inject a bit of code into the KeePass process and have that simply call the functions on the protected strings to ask KeePass for their values, the same as a plugin can.
That's why I regard passwords in an unlocked KeePass database as (well) obscured, but not cryptographically secure in the same way as a locked database is secure.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.