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?

  • 53
    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, 2015 at 9:17
  • 5
    @paj28 That's one reason it's important. There are others.
    – cpast
    Jun 7, 2015 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. Jun 7, 2015 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. Jun 7, 2015 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.
    – E.P.
    Jun 8, 2015 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:


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

  • 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, 2015 at 16:47
  • 6
    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, 2015 at 18:26
  • 6
    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, 2015 at 19:58
  • 5
    @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.
    – user428517
    Jun 8, 2015 at 21:13
  • 2
    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, 2015 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.

  • 3
    +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. Jun 7, 2015 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.
    – AKS
    Jun 7, 2015 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 avoid transmitting the passphrase anywhere, including email (not even to you)?
  • 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.

  • 5
    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. Jun 8, 2015 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, 2015 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. Jun 9, 2015 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, 2015 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, 2015 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.


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.

  • @cHao: this was discussed in the question security.stackexchange.com/questions/23006/… and the OP came to the conclusion that the best way to do things was to hash on both the client side and at the server. The server-side hash fixes the password replay problem you mention, and the client-side hash prevents the web site from determining the type of password types the user uses (similar user passwords between sites and/or between password changes). Jun 2, 2016 at 11:50
  • @MarkRipley: Sounds like a good idea. Unfortunately i don't remember exactly what comment you're replying to, as it doesn't seem to exist anymore. :P But looking at the answer, i can reimagine what i'd have said...
    – cHao
    Jun 8, 2016 at 22:26
  • @cHao AFAIK you side-tracked (or got side-tracked) into completely different issue of a replay attack, just like the linked answer.
    – Agent_L
    Jun 9, 2016 at 11:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .