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.
Write a short, clear and jargon-free formal letter stating your concerns and concluding that in your professional opinion, it should be rectified. Address it to someone reasonably high up in the customer.
If they then choose to ignore your advice, that's their prerogative.
(Keep a copy of the letter yourself, too.)
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.
If you can, a live demonstration works great. Ask the user to create an account with a password (not the password they normally use). Go into the database and retrieve, and explain that anyone who has access to your database (either by permission, or via a security breach) can simply go ahead and do this.
The best reason to never keep password in plain text is actually a legal one.
There are laws, such as the Data Protection Act in the UK, which state that reasonable efforts must be made to keep sensitive data secure. Storing passwords in plain-text will clearly violate this, and in turn potentially null any indemnity insurance you have in the event of a breach of security. This could leave you open to a large liability suit if you don't take this simple measure.
When it comes to business men, you always have to talk in terms of their pockets, and stating that an hours work to hash the passwords, and change the login will cost them a tiny amount compared to the potential cost if something went badly wrong.
It would also be worth noting, that if someone has designed a system as fundamentally flawed as this, the likely hood of there being an error which can expose sensitive data like this is exponentially higher.
On top of this, as others stated, a live demonstration is good. take a random staff members password out of the database, and try it on their other systems, you won't have to try many before your in.
Never store a password in plaintext.
I would recommend to read those questions:
If your customer isn't interested in details - just implement it. (Also provide a proper password recovery procedure). It's not really a big deal for you as a programmer but really improves the security & quality of your product.
If he wants to know what you intend to change - explain it to him. Tell him about the security issues and he will understand. Also a live example really helps to open customer eyes: Simply retreive his password from their old system and show him how easy it would be for everyone.
I've always done it that way: If I feel it's important to have a security feature in one of my products - I've always included it. It adds a big plus to the quality of your products and gives you many "woah you thought of everything" moments.
Bastanneu, do you know the English expression "Cover your a**"? Imagine this scenario:
I recommend you make your concerns known upfront. And keep proof (signed letter, etc.).
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.
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.
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!
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.
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.
