Cryptographic hash functions and personal password management

Question

Background: I've always reused same username/password on all websites and got hacked regularly. I am considering using a password manager, but I don't like the need of storing a database. So I came up with my own idea.

Assume there are multiple services for which one needs to be able to recover a password, each having a unique name name_i - a short string. You pick a master_password. Let h(x) be the output of a cryptographic hash function for string x and + denote concatenation. Then one can choose their password for service name_i to be h(master_password+name_i).

Knowing the name and master_password it is trivial to recover password for any given service. By cryptographic hash function definition, even when a subset of passwords gets leaked, the master password an the rest of the passwords should be safe.

Is the above reasoning correct and could this be a viable way of managing my own passwords?

Answer 1

I've actually built a cryptographically secure password manager which generated passwords from a main password, a string, and a set of parameter values. This is not as trivial as it seems, and I'd recommend using a regular password manager (I like 1Password) instead. Here's why:

• Your proposed solution is not secure. When using a password as the source of entropy, it's recommended to use salt, which you have no way of storing, and you need to use a suitable password hashing function, not just concatenation with a cryptographic hash. You'd need to at least switch to Argon2id or scrypt or some other suitable function.
• Simply using the hash output will not work for many websites. If the output is hex, it won't contain both upper- and lowercase letters or special characters, which many sites require, and some sites limit strings to a certain number of characters, and a 64-character hex output will be too long. Some sites require a special character, but it has to be from a limited set. You need a way to take your hash and generate a string of a specified length and composition.
• You also need a way to encode arbitrary existing passwords. While sharing accounts is not a good security practice, in some cases it will be required. Perhaps you and your partner share a credit card, but the company allows only one account to manage it. Thus, you need to be able to take an existing password and store it using your password manager.
• You need a way to change passwords for a site. If a site is compromised, they may force you to reset your password, and you'd need to pick a new one. Using just the site name won't work here, and you'd need to include some sort of version number for the password, which requires that you store that somewhere.
• Most cell phones don't offer general purpose terminal commands or hash programs, so you won't be able to perform this functionality on your phone. If you're using secure passwords, typing a long password in from your computer can be very difficult.

In the ideal world, where any cryptographically secure string were allowed as a password and sites could never be compromised, this might be a viable approach with a change to the structure of the algorithm. However, your design has serious practical problems due to real world constraints. I even found my design, which addressed all of these issues by storing a set of site names and parameters, to be functionally difficult to use, which is why I switched to 1Password. I would strongly encourage you to use a standard, secure, reputable tool for this, whether it stores data in the cloud or on your local machine, to ensure that it's secure and flexible enough to meet your needs.