I wish to reduce the barrier of entry to a more secure method of generating/storing passwords. The main stumbling block for anyone I have spoken to, or tried to convince to switch to a password database is not necessarily complexity, but perceived complexity.

I have so far convinced some people to avoid re-using passwords, and pointed out resources on creating stronger passwords, or providing instruction myself on how to do so. This now leaves the problem of storing these passwords securely.

Taking into account:

  • Memorising all passwords is not possible.
  • Storing all passwords written down, and secured is not possible either.

Are there any common methods, or best practices, for enabling users who lack technical expertise to safely store passwords?

Edit: My previous version of this question was put on hold as being a product request, this would be correct as I was looking for an encrypted text file "database". I'm repeating the requirements laid out there as it keeps the basis for @Craig's answer, and an outline of how simple my requirements were.

My ideal would have extremely limited functionality:

  • Requires a pass-phrase to open/decrypt the 'database' file.
  • Upon the database opening, the user is simply presented with a plain text editor.
  • Minimal settings immediately apparent in the user interface.
  • A one-click password generator, with 'sensible' defaults.
  • Windows support is a must, cross platform beneficial, but not a requirement.

closed as off-topic by Stephane, Mark, TildalWave, Jens Erat, schroeder Jan 3 '15 at 18:32

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • Are you familiar with KeePass or LastPass? Are those really too sophisticated for the folks you're thinking of? – Craig Jan 3 '15 at 12:35
  • If you cannot find an answer you could develop this program in visual basic in a 1-2 hours with little programming knowledge. Visual basic is fast and easy to learn. You could also hire a freelancer to develop the program for about $20 – Tim Jonas Jan 3 '15 at 12:45
  • @Craig I'm afraid so. If it takes more than a few minutes for them to be accustomed to it, and can cause confusion by clicking a "wrong" button, it's not going to be used. If they fully understood the risks involved, they would put in the effort, but they don't. There are several people I know of who would be very likely to use a program meeting the above requirements as they are already used to that workflow, and it simply adds the step of entering a passphrase. – Phizes Jan 3 '15 at 12:46
  • 1
    @TimWilliams is right -- it wouldn't take much to develop this. You'd just use the password as the key to encrypt the file using the strongest symmetrical encryption available to you. The weak points would be how you handle the encrypted contents of the file during decryption and re-encryption, during password changes, and so on (are you going to decrypt the file strictly to memory? You have to securely overwrite the memory when the program closes, it's susceptible to being read by other programs when it is open, etc.) – Craig Jan 3 '15 at 12:52
  • @Phizes Yeah, I deal with end-users, too. I get it. ;-) – Craig Jan 3 '15 at 12:52

There have been a few "encrypting text editors" around for a long time. I don't know what kind of longevity most of them have, really. UltraEdit will encrypt text files and it's been around forever. A short search sort of turned up these alternatives:






Cryptography can be really tough to do right, so you want to investigate the background of whichever solution you choose. If you roll your own, you want to design it carefully, or you end up making promises that you aren't really keeping. You have to decrypt the data to view it. But when you decrypt it you have to store it and present it. Where do you do that? If you write it to disk unencrypted, even inadvertently via temp files that your app may create, then you've compromised the integrity of your solution. If you decrypt it only to memory, that's good, but you have to be able to securely overwrite it when your program exits, and it is potentially vulnerable while your program is running. If you're using a garbage-collected development tool like most modern ones (Java, .NET C#/VB, etc.), then you don't really have control over what the GC does with the memory your strings are stored in. It might be a very long time before that memory is actually cleared. In the case of .NET, strings are immutable (you can't overwrite them), but there is a secure string class that is overwritable (but harder to use). Or you can pin memory in unmanaged code sections and have your way with it. Which is also harder. But then you still have to consider the possibility of cleartext copies of your data ending up in the Windows paging file (or Linux/UNIX swap file), and so on.

Cryptography is just hard to get "right." :-)

  • @Phizes You're welcome. That is by no means an exhaustive list. Of the ones shown, my knee-jerk reaction would be to look at UltraEdit and Notepad++ first, only because I know those editors have been around for a long time. But I'd research the others and look for the important points about how the data is handled during encryption/decryption, etc. Good luck! – Craig Jan 3 '15 at 13:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.