These apply in the US:

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

FIMSA: http://en.wikipedia.org/wiki/Federal_Information_Security_Ma...

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

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