Zero Inverse

Just read this article and it has good pointers for anyone putting passwords on their website.

http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html

In summary, if we’re storing passwords, we’re probably storing those passwords incorrectly. If it isn’t obvious by now, cryptography is hard, and the odds of us getting it right on our own are basically nil. That’s why we should rely on existing frameworks, and the advice of experts like Thomas. What higher praise is there than that of praise from your sworn enemy?

Let’s recap:

1. Do not invent your own “clever” password storage scheme. I know, you’re smart, and you grok this crypto stuff. But through this door lies madness– and abominations like LMHash that have ongoing, worldwide security ramifications we’re still dealing with today. Take advantage of whatever password storage tools your framework provides, as they’re likely to be a heck of a lot better tested and more battle-proven than any crazy scheme you and your team can come up with on your own. Security vulnerabilities, unlike functionality bugs in your application, run deep and silent. They can lay dormant for years.
2. Never store passwords as plaintext. This feels like security 101 and is completely obvious in retrospect. But not everyone knows what you know — just ask Reddit. Store the hashes, never the actual passwords. Educate your fellow developers.
3. Add a long, unique random salt to each password you store. The point of a salt (or nonce, if you prefer) is to make each password unique and long enough that brute force attacks are a waste of time. So, the user’s password, instead of being stored as the hash of “myspace1”, ends up being stored as the hash of 128 characters of random unicode string + “myspace1”. You’re now completely immune to rainbow table attack.
4. Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier than he actually is. But he’s right. MD5 is vulnerable. Why pick anything remotely vulnerable, when you don’t have to? SHA-2 or Bcrypt would be a better choice.

Recently, I attended an interesting event where Ellie Cachette presented her new web project http://endcorpabuse.com

It’s a great way to let people share their bad experiences with companies that abuse their power.  In her example, thousands of people were infected with HIV from infected blood from Bayer, a pharmaceutical company.  Instead of recalling the tainted product, they went ahead and sold it, figuring it would be much cheaper to get sued later.  And it was cheaper.  Meanwhile, the families of infected loved ones had to fight for 10+ years in lawsuits to even (1) find out there were thousands of infected people, and (2) to get any recovery.  By then, their loved ones had no doubt suffered.

I’m glad Ellie came up with a great solution.  It’s something I have been wanting to see, ways to use social networks and the Internet to stop all the corporate abuse.  This is not about improving customer service or addressing product problems, like GetSatisfaction helps do.  This gives all of us the power to highlight unethical practices of companies.  Imagine how this could have addressed the isseus with Goldman Sachs, AIG, Citibank, GM, and other companies who take advantage of the average American.

Stop Corporate Abuse!