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 am not asking why hashing should be done. Instead, I want to know how to prevent that developers record user passwords to hack their user's other accounts, especially their email.

Couldn't they store their user's passwords in plaintext without the users knowing?

Is there any way for a user to detect/prevent this?

share|improve this question

migrated from webmasters.stackexchange.com Jun 7 at 8:39

This question came from our site for pro webmasters.

45  
You can't, that's why it's important to use different passwords on different sites. At least, when security matters to you (random forums, or e-commerce sites may not matter). If you struggle to remember all those passwords, use a password manager. –  paj28 Jun 7 at 9:17
5  
@paj28 That's one reason it's important. There are others. –  cpast Jun 7 at 13:00
6  
One site that does this is Mint.com. I don't know if they store my banking passwords in plain text, but they at least need to be able to reconstruct my passwords in plain text because most of the banks don't have proper authenticated apis to access their data. That being said, I still use Mint in spite of that major security flaw. The usability of my own bank's web site/android application is so awful, I've pretty much given up on good security in favor of actual use. –  Stephan Branczyk Jun 7 at 18:42
2  
While there's no risk that this will give false positives it certainly will give lots of false falses: Ask websites for your password, if they give it back to you in plaintext instead of forcing a new password then you can say for sure that it is stored in plaintext. Obviously they could store it in plaintext but still force you to make a new one. This is more likely to find a naive developer than a sinister one. –  Dean MacGregor Jun 7 at 20:47
4  
You can't know whether they will behave ethically (and competently) with your data, but you can sometimes find out when they don't. In the case of storing passwords in plaintext, if they appear in Plain Text Offenders then it's a big red flag to be careful with what you give them. –  Emilio Pisanty Jun 8 at 14:02

5 Answers 5

Of course they could, but then they could also just email themselves every time you change your password.

Now, depending on the type of system, there are plenty of regulations, audits, reviews, and processes that might be relevant to ensure that the developers don't do this, or many other types of malicious activity. However, you, as a consumer, usually do not have much insight into any of this - except for when it goes wrong, for example if they email you your original password when you ask to reset it.

But you're asking the wrong question here.
Yes, it is important that whatever systems you use are developed securely, but that will never remove the element of implicit trust you will always have in the system itself - and, in this context, the developers are equivalent to the system itself.

The real question you should be asking - and indeed you seem to be implying this - is how to protect your other accounts, on other systems, from a malicious developer or system.
The answer is simple, really - use a different password for each system.

Allow me to repeat that, for emphasis:

NEVER REUSE PASSWORDS ON DIFFERENT SYSTEMS.

Create a unique (strong, random, etc) password for each site, and never ever enter your password for SiteA on to SiteB.
Because as you intuitively noted, if SiteB has your password for SiteA in any form, then that password is no longer secure from SiteB.

Just for funsies, here is an xkcd on this:

XKCD Password Reuse


One last note, if you're starting to worry "How in heck am I going to remember a strong password independently for each different site??!!?" - take a look at this question here on passphrases, and also look into password managers (e.g. Password Safe, Keepass, LastPass, 1Pass, etc).

share|improve this answer
8  
an alternative to having a seperate password for each site is to have a handful of passwords that you use, and switch between depending on the level of security of a site and how much you trust it. I.E. one password for your email (which controls password resets) one for your banking institutes, and another for all the crappy websites (forums/gaming sites, sites that force you to make an account, etc). just like you have a spam email (or you should), you should have a spam password. –  n00b Jun 8 at 16:47
4  
Ongoing use of password generators like you describe are problematic @Agent_L. They do not accommodate changes in the master password or site passwords very well. If someone is in a position to use a password manager instead they probably should. –  PwdRsch Jun 8 at 18:26
3  
n00b - so if I get your password from one attack on a bank that leaks info, I can get all your bank accounts? Hmmm - not your best plan! –  Rory Alsop Jun 8 at 19:58
3  
@agent_l every password manager i've looked into includes a password generator for when you need a new password. i doubt anyone actually makes up their own passwords if they're using a manager. –  sgroves Jun 8 at 21:13
1  
Generators sound cool, but if you always generate your passwords using the same seed + sitename and never save the result, how do you reset your password on a site that was compromised? No, password managers are the way to go. Every one of my accounts, no matter how vital or trivial, has a unique 16-character random password associated with it. –  Mikkel Jun 8 at 21:24

You cannot know that someone will behave ethically or wisely, so:

  1. Never re-use passwords across sites.
  2. Decide how much information to share.
  3. Withhold information that is not required, and suspect any website that asks for more info than is needed to give you a particular service.

I'm afraid that some developers aren't forward-thinking enough to understand the implications of an information leak for their users, so protect yourself rather than relying on others.

share|improve this answer
2  
+1 "or wisely", because there's little practical difference to me between a programmer who intentionally steals my password, vs a sysadmin who cocks up the Linux installation, the server gets rooted, and some hacker steals my password. If anything I'd slightly prefer it's the programmer, since the company involved at least has an address to give the cops. –  Steve Jessop Jun 7 at 12:32
2  
...has an address to give the cops: I'm a freelancer working from Asia, and hardly anyone asks my address. But developers and sysadmins are most strong trust in the chain. –  Ayesh K Jun 7 at 13:04

As others have said, you can't fully know what the developers are doing with your data once you hand it over. It may give you some confidence to examine how the site operates to see if they follow security best practices on the pieces of the system visible to you.

  • Do they use HTTPS on pages with sensitive info (including login)?
  • Do they email you your password in plain text?
  • Do they allow for two factor authentication?

Checking these boxes doesn't guarantee they aren't doing something shady elsewhere, but it gives you a better sense of how the developers have setup the site.

As mentioned, avoiding password reuse is the most important security practice you can follow to protect yourself.

share|improve this answer
3  
I'd add an additional box to check: "Do they needlessly restrict what characters you can use in your password?" A properly-hashed password is hard to distinguish from random binary data, and so anything that stores such a hash needs to be able to account for any possible sequence (for example, by hex-encoding the hash for storage, and then unencoding it when you need to compare something to the hash). If the site restricts what characters you can use in your password, this could be because someone isn't storing it properly. –  The Spooniest Jun 8 at 16:28
    
@TheSpooniest: The code required to map ASCII strings into sequences of bytes such that strings that compare equal will always yield the same sequence of bytes is trivial. The code required to do likewise with all possible Unicode strings is massively complicated and has lots of weird corner cases, especially if one considers the possibilities of mixed left-to-right and right-to-left characters. One could allow a lot of non-ASCII characters without difficulty, but it's easier to supply a small list of permitted characters than to explain what characters are and aren't allowed. –  supercat Jun 8 at 20:52
    
@supercat: That only holds if you're attempting to display passwords to users, and I really hope you aren't doing that. If you aren't, then you just pick an encoding to use internally, encode the password accordingly, run it through your hashing algorithm, and Base64 or hex-encode. After that, it's just a matter of making sure that your password fields use that encoding, or that you can detect the encoding they use if for some reason they have to use a different one. –  The Spooniest Jun 9 at 12:16
    
@TheSpooniest: With ASCII, one can pretty well guarantee that if someone types "Fred123" as a password, each ASCII character will generate one codepoint; if someone types a password with diacritics or a mixture of right-to-left or left-to-right characters, the exact sequence of code-points received might be different on different browsers. If someone types a combining accent followed by a letter and the combination is in some browser's tables but not others, then some browsers might report that as one character and some as two. If one were storing plain text, it would be possible... –  supercat Jun 9 at 14:47
    
...to say accept any password whose normalized form matches the normalized form of what's in the database, and not have to worry about the possibility that an incorrect normalization table could cause the database to store a hash that won't match any correctly-normalized passwords after the table is fixed. –  supercat Jun 9 at 14:57

One way you can tell that they are able to get your password is if the forgotten password system is able to email you your old password. If it forces you to generate or set a new one then it's still possible that they have stored in plain text/2 way encryption though.

The other way you could tell is by signing up for a free hotmail account and signing up to a few (trusted) sites with the same password, see if anything happens.

Other than that, you can't really tell.

share|improve this answer

The only way how a website can prove it's NOT storing your password in plaintext is to never receive it in plaintext. This can be only achieved via client-side hashing script. Unless you can analyze website code and/or sniff traffic you have to assume that the admin has full knowledge of your password in plaintext.

See this question from an admin who wanted to give his users peace of mind you seek. it has many interesting answers, albeit most of them focus on security instead of proof-of-not-storing-plaintext.

share|improve this answer
1  
Hmm, but if you hash the password client side, and then transmit the hashed value over the internet, how does that help? A hacker who's sniffing the line finds the hashed value, and that's what he sends to the server, and he's in. He doesn't care what the original value was. Okay, there are systems that send a random salt value and the client is supposed to use his password to encrypt the salt and send it back, etc. –  Jay Jun 8 at 23:01
1  
@Jay uhm, I think you didn't read the question. The question is not about security of login, the question is "can site X admin learn my site X password". –  Agent_L Jun 9 at 9:38
    
Okay, rather than "hacker sniffing the line", substitute "admin looking at what gets stored". Same issue. –  Jay Jun 9 at 13:12
1  
@Jay I am really having hard time trying to understand your point here, and I can't help but think you're talking about different question. Logging in as the user is out of scope of our discussion - admin already has full access to database, he can simply change the hash in db to HIS pwd, log in and then change the hash back. We're discussing here if he can learn what plaintext password you're typing in. Client-side hashing solves that: if the password is hashed at client's side - malicious admin can see just hashes, never plaintext. This is my answer to original question. –  Agent_L Jun 9 at 13:58
1  
@Agent_L: Problem is, even if someone doesn't have enough access to change the hash, but can somehow view it, they can still send that and be in. The hash ends up with most of the weaknesses of a plaintext password (with the main exception of its not being useful on third-party sites). –  cHao Jun 9 at 14:29

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.