The HR department at the company that I am currently working for has requested that I provide a system for storing employee social security numbers in our company database. The reason for this is to streamline payroll completion, as we use in-house software for employee timesheets but have to integrate with third-party software for our actual payroll system. This is a relatively small company (20-30 employees), and we'd only be storing current employees' SSN's (so a breach would only have limited impact), but I would still like to bank on security.
I would like to know if there is any convention out there for storing information as sensitive as social security numbers. I'm not very skilled in encryption, and I understand that there are several encryption techniques that I could resort to, but I was wondering if there was one way in particular that was best suited for this type of situation. Would AES be my best bet?
As for current software, we're running MySQL and our web interface is written in PHP and running on an IIS server.
I didn't see it mentioned anywhere, but is it necessary for this information to be online? If not, then you've secured one major avenue of attack by simply having this info stored in a database on a computer that's not connected to the internet. Or, if you can get away with having it stored on your LAN somewhere (so HR can have access to it, or whatever), as opposed to production servers, that's still a step in the right direction.
You mentioned that you're at a relatively small company, but it seems like an investment in some cheap hardware wouldn't be too difficult a thing to convince the decision makers of, given the benefits of storing this kind of sensitive info offline. And barring a massive hiring spree in the near future, you don't need a server class computer for storing personal info on ~30 employees by any means.
Wherever you store it, I'd still consider some kind of encryption. AES 256 is the standard for secure these days in most applications and is pretty widely supported. It doesn't sound like it's the sort of application to be under any kind of load, so again, there's no harm in going for a larger key size along with the cheap hardware, from the sounds of it.
As far as implementation goes, if you're comfortable with MySQL - stick with that, they've got the tools you need to do what you want: http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html
In the end, security is all about layers, no single solution is going to be the silver bullet, but you can go a long way by adding some pretty simple, common sense security measures.
Edit: after reading what Graeme said, I feel I should add that most security breaches are an inside job - make sure to protect your data at the disk level, through the database, and over the wire.