I've currently inherited an application at work and to my dismay, I have realized that the user passwords stored in the database are encrypted using an in house encryption function, which also includes the ability to decrypt.
So all someone really needs to do is copy the user table and copy the encryption assembly (anyone with database production access) and then they would have access to 100,000 email addresses and potential passwords for them.
I'm trying to explain to the business why this is not a good idea, but the security concepts seem to go over their head as they are not that technically minded (it's for government). Plus there are actually existing functionality within the application for admin users to retrieve user's passwords in order to log in as them and do stuff (which they have said, they require).
So they don't understand the security implications. And in order to implement a stronger security policy (hashing passwords so they can't be easily retrieved), I have to remove existing functionality for them.
What should I do? I didn't build the password system in the first place, so it's not like I can be blamed if anything does go wrong. On the other hand, I don't feel good about it and I also don't want to have access to 100,000 potential email logons.
Best Answer
Implement the functionality they need in a secure way. Administrators logging in as another user can be implemented without them knowing the user's password. They can log in as themselves, and then have some 'change-identity' function available.
Securing a password database is not a business concern, it is a technical concern. Not doing so is a bug. If the business thinks of security as a functionality tradeoff, security will lose. You should not give them any reason to think of it this way.