There has been a lot of talk of identity theft, security threats and securing private data lately. You’ve all seen reports of a buggy company websites which exposes private data to the public, phishing scams or an employee using private data for personal use. It makes you think about all of the personal data that you make available each day, whether that be to social media sites, for online purchases or even your phone and utiliy provider. How secure is it?

From a service provider perspective, the minute we store a user’s private data, for example their username and password, we’ve taken on the responsibility of securing that data too. Let’s say a hacker somehow obtains a list of all our usernames and passwords. Either it was an inside job by someone who had access to the database, or the database was accidentally exposed to the public web. It doesn’t matter how. It just happened.

Now as a customer I wouldn’t be happy about my prvate data becoming available. However, I would expect the owner of the application in question to have taken sufficient measures to render it useless to third parties. At the very least, the password is going to be encrypted, right?

RIGHT?????

The answer – from experience – is way too often “unfortunately not”!

Don’t get me wrong, most system designers, developers and project managers are smart people. They think long and hard and often times come up with a reason to avoid taking the standard security measures which everyone sort of knows about.

They are wrong!

How can I be so sure? Because, when it comes to web-app security, cutting corners doesn’t buy you anything. It doesn’t save you coding time (in the long run). It doesn’t give your users a better experience. All it does is weaken the security of your web site, needlessly putting your users, your employer, and yourself at risk.

As the developer, you might think that it’s relatively unimportant if your user’s application password is exposed as plain text. After all, what’s an attacker going to do with, for example, forum credentials? Post angry messages on the user’s behalf? And what about the small business that requires private data from their customers to sign up for a company newsletter? Same thing here. The consequences of exposed data seem small.

But most users tend to re-use the same passwords, probably because they can’t remember the two dozen unique usernames and passwords they’re forced to have. So if you obtain their forum password, it’s likely you also have the password to something a lot more dangerous: online banking, PayPal, etc

So please allow me to state the obvious:

If you are storing plaintext passwords in a database, you are making a mistake!!!

A lot of developers – often times too late – move to hashed passwords. Even this is not enough to thwart a determined attacker. Hashes alone are better than plain text, but barely. Hashing the passwords prevents plaintext exposure, but it also means you’ll be vulnerable to astonishingly effective rainbow table attacks.

The solution here is salted hashes based on computationally expensive(!) hash functions which were designed for password applications. If you do not know what a “salted hash” is or why you should waste precious compute cycles for password storage – you need some help. Hire someone that knows. Otherwise, it’s only a matter of time before you pay for this…

So please let me take this opportunity to ask if you know of (or perhaps work on) any software systems that store passwords plain text in a database. If so, fix your software now:

  • Salt and hash each and every password (use a computationally expensive hashing function such as bcrypt that was designed for password applications)
  • Store the salt and hash – not the password – in your database.
  • Throw the password itself away.
  • Educate your fellow developers! This might feel like “development 101″,but not everyone knows what you know. Really!

You will be glad you did…