53

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?

poush
  • 635
  • 1
  • 6
  • 5
  • 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 07 '15 at 09:17
  • 5
    @paj28 That's *one reason* it's important. There are others. – cpast Jun 07 '15 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 07 '15 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 07 '15 at 20:47
  • 1
    Why isn't there a standardized way to do public key authentication yet? (Have the browser generate a key pair and send only the public key to the server, then save the private key locally, optionally with a password) – user253751 Jun 08 '15 at 05:12
  • 1
    Unless you can fully examine site hardware and software at the times you enter your password, you can't be "sure". – user2338816 Jun 08 '15 at 06:37
  • 2
    Don't forget that this isn't *only* about passwords - one of the reasons I hate "password reset questions" is that you're more or less forced to use the same ones on all the web sites (that have the same questions - very common). Of course, passwords are the thing that's most abused *automatically*, but there's other information that can be also used against you (like "last 4 numbers of your credit card" etc.) - each of them innocuous on its own, but together... And I'd be more warry of naive developers, rather than outright malicious. At least as long as you don't visit many `.ru` webs :D – Luaan Jun 08 '15 at 07:12
  • You never know it. I myself created an in-house system that store password every time a user authenticate into the system. It works well for a while until I feel lazy and remove it from the system. – vasin1987 Jun 08 '15 at 11:40
  • 1
    @Luaan has a really good point - this is reason I use bogus answers to those questions even on the most important sites (anything financial)... I can always go to the bank if absolutely necessary to prove my identity. – user1801810 Jun 08 '15 at 13:46
  • 2
    @user1801810 I use long random strings as the answers, and store them in a relatively safe location. If I lose both the safe location, and the password, well - yeah, there's more direct ways to get verified. It's just yet another thing to be careful about :( And they call it *improving* security... – Luaan Jun 08 '15 at 13:59
  • 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**](http://plaintextoffenders.com/) then it's a big red flag to be careful with what you give them. – E.P. Jun 08 '15 at 14:02
  • @StephanBranczyk I want to add that having worked for several banking institutions in their different "security" departements, you definitely do well not trusting them in keeping your password in a safe, non-reversible, encrypted manner. – ereOn Jun 08 '15 at 18:52
  • @immibis TLS allows for client certificates to be provided to the server which can be used for authentication purposes, but generation is expensive (both in terms of time and entropy), they generally are a pain to move across devices, and the UI is normally inconsistent across implementations (and sometimes changes between versions). Barring website-imposed limitations like maximum password length (which there should be no need for if you do proper password hashing, for example) passwords can be made arbitrarily complex. TLS client certificates also present some practical problems in use. – user Jun 09 '15 at 11:10
  • 1
    Even if you can trust them perfectly to behave ethically, you can't trust them to never make mistakes. Everybody makes mistakes, and somebody could make one of their mistakes when coding how your password is stored. – Jon Hanna Jun 09 '15 at 15:17
  • "Code reviews".... – Petah Jun 10 '15 at 09:52
  • You can't, I've websites that I coded even before I got into the university and yes they still store plain-text passwords.. :/ Developers are lazy, if the framework doesn't support it natively, there is a high risk they didn't implement hashing. Use Password Managers! – EralpB Jan 23 '17 at 14:09

5 Answers5

80

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

Community
  • 1
AviD
  • 72,138
  • 22
  • 136
  • 218
  • 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 08 '15 at 16:47
  • Rather than password **managers** I'd recommend a password **generator**. It will create unique passwords from hashed website address + your master password. This will not only save you from remembering passwords, but also from making them up as well! – Agent_L Jun 08 '15 at 17:18
  • 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 08 '15 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 08 '15 at 19:58
  • @PwdRsch As everything, it's a matter of security vs usability and as every time it's a matter of choosing right tool for a given task. Sure, for main mailbox and bank there are unique passwords that should not be stored anywhere but remembered. But most of us have dozens of accounts whose security means next to nothing. Generators are perfect for that, as drawbacks you've just described never materialize. – Agent_L Jun 08 '15 at 20:26
  • 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 08 '15 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 08 '15 at 21:24
  • 1
    @Mikkel 16 characters? That's grade school ;-) If you don't need to remember it anyway, crank it up! 26 chars, 32, easy... (Though it is arguable how much additional benefit you'd get after e.g. 26 chars...) – AviD Jun 09 '15 at 06:51
  • 1
    @Agent_L as sgroves mentioned, all decent password managers include password generation (that is part of managing, its not just "remembering"). I wasn't explicit, but that is always assumed when we talk about password managers. – AviD Jun 09 '15 at 06:52
  • @sgroves, AviD, Mikkel - none of you have addressed my main point: Important passwords are too important to save in a manager. Trivial passwords are too trivial to save in a manager. That's the point: I don't care if my Stack password was compromised - there is too little I can lose to care about that. I don't use managers to save my workstation password - it's too important to be saved anywhere (plus, I can't use a manager for Windows login). Anyway, this discussion is grossly offtopic as even the answer is not on topic. – Agent_L Jun 09 '15 at 09:48
  • 2
    @Agent_L but I have addressed that. Important passwords need to be strong - really strong, too strong to remember. On the other hand, there ARE situations where you do need to actually remember the password - and that is where passphrases come in, as I did mention in my answer. – AviD Jun 09 '15 at 10:39
  • "But you're asking the wrong question here." Nope, you're answering the wrong question. The first and second paragraph are ok, the rest is just bloating it. – Christian Strempfer Jun 09 '15 at 15:32
  • 1
    @ChristianStrempfer why do you think it's the wrong question? The OP was clear that he is worried about the developers using his password to access his email account. I clarified why "how to prevent that developers record user passwords" is the wrong solution, and besides the point. It was clear that this is a case of XY problem; I focused him on the root cause and pointed him at actual solutions for his real problem. – AviD Jun 09 '15 at 15:37
  • @agent_l what passwords are too important to save in a manager? maybe something for work, but you could use a separate account for that. i will happily store all passwords in a manager, though ... it's all stored locally. – user428517 Jun 09 '15 at 15:43
  • @AviD: It isn't clearly a XY problem to me. The OP is aware that knowing the plain password, could be used to "hack" another site. It's a short to-the-point question. – Christian Strempfer Jun 09 '15 at 15:48
  • 1
    @AviD: Don't get me wrong. It's not a problem you're mentioning dangers of password reuse, but it makes up 90% of the answers height on screen, while it should only be a side note. – Christian Strempfer Jun 09 '15 at 15:55
  • @ChristianStrempfer the OP is basing his risk assessment of the "unethical developer not hashing the password" threat, on the assumption of password reuse. To me, this seemed to be the core of it, hence why I said it is an XY problem, IMO. That is why I focused most of the answer on responding to the password reuse issue. – AviD Jun 09 '15 at 16:05
12

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.

Grizzled
  • 247
  • 1
  • 4
  • 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. – Steve Jessop Jun 07 '15 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 07 '15 at 13:04
5

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.

bignose
  • 548
  • 4
  • 7
fotijr
  • 151
  • 3
  • 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. – The Spooniest Jun 08 '15 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 08 '15 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 09 '15 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 09 '15 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 09 '15 at 14:57
4

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.

Andrew Smith
  • 141
  • 2
2

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.

Community
  • 1
Agent_L
  • 1,921
  • 14
  • 13
  • @cHao: this was discussed in the question http://security.stackexchange.com/questions/23006/client-side-password-hashing 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). – Mark Ripley Jun 02 '16 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 08 '16 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 09 '16 at 11:35