I'm starting to have a big list of passwords I need safely stored. I was looking at password managers like LastPass, but these always seem to be targetted by hackers and have been compromised before.

Would I lose anything from storing my passwords in a text document that I encrypt myself using AES 256? Then just decrypt when I want the password?

  • 48
    Why not use a local password manager, like KeePass? Commented Jan 23, 2017 at 9:46
  • 7
    I'm seconding the KeePass suggestion. It's offline and stores the passwords safely. Plus it comes with a number of features that come in quite handy, once you exceed a certain number of credentials.
    – SaAtomic
    Commented Jan 23, 2017 at 10:02
  • 1
    Furthermore, if you need some passwords frequently on other devices e.g. mobile phone you can consider to save a smaller version of your password database file in a secure cloud like Tresorit (end-to-end encrypted). There is an tresorit and keepass app for Android and iOS. You could combine this smaller password database with a key file, which is only saved locally on these devices.
    – Artery
    Commented Jan 23, 2017 at 14:58
  • 3
    Another local password manager is pass which keeps things simple by storing the passwords as gpg-encrypted text files with a directory hierarchy of your choosing. It's only 594 LOC of easy to read bash doing a simple combination of pwgen, gpg, and git. It also has an android app, and you can sync from any machine you control (e.g. vps, ssh through vpn to home computer, etc.).
    – JoL
    Commented Jan 23, 2017 at 18:35
  • 3
    By "encrypting text file with AES-256" you basically make your own poor man's password manager. After all, what the latter does is "encrypt (not necessarily) test file with some form of strong encryption". Commented Jan 24, 2017 at 6:42

7 Answers 7


Considering those compromises you mention, do you think that encrypting files yourself will be easy? How do you know you won't get into those same pitfalls that resulted in compromises of password managers?

AES 256 is believed to be computationally secure. Every computer ever made working simultaneously to brute force the key, working since the beginning of time, would have a probabilistically negligible chance of ever finding the key to an encryption.

However: a secure algorithm doesn't guarantee a secure implementation. Just to give you an example, here are a few questions you should ask yourself:

  • How are you going to ensure that two identical passwords in your list are not encrypted to identical AES ciphertext? (so that if the adversary knows one password, he'll know where it is reused)
  • Are you sure your decrypted password list cannot be reclaimed by a process allocating RAM after you have consulted your list?
  • Are you sure your decrypted password list will not end up is the swapfile?
  • What communication mechanisms will you use between the user providing the master password, the process decrypting the password list and the target application in need of one password?

Password managers are designed with those (and perhaps many others) concerns in mind. It's almost impossible to get everything right when doing it yourself the first time, especially if you're not a security expert.

  • 2
    @Cruncher maybe you already use the same one on different sites Also this is not only for passwords. What if two usernames in the file are the same? What if you add a few bites so all passwords move and the adversary has access to both encrypted versions? Crypto is hard to get right.
    – Josef
    Commented Jan 23, 2017 at 14:51
  • 16
    @Cruncher While using different passwords for different things is certainly good, I would consider a password manager that leaks the fact that I have identical passwords essentially broken. Commented Jan 23, 2017 at 15:09
  • 1
    "How would you "lock" your text file after certain period of inactivity?" Commented Jan 24, 2017 at 6:45
  • 5
    @Cruncher: What if the two URLs are really using the same authentication site? (e.g. Gmail & YouTube)
    – user541686
    Commented Jan 24, 2017 at 9:05
  • 1
    @JDługosz no, it should not use ECB. If I'd get a penny for every Java tool that uses ECB because that's the Java default, I'd have a lot of pennies! Many people who want to use "AES" don't even know what modes of operation are!
    – Josef
    Commented Jan 25, 2017 at 6:56

You'd lose the ability to generate random passwords at the click of a button, which might mean you tend towards weaker passwords from the lack of convenience - one of the benefits of password manager apps, whether online or offline, is the generation of long random strings.

However, you would keep the security of the passwords being safe if you lost a copy of the file, assuming you use the encryption method correctly.

Depending on how you did it, you might introduce a new issue for shoulder-surfing - with most password managers, only the password you want to use is displayed. If your text file includes multiple passwords, you might expose them all when viewing a specific one. You could avoid that by having multiple files, or a single file with really big gaps in between passwords, I suppose.

You probably also don't get as much assurance that the decrypted data isn't written to disk - password manager apps tend to be very careful to keep decrypted passwords in memory, but you'd have to ensure your decryption handling does the same yourself.

  • You don't have to even display the password with KeePass (and I assume other managers) -- but of course then you have to trust that your clipboard is secure. +1 for the last para -- most deceent text editors store recent changes periodically to disk
    – Chris H
    Commented Jan 24, 2017 at 10:27
  • 1
    Good point - I really should have remembered that, since I use that ability all the time!
    – Matthew
    Commented Jan 24, 2017 at 10:28
  • One way to minimize the damage from shoulder surfing as you decrypt all your passwords (because they're all in a single file) is to separate your passwords into multiple files by site. The downside is that you expose a list of sites to the operating system. GPG4Win can be good for this application as it has a clipboard viewer that can be used for encrypt/decrypt.
    – tgharold
    Commented Jan 24, 2017 at 19:30
  • @ChrisH if you don't trust your clipboard you with keepass you can use its hybrid auto-type feature - then the malware would have to sniff out the keyboard and the clipboard at the same time - which it certainly could do, but you rule out all pure keyloggers and clipboard-sniffers.
    – piet.t
    Commented Jan 25, 2017 at 9:48
  • @piet.t Fair enough. In practice I do trust my clipboard, which is just as well as I don't integrate it with firefox. The plugin is just too annoying (for me) if I keep KeePass closed/locked.
    – Chris H
    Commented Jan 25, 2017 at 10:10

Would I lose anything from storing my passwords in a text document that I encrypt myself using AES 256?

Security wise, no. Convenience wise, yes. It depends of how you keep your password stored and on the length of the key. But yes, you could definitely do it yourself.

  • 9
    Security wise, no => challenged! Secure coding is hard, and do-it-yourself security is generally not secure at all. Matthew and Dmitry Grigoryev have given a few flaws likely to be found in home grown solutions. Commented Jan 23, 2017 at 13:30
  • And if there was a vulnerability on your machine, decrypting a file will all passwords in could allow them all to be compromised. Using a password keeper would limit exposure to one at a time.
    – TripeHound
    Commented Jan 23, 2017 at 14:10
  • "will all passwords" => "with all passwords"
    – TripeHound
    Commented Jan 23, 2017 at 14:28

In your point, it is a good idea to store passwords locally in your own application without going for a commercial product. Because you do not know what are the vulnerabilities exist in those products and how many hackers are targeting those applications.

If you are going to build your own tool , following are the things you need to concern.

  • The Language/Tool you are going to use and its cryptographic support
  • How you are going to secure the keys that are using
  • Which algorithms are using and what are the key lengths
  • Do we need to depend on any other 3rd party packages/ tools apart from the main development language/tool
  • How you are going to persist your encrypted data(text file/DB/or in the cloud etc..)

If we take the Java as an example (I do not know how much you are familiar with it), following are the things you need to consider.

Would I lose anything from storing my passwords in a text document

No. You would not if you are using the correct algorithm.

AES 256?

If you are using Java, this is not possible because of key size restrictions are implemented in the Cipher class of Java. Either you need to depend on the Bouncycastle Cryto library or use unlimited strength JCE files. But then again you need to check your Jurisdiction laws before using this if you are planing to export your encrypted data.

My suggestion is go ahead with AES 128 because its kinda like defacto standard in the industry now.

The beast way to secure your encrypted data in your context is, using Java's object encryption using SealedObjects because I think it is an extra burden to use a DB to store your encrypted data.

Store your keys in a Javakey store becuase it is one of the best ways to store and distribute your encryption keys.

You can create a Java application which excepts the password for your Keystore and doing the encryption and decryption. You can simply create a class like follows and manage your passwords. Do a key search after you decrypt the array/list of objects.

public class PasswordStore {
    private String Key;
    private char[] passwd;
    private Date Updated; 

    public String getKey() {
        return Key;

    public void setKey(String Key) {
        this.Key = Key;

    public char[] getPasswd() {
        return passwd;

    public void setPasswd(char[] passwd) {
        this.passwd = passwd;

    public Date getUpdated() {
        return Updated;

    public void setUpdated(Date Updated) {
        this.Updated = Updated;

You can finally encrypt an object something like as follows.

private List<PasswordStore> passwords;

Keep in mind to use other secure programming techniques such as not to store your password in string variables because strings are immutable and vulnerable to memory hijacking attack.

  • 7
    "No. You would not if you are using the correct algorithm." That's an awfully big IF. The almost universal response to security questions is don't invent your own system, and don't write your own implementation of an existing one ... because the chances of getting it wrong are much higher than the (potential) vulnerabilities in a tried-and-tested system. Going with a local-store-only password keeper would be my advice: if nothing else, "normal operation" will leave only one password in plain-text at a time, whereas storing everything in one file risks exposing the lot.
    – TripeHound
    Commented Jan 23, 2017 at 14:07
  • 1
    Also make sure your passwords don't end up in swap/on the disk unencrypted. Make sure to use a secure mode for AES! Make sure again that you don't use ECB mode for AES! (Java does this by default and it is horribly insecure!) And this are just some common pitfalls to begin with. So if you want security, don't hack something together, use a well known, trusted, open-source product like for example KeePass.
    – Josef
    Commented Jan 23, 2017 at 14:12

You might be interested in pass.

With pass, each password lives inside of a gpg encrypted file whose filename is the title of the website or resource that requires the password. These encrypted files may be organized into meaningful folder hierarchies, copied from computer to computer, and, in general, manipulated using standard command line file management utilities.

pass makes managing these individual password files extremely easy. All passwords live in ~/.password-store, and pass provides some nice commands for adding, editing, generating, and retrieving passwords. It is a very short and simple shell script. It's capable of temporarily putting passwords on your clipboard and tracking password changes using git.


Although I agree with the general sentiment that a password manager designed for the task is best, I'll go out on a limb and propose that for some use cases an encrypted text file works fine. You'll need to be sure that unencrypted data is never written to disk, the best way that I've found is to have the text editor transparently encrypt and decrypt the file.

I use VIM for the purpose. In VIM 7.4 add the following to your ~/.vimrc file:

if !has("nvim")
    :set cryptmethod=blowfish

Now open a new file as such:

$ vim -x secrets.txt

VIM will ask twice for a password.

Now you can open the file without the -x flag and VIM will ask for a password on each open. Saving and editing works normally (well, normal for VIM).

I'm not aware of anything on Android or iOs that will be able to decrypt the file, mind you. I personally use LastPass for my normal passwords, and use VIM encryption for some specialty work that needs to be compartmentalized.


I would not write your own because that has its own risks and takes a lot of time. Unless you are just wanting a project.

What I did was search for a password manager that stays out of the spotlight. The one I found creates a encrypted database file that you can store locally or in a cloud service like Dropbox, etc (This is nice because you pick a cloud and it isn't just one company's cloud hackers have to focus on). It has a basic app that allows you to tag passwords and generate strong passwords. It may not have some of the cool features like lastpass or dashlane, but it also doesn't have a cloud that is continually getting attacked.

Sorry I am not going to share the name of the one I use (keeping it out of the spotlight and all), but do your research and you will find a good one that isn't a big name one and that you don't have to program yourself.

  • Without providing the name of the program, you're basically saying what was already stated in a comment to the question... And merely because it's lesser known doesn't mean that it's less likely to be attacked - might also mean that it's had fewer people looking at the security. Keepass and Password Safe, for example, have had a lot of people trying to find flaws in them, and had flaws found in this way fixed.
    – Matthew
    Commented Jan 23, 2017 at 15:22
  • 9
    I wouldn't trust a password manager that relies on security through obscurity to not be compromised...
    – VLAZ
    Commented Jan 23, 2017 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .