I am currently developing an application to store my passwords safely. It will be a proof-of-concept at first, but I am planning to upgrade it later. Anyway, here is how the passwords are accessed:

  1. Enter a username and password. Hash both entries upon submitting, and compare to hashes stored in code. If hashes match, proceed to next step.
  2. Use the actual username and password entered as keys/pointers to data in a text file of a large amount of seemingly random characters. This file will be generated manually and will be stored with the program.

Example: username can be converted into a number which corresponds to the character to start from in the file. The password will be converted into a number representing the amount of characters in between each useful character in the file, i.e. read the file, starting at username, but only keep every password-th character.

I'm not sure how to make this approach more secure and I welcome any suggestions.

  • 8
    How to make this approach more secure? Abandon it entirely, and use actual encryption instead of obfuscation for your proof of concept. For real-life use, download an already existing local password manager. If you feel an itch to code, just find an open-source one. – Ben May 10 '16 at 4:46
  • 1
    You may as well use clear-text. Get a real password manager – Neil Smithline May 10 '16 at 5:22

The first rule of crypto is do not roll your own crypto. You are trying to come up with a new solution to an old problem where established best practices already existst. That is a bad idea, since even if you are a security professional as a human you are likely to make mistakes, and your untested solution will go through much less review than already established solution has.

So what is the right way to do this? There are already multiple password manager programs that does this. They generate an encryption key from the master password with a key derivation function (such as PBKDF2, bcrypt or scrypt), and then encrypt the passwords with this key (for instance with AES).

Now, what is the specific problem with your scheme? It is to easy to brute force. I assume an attacker will know the username, so using it adds no security. What you are left with is the password that is used as an offset in the file. The entropy of the password will be no longer than the length of the file (lets call it N), since jumpig say 2N + 5 characters will be the same as just jumping 5 characters (i am assuming you wrap around when you reach the end of the file). If you want an attacker to have to try a billion passwords, you need a 1 GB file.

A KDF is designed to be to slow to brute force, but acceptably fast if you only run it once. The only way to make your scheme slower is to make the file larger and larger. This is unpractical, since it will add the same amount of overhead no matter if you just try one password or if you try millions.

This scheme is in no way more secure than the tried and tested approach. Use that instead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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