

Ask HN: Official source stating hash DB password requirement? - laurencei

The government organisation that I work for pays <i>alot</i> of money to a company to supply and host a specific web service.<p>I just discovered (by having to reset my password) that the passwords are not being hashed (because the reset service emailed me my current password in plain text).<p>Does anyone have an authoritive link that I can use in my email to my boss, stating that hashed passwords are basically a "101" of web security? i.e. something that he can use to tell the other company that their service is not good enough
======
byoung2
These apply in the US:

If the government agency takes money online, PCI compliance
([http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...](http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard))

FIMSA:
[http://en.wikipedia.org/wiki/Federal_Information_Security_Ma...](http://en.wikipedia.org/wiki/Federal_Information_Security_Management_Act_of_2002)

FIPS 140-2: <http://en.wikipedia.org/wiki/FIPS_140-2>

------
shanelja
The link at the bottom is the Stack Overflow IT security blog, I will drag out
some direct quotes to help you to summarize, editing slightly to make it more
readable to people not knowledgeable in the industry.

 _The bad thing about such “cleartext” storage of passwords is that it induces
a vulnerability [in a certain type of attack] ... where the attacker could get
... access to the server data. If that data includes the user passwords, then
[they] could use these passwords to sign in as any user and get the [same
computer privileges and accesses as that user]_

In simplistic terms, if an attacker gains access to your database and the
passwords are not hashed (stored in an unreadable by human format), the
attacker has near instant access to any users account within that database and
the application it powers.

 _Also, the passwords themselves can be a prized spoil of war: users are human
beings, they tend to reuse passwords across several systems._

Or, if your users are reusing their work passwords on say, their Paypal or
personal email, the attacker has access to these (assuming he knows their
login / email there too.)

 _We just want [to slow down the attacker]._

If your attacker is looking to only get one users passwords, the odds are
unfortunately that they will manage to break a hash using pre-built lists of
password hashes or using a computer program to recreate the process the server
makes in hashing it, on every possible password (within reason) - hashing the
password will however slow the attacker down (and perhaps stop them entirely)
instead of the instant access they would otherwise have to your users
accounts.

 _A hash function is the right tool for that. In full details, the hashing
process should include a [random key generated just for that user] ... and be
appropriately slow_

Simply put, use a _salt_ with your users password, perhaps by hashing their
username and appending it to the end of their password, to make their hash
unique to them, so pre-built libraries of passwords become unusable, slowing
the attacker down considerably. Use a function which takes a long time to
complete, so not the MD4/5 or Sha family, but something along the lines of the
algorithm Blowfish.

 _Password hashing is damage containment._

Password hashing is the last line of defense once the attacker is already in
your server, but don't assume this makes it useless - the odds are, if your
company isn't bothering to hash their passwords properly, they probably
haven't bothered to properly secure the website or application either.

[1] - [http://security.blogoverflow.com/2011/11/why-passwords-
shoul...](http://security.blogoverflow.com/2011/11/why-passwords-should-be-
hashed/)

