I'm developing a web application with a strong focus on security. What measures can be taken to prevent those who work on the application (programmers, DBAs, quality assurance staff) from capturing user entered values that should be well-protected, such as passwords, social security numbers, and so forth?
-
3I would suggest that you post the question in: security.stackexchange.com/?as=1– NoChanceCommented Jan 29, 2012 at 2:33
-
"Prevent" is a very strong word. You can't prevent bad actors from doing bad things. What you can do is learn and apply fundamental security principles like "least privilege," "separation of duties" and "implicit deny," architect things in secure ways, and hire people that you can trust. Have workable plans in place to mitigate the damage when the inevitable eventually occurs.– Robert HarveyCommented May 15, 2017 at 20:46
-
The technical terms for the technologies that you need: hashing and encryption.– Robert HarveyCommented May 15, 2017 at 20:48
Add a comment
|
2 Answers
This is quite simple. Banks do it all the time.
You have three groups of people involved. These are security groups. With distinct authorizations.
Developers cannot assign security authorizations and cannot see production data.
Operators cannot assign security authorizations and cannot create software.
Security folks who set the authorizations and can neither create software nor operate the software.
The developers create software. The operators install it and operate it. The security folks assure that the two groups are kept separated.
-
8OK, but a developer could still add something into the system that emails production data to his/her private account; or writes production data to some server where he/she will pick it up. I think the only way around this is with a rigorous code-review regime. Commented Jan 29, 2012 at 2:52
-
3There is always that level of trust that is given to employees. Someone has to have the keys to the palace, and if you can't trust that they understand the power that is given to them, then maybe we shouldn't be giving those keys to that person in the first place.– ChrisCommented Jan 29, 2012 at 4:16
-
1Yes, but having keys that require more than one person (like code review regime) means that you need two to go "astray" before you are compromised and that is less likely than "just one" employee going astray and abusing the key given to them. It's all a matter of balancing trust and the consequences of that trust being abused. And don't forget that people and circumstances change. A person trustwhorthy when the keys are given can have things happen in life by which (s)he becomes less trustworthy... Commented Jan 29, 2012 at 10:28
-
1@EmmadKareem: Correct. Security person sets and resets groups and passwords, but can't see data. Only operators can see real data. Think of data like actual money handled by actual tellers. Programmers don't touch the money; only tellers to. Similarly, security people don't touch money; only tellers touch money.– S.LottCommented Jan 29, 2012 at 12:59
-
1@EmmadKareem: DBA's are not developers. There are two groups: security and data. Data DBA's are a special part of "operations". They should not have authorization to change security; they cannot write code; they will see data, however, and must be treated like operators, not developers.– S.LottCommented Jan 29, 2012 at 15:45
The programmers don't have access to the production servers. But someone has to have access. There's no way around it. And there's always a chance that someone may go insane and abuse their access.
Data that is hashed/salted is theoretically secure even from the people who have full access to view it. But most data is not appropriate for hashing.
answered Jan 29, 2012 at 3:10
