Designing my app with security in mind

As I wrote about on this blog previously, I am working on an app for iPad.  It has nothing whatsoever to do with security but instead blends three of my interests: travel, writing and technology (you’re all going to download my app, right?  It uses a freemium model).

Because of the way that Apple has set things up, they take care of a lot of the security.  For example, they handle all of the financial transactions for app purchases so I don’t have to.  I’m pretty thankful for that because I wouldn’t want to be the one to do all of that stuff.

I outsourced the development and I had a call with them and I had one specific requirement.  I have a web backend where I can view statistics about in-app purchases, and I want to be able to load additional content so that the app can update.  To do this, my team is building me a web portal.  I asked them “How do you store the username and password in the database on the backend?”

Their reply: In clear text.

I said “No, you can’t do it that way.  You have to encrypt the password using a password hash.  Use SHA-256 (or some other algorithm, I forget what I said).”  I explained that if I forget my password, it should be irrecoverable for me unless I reset it.”

Even though I don’t think any hacker would try to hack my system (there’s nothing of value), I still insisted on encrypting the password with salts.  That way, even if they do an SQL-injection attack and leak my username and password, it’ll be reasonably protected.

There are lots of other things I can have them do like ensure that the page is accessed over https, and make it resistant to SQL-injection (such as validating the input or restricting the number of characters to 24).  But the point is that most programmers are not security experts.  I’m not a security expert either (I know spam) but at least I know some of the basics. 

I’m probably not a target, but I’m still not going to take any chances.  As a security writer, I should be leading by example.