How to secure password from developers

Hello,
I am looking for a password protection method in .net for connecting SQL server.
I have a requirement is to secure passwords from developers.
I know most of people will suggest me to use config file store password and some people say use windows authentication.

But my requirement is quite different, I don’t want to reveal password to developers. If I use it in config file the password will be known to developers. How to deny access to config file for developers and give to access to visual studio to that config file?

If I use Windows authentication there is risk of connecting directly to the database server by installing management studio or some other third party tools. Is there any way that will make windows authentication will work only if access from code?
Please help me.

You can use the config file and still protect its contents. Follow the CodeBank link in my signature below and check out my thread on Protected Configuration. You may then want to read more about it on MSDN and elsewhere.

Quote:

---

Originally Posted by jmcilhinney

You can use the config file and still protect its contents. Follow the CodeBank link in my signature below and check out my thread on Protected Configuration. You may then want to read more about it on MSDN and elsewhere.

---

However developers can decrypt it and have the password right ? I am looking for method where for developers also it is difficult to get password.

To be honest, this doesn't make a lot of sense. The password is not what you are ultimately protecting, but the underlying data. Even if, for example, they don't have the read/write password, but they have read/write access, then no one cares about the password.

At some point, you have to give someone the password. The only thing I can think of is that you want to prevent developers from passing that password onto someone else, who shouldn't have the password. At which point, I think you have bigger problems.

What is the reason for this? Maybe there's something else that can be done.

Quote:

---

Originally Posted by SJWhiteley

What is the reason for this? Maybe there's something else that can be done.

---

I am storing details of customers in database. I am trying to secure that data by protecting password so that I can say to my customers that your data is 100% secure. There is least chance of accessing by read/write permission. The most possible chane is by accessing server from outside only. For that they need password. Can I know that "something" that can be done ?

Quote:

---

Originally Posted by IT researcher

However developers can decrypt it and have the password right ? I am looking for method where for developers also it is difficult to get password.

---

If anyone could simply decrypt data that you encrypted then there'd be no point to encryption in the first place.

We had only the lead developer encrypt the actual production password so that none of the other developers ever saw that password. The password was changed on a regular basis also.

If you don't trust your developers, it's already game over.

They don't need the raw password to steal data. Once they have the ability to connect, they have the keys to the kingdom. All they have to do is write a sneaky bit of code that stashes data in a log file somewhere. Are you code reviewing every file they submit? Are you auditing every lone of code? No? Then for all you know they're writing code that emails them a daily summary of sensitive information. Or uploading it to an FTP server somewhere. Or encoding it inside "crash reports". Or, they can just sit in the debugger and write code that does SELECT * FROM CUSTOMERS and dump that to a file on their development machine. Game over.

The only solution I can think of is to /not let them touch the database at all/. Write a web service yourself through which the application accesses the database. Give the developers user-based names and passwords and have the web service audit everything they do so you can cut them off the moment they do something shady.

But then you have a bigger problem. How do you know you can trust yourself?

Not to production they don't, well only a select few had prod access. For dev, QA and UAT all data had to be scrubed so that no identifying data was left in the database.

I agree with Gary - they should only touch a database that has been de-personalized.

Quote:

---

Originally Posted by GaryMazzone

Not to production they don't, well only a select few had prod access. For dev, QA and UAT all data had to be scrubed so that no identifying data was left in the database.

---

Ah. Forgot about that. This is actually a clever solution for OP.

IT Researcher:

Have two databases. One is the customer-facing database, and only you know the credentials to connect to it. It's your job to put those credentials in the program before deployment. Developers aren't allowed to do anything with this database. (Maybe if you're looking over their shoulder. You get the picture.)

One is the 'developer' database. It's got the same schema, and you fill it with test data that's definitely not customer data. Developers can have the password to this one because there's nothing dangerous there.

I actually have scripts I've written that do the "depersonalize". Change StudentName to be "STUDENT NAME: "+Cast(StuId as varchar(100)), for instance.

Get rid of addresses - parent names.

It can be more than that of course base on what the data represents. I have had to change SSN, birthdates, Credit card numbers, addresses, names if it is HIPA data there is even more.

Quote:

---

Originally Posted by IT researcher

...I can say to my customers that your data is 100% secure.

---

This is something only a used car salesman could say. As long as the data is on a computer, it will never be 100% secure. You can only make it as secure as possible.

Quote:

---

Originally Posted by GaryMazzone

Not to production they don't, well only a select few had prod access. For dev, QA and UAT all data had to be scrubed so that no identifying data was left in the database.

---

Ah, that makes sense. However, how is a dev supposed to work on a database where you are not dealing with 'real' data? I've never been in a situation like that. However, is that the situation here?

Quote:

---

Originally Posted by szlamany

I agree with Gary - they should only touch a database that has been de-personalized.

---

But this would mean a replicated - but sanitized - database, wouldn't it? In which case, having the pswd to that db wouldn't matter.

The password for those lower level databases would not be the same as on Production.

Quote:

---

Originally Posted by SJWhiteley

But this would mean a replicated - but sanitized - database, wouldn't it? In which case, having the pswd to that db wouldn't matter.

---

If you want to be able to prop up in front of a client some fact about how the data was 100% guarded then you have to not show that real data to developers.

I've never been in exactly this situation myself. I've always been fully allowed to see data I worked with.

I've had to do demo's and trade shows where the data needed to be depersonalized.

I have been in this position. There was a special area that we allowed only certain developers to see data (after signing confidentiality paperwork) to work on production data issues (only very senior developers). This database contained financial data and that is under very tight control.

When I did contract work at Anthem BC/BS they physically split development and production into two different buildings.

You rarely walked into the production IT area - I think my badge probably wasn't even permitted through security.

Quote:

---

Originally Posted by SJWhiteley

Ah, that makes sense. However, how is a dev supposed to work on a database where you are not dealing with 'real' data?

---

This idea comes up a lot in terms of unit testing. The philosophy is the "If it looks like a duck, walks like a duck, and quacks like a duck, it's a duck."

There's no difference between a patient record for a real person and a patient record for a fictional person with test values. If I rename "Marsha Smith" to "Female Patient1", and replace her SSN with something like "111-111-1111", and that exposes a bug in my system, something's seriously wrong. It's just data. Obviously, you want your test data to be very similar to real data. It won't do to make the SSNs in test "3" or some other non-real format. But test data's also good for testing extreme cases, like the name "�� ��", which is legal in some jurisidictions and I guarantee you won't work in 99% of data entry systems without losing data. It certainly doesn't work on this forum. But what's nice about that is you get to make a row with that name in test data to make sure it works without waiting 15 years for some unlucky child-of-a-Millenial to cause a major billing glitch when the insurance company rejects claims for the name "? ?".

So it's "real" data in that it's the same database schema and it's a bunch of rows with legal values for that schema. But it's "safe" data in that it's not based on real customer data, but instead represents fictional customers except for rare coincidences. And if "Joe Sixpack"'s records work in test, it's hard to imagine why a 'more real' record like "Scott Hanselman" won't work.

Developers are the people that create the app. Do they need access to the production server? I think not, so give them a connection string that points to a quality or development server and then change it for the production version.

Where I work, it sort of depends... for the most part, we use a demo database for our development. The Products group releases a new version when a new version of the software comes out. That's usually what we start with as a base when working on a customization for a client. If at all possible, that's all we use. Fake data with real-world configurations. Sometimes thought, you get to a point where using client data is unavoidable. A couple rules we play by - 1) CC numbers are NEVER, EVER stored in the system. They get stored externally in a vault, and all that gets processed on our end is a token. SSNs, should they exist are normally encrypted anyways, but most of the time we'll clean them from any development database, even if they are sample SSNs. As a matter of practice, all portable systems used (and since all of us developers work from home, and/or travel to clients, that includes our laptops) must have all hard drives encrypted. Often we have client-specific or client-sensitive data more than just data, of their contacts, but also documents and other IP and other things, so everything gets encrypted.

Depending on the setup with the client, they will either use Windows authentication, or SQL Authentication. In either case, if we are working directly with a client's system, they control who does and doesn't have access... so only the developer assigned to that project have access. For cases where we are hosting their data... well... that's stored in our data centers where we don't have access, and have to actually submit tickets/jobs in order to do something as simple as a select for a record.

During development, we may or may not have access to their data, and quite honestly, most of us would rather not have their data in any form if we can help it.

At the developer level, the security isn't all that tight - there's only 5 of us that deal with client data anyways - it's more of a concern about the client data getting out into the wild that we're concerned about.

-tg

Quote:

---

Originally Posted by techgnome

As a matter of practice, all portable systems used (and since all of us developers work from home, and/or travel to clients, that includes our laptops) must have all hard drives encrypted.

---

TG,
Are you using something like TrueCrypt?

What kind of performance hit does that have?

Do you need to enter a master key on each wake from suspend or just hard boots?

Not sure... I think it's bitlocker... it's controlled by IT. The only performance hit I've seen is for the first 7 hours after it was activated as it encrypted 1.25 terrabytes of data (across two drives).
After that, it's all tied to my network/windows login, so I login once... Security has the screen saver locked so that it requires login after being dismissed. So... yes, I have to enter my pwd after a sleep, hibernate warm or cold boot...

-tg