Once upon a time, I worked for an organization who had web-based everything: timesheets, expense reports, and even various HR behemoths. One of the interesting things was that when I arrived, the logins were a mismash of various combinations of your employee id and social security number.
Yes, you read that correctly, our social security number.
During my tenure there, I saw the transition occur from user empId/full SSN to using empId/last four digits of SSN. Both solutions were wrong for a multitude of reasons, but let me address the big ones here:
- First, it's unchangable by the user. Once I know your information, your account is compromised. Period.
- Next, a user accounts can't be created until they've been through the HR process. For some this was same day, for others it was a week. In the meantime, they would have to log their hours on paper or use someone elses' account (see above point).
- Next, it allowed developers to have inappropriate access to individual's accounts since we had access to everything.
- Finally, it was a frickin' Social Security Number! For any organization concerned about security, this smacks of negligence. I laughed when the security office sent out a newsletter about stopping identity theft and the first rule was “Don't use your SSN as a password.”
The solution to this horrible problem was simple. I worked with one of the IT crew to use the LDAP server which was already in place. Yes, it was available all along. We converted a single application to use this method – tweaking the login page – and deployed it along side the old version. This allowed a user to authenticate using their email username and password and was otherwise completely transparent to the user. We would still get the benefit of a single set of credentials but all of the bad points above were resolved.
The success of this demo? Technically, it went flawlessly, it was completely transparent other than the url. Politically, it was a failure. The Development Manager stated that “security is irrelevant” and proceeded to kill off the project and disallow the IT and Dev groups from working together any more.
Fast forward a few months and the DevManager began to realize that as his group moved on, it was possible that sensitive data was also walking out the door. At that point, he created a Master Plan(tm)… to convert to using LDAP for everything. That must make me a visionary, right?
Anyway, this solves the day to day problem and having a user change their password problem, but it doesn't solve the “Badguy Insider” problem. We need a different strategy to handle that and it needs to be multi-level.
- First, find out if this sensitive info is really required. For payroll/tax applications, it makes sense and is probably required. To submit your timesheet for the week… unlikely. If the data isn't there, the entire problem goes away.
- Next, ask “what problem is it solving?” If the goal is to have a globally unique identifier, do you need to use SSN? Would company-provided email address, employee id, or something similar work?
- Next, if it must be there, take steps to limit who has access to the information. If possible, this should be managed at the database level. Have all of your data segmented into a different database. If this isn't an option, go to a restricted table or even a column if you must. If you can lock down what users/scripts can access it, the problem becomes much smaller.
- Next, if you can't do any of the above, you can obfuscate it. Applying a simple MD5 hash can effectively obscure the data from many malicious users while simultaneously providing a high confidence of uniqueness.
- Finally and most importantly, if you must have the data, create some sort of logging/auditing that can be used to track when/if leak occurs. In all of my applications there, I created application-level logging which captured logins, logouts, new data, etc. All sensitive information should have the same – and more! – logging put into place.
So what am I trying to say? It's simple. The data you hold – yours or not – is what allows your business to exist, thrive, or die. If you don't treat it as such, you'll only do one of those three.