The established solution for this problem is to use different passwords for different websites along with a password manager. That way you won't have to reinvent the wheel.

I know the rule don't invent your own crypto/protocol, that's why I
want to know if there exists a know protocol for a client securing
himself?

Not every problem has to be solved by a technical, overcomplicated solution.


Not reusing password is an elegant solution.

I used to use a browser extension which did pretty much exactly what you suggested. (It took my actual password + the URL of the site, hashed them together, and generated a password from that). It was great ... until eBay made me change my password because they had leaked their database. At that point, I had to remember which sites used one password, and which another.

The additional problem is that if any site had stored my "password" in plain text, then an attacker might have recognized how my password had been generated, and cracked it.

The final problem is sites like amazon.de, amazon.co.uk, and amazon.com which all need to share a password.

I have switched to a password manager (LastPass) secured with a strong, randomly generated (diceware), password (and 2FA on my important accounts).

I know the rule don't invent your own crypto/protocol, that's why I want to know if there exists a know protocol for a client securing himself?

The problem you are experiencing in the Security Engineering space is known as the "Greedy Password" model. Each website you visit thinks it is the only site on the entire web, and they think it is OK to ask you to manage/remember complex passwords. Also see Peter Gutmann's Engineering Security.

You can do as @MechMK1 suggests and use Password Manager. The problem is, it just moves the password problem around and makes it a little easier manage. You still need to use a real password at some point in time. In a risk management framework you have reduced risk but not eliminated it.

You should use throw away passwords for every non-critical account. I personally use Strong Random Password Generator to generate random 32-byte passwords for each greedy site. Humorously - in a morbid sort of way - some sites cannot handle the long or complex random passwords. Some of the sites make you provide a weaker password.

Once you log into a site they give you a token (cookie) for the site you don't need the password anymore. If you do need to re-enter the password then let the browser enter it from the credential store.

If the password is not in the credential store, then simply go through "Password Recover Password" process. The site will send you an email, and you can use the process to set another throw away password. I use it all the time for expired cookies.

The link sent in the recovery process email is known as a "Self-Authenticating URL". I believe Python uses a similar to authenticate packages. Also see Peter Gutmann's Engineering Security.

Several accounts will be important enough that you need a real password. For example, your corporate password and your Microsoft email account password. For them, use a strong password and write it down so it is not lost or forgotten. Then put the password in your wallet or purse. Even better, setup 2FA for the critical accounts so the attacker needs both your password + OTP/token.

Some services, like Spotify, are considering doing away with passwords all together. They are adapting the "Password Recovery Process" for authentication. When you want to log-in, you enter your email address and they send you a link for a token. You no longer need a password - you just need an email account.

The number one threat is the network attacker, and they have not managed to reach through your monitor and read your post-it notes. If they break into your password manager or browser credential store, let them collect as many throw-away passwords as they like.

I am looking for what I can do to my password before sending it to the server... I was thinking of sending hash(password + service) to the servers

If you like to do theses sort of things (risk analysis, attack modelling, etc), then you should read Peter Gutmann's Engineering Security. His PhD dissertation studied Security and User Behavior. His book is a treatment for building safer, more secure systems.

I'll only answer the crypto aspects of your reasoning; for discussions of the security implications of having a stateless master password, see other answers.

Conceptually, your idea is good. It would be correct in the Random Oracle model, where hash functions have independant outputs for partially identical input. However, in the real world, our hash functions have limitations, and can be vulnerable to extension attacks.

The risk, here, would be that an adversary might steal the output H(key + service1) for a compromised service, and find a more efficient way to generate H(key + service2), that doesn't require to fully recover password.

For this reason, we would not use hash(key + service/salt) as the primitive. Instead, we would use a Message Authentication Code function, MAC(key, service). MAC functions are specially designed to prevent this problem.

The question you have to ask yourself is what are you trying to achieve ?

You said you want to have a unique password, that you will hash with :

Hash(Password + Service) the resulting hash, depending of the algorithm used (hint : do not create your own algorithm), will probably be 32 character long.

The first problem is see is : what if the website does not allow you to use a 32 char long password ?

Second problem : Do you plan on remembering these lenghty password for every different website ? If you plan on saving them somewhere, using a password manager to create 10 character long, unique, random password, that you won't use for any other website is both easier and more secure

If you plan on remembering these 32 char long passwords, it's still easier to remember an unique 10 char password.

To get back to my initial question : what are you trying to achieve ?

Salting and hashing the password in the database is a layer of security so that :

• if the database is compromised the hacker will have trouble finding your original password and thus he cannot compromise your other accounts on other services if you did use the same password (or small variations) on every website.


• but if you are using a different password on each website/service, even if someone gets your password for a site, he can't do much with it so you should not care

If the attacker silently compromised the service you are using and has a full access he can simply steal your sessionID to impersonnate you, he can modify the application behaviour so your clear-text password is sent to him before hashing, he can change your hashed password in the database to his own hashed password, login with his password and then change back the password in the DB to your hashed password... he basically owns the system and YOU can't do anything about it.

By hashing and salting the password, the service/site you are using are not trying to protect them, they are trying to protect your other accounts in case they get compromised.

As others have said you should not be re-using your password however I would also add that you should not be re-using your id. If the creation is under your control then use something random for each one:-

Server 1, ID: bluecanary81 Password: isoudi£&8r902)38rficsu78

Server 2, ID: tuliptop19 Password: uiouew893£*(2dferff$()_5

etc., etc.

If the system insists on an email address then get your own domain and use bluecanary81@mydomain.com for Server 1, tuliptop19@mydomain.com for Server 2 etc.

That way even if someone gets your credentials there is no exposure on any other system.

https://getvau.lt/ seems to answer your question exactly, it will hash your password with the name of the site giving you a unique password for each site while allowing you to only remember one.

Personally I would still recommend a password manager, but if you insist...