How to guarantee that password is hashed on server-side?

Question

I'm worried when I send a password to a server, even with SSL or TLS, that the server stores the password in cleartext. Is this the case? If yes and the server gets hacked, all passwords are available in cleartext and can be used on other sites.

Is there any mechanism that guarantees that the password is hashed before reaching the server-side making it unique to the server, like additionally hashing it on the client-side? Which seed would be used then to be able to reconstruct the same hash, without the server/attacker knowing the seed too?

Update1: The scenario is everyday usage of internet sites. I know that servers "should hash passwords" and "users should different passwords" but this is simply not a realistic situation. @Password-safes: what if you're on the go? @Different passwords for every site: unrealistic

Related answers:

• https security - should password be hashed server-side or client-side?
• why-do-some-people-really-hate-security-via-client-side
• Wikipedia - Secure Remote Password protocol

Answer 1

You raise several issues.

Server trust

You never know what the server will do with your password once you send it

Password reuse

Password reuse can be prevented by you: don't use the same password at multiple places.

Hashing

If you were to hash the password before sending it to the server, then the hashed password would become the password. If the server would store that, and it would be read by an attacker, he could log in with it. He doesn't need the original password, since the server checks the hash. It would prevent usage of the password at different websites, but the best measure against that is not to reuse passwords.

A protocol that will work in this situation is a challenge-response scheme. The server could send a challenge to the client, the client could hash the challenge with a keyed hashing protocol (like HMAC+SHA1) and send that back to the server. The server however still needs the password to verify the hash, so it must be stored.

If you want al scheme in which there is no shared secret between the client and the server, look to asymmetric encryption. You could give the server your public key, and have it verify who you are by encrypting a nonce with the private key. You can use SSL for this, with client certificates.

Answer 2

Unless the service provider lets you see the database, no, there is no way to guarantee it. This has proven to be a risk in the past and no doubt will again.

You can't do much in this scenario before the server to pre-hash your password, as that basically makes your pre-hashed password the target that your password would be in an environment where pre-hashing was not done. Your link to the server-side/client-side question answers this quite well.

Instead, concentrate less on a technical solution, and more on a contractual one - require your providers to hash passwords, and include penalty clauses. Right to audit is a useful requirement.

Answer 3

I don't think there is a practical way of testing a server to know that it only stores hashes of your password, but I can think of a theoretical one:

Given known hash collisions for common hash algorithms (MD5, SHA1), you can test a server for storing hashed passwords if it authenticates you using either of a pair in a hash collision.

Example: Let's say "abc" and "xyz" both have MD5 hashes 0123456789ABCDEF (obviously that's not true). You can verify that the server uses MD5 hashes if you can log in using both "abc" and "xyz" as passwords.

But this is useless in practice for several reasons:

• It would fail the test if the server properly salts its hashes (i.e. hash("abc") = hash("xyz") but hash("abc" + salt) != hash("xyz" + salt)
• AFAIK there are no known hash collisions for SHA1, which is in common use.
• It would be even more difficult to obtain a hash collision for values that conform to common password restrictions (ex. passwords can only have numbers and letters and have a maximum length)
• Even if the server stores a hash of your password for authentication, it doesn't confirm that the server is also not storing your password in plaintext somewhere else (I've seen passwords show up in system and web log files, database replication logs, session data files, etc.).

In practice you should assume that websites are doing it wrong, and therefore you should not use the same password for different websites.

Answer 4

You can’t. The server can do whatever it wants with the data you send to it. Even if it states that the data is secure with it, you can’t tell whether that’s actually true. So you either trust the server that it handles your password appropriately. Or you make your own arrangements and use a different password for each site.

At best those passwords are also completely different from each other so that one can’t extrapolate from one to the other (i. e. no obvious prefixes/suffixes). You can use a password manager to generate and remember those passwords. And as many of those are embedded into browsers, they do also help to prevent phishing as the stored passwords are associated to certain sites/URLs.

Whether you use different passwords for different web sites and/or a password manager to generate/remember those passwords depend on your own risk perception.

I personally use a password manager and thus have a different password for each site. The obvious down side is that I can only login into just a couple of sites without it, e. g. when I’m not at my machine. But as one of them is also an OpenID provider, I’m happy to be able to log into the Stack Exchange Network as well.

Answer 5

You cannot be sure that the server will hash the password before storing it. @Rory points out that it is a reasonable requirement which you could try to enforce by non-computer means, but it is not realistic to believe that all servers will do things properly. The solution is not to use the same password (or passwords which can be guessed from each other) for two distinct sites.

"Distinct" passwords can be generated from a "master password" with a cryptographic hash function (e.g. you hash the concatenation of the site name and the master password -- there are ways to botch that, but the principle is sound). Software exists for that. Or you can store randomly generated passwords in a file, symmetrically encrypted with a master password. Software exists for that, too. It could take several forms (an encrypted file; a SSH connection to a server which hosts the password file; a browser extension which uses a cryptographic hash function;...).

Either way, it is hard to do in your head only (curse that biological brain !), because it requires doing extensive computations and/or remembering many random elements.

I claim, however, that the "do it in your brain" scenario is not realistic. Why would you want to compute the whole thing in your brain ? That would be because the local machine on which you are about to type the password does not have the necessary software installed; that's a random machine in, say, a cybercafe. Hey, wait ! You are about to type your password on a cybercafe machine ? A machine which could be clock full of key loggers and other malware ? Now that's a bad idea. No need for a badly written server, in these conditions: you are quite good at doing unsafe things by yourself.

So the need for a password derivation/storage scheme which you can run "in your brain" is actually a need for being able to do something which is quite stupid, security-wise. So do not do it. If you cannot access a safe storage or generator for per-site passwords, then you are not in a context where you could safely use the said password anyway.

Answer 6

I know this is not an answer you looked for, but from user POV you don't have much of an options - log in or not to log in?! However, why not use unique password on each site and store them in keychain application?

Remembering password for each login is, let's be serious, not really an option today (almost every site requires registration and logging). However, if you use keychain application, you need only to remember master password. Downside is, of course, single point of failure (but, of course, the same applies to using the same password all over again everywhere).

One of such application is keepass

How do you keep track of all your passwords? - Q on SU.stackexchange

Answer 7

One way of determining how a provider is storing your password is to "forget" your password. On a properly set up site, even the administrator should not be able to discover your password since the only thing that gets stored is the salted hash of the password.

Almost every site that allows users to create an account offers a mechanism to recover access to those accounts should a user lose or forget their password. A properly set up website will challenge you to answer security questions and then reset your password whereas a definitely broken site will tell you your password.

Not 100% foolproof, lots of false negatives but zero false positives.

Answer 8

You can't, and this is why OpenID exists -- because as a user you have only two options if you are going to use sites that require logging in without it: 1) trust them, 2) use a unique password for each site.

Answer 9

client side encryption or hashing is usually not effective because the client-side code and any secrets it uses are available for anyone to inspect - an attacker can view the source, step through the Javascript with Firebug etc.

You cannot know what the server does with passwords and whether it properly hashes them, so it's worth to be paranoid about your passwords. I would recommend either writing your important secrets and keeping them in your wallet (Bruce Schneier's suggestions - [1]) or using a mobile app like 1Passwd.

[1] http://www.schneier.com/blog/archives/2005/06/write_down_your.html

Answer 10

If I understand your question correctly, then:

1. There is no way to guarantee it. I guess that you could maybe write a client-side browser extension (perhaps a javascript injection would do?) that would hash the value of every password-textbox right before submitting it. I can still see ways that it could have problems. But it would be a start.
2. There is an easier solution that I employ - don't use a different password for every site, but use a different password for... how to put it... security level of a site? That is, use the same password for all the sites where you don't care if it gets stolen (like blogs, maybe stackexchange network, etc), but use individual passwords for the sites which really are security sensitive (like bank websites, paypal, etc.). That way you still have several passwords to remember, but it should be a manageable amount, and it can be made even easier to remember by using passphrases.

Answer 11

used on other sites.

Use a unique per site password, problem solved I'd say.

Answer 12

The best method I have seen to secure passwords for different sites is to simply use a password manager with a generated password.

Another method I've seen is to remember a single password and hash it with the domain of the site as the salt. Hashing can be done with a wide variety of online services, just pick one that supports using a salt and preferably not using MD5. Most people would just think you were using a randomly generated password before they would bother breaking the hash.

While it is usually impossible to tell if a password is stored in plain text or not, checking the password recovery method can give you some clues. If it is possible to get your old password back in an email then you password is for sure stored in plain text (or a reversible encryption).