I'm using Azure Cloud Services, not Web Sites.
I would like to know if storing sensitive data (passwords) in Azure Service Configuration Settings is secure.
I really don't want to implement the 4-part blog series required to encrypt the web.config in Azure Web Roles, so I'm thinking I could just keep my settings in Azure config and then access them through RoleEnvironment.GetConfigurationSettingValue().
These settings are in a config file much like web.config, so my question is whether this config file is just used to build the cloud service and then discarded, or if it stays on disk during the life of the instance (thereby exposing sensitive data to attack).
I like the ability to update these settings at runtime through the Portal and I consider the Portal a secure endpoint, so I'm OK with it. However, if the file stays on disk then it is no more secure than the web.config file IMHO.
We encrypt/decrypt Azure config settings and other content using the domain certificate installed on the web roles. I posted a full example on my blog here: Securing Azure ServiceConfiguration values for Enterprise Deployment.
I created a feature request: http://feedback.azure.com/forums/34192--general-feedback/suggestions/9025255-certificate-based-settings-encryption
This is similar (but more idiomatic, imho) to what Remote Desktop plugin does. Remote Desktop adds:
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="<name-of-user-account>" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="<base-64-encrypted-password>" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="<certificate-expiration>" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
</ConfigurationSettings>
<Certificates>
<Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="<certificate-thumbprint>" thumbprintAlgorithm="sha1" />
</Certificates>
RDP plugin "knows" Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword value is encrypted will use the certificate Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption to decrypt it.
My feature request is to add attribute named thumbprint to <Setting /> node. Calls to CloudCloudConfigurationManager.GetSetting() would seamlessly decrypt the value using the certificate indicated.
How wonderful that would be...
Related
I have a working Azure web role which I've been using over an http endpoint. I'm now trying to switch it over to https but struggling mightily with what I thought would be a simple operation. (I'll include a few tips here for future readers to address issues I've already come across).
I have created (for now) a self-signed certificate using the powershell commands documented by Microsoft here and uploaded it to the azure portal. I'm aware that 3rd parties won't be able to consume the API while it has a self-signed certificate but my plan is to use the following for local client testing before purchasing a 'proper' certificate.
ServicePointManager.ServerCertificateValidationCallback += (o, c, ch, er) => true;
Tip: you need upload the .pfx file and then supply the password you used in the powershell script. Don't be confused by suggestion to create a .cer file which is for completely different purposes.
I then followed the flow documented for configuring azure cloud services here although many of these operations are now done directly through visual studio rather than by hand-editing files.
In the main 'cloud service' project under the role I wanted to modify:
I imported the newly created certificate. Tip: the design of the dialog used to add the thumbprint makes it very easy to incorrectly select the developer certificate that is already installed on your machine (by visual studio?). Click 'more options' to get to _your_ certificate and then check the displayed thumbprint matches that shown in the Azure portal in the certificates section.
Under 'endpoints' I added a new https endpoint. Tip: use the standard https port 443, NOT the 'default' port of 8080 otherwise you will get no response from your service at all
In the web.config of the service itself, I changed the endpoint binding for the service so that the name element matched the new endpoint.
I then published the cloud project to Azure (using Visual Studio).
At this point, I'm not seeing the results I expected. The service is still available on http but is not available on https. When I try to browse for it on https (includeExceptionDetailInFaults is set to true) I get:
HTTP error 404 "The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable"
I interpret this as meaning that the https endpoint is available but the service itself is bound to http rather than https despite my changes to web.config.
I have verified that the publish step really is uploading the new configuration by modifying some of the returned content. (Remember this is still available on http.)
I have tried removing the 'obsolete' http endpoint but this just results in a different error:
"Could not find a base address that matches scheme http for the endpoint with binding WebHttpBinding. Registered base address schemes are [https]"
I'm sure I must be missing something simple here. Can anyone suggest what it is or tips for further trouble-shooting? There are a number of stack-overflow answers that relate to websites and suggest that IIS settings need to be tweaked but I don't see how this applies to a web-role where I don't have direct control of the server.
Edit Following Gaurav's suggestion I repeated the process using a (self-signed) certificate for our own domain rather than cloudapp.net then tried to access the service via this domain. I still see the same results; i.e. the service is available via http but not https.
Edit2 Information from csdef file... is the double reference to "Endpoint1" suspicious?
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="HttpsEndpoint" />
<Binding name="Endpoint1" endpointName="HttpEndpoint" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="HttpsEndpoint" protocol="https" port="443" certificate="backend" />
<InputEndpoint name="HttpEndpoint" protocol="http" port="80" />
</Endpoints>
<Certificates>
<Certificate name="backend" storeLocation="LocalMachine" storeName="My" />
</Certificates>
On one computer I have 2 projects - a client application and another that holds the identity server and identity manager. When I run the client site on this computer everything works. I am able to sign in, register etc. This project was already set up and working.
I made a copy of the projects and put them on another computer. I have set the sites up in IIS and created a self signed certificate.
When I run the client site and attempt to sign in I get the yellow asp.net error page with the message "The remote certificate is invalid according to the validation procedure". When stepping through with the debugger I also see: "The underlying connection was closed: could not establish trust relationship for the ssl/tls secure channel"
I figure the errors have to do with the certificate so in MMC I made sure that the certificates are installed in the trusted root certification authorties folder.
The other thing I did was check the web.config files in the projects.
In the client site I have something like:
<oidcClient clientId="codeclienthere"
clientSecret="secrethere"
signingCertificate="keythatmatches_certificate_hash_here"
issuerName="https://identityurlhere/issuer"
...
Then in the identity server and identity manager web.config files I have something like:
<appSettings>
<add key="owin:AppStartup" value="startup" />
<add key="Issuer" value="identity_url_here/issuer" />
<add key="Thumbprint" value="keythatmatches_certificate_hash" />
<add key="WebClientId" value="codeclienthere"/>
<add key="WebClientSecret" value="secrethere"/>
...
I changed the signing certificate and thumbprint values to match the certificate hash. For the attribute "issuerName" and key "Issuer" I tried leaving it the same, setting it the name of the certificate and prepending "CN=" to the name of the certificate. I am unsure what value should go here. I am also unsure what other things I should check.
The problem here was that there were hidden characters in the thumbprint that I did not notice. I had pasted in a text editor to compare or something and they got removed so when I pasted them back in the config file they did not match as needed.
I have an application pool that I use for development… and I have it running under my credentials (so I don't have to worry about permission/access issues). Two things make me think my credentials might be just sitting in a file (or registry entry)… which is worrisome:
When I change my password, I have to update the stored credentials
The setup dialog has a confirm password field
If IIS was just storing some authentication token or something, I would expect to only enter my password once (because authentication was happening immediately).
Anyone know where my credentials are being stored? Are they just encrypted using some system key then pulled out and used when the app pool spins up?
Here is the dialog where I'm entering the identity's credentials:
I open that dialog from the app pool's Advanced Settings:
Other Info
IIS 7.5 on Windows 7
I am using virtual accounts for other application pools, but that's not what I'm using here: I'm using actual Windows account credentials
UPDATE
Based on nicolas-dietrich's response, I found the following…
The application pool credentials (and general settings) for IIS 7.5 are stored in %systemroot%\System32\Inetsrv\config\applicationHost.config.
Encryption is handled by AesProtectedConfigurationProvider, which is the standard (?) way to protect sensitive config info (like db connection strings or–you know–passwords)
Here are the relevant sections with sensitive/irrelevant info replaced by ellipses (…):
<configProtectedData>
<providers>
<!-- … -->
<add name="IISWASOnlyAesProvider" type="Microsoft.ApplicationHost.AesProtectedConfigurationProvider" description="Uses an AES session key to encrypt and decrypt" keyContainerName="iisWasKey" cspProviderName="" useOAEP="false" useMachineContainer="true" sessionKey="…" />
</providers>
</configProtectedData>
<system.applicationHost>
<applicationPools>
<add name="DefaultAppPool" queueLength="5000" managedRuntimeVersion="v4.0" />
<add name="GeneralDev" queueLength="5000" autoStart="true">
<processModel identityType="SpecificUser" userName="mydomain\myusername" password="[enc:IISWASOnlyAesProvider:…:enc]" />
</add>
<!-- … -->
<applicationPoolDefaults managedRuntimeVersion="v4.0">
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="false" />
</applicationPoolDefaults>
</applicationPools>
<!-- … -->
</system.applicationHost>
Hopefully, safe enough? ¯\_(ツ)_/¯
In IIS6 the AppPool identities were stored within the IIS metabase (%systemroot%\System32\Inetsrv\metabase.xml) in an encrypted string located under W3SVC/AppPools//WAMUserPass.
That was not so secured though as it was possible to decrypt and to show it as plain text (http://www.jasonsamuel.com/2010/04/28/how-to-get-the-iusr-and-iwam-user-account-passwords-on-an-iis-server/)
I would like to hand over a webapplication to some people but these people should not allowed to has access to the database with some tools. Using the webapplicaton and in the background the database is ok.
Wildfly has a config with these code:
<xa-datasource jndi-name="java:jboss/datasources/ExampleXADS" pool-name="ExampleXADS">
<driver>h2</driver>
<xa-datasource-property name="URL">jdbc:h2:mem:test</xa-datasource-property>
<xa-pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</xa-pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</xa-datasource>
As you can see, there is also the username and password available. How is it possible to exclude / encrypt these, so only the administrator know the password for the database.
The same also for the whole application server - there are also users and password.
How can I do this?
EDIT:
The "customer" will get the whole application inclusive the webserver configuration. (Wilfly and .war - file)
It´s only for saving the software key in the database.
The first time if the "customer" start the web application, he will be prompted so enter the licence key.
After entering the license key a Webservice will be called. The return code is "false" or "true" (is key valid or is key not valid)
My first idea was to store the flag in the database. But if a user has access to the database, he can manipulate this flag on his own.
Is there any other possibility to set a flag for "the software key is valid" instead saving the flag in the database.
Any ideas?
You can use security domain to get over this, there could be some specific changes for Wildfly but for JBoss 7.1.1 here is what you need to do.
Find the location of jboss-logging-3.1.0.GA.jar in your JBoss/Widlfy server. In case of JBoss 7.1.1 it should be something like - modules\org\jboss\logging\main\jboss-logging-3.1.0.GA.jar
Find the location of picketbox-4.0.7.Final.jar
Check if the picketbox jar has org.picketbox.datasource.security.SecureIdentityLoginModule class.
Run the following command from JBoss server root folder to encrypt your datasource connection password
java -cp modules\org\jboss\logging\main\jboss-logging-3.1.0.GA.jar;modules\org\picketbox\main\picketbox-4.0.7.Final.jar org.picketbox.datasource.security.SecureIdentityLoginModule PasswordXYZ
Get the output text and in the standalone.xml add following security domain under elements:
<security-domain name="encrypted-ds-WASM2" cache-type="default">
<authentication>
<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
<module-option name="username" value="WASM2"/>
<module-option name="password" value="89471a19022f8af"/>
<module-option name="managedConnectionFactoryName" value="jboss.jca:service=LocalTxCM,name=MySqlDS_Pool"/>
</login-module>
</authentication>
</security-domain>
Use this security domain in the datasource element as follows:
<datasource jta="false" jndi-name="java:jboss/jdbc/JNDIDS" pool-name="OFS1" enabled="true" use-ccm="false">
<connection-url>jdbc:oracle:thin:#x.x.x.x:1521:xxxx</connection-url>
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
<driver>oracle</driver>
<security>
<security-domain>encrypted-ds-WASM2</security-domain>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
<background-validation-millis>1</background-validation-millis>
</validation>
<statement>
<prepared-statement-cache-size>0</prepared-statement-cache-size>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</datasource>
Reference Link: http://middlewaremagic.com/jboss/?p=1026
It is not possible. If the web application has to be able to decrypt the password to use the database, anyone on the server can do the same.
If you want to restrict access, keep the server under your control and let them access it only through a web front end.
(And even if it was possible to usefully encrypt, if they have server access they can trivially copy the database files onto their workstations, or add new user accounts to the database server).
I have been using owin oauth bearer tokens for web.api authentication. I had only a single server. I never needed to custom generate a machine key. Right now, I need to move to a web farm behind a load balancer. I dont want my current users' bearer tokens to become invalid when I move to the farm. How do I export an auto generated machine key, and import to to another server?
The configuration file deployed on each server must have the same machine key. Some reference here.
Basically you have to copy this section to the other servers' config file:
<machineKey validationKey="A970D0E3C36AA17C43C5DB225C778B3392BAED4D7089C6AAF76E3D4243E64FD797BD17611868E85D2E4E1C8B6F1FB684B0C8DBA0C39E20284B7FCA73E0927B20" decryptionKey="88274072DD5AC1FB6CED8281B34CDC6E79DD7223243A527D46C09CF6CA58DB68" validation="SHA1" decryption="AES" />
It's always best to use a script to generate your own machine keys.