The Three Laws of safely storing user passwords

Weakest Link (Pic Source Flickr)


I’m always excited by new startups inventing new ways to disrupt not just established players but routine things we don’t give a second thought. There is suddenly a new way of doing things because someone somewhere was smart enough to invent it! I was quite excited when I heard about Using Miles, a startup which allows us to track our miles and membership points in a single across the board interface. And one of the first things that I always do with a new service is try out the “Forgot my password” option. I wasn’t expecting any surprises from but to my horror they seem to have emailed me the password in plain text! I shudder to think what other private user information they might be inadvertently exposing!


As a founder and startup in its early stages, I empathize with my fellow beings over the pressures of creating something new and taking it to market. However, startup founders have this annoying little habit of cutting corners when they should have known better. And one of those often cut corners is handling user data in a safe and secure manner. It is amazing that when even a simple google search can reveal the top things to be done, startups continue to ignore basic facets of security. This is even more so deplorable when it comes from a startup that has been in TechStars and funded well! Apparently we don’t learn much from history!

I’m writing this post to layout simple steps and process flows that should be followed for managing such things as user email and password. If you’re a CTO/CEO in a startup do make sure that your team is following these as the least necessary to do what is needed. These are not by and far a comprehensive list of items related to user data security, but it should be a good start.

One of the first things to recognize is that users will invariable use weak passwords and they will also reuse their passwords across sites. This often means that if one site or database is compromised, it puts every other site where the user may have an account at risk! This brings us to the first rule “A password stored in secured manner will continue to be secure even if it is exposed in its encrypted or source form”. Thus,

“All passwords must always be stored with a randomly generated salt and hashed using a cipher scheme such as PBKDF2.”

Once you’ve done this you’ve created the first line of defense which will protect in the unlikely event of a hack. Beware of anyone who tries to convince you to use BCrypt or any other scheme! Now that you’ve followed the above, it is important to understand that encryption is not selective. If you’ve already decided that data is worth protecting it is important to be consistent in your approach to it. There is no point in securing it in one place and then flinging it around in emails! This brings us to our second law “The rate at which your security is affected by outside factors is directly proportional to the weakest link your security chain. Thus,

“Never send passwords in plain text either via email/sms or any other mechanism of communication no matter how secure the communication channel may seem to be.”

If your developers are trying to convince you that it’s only a temporary password that they are sending to users, make sure you remember to spank them for being lax with data security!

The last and third law of security is quite simple, “A taunt force exerted on group of hackers will come around to bite you in the ass”. As those in Gawker Media learned this the hard way when they challenged 4chan that ended up compromising all of their sites! If any of your employees have a favorite pastime which involves inviting people to attack your system, you better have an army of security experts at your beck and or call; or make sure that your employees understand security is nothing to be taken lightly or joked about on public forums.

I hope this should provide you with enough knowledge to go and discuss this in detail with your development team. As for UsingMiles, I’m going to give them a pass until they can improve upon basic security.

The Password Fiasco – Question not asked

LinkedIn is HackedIn

It’s been a few hours since the news of the password breach first broke out and later confirmed in company blog. There is even a site where you can check if your password in among those leaked online. And while the dust is still settling down, the question that begs an answer is why were our passwords stored using SHA1 hashes with no salts? This is when SHA1 has been proven to be weak and any reasonable mind would not think of its continued usage. Given that fact that seems to use every other tech out there under the sun including some home grown tech, I’m genuinely surprised why someone who has actually read about Cryptography was asked to design (or redesign) the security architecture of the  networking site. And while it would seem presumptuous to assume that an effort in that  direction was not made, the breach leaves little doubt on the fact that no one really thinks about security before they are faced with a breach (and yes your recent misgivings on privacy don’t help your cause)! Which brings us to the question that no one seems to be asking:

What is being done in the aftermath of breach to ensure that our passwords will remain safe and secure even if a similar breach occurs in future?

The important point to note there is that breaches occur invariably no matter how security conscious you may be. This is because any modern software stack is composed of multitude of technologies, languages and libraries, it’s inevitable that some new vulnerability will be discovered before you’ve had time to fix it. Once we realize this simple fact we can begin to not only create secure systems, we can think about how better to protect user data in case of such a breach. If the response of Linkedin team is to simply use a Salt+Hash with a SHA512 algo, I would not be surprised that they will be faced with similar breach which would expose our passwords yet again. And please don’t go running towards Bcrypt as the De Facto for storing passwords, find someone who knows this shit and build a better infrastructure. As for the rest of us, stop using the same password on every site and account and start using a password manager now.

The language Dilemma!


When my cofounders asked me to chip in a new venture, I was more disappointed than excited to know they are developing the platform on Java/Spring based framework. While there is certainly nothing wrong with it, it reeks of years of following whimsical enterprise standards and bloated code that can kill your libido faster than you can say Java. I knew as a startup in nascent stages we had to be agile enough that even major changes didn’t hinder us with a rigid architecture and configuration changes. The question now was what to pick up as our primary dev language. While answering this question, I listed out all of the parameters which were important to us: Continue reading