Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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:

share|improve this question
2  
That servers should hash passwords is actually very realistic - even many free web servers provide this. Hashing isn't difficult, and the overhead isn't huge - is the server getting thousands of login attempts every minute? –  Rory Alsop Dec 7 '11 at 11:38
    
@RoryAlsop That most servers hash passwords is a realistic assumption; but it's also true that some sites encrypt them instead and that others hash but don't use salts properly or at all leaving password data vulnerable if the site is compromised. –  Dan Neely Dec 7 '11 at 16:17
    
If you use a password generator then it is quite realistic to have different strong passwords for each website. SuperGenPass for example will work in any Javascript-capable browser and even mobile browsers. –  Andrew Lambert Dec 7 '11 at 18:23
    
There are portable versions of software like LastPass, using a different password on every single website is extremely easy, LastPass for example can generate one for you automatically. Stop reusing passwords if you are worried. This is a silly question because the answer is obvious, don't trust anyone, if you got something to lose. –  Ramhound Dec 7 '11 at 21:20

12 Answers 12

used on other sites.

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

share|improve this answer
1  
yes, I know, but I think it's simply an unrealistic requirement to remember a password for all the 100 sites you're registered on. password store? okay, but what if you're on the go. use your in-the-head hasing, like adding the domain? okay, but actually insecure as the pattern can easily be uncovered. –  lambdor Dec 7 '11 at 10:42
    
That requires you to keep a lot of passwords these days. A password-storage program (e.g. PasswordSafe) could alleviate that pain. –  S.L. Barth Dec 7 '11 at 10:42
1  
@lambdor - Lookup LastPass...If you are on the go then you have access to hardware you have control over. If you don't have control over the hardware then you shouldn't be trusting it with your username and password. –  Ramhound Dec 7 '11 at 21:23

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.

share|improve this answer
    
"require your providers to hash passwords, and include penalty clauses." this unrealistic for free services –  lambdor Dec 7 '11 at 10:47
    
Including penalty clauses, perhaps, but requiring them to assert they hash passwords is definitely realistic. Especially post Sony and other anon/lulzsec attacks –  Rory Alsop Dec 7 '11 at 11:33
    
@RoryAlsop: I like the contractual idea -- do you know of anyone putting language like this, say, in their privacy policy or TOU? –  bstpierre Dec 7 '11 at 12:49
    
@bstpierre - yes, and I have worked with some large organisations who have taken this sort of thing much further and demanded the provider have penetration tests by CREST approved testers, deliver monthly MI on intrusions etc –  Rory Alsop Dec 7 '11 at 12:56

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.

share|improve this answer
    
"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." interesting. Is this actually used at authentication for webservices and how can I verify this scheme? But I assume this can't be done when on-the-go as you don't have acces to the private key. –  lambdor Dec 7 '11 at 10:51
    
@lambdor I've yet to see that used in practice for a website. I imagine because it's inconvenient to carry a certificate around and just too difficult for most people. Works well for SSH though. –  WalterJ89 Dec 7 '11 at 11:29
    
A simpler way to implement a scheme like this is by using an OTP (one-time-password) generated by a device like a Yubikey or an app like Google Authenticator. Works for mobile use. –  chris Dec 7 '11 at 11:58
    
@lambdor, One bank I use has the combination [SSL certificate, user ID, user PIN] as one choice for authentication for logging in. MyOpenID.com also seems to allow authentication by SSL certificate. Authentication by certificate (in combination with or in lieu of other credentials) doesn't seem to be a common practice, however. –  Michael Kjörling Dec 8 '11 at 10:32

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

share|improve this answer
    
"simply use a password manager with a generated password": what if you're on the go? "checking the password recovery method" thx for tip :) a black-list of sites would be nice –  lambdor Dec 7 '11 at 10:46
    
@lambdor I have KeePass on my phone and on a thumb drive. Dropbox to keep it synced between a few different places. (although that last part does make me nervous) –  WalterJ89 Dec 7 '11 at 11:10
1  
I use a KeePass variant, and as I'm also nervous about Dropbox, I just manually synch as and when needed. –  Rory Alsop Dec 7 '11 at 11:34
    
@RoryAlsop that must be 1Password then ;-) –  chris Dec 7 '11 at 18:01

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
What about places like a work machine where you're not allowed to install software willy nilly? You believe the machine is secure, but the tools aren't available. –  McKay Dec 7 '11 at 17:44
    
@McKay - don't ask personal website while at work, problem solved, lastpass can be accessed from work in most cases. otherwise you can always export the password list. –  Ramhound Dec 7 '11 at 21:24

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

share|improve this answer

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.
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.