Best practices for storing passwords in Windows Azure
For those who know, what advice do you have for storing passwords in a Windows Azure config file (accessed via RoleManager)? It is important to:
1) Developers should be able to connect to all production databases when testing in their local field, which means using the same config file,
2) As developers need the same config file (or very similar) as the one deployed, passwords should not be legible.
I understand that even if the passwords in the config were not legible, developers can still debug / watch to grab the connection strings, and while not desirable, it is at least acceptable. What is inappropriate is people who can read these files and grab connection strings (or other locations that require passwords).
Top recommendations?
Thank,
Aaron
source to share
Hum, developers shouldn't have access to production databases in the first place. It is inherently unsafe, whether on blue or elsewhere. Performing live debugging on a production database is risky business as a simple mistake will likely crash your entire production. Instead, I propose to duplicate production data (ultimately as an overnight process) and let the developers work against the unsupported copy.
source to share
I think this can be partially solved with some sort of credential storage service. I mean some kind of service that doesn't need passwords but only allows access for SSPI authenticated computers and users who are whitelisted. This service can be a simple WebAPI hosted under an SSLed server with simple principles: 0) Protected items are in the form of an IP whitelisted ACL, or with a computer-based name, or a named resource-based certificate, or mixed. 1) all changes to the saved data are made only via RDP access or SSH to the server hosting this service. 2) access to protected parts of information is carried out only through SSL, and this API is read-only.3) the client must first confirm their own permissions and get a temporary token with an api call like https://s.product.com/ 3) the client must provide a certificate and the machine id must match the logical whitelist data for the resource on every call. 4) the data request looks like this: Url: https://s.product.com/resource-name Header: X-Ticket: value obtained in step 3 before it expires, Certificate: same certificate as for step 3.
So, instead of a username and password, one can store an alias for such a protected resource in the connection string, and in the code, this alias is replaced by the real username-password obtained from step 4 in the Sql connection factory. The alias can be specified as a username in a special format such as obscured@s.product.com / product1 / dev / resource-name
Dev and prod instances can have different credential aliases like product1.dev/resource1 and product1 / staging / resource1, etc.
So, only by debugging the prod server, sniffing its traffic, or injecting registration code - emailing at compile time, can you find out the production credentials for the real protected resource.
source to share