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.