Being Non-Relational

When I saw the first version of Majikal, it looked like the biggest challenge of my professional life. It was little better than ancient mainframe model to start with. The only good part was data interchange format (JSON) that made me believe I was looking at 2011 codebase.
MySQL database or any relational database for that matter is a good choice to build enterprise products where the requirement is not so dynamic as it is in the modern days. Whenever there is change in domain model, you need to make a lot of code change to support the backward compatibility. The ORMs present in the market are not really masking the complexity. As you know Database has strong influence on domain model, many domain objects make more complex mapping joins in RDMS and that will make the queries even harder to write. I also had to write lot of boilerplate code to map the JSON APIs to the normalized domain model. What if JSON was our primary model?
I started looking for document based databases. CouchDB was simple keystore, it gives great flexibility on schema design front but leaves a lot on developer to implement the domain model. Cassandra, on the other hand offers huge scalability but schema design was way too difficult. I found mongoDB quite upto the requirements as it was simple to use and can execute similar queries to RDBMs. On one hand it can store JSON natively.

One of the challenges that comes with moving to MongoDB is figuring how to best model your data. While most developers have internalized the rules of thumb for designing schemas for RDBMSs, these rules don’t always apply to MongoDB. The simple fact that documents can represent rich, schema-free data structures means that we have a lot of viable alternatives to the standard, normalized, relational model. Not only that, MongoDB has several unique features, such as atomic updates and indexed array keys, that greatly influence the kinds of schemas that make sense.

The Linkedin.com Password Fiasco – Question not asked

LinkedIn is HackedIn

It’s been a few hours since the news of the Linkedin.com 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 Linkedin.com 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.