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.
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:
It's probably more common than we think.
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.
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???."
- 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.
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.
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.
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.
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.
If i were customer of your bank i would withdraw all my money & ask to close my accounts.
