

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

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?<p>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.<p>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.
======
fhoxh
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...](https://www.owasp.org/index.php/Broken_Authentication_and_Session_Management)

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

[http://blog.moertel.com/articles/2006/12/15/never-store-
pass...](http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-
a-database)

[http://marknelson.us/2011/02/06/gawker-considered-stupid-
cri...](http://marknelson.us/2011/02/06/gawker-considered-stupid-criminally-
stupid/)

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???."

------
kwantam
\- 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.

------
Khao
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.

------
mark-r
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>

------
oogali
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 s __t 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.

------
micks56
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.

------
pbreit
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")?

------
aparadja
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.

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

------
mpunaskar
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.

------
HoyaSaxa
Any chance you are affiliated with Fiserv?

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

~~~
mariuolo
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.

------
shaydoc
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 ?

~~~
polyfractal
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/>

~~~
shaydoc
bcrypt it is...

