I have been working on the Nouncer authentication API calls the past few days and been struggling to find the right way to balance between features and security. Like most sites, somewhere deep inside Nouncer there is a database table with usernames and passwords. I knew I did not want to store passwords in plain text, nor allow unsecure authentication. As I was working out the details, I started to think about what other pieces of information I want to store which are a security liability if someone broke into the database and stole user records. Nothing really stood out.
Talking to some friends, trying to make sure I got everything covered, someone asked me if I store social security numbers or credit card information. All financial information is handled via a third party system so no issue there. As for social security numbers, “why would I need that?” I asked, and a new idea came to mind. One of the content delivery parameters of the API allows for delayed message delivery. But how about a delay triggered by death? Sounds a little crazy but it is actually doable.
Many sites today provide access to the social security death records database. A simple lookup of the social security number once a month will do the trick. This is pretty simple to execute if you are willing to accept up to 2 years delay in message transmission after you die (the time it usually takes for these databases to update). But then again, 2 years is nothing when you are dead.
For now, the delivery-on-death feature will wait until other more important API calls are implemented. I won’t be surprised if someone reads this post and creates a quick site to do just that. You put an email address, a message, and your social security number and the server will deliver the email once your social shows up as deceased. Without the context of a user record with name and address, it is just a 9 digit number anyone can guess anyway. But context is everything in Nouncer and with that comes the liability of storing social security information.
Back to reality, thinking about storing passwords, I have decided to turn the liability into a design feature, and use OpenID instead. Most sites still have their own username and password system, but allow you to assign an OpenID to an account for an easier login. In an API, this is not really an issue as users are already signing in through another service which has to offer sign-up services. If the user does not already have an OpenID, the service can offer to create one for them using one of the affiliated OpenID programs.
So expect to see a fully integrated OpenID support within the Nouncer API. For now, don’t expect to hear from me when I’m dead.