22

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?

Andy Lester
  • 339
  • 2
  • 6
Sinder
  • 389
  • 2
  • 8
  • 91
    The fact that you want to re-use the same password for Facebook and Amazon is the far bigger sin. Instead, use an offline password manager and create a truly random password for every website. If one leaks, only that website is affected. –  Aug 07 '19 at 11:46
  • 8
    I would suggest a re-phrasing of your question and the problem you are trying to solve: "how can I re-use my password and still protect the password if it is exposed from one source?" – schroeder Aug 07 '19 at 12:27
  • 2
    I doubt anyone would recognize the hash as anything but nonsense, and unless you were a high-priority target they wouldn't spend the time trying to crack your password when they could try thousands of others that aren't so secure – Radvylf Programs Aug 08 '19 at 19:22
  • As a note, I would only recommend reusing passwords in contexts where the password being obtained illicitly won't cause significantly more damage if it's used for two accounts than if it's used for one. ...The only real example of that that comes to mind is certain MMORPGs, which only allow a limited number of characters per account and have no way to raise the cap. – Justin Time - Reinstate Monica Aug 10 '19 at 09:09
  • 1
    I'm shocked that this question has 21 upvotes in a security forum. – Carey Gregory Aug 10 '19 at 15:33

8 Answers8

95

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 SN2\ZJ2Cw92DQx^{$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).

  • 1
    Not necessarily true that password re-use is a "security issue", there is also [LessPass](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4). You still use a master password to unlock your password database. By exploiting a very very very difficult to reverse function one can generate safe passwords. It's more of a tradeoff between leaking a master password but not having to store your passwords in a file (which can also be stolen and masterkey keylogged). – Gizmo Aug 08 '19 at 00:44
  • 26
    @Gizmo [What are the cons of stateless password generators?](https://security.stackexchange.com/q/214301/68614) – gronostaj Aug 08 '19 at 04:30
  • If an attacker has the master key and knows the algorithm used then all passwords are compromised too (that's why I always use the offline apps, if someone can keylog my PC, then someone can also extract a password database file). Also remembering things is still a thing e.g. if a website changes domains or you need to reset your password (how many times did I reset it?). Some websites also only accept specific charsets. – Gizmo Aug 08 '19 at 06:59
  • 8
    @Gizmo If you were to look at the questions discussing stateless password managers, you will see the exact same points being brought up. A truly random password is the *best* kind of password, and any reason not to use a truly random password needs to be really, really good. –  Aug 08 '19 at 07:33
  • 5
    @user1717828, and a blurb of 16 hex digits would be a very good password if it were random, but since it's just a weak hash of a rather weak password it's somewhat suspect. (btw, `4755...` is the hash of `hunter2+gmail.com\n`, with a newline ;) Did you use `echo ... | md5sum`? `echo` always adds a newline at the end, `printf ... | md5sum` would be the solution in that case.) – ilkkachu Aug 09 '19 at 05:51
  • 1
    *why are offline password-managers worse? - Only usable on one device, or hard to keep in sync between multiple devices (because it's offline) - and if you lose the file, alle your passwords are gone and you cannot even reset your password, if you also used it for your e-mail account. **Not saying you shouldn't use one, but you should also know the drawbacks** – Falco Aug 09 '19 at 13:10
  • @Falco: 1. Keeping your files backed up is good practice anyways. 2. Keeping passwords in sync can be solved too, by keeping the DB in sync. 3. OP's scheme doesn't solve any of these problems either. –  Aug 09 '19 at 13:15
  • @MechMK1 most syncing solution are solved by an online DB, as are many reliable backup solutions. so it's not an offline password manager anymore - since if I crack the password to access your DB and your masterpassword, I can access all your passwords. - OPs scheme solve the problem of losing the password-file, since there is no file only an algorithm which can be reproduced. And it is immediately usable on any device, where you can access the password-generator-webapp. – Falco Aug 09 '19 at 13:22
  • @Falco I can use my own server, backed by a client certificate. I am just as secure, and don't need to worry about any outsides. Furthermore, what OP is doing is essentially adding one round of MD5 or SHA1 - and you *still* have to remember your password. If you don't, you're screwed either way. –  Aug 09 '19 at 13:26
  • @MechMK1 Also, offline password managers often end up violating password rules of websites and so you still end up having to track those odd passwords. Also some sites require password changes at different frequencies than other sites. Password managers are better. – Greg Schmit Aug 10 '19 at 06:18
23

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.

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
yeah_well
  • 3,699
  • 1
  • 13
  • 30
  • 2
    I would say that a Password-Manager is a **technical and quite complicated solution**, just one you don't have to build yourself. – Falco Aug 09 '19 at 13:08
  • @Falco "Not reusing password is an elegant solution" – yeah_well Aug 09 '19 at 16:29
  • How do you do this? I personally cannot remember 50 different independent passwords. Not reusing passwords without a complicated, technical tool is quite impossible for the average human, but it would be elegant if you could do it. – Falco Aug 12 '19 at 09:43
3

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.

b0fh
  • 141
  • 2
  • Note: length extension attack is possible for MD constructions not for sponge constructions. See this question from [Crypto](https://crypto.stackexchange.com/q/47415/18298) – kelalaka Aug 10 '19 at 17:10
3

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

Martin Bonner supports Monica
  • 236
  • 2
  • 9
2

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.

0

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.

Maxime
  • 149
  • 6
  • *"the resulting hash, depending of the algorithm used \[...\] will probably be 32 character long."* No. It might be 128 *bits* long. Expressed as a string of hexadecimal digits, that is 32 characters long, with characters of the set \[0-9a-f\]. Expressed in Base64, the exact same value is represented as 22 characters out of a 64-character set. In binary, printed as 0 and 1, it would be represented as 128 characters out of a set of two. In each case, *it's still the exact same value!* It's just represented differently. Changing the representation does not change anything cryptographically. – user Aug 08 '19 at 21:31
  • I was just trying to point out that EVEN if it was a good idea (and it's not a good idea), you might have issues using the hash as a password. – Maxime Aug 09 '19 at 08:44
0

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.

deep64blue
  • 103
  • 3
  • Why not? The ID is traditionally not presumed to be a secret. In addition, the same username allows recognition across platforms. If you have unique passwords, this is not a security problem. – vidarlo Aug 10 '19 at 15:51
0

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

Jamie Kitson
  • 101
  • 2
  • 1
    [What are the cons of stateless password generators?](https://security.stackexchange.com/questions/214301/what-are-the-cons-of-stateless-password-generators) – Disenchanted Lurker Oct 16 '19 at 11:09