I'm a fairly new to cryptography, but I recently decided to take up the challenge of trying to write a Java password manager that could store passwords on the local machine while still being secure. These were my thoughts, so I was wondering if anyone could point out any obvious security flaws.

  1. The user enters their master password, say "password". "password" gets encrypted using 2 different RSA semi-primes to 2 different BigInteger values. For this example I'm not going to use massive numbers. Say 5324541 and 10983747. The first encrypted value, 5324541 was stored in a .txt file so the encrypted value of the master password gets checked against this to determine whether or not the program proceeds.

  2. There is going to be another .txt file that stores numbers corresponding to the users passwords, say

    • Facebook, 4363454
    • Twitter, 3423421
    • Instagram, 9997532
    • Bank, 671
    • ITunes, 1400000
  3. The second number, 10983747 (this one wasn't stored on the machine, it was generated on the fly when the user entered the master password) will then be used to generate the actual values needed to retrieve the passwords.

    • 10983747 + 4363454
    • 10983747 + 3423421
    • 10983747 + 9997532
    • 10983747 + 671
    • 10983747 + 1400000
  4. These will be the values the individual passwords hashed to. I plan on hashing each of the individual passwords to Big Integers to avoid collisions, but I plan on making that function fairly easy to compute and easily invertible (not secure at all). Example, the password "hello" would map to some number, say 54338988, but the number stored in the txt file would be (54338988 - 10983747). This way, nobody could figure out what the actual hash was without knowing the 2nd key that can only be generated on the fly by the master password.

I've also been thinking about implementing a feature to protect against keylogging if the user wanted to. It would generate a random bijection from the set of characters to themselves every time it ran. If the user's password was "ab" (oversimplified example) and the map said to type "F" for a and "!" for b then you would enter "F!" as your password an the program would use the bijection I constructed to figure out what you actually meant.

Like I said, I'm kind of new to cryptography, so there may be some major oversight here. I would really appreciate any insight into possible issues, security flaws, or suggestions as I'm really interested in learning about the subject. Thanks!

  • I'm not sure that the fact you want to write it in Java is important.
    – schroeder
    Commented Oct 29, 2016 at 17:43
  • 1
    2 things: 1) when designing security features, first specify what threats you want to counter. I'm not seeing that in your post. 2) There are open source password managers that you can study in order to get ideas on how to proceed. I recommend looking at those first.
    – schroeder
    Commented Oct 29, 2016 at 17:45
  • In general, include some amount of randomness in your encryption schemes. This way even if one password is compromised, others will not be. You can search the term "probabilistic encryption" for further ideas
    – Limit
    Commented Oct 29, 2016 at 18:24

1 Answer 1


First of all, you should not roll your own in situation where security is of any importance. (Just playing around for fun and learning is a different matter, of course.)

Second, I agree with schroeder that you should look at the source code of existing password managers and learn from them.

With that said, here are two big problems with your design:

  • Let's say that an attacker knows e.g. the victim's Facebook password. She runs that password through your function and gets 15347201. Then she substracts the value stored for Facebook in your text file (4363454) and gets the secret number 10983747. She now has the number that will let her decrypt any of the other passwords.
  • There is no step that is slow by design to prevent brute forcing. Usually key stretching is used for this, i.e. hashing the master password with a slow hash function (e.g. bcrypt of PBKDF2) to generate the encryption key.

There might be other flaws as well, but this should be enough to make you want to pick another scheme.

You must log in to answer this question.

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