tags:

views:

answers:

I understand the mantra of "don't roll your own" when it comes to site security frameworks.

For most cases anyway.

I'm going to be collaborating on a site that integrates text-messaging into the system.

I'd like to use an existing, well-tested security framework to protect the users data, but I need it to also protect a users phone number as well.

I wouldn't want to be the one responsible for a list of users cell phone numbers getting jacked and spammed.

What suggestions can the community offer?

+1 A:

Since you need to be able to retrieve the phone numbers, the only thing you can really do to protect them (beyond the normal things you would do to protecting your db) is encrypt them. This means that you need to:

Make sure the key doesn't leak when you inadvertently leak a database dump.

Note that techniques applied to passwords aren't applicable here. You can store a password salted and hashed (although the value of doing so can be disputed), but that doesn't work for phone numbers.

If someone jacks your server, they can do anything the server can. This must include recovering the phone number, but doesn't include recovering the password if it's hashed well. So the phone number is just a particular case of protecting confidential data.

If phone nos truly are the only sensitive data in the app, then you could look at walling off the part of the app that sends the texts, and asymmetrically encrypting the phone nos. In a different process (or on a different machine) run an app that has the key to decrypt phone nos. This app's interface would have maybe one function taking an encrypted no and the message to send. Keep this app simple, and test and audit the snot out of it. Either hide it from the outside world, or use authentication to prove the request really came from your main app, or both.

Neither the db nor the main part of the app is capable of decrypting phone nos (so for example you can't search on them), but they can encrypt them for addition to the db.

The general technique is called "Privilege separation", the above is just one example.

Note that phone nos would generally need to be padded with random data before encryption (like salting a hashed password). Otherwise it's possible to answer the question "is the encrypted phone number X?", without knowing the private key. That may not be a problem from the POV of spammers stealing your distribution list, but it is a problem from the POV of claiming that your phone numbers are securely stored, since it means a brute force attack becomes feasible: there are only a few billion phone nos, and it may be possible to narrow that down massively for a given user.

[Edit to add: in fact, it occurs to me that under the heading of 'keep the privileged app simple', you might not want to use a framework at all. It sort of depends whether you think you're more or less likely leave bugs in the small amount of code you really need, than the framework authors are to have left bugs in the much larger (but more widely used) amount of code they've written. But that's a huge over-simplification.]