Though I do have a good memory of passwords, it is quite impossible to have one password per application. Yet, it should be... My current way to deal with passwords is to have five passwords and to choose one of them according to how much I trust the application and how sensitive it is. I usually renew my password within 6 months to 2 years.

The idea I just got is to make a script that generates a password from a master over-strong password and the name of an application. I already see both assets and drawbacks.


  • Just one password to remember
  • A different password for each application


  • If the master password is lost, so are the others.
  • If somebody ever find the master password... Finding the others would be a cakewalk.

I also wonder if the algorithm would be reversible (i.e finding the master from the name of an application and the related password).

So I improved my idea : What if the script generates a random password and stores it with the others, on a file, next to the name of the related application. This file would then be encrypted with a 4096-bits RSA key, itself protected by a password that could be renewed on a month base.

Briefly, I'd like to know if the latter is a good idea or if my current method is still better.


3 Answers 3


Safely deriving site-specific passwords from a master password is possible. It requires, namely, a deterministic one-way function: "deterministic" so that the site password can be recomputed, "one-way" so that it is not feasible to recompute the master password from a site-specific password. As first order approximation, a cryptographic hash function does the trick.

The system can be enhanced by making the password derivation (from master to site-specific) configurably slow, to avoid an efficient dictionary attack (an evil site could "try" potential master passwords, to see if it gets the one you used). A "slow hash" is a hash with many iterations. You may also add a salt: a piece of data which is not secret, but yet chosen randomly so that two distinct users of your master-to-site-password software do not end up with the same site password if they happen to use the master password. Salts can be stored in a file (they are not secret) but this would prevent you from rebuilding all your site-specific passwords from your knowledge of the master password alone (i.e. to the problem of remembering, you are adding the problem of data backup).

This is very similar to the question of storing server-side password hashes (for which the usual solutions are bcrypt and PBKDF2). The problem is made easier by the master password being "master". Since you have to remember only one password, you may as well make it a big, fat, random, high-entropy password. Generate a sequence of 17 random lowercase letters, learn it, and you will be fine (because 2617 is about 280, and invoking 280 times a hash function is beyond what is feasible with current technology). An all-lowercase letter password is easy to type, especially on smartphones.

Others have given pointers to existing software which does just that.

Your idea of using a RSA key and encrypted random passwords also works. However, it means storage. If you are traveling and someone steals your laptop (an unfortunate but alas not utterly implausible event), then not only are you deprived from your machine, but you also lost your passwords, until you buy a new machine and retrieve your backup of the encrypted file full of passwords. This can be inconvenient. Deriving the passwords deterministically from the master password means that you will not lose them while you remember the master password.

Also, any new password (for a new site) requires fiddling with the file and its backups, there again something which might be difficult while traveling.

Using an intermediary storage allows for password renewal, but why would you do that anyway ? Password renewal is useful when you manage a big organization with hundreds of passwords and you assume that some passwords will be weak, and some will be broken. It is a way of containing damage and makes sense only if there is a non-zero proportion of broken passwords at all times. Password renewal is a field army thing. It does not scale down: when you get down to a single master password (your case), that password is either fully not broken or fully broken. In the former case, there is no need to renew the master password; in the latter, you have more urgent issues to deal with, including changing all your previous site-specific passwords.

To state it briefly: if your master password needs renewal, then it was broken; which means then all your site passwords are toast. Thus, master password renewal without changing the site passwords is useless.

  • 2
    The problem with derived passwords is diferent policys on passwords (must be changed every N days must contain M lowercase, L upper case, K digits, J non letters/digits....)
    – symcbean
    Jan 21, 2013 at 14:08
  • Your master password can get broken because you entered it in the presence of a camera. That doesn't automatically mean that the file in which the passwords were stored is also compromised.
    – Christian
    Dec 20, 2013 at 17:43

I used to have a similar system of different password for different strength but changed. With companies like LinkedIn leaking passwords loss of passwords is a real concern. Given that social media accounts can be used to impersonate yourself I wouldn't put them into a low security category.

Password Managers like KeePass are a good solution to the problem. DropBox allows for easy backup. That means that an attacker has to both compromise your master password and your online storage.

Password Managers also add additional features like TAN's and multiple database files in case you don't want your bank passwords to be unlocked by the same master password as your usual passwords.

I like the fact that compromising the master password via a camera or a bug isn't enough to break into an account. It adds an extra layer of protection.

When it comes to the problem of losing passwords, there are ways to backup passwords. You could lend two books to two friends.

On a random page of the first book you write the first half of a backup password. On a random page of the second book you write the second half.


(Apologies in advance, don't have the privilege to comment yet). I think it's a legit question, as a one-password based solution still isn't perfect (as is our memory for storing passwords!). As you said Antoine, there are some major downfalls to this solution, such as forgetting the master passwd or even it getting hacked or decrypted somehow.

I always wondered about the possibility of reversing the password-generation algo Antoine, and if you're looking to have a very safe password keeper, it's a fair question to ask.

Still though, I have been a 1Password user for years now, along with the Firefox password manager, because I think it's safer to have a unique pwd for each account which is encrypted, than just ONE strong password for all accounts that you are sure you won't forget.

You must log in to answer this question.

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