current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 10 down vote favorite
2

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?

share|improve this question
3  
I would suggest that you post the question in: security.stackexchange.com/?as=1 –  Emmad Kareem Jan 29 '12 at 2:33

2 Answers 2

up vote 21 down vote accepted

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.

share|improve this answer
8  
OK, 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. –  David Wallace Jan 29 '12 at 2:52
3  
There 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. –  Chris Jan 29 '12 at 4:16
1  
Yes, 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... –  Marjan Venema Jan 29 '12 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.Lott Jan 29 '12 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.Lott Jan 29 '12 at 15:45
up vote 2 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.