How can this encryption algorithm be improved?

Question

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.

Answer 1

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.