Storing Password in Databases in plain text vs Cus

Question

I want to call "storing a password in plain text in a Database" a bad pratice... but our customer did this in his Application. They want me to renew that Application.

My point: I want to change this...but since it is not a need for our Customer it is still unclear.

How do you handle such issues regarding security? From my point of view it is difficult to explain such issues to Customers.

Answer 1

This is a situation where you have to phrase things properly. Plaintext passwords is not something you phrase as "bad practice". It's something you phrase as broken, something that simply can not be done. You must make your contract contingent on fixing their password storage, it is not optional. That's not to say you can't have a friendly discussion about why it can't be done, but you must make it clear that you won't do it, no matter what.

Then the question becomes how do you convince the business folks that it is not a valid solution. This should also be fairly easy. Find the decision makers, and bring them to a machine where you have the database query browser open. Type out the query "Select password from credentials where username ='DECISION_MAKERS_USERNAME'", then have the decision maker execute it (be polite and don't watch the screen as they do it) Explain that any employee with database access will be able to do this. Generally I would think that would do the trick, but if you need to do further convincing explain that a large portion of users share passwords across applications, and that any employee would be able to break into things like bank accounts, email accounts, etc with it. If that still isn't enough, explain examples of lawsuits and fines for companies that have done this.

Whatever you do, don't explain the technical details of any of it. Just show the consequences. Don't explain hashes, salts, or use words like "plaintext". Just explain that is it is now, people can see passwords, and that it will be easy to change it so that nobody can see the passwords, but they still would work.

If you can't convince them, don't take the client. And you should probably warn the users of the app that their passwords are not securely stored.

Answer 2

Demonstrations and explanations are most useful, but when you say you are to "renew" the Application, are you working from documentation, a functional or technical specification?

Asking to be involved in finalising these documents and included in their sign-off would be a good idea.

Ultimately, it is a need for the customer, they just don't realise it yet.

Answer 3

You should simply explain to the customer that login is not secure if someone with bad intention has access to the database. If the application it's inside the company, maybe it's not worth to change it. You have to analyse if it's really a value and you can only know it by talking with the customer. Maybe the data is not very confidential and it's not a priority to have a lot of security. All depend of the software goal and where is the database and what the customer want its data secure.

Answer 4

I would explain that what they have done is bad practice and ask them if they would like you to change it. I would advice against doing anything outside the permit of what you were asked to do without consulting them.

Answer 5

From a strictly professional point of view, you have to ask yourself if leaving it as is would pose as a problem later on (do you have a support contract that may be called on in the event of a highjacker stealing a pass from the DB?)

Personally, I do not think it is hard to explain to someone why storing passes un-encrypted is unsafe, however, as Daok pointed, you really needn't worry about passes on system that does not hold private-personal-secret-magical data.

Nowadays it seems so easy to use encryption for this purpose that, depending on the technology you are using, it could mean just the slightest effort in coding and time to get it done.

Cheers mate!

Answer 6

I think "bad practice" is an understatement. "Irresponsible" might be more accurate.

If it's worth to protect it with a password, it's worth doing it properly. Storing passwords in plain text is an embarrassing security breach waiting to happen.

If "security" is anywhere in your customers wishes (which I guess it is, since there are passwords), they've implicitly asked for a decent security system, which includes proper handling of passwords. They may not ask for "passwords being stored securely" (hashed and salted) because they're not the experts; that's what they hired you for.