3

Why is it so important not to save passwords in plaintext? I think it is the same issue like authorizing a user on a RESTful webservice, where most developers claim: "Don't send your security token inside the URL". If I'm a hacker and having access to database, it's unimportant if the password is secure or not, because a password can be changed (factor: human), but not my house number, etc.

The same in my REST example: If I have the possibility to grab the network traffic, it should be unimportant if the Authorization token is placed inside the URL or the POST/PUT header.

Why shouldn't I store passwords in plaintext? I saw many people facepalming, but nobody are fit enough to give me a good answer.

Improve this question
1
  • 5
    You are mixing password storage and password transport. Also, there is really a huge amount of information out there about this topic, like this. I suggest that you first to you own research and then you come back asking with a more specific questions, i.e. which kinds of explanations you don't understand or which don't apply in your specific (unknown) case.
    – Steffen Ullrich
    Apr 15, 2016 at 5:41

4 Answers 4

Reset to default
8

To make it simple, if passwords are in plain text, the security would be compromised by anyone having a glance at it.

Now, you need to remember that website log-in isn't the only access to a database. An attacker might be able to get some information from your database in various ways.

First you need to know that it happens. And a hacker typically won't leave a note saying "hey there, I was here, thanks for the data!". So unless you get to know about it, you can't change your password.

Now let's say that there are more users on your system/website. If you get to know about it, you need to inform all the others. How long would it last between the breach, you getting to know about it, you informing your users, covering the hole, and everyone having changed their passwords?

And if your system is open to the public, you can't rely on users not reusing the same passwords. So not only your lack of security compromised their account on your system, they may compromise their other accounts elsewhere.

Also, having passwords saved in plain text, means you know them. And as a user, I don't see any reason why you should know what my password is.

Improve this answer
5

Why should I don't store passwords in plaintext?

There are 2 main reasons:

  1. If a database dump is obtained, attackers can simply login with the plain-text password in the dump. If the passwords were hashed, the password would first need to be brute-forced.

  2. Lots of users reuse passwords, as bad an idea as it is, so your security failure could compromise other systems too.

If I'm a hacker and having access to database, it's unimportant, if the password is secure or not, because a password can be changed

That's only if you get write-access to the database. If you have obtained read-only access, or acquired a backup of the database, you would be able to login with the existing password, but not edit the live database. If the password were properly hashed and salted, you would have to brute-force it first, which if unique and well-secured would be infeasible.

The same in my REST example: If I have the possibility, to grap the network traffic, it should be unimportant, of the Authorization token is placed inside the URL or the POST/PUT header.

It's not the transmission that's the problem, it's the inadvertent plain-text storage that's the problem (not unlike storing a password in plain-text). URL's are commonly logged to various log files. These log files are not always well-secured, and at best, doing this increases the places an attacker could obtain the token. The fewer places a secret is stored, the better.

Improve this answer
2
  • >That's only if you get write-access to the database. Well, I meant with "change password", that an hacked user can change his password (create a new one), but I can change his zip code or house number.
    – user3417078
    Apr 15, 2016 at 5:46
  • @techraf Yeah, it's somewhat of a tangent, I put it as a separate point at the bottom, with some explanation of how the issue is similar.
    – Alexander O'Mara
    Apr 15, 2016 at 6:08
3

There's another aspect to this discussion beyond the technical: if it is your design to not secure passwords, then you, as the service operator, are responsible and liable for them. Passwords are security measure for individuals. They aren't the property of the service. If passwords are properly secured (hashed, etc.), then the service operator has done its due diligence and is only liable for protecting the access to the hashes.

For instance, if someone's account is accessed without authorization, the user can simply blame the service provider because the it is known provider knows all the credentials. And yes, this depends on this fact being known, which should be assumed (security should never depend on ignorance of design).

Improve this answer
2

There is a slew of reasons you shouldn't plaintext store passwords. I'll go through some of them (since realistically you should only need ONE reason not to do it - it's not hard)

  1. travel - at some point your password has to be read from the database and that requires it to actually GO somewhere, having the passwords not in plaintext grants another level of privacy, let's assume you feel the same way about encryption as you do password storage and your sites internal communications are unencrypted - plaintext storing passwords provides an attacker with... well... the passwords!!

  2. You say that ' If I'm a hacker and having access to database, it's unimportant, if the password is secure or not, because a password can be changed' that just isn't true, access doesn't necessarily mean write access, i.e. if you do a dump then you can only read and a plaintext stored password can be read quite easily.

  3. a red-flag system: If your hypothetical hacker can change passwords as you say then your user wouldn't be able to log in and flag this to you, so you give them a password reset, let's say your hacker does his naughtiness again and your user flags it again - you know you have a problem. It's not ideal but what does storing your passwords in plaintext give you?

  4. end-users are famously rubbish at security, they probably use that password on other sites/applications. Why would you want to compromise ALL of their platforms?

  5. Possibly the most basic reason - IT ISN'T YOURS TO SEE

Improve this answer

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