In this post, I will share my experience with one of the easy-to-use analytics library Flurry for your iPhone app. They claim in the documentation that the integration can be done in 5 min and I found it to be true to the certain extent. Flurry Analytics provides an incredible amount of actionable intelligence into how and where people are using your app. You can quickly identify your most engaged and valuable users by grouping them on key characteristics such as demographics, location, language preference, and usage of select features in your app. The Flurry iOS Analytics Agent allows you to track the usage and behavior of your iOS application on users’ phones for viewing in the Flurry Analytics system. Continue reading
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 UsingMiles.com 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.
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.
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.
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