"Common password problem" is well known problem, when user uses one password for many resources (web sites, logins to computers, etc...) For example, if one web site loses it' database, which contains user passwords and emails, somebody when might try to use this password on other sites and come to success...

To solve this issue pwdhash exists. This is good solution, only problem is, that user needs special software to compute the password for each web site, for example. So user needs some reliable software for this. User should be sure, that this software doesn't remembers and transfers to somewhere in network entered main password. User should be sure, that this software can't be imperceptibly replaced with malicious version of program that is indistinguishable from the original. For example, it's hard to trust to "pwdhash" application from Google Play market (because it is issued by unknown person and might be silently updated in future). Also it's hard to trust to original "pwdhash" web site, because it might be replaced in some moment of time. Moreover, web site might be just inaccessible.

To solve "common password problem" I want to use some sort of one way hash, which can be computed by hands, on sheet of paper, or even can be counted in mind. I understood, that this might be not strong cryptographic hash, but from other side, I can completely trust this method.

Suppose I have service name, for example "booking" (.com). I want mix it with some permanent password, lets suppose this will by my name "kirill", and I will get password which I can use for login to "booking.com" website.

At first, I will translate name of service and permanent password to numeric form. To do this, I will use telephone keypad layout. So translation will be following:

"booking" = 2665464

"kirill" = 547455

Then I compute: $R = N * 1000000 \bmod S$, where $N$ is name of service encoded in numberic form, $S$ is my permanent password in numeric form. And $R$ is resulting password, which is valid only for some particular service.

I will get:

R = N % P * S = 2665464 * 1000000 % 547455 = 64052235

Now I translate $R$ back to alphanumeric form, again by using telephone keypad. First time i selecting first letter for each corresponding digit (zeros and ones i can't tranlate, so i leave it as is). So I will get:

314715 = "M1gp1j"

Also I will make the first letter capital (many services require to mix capital and lowecase letters). And in case, if resulting string doesn't contains any digits, I will leave last digit as is (again, some services require to include digits in passwords).

So, I get password, which is unique for each service and looks like randomly selected characters. And it's hard to reverse it, to get my permanent password (547455 or "kirill"). Of course, for practical purposes length of my permanent password should be longer, more than 8-10 characters.

This is good or bad method? And why? And how this method can be improved?


  • $\begingroup$ I'm sure that there are answers here and on security SE that explains why deriving all your passwords from a master password has practical security downsides. I'm less sure that they lay out the relative inconvenience compared to password managers, password notebooks, or memorized passwords. $\endgroup$ – Future Security Jun 7 '19 at 13:12

What you're after is fundamentally impossible. Password hashing algorithms are inherently slow. They're designed to be slow even on a computer. Otherwise they would not serve their purpose, which is to make brute force search infeasible. A fast password hash is a broken password hash. You cannot possibly get anywhere near the requisite level of slowness with manual calculation.

For anyone with a computer, given a site-specific password that is calculated from a master password by hand, it will be trivial to go try billions of potential master passwords until they find a matching one.

And having potential multiple matches won't save you, because there can't be many of them, otherwise the number of possible site-specific passwords would be ridiculously low.

| improve this answer | |
  • 2
    $\begingroup$ Conceivably one could choose a master password with 256 bits of entropy, and then the question is to find a pseudorandom function family that can be computed with pencil and paper—there is no need for a password hash in this case. $\endgroup$ – Squeamish Ossifrage Jun 7 '19 at 21:03
  • 1
    $\begingroup$ @SqueamishOssifrage Yes, with an implausibly entropic input, this can work, but it's not the hypothesis in the question. $\endgroup$ – Gilles 'SO- stop being evil' Jun 7 '19 at 21:08
  • $\begingroup$ It's not implausible. One can memorize a 20-word diceware passphrase without much trouble. $\endgroup$ – Squeamish Ossifrage Jun 7 '19 at 21:11
  • $\begingroup$ @SqueamishOssifrage Sure, there are people who've memorized tens of thousands of digits of pi. I meant implausible as in most people can't or won't do it, not implausible as in impossible for anybody to do. $\endgroup$ – Gilles 'SO- stop being evil' Jun 7 '19 at 21:13
  • 1
    $\begingroup$ Tens of thousands of digits of pi is not comparable to a 20-word diceware passphrase. One could still get a reasonable security level—much better security than your childhood pet's name—with a 10-word diceware passphrase. It is absolutely feasible for an ordinary person to memorize such a passphrase; one tends to memorize it merely by using it a few times. $\endgroup$ – Squeamish Ossifrage Jun 7 '19 at 21:16

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.