Banking site stores passwords in plaintext. Coworkers think it's no big deal. | Hacker News Reader

Banking site stores passwords in plaintext. Coworkers think it's no big deal.

23 pointsewald17 comments

At my company, we develop and maintain a home banking website, that deals with millions of dollars, and the passwords are stored in plain-text. I can't convince management it's a bomb waiting to explode, because the "most senior" programmer doesn't think it's a problem, since "nobody will have access to the database." What should I do?

And it gets better, because everyone on the development team has access to the production database. If anyone hacks any computer of the devs, they can obtain the database and steal millions.

The entire security of hundreds of clients is based on the fact that our network can't be hacked, that an evil employee does not exist, and that the website is invulnerable.

View on HN

It is one of your primary duties to safeguard the best interest of your organization. Incontrovertibly, the best interest is not served by storing passwords in plaintext as this can result in grave harm to your organization.

Accordingly, while I would not share any details with the outside world, I would advise you to strongly push the issue internally, from the position of an educator.

Here are four articles that may assist you in composing a stronger series of arguments:

https://www.owasp.org/index.php/Broken_Authentication_and_Se...

http://cwe.mitre.org/data/definitions/256.html

http://blog.moertel.com/articles/2006/12/15/never-store-pass...

http://marknelson.us/2011/02/06/gawker-considered-stupid-cri...

You will want to further notate that the effort of implementing non-plaintext authentication really isn't terribly significant.

What troubles me is this "most senior" programmer of yours. If storing passwords in plaintext is OK with him/her, meaning that he/she has a weak background in security engineering, I can't imagine that there aren't many additional severe security issues (SQL injection, XSS, CSRF, etc...). Most concerning of all though is that this "most senior" programmer seems disinterested in due diligence and is instead actively arguing against widely known best practices.

If, after your strong push, management still is not motivated, personally, I would resign. I would not want to be professionally affiliated with an organization and management that have a materially compromised decision-making process.

At some point in the future, your organization may be compromised, which may lead to people losing their jobs. You will not, in the future, want to be on the receiving end of questions like, "So the web application that you worked on stored passwords in _plaintext_???," "So how exactly was it that you were unable to present a compelling case to do something that is so blatantly obvious???."

- Enumerate the attack vectors that this practice opens, and give examples of companies that have been burned by similar attacks in the past.

- Ask management if they would be willing to inform all their users about their practice of storing their passwords in plaintext.

- There are several court cases in recent history where users have sued service providers for negligence after a data breach occurred. Failing to take even the most basic security measures is a liability and opens the door to successful litigation in the case that you are hacked. Is management aware of this?

- Financial service providers like Visa have security standards that their clients must follow. Even if these do not directly compel your company to action, they serve as an example of "industry best practices".

- I assume you've already confronted the "senior developer" about these issues; is this a complete dead end?

- Pull out the whistle. Talk to journalists in industry magazines about your company's behavior.

- Comedy answer: tell LulzSec and let them drive the point home for you.

I had this happen at my last company too. We had basically no security except great firewalls and servers configured to let no one pass. Then one day, on server who wasn't properly configured got busted and all our source code (it was an asp website so the source code is on the server) was compromised. From there, the attacker tunneled to our databases, since all the databases used the same password and the default user with all privileges. They were only blocked from being accessed from unknown IPs, but once on the inside of our network, it was easy to access.

And I'm sure there are thousand more stories like this that aren't told on the internet because companies are ashamed to admit that they've been hacked.

The best way is to point out real-life bad outcomes. It's a bit difficult because they tend to be hushed over. Here's one example, I'm sure nobody had access to their database either: http://www.bankinfosecurity.asia/articles.php?art_id=2415

I'm fairly certain this is running against Federal Reserve policies (yes, they do IT-related audits from time to time). And if your bank customer is a public company, this runs against Sarbanes-Oxley (protecting revenue chain; separation of development, UAT, and production environments; routine vulnerability assessments; and many more things...)

While you're not the actual bank, your company is probably providing a piece of paper saying they're complying with the requirements the bank has provided (if they indeed have provided them).

So, assuming something evil does happen...

- Customer complains to state consumer agency

- State consumer agency refers to state banking agency

- State banking agency follows up with bank

- $bank says we have "a letter of compliance/best practices/whatever" from $company.

- State banking agency focuses on the information exchanged between $bank and $company, to determine which party was negligent, and maybe even refers case to state attorney general.

- The underwriter of your errors and omissions insurance is now royally pissed, and is also crawling through your e-mails and such to determine how much liability they have based on your policy.

I'm sure I've left out a few things, but basically, this is a st storm waiting to happen. If management doesn't care about losing the entire company, and possibly going to jail, I dunno.

And if you want, replace state consumer agency with FTC, and state banking agency with Federal Reserve.

Show the bosses this chart: http://www.deadondemand.com/products/digitalshredder/

It describes how much money they will personally owe and how much prison time each of them could do when there is a breach.

note: I have no financial interest in the company linked. It is simply the most comprehensive chart I have seen.

It's a bit surprising in this day and age that you would have so much trouble convincing enough folks (at a financial institution nonetheless) that this is a bad practice. Does your organization not have anyone responsible for information security and customer privacy (that's usually a different person from the "most senior programmer")?

Become the evil employee? ;)

Seriously though, I encountered a similar situation in a previous job. It was a media company instead of a bank, so the stakes were not as high. Still, they had user emails and plaintext passwords in the database. I warned the other developers and my manager about it, but they all dismissed the fix as a low priority task.

I spent some time digging through the web app's source code, and found an SQL injection bug. I then demonstrated the exploit to the whole team at a meeting. My next task was to implement the fix.

Your coworkers' attitude gives me the impression that finding an exploitable security hole isn't an enormous task. Sure, a live exploitation demo is a gimmicky internal marketing tactic, but it might work.

Write a letter to the board members of your company explaining the situation clearly in non-technical terms.

Systems can be and will be hacked. Nothing is secure in this world. Redirect them to recent Lulzsec hacks, it might put some light in their heads.

If i were customer of your bank i would withdraw all my money & ask to close my accounts.

Any chance you are affiliated with Fiserv?

Do nothing. This isn't your responsibility, and you're risking your job by going behind the back of the most senior programmer.

Perhaps I've grown cynical, but I second the suggestion to shut your trap.

First of all nobody loves Cassandra, especially because it shows them they were wrong. Moreover, the moment something will happen you might be caught inbetween the shitstorm exactly because you mentioned the possibility and hence becoming suspicious yourself.

what bank do you work for, looney tunes acme bank ? Did your "senior programmer" dude never hear of salt and SHA1-Hash, fairly trivial to do ?

It is amazing that a "senior" guy would resist something as simple as hashing a password.

That said, salting a simple hash is not nearly as effective as people think. Given the computing power of modern GPUs, you should use bcrypt:

http://codahale.com/how-to-safely-store-a-password/

bcrypt it is...

I know of one major core financial provider that doesn't encrypt their home banking passwords either.

It's probably more common than we think.

Reply on news.ycombinator.com