I know that all servers should at least store my credentials as hash(password + salt) + salt, with a secure and well known hash function and a salt unique for me, generated from a secure and well known source.

The problem is that servers should do that but may not, so as a user I can't trust them.

I am looking for what I can do to my password before sending it to the server, so that if the server is storing plaintext for example, it will not compromise the security my password on other servers.

I was thinking of sending hash(password + service) to the servers with the service being "Facebook" or "Amazon" for example. This way if someone get hash(password + service) stored in plain text from that service, that's as if they found the hash of my password + the salt, unique for that service.

I already see a problem with that idea: someone could create a rainbow table for each service, making the use of the service as a salt useless.

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?

You are trying to solve a problem that you shouldn't have in the first place: Password Reuse

The concept is simple. You think of a "good" password and use that for everything. Your bank account, online shopping, your e-Mail provider, etc.

The problem is, if it gets leaked by any one of them, then all of the other accounts are potentially in danger. This is a completely unnecessary risk!

What about my suggested scheme?

You yourself said don't re-invent the wheel. If you were to actually do that, you would either have to write an application that calculates the hashes for you, or calculate them yourself and store them.

There are already applications that solve the problem of credential storage, and they do a way better job at it: Offline Password Managers

Why are Offline Password Managers better?

Because they generate truly random and unique passwords. There is no need to bring cryptography into this. No need to tie my password for my e-Mail account to it somehow containing the string "gmail.com".

Because SN2ZJ2Cw92DQx^{$OmqAC_P'xR|Md)[ is definitely a better password than the MD5 sum of hunter2+gmail.com (it's 01f9a94a0febf268495d08f5960e7f05, in case you were wondering).

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'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.

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 {Gmail|Yahoo|Hotmail|Apple|Microsoft|etc} 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.