pwd-hash like algorithm which can be computed on paper &quot;Common password problem&quot; 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 &quot;pwdhash&quot; 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 &quot;pwdhash&quot; web site, because it might be replaced in some moment of time. Moreover, web site might be just inaccessible.
To solve &quot;common password problem&quot; 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 &quot;booking&quot; (.com). I want mix it with some permanent password, lets suppose this will by my name &quot;kirill&quot;, and I will get password which I can use for login to &quot;booking.com&quot; 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:

&quot;booking&quot; = 2665464
&quot;kirill&quot; = 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 = &quot;M1gp1j&quot;

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 &quot;kirill&quot;). 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?
Links:
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.