How secure is the local data
ApplicationData.Current.LocalSettings
storage used in Windows 8 Store Apps?
This application data storage article says nothing about security, neither does this one.
Can this data be manipulated from outside of the app?
I looked at the location of the data
C:\Users[username]\AppData\Local\Packages[package_namespace]\LocalState)
but did not find it. Where is it saved exactly?
I'm trying to asses the security of this storage mechanism to decide whether I can store security-critical information there.
After some more investigation I found:
http://lunarfrog.com/blog/2012/09/13/inspect-app-settings/
The data is stored in
C:\Users[username]\AppData\Local\Packages[package_namespace]\LocalState\Settings\settings.dat
which is a Windows NT registry file (REGF) which can be openend with the registry editor and can also be manipulated.
Meaning, local storage is NOT safe.
If there is no other way, encrypting the data and obfuscating the keys is a possibility.
If it's user credentials that you want to store, take a look at PasswordVault class. Otherwise use DPAPI as you already suggested yourself.
This application data storage article says nothing about security, neither does this one.
Can this data be manipulated from outside of the app?
That storage is similar to iOS's Core Data. Its essentially untrusted input unless storage is protected (below the application level). Even if the storage is protected with encryption, its likely not authenticated so its subject to tampering.
If there is no other way encrypting the data and obfuscating the keys is a possibility.
On Windows Platforms, the standard way to protect sensitive data is to use the Data Protection API (DPAPI). Use DPAPI with the user supplied secret (the additional entropy in the APIs) for the best protection. You store the DPAPI'd data with the user's profile, in the registry, or on the filesystem. See, for example, Windows Data Protection, How to: Use Data Protection, and Data protection API (Windows Store apps). Michael Howard and David LeBlanc have a good treatment of the subject in Writing Secure Code, Second Edition. See Chapter 9, Protecting Secret Data, beginning on page 299.
If you want database like encryption, look at SQLCipher. It uses authenticated encryption, so it provide confidentiality and integrity. Windows 8 supports native libraries, including on their phones (see, for example, Native code on Windows Phone 8).
Related
I want to use Cosmos db with c# code. A really important point is that data should stay encrypted at any point. So, as I understood, once the data on the server, it's automaticaly encrypted by azure by the encryption-at-rest. But during the transportation, do I have to use certificate or it's automatically encrypted. I used this link to manage the database https://learn.microsoft.com/fr-fr/azure/cosmos-db/create-sql-api-dotnet. My question is finally : Is there any risk of safety if I just follow this tutorial?
Thanks.
I think that's a great starting point.
Just one note, your data is only as secure as the access keys to the account so, on top encryption at rest and in transit, the Access Key is probably the most sensitive piece of information you need to protect.
My advice is to use a KeyVault to store the database access key rather than define them as environment variables. Combined with Managed Identity, your key will never leave the confines of the azure portal which makes it the most secure option. I'm not sure how you plan on deploying your code but more times than not I've seen those keys encoded in source code or in some configuration file that ends up exposed.
A while ago I wrote a step-by-step tutorial describing how to implement this. You can find my article here
I would suggest you to follow the instructions mentioned in here, and not even using access keys, because if they are accidentally exposed, no matter that you have stored them in a Key Vault or not, your database is out there. Besides, if you want to use access keys, it is recommended to change the access keys periodically, which then you need to make this automatic and known to your key vault, here it is described how you could automate that.
We want to migrate HSM keys from Thales paysheild 9000 to Azure Key vault. We would like to know if this migration is supported and if supported, what’s the migration approach and use cases where customers have already migrated to Azure. We have gone through the article https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/key-vault/key-vault-hsm-protected-keys.md, it talks about Thales nShield family but we are using https://www.thalesesecurity.com/products/payment-hsms/payshield-9000
Thanks in advance.
Excellent question, as Dan suggests you should contact Microsoft for clarification, but unfortunately I don't think it's possible.
Recapping, as I'm sure you are aware the purpose of HSM's is so that the keys are not exportable.
Microsoft (and I assume Thales) supports key backup: https://learn.microsoft.com/en-us/rest/api/keyvault/backupkey but it can only be restored to the same geographical area.
In the article you supplied it mentions "Key Exchange Key" in each geographical area, which I assume will mean that Microsoft will be using a different key to that of another install of an HSM.
Having said this I'm not a general HSM expert, these are just links I have come across over time using KeyVault.
Please do contact Microsoft as I would to be interested if this is possible, please post an answer once you have heard back or a Microsoft employee can perhaps answer directly.
On the Thales literature it states:
"With nShield BYOK for Microsoft Azure, your on-premises
nShield HSM generates, stores, wraps, and exports keys to the
Microsoft Azure Key Vault on your behalf"
http://go.thalesesecurity.com/rs/480-LWA-970/images/Thales-e-Security-Microsoft-Azure-UK-sb.pdf
Interestingly it says generates / stores which suggests a pre-created key could be migrated. However on the contray I'm guessing the export must happen using the "Key Exchange Key" and stored in both on-prem and exported for Azure at the same time, not on-prem first, in the BYOK process.
This blog post has keyvault team's contact details if it helps: https://blog.romyn.ca/key-management-in-azure/
The migration of important keys, that are encrypted under current LMK on your Thales payshield on premises, is very straightforward process:
1- Use console command GC to generate new ZMK in a clear format component, this will be done by using key type to be 000 which is ZMK key type, and also to choose clear format components option use letter 'x' in GC command steps.
2-Repeat the GC command above 3 times to generate 3 different plaintext format components of the new ZMK.
3-Now, at your payshield 9000 HSM, use the console command FK which means Form Key from components, the result is the new ZMK encrypted under old LMK.
4-Use the command KE ,which means export key, to export the important data encryption keys (DEK), such as ZPK for example, which is encrypted under old LMK to be encrypted under the new ZMK. Note: in KE command here use key type to be 001 which is ZPK key type.
5- Now you need to manually distribute the same new ZMK to the other party that you are going to migrate to.
6- You can do this manual distribution to such an important key (new ZMK) by sending the 3 different plaintext format components, which you have generated earlier in step number 2, to three different security officers at your corporate, and for security reasons, no one can have the 3 components all together.
7- On the other entity that you wanted to migrate your keys to, which is Microsoft Azure Key Vault cloud service, Azure is offering securing your keys in a hardware HSM environmental of nShield type, which is general purpose HSM and it is not specific in payment transactions like Thales payshield HSM.
8 - Refer to Microsoft Azure key vault documents, to know how to form the new ZMK of the 3 different plaintext format components that you have generated before, and refer to nShield manuals also to check the command which is responsible for importing keys.
9- Now, your important keys such as ZPK which was exported under new ZMK, are now imported under the same ZMK, and finally stored encrypted under the new LMK of your nShield provided cloud service.
We make heavy use of dynamic datasources. We retrieve server name and database names from a table in a SQL Server database. A package loops through the server names and database names and executes once for every server, for every database.
These values are then put into the ServerName and InitalCatalog fields of the dynamic connection. User and password are pre-defined (and therefore the same for every connection). I would like to fill the user + password from a table too but then I have to store the passwords as clear text in that table.
Is there a way to store the password encrypted in that table and decrypt it when I need to use it? Any person having access to the SSIS package is allowed to know the passwords but they should not be easily read from the table containing the connection strings.
All suggestions to handle this (f.e. using different approaches) are very much appreciated !
The preferred solution is to keep using integrated security.
Normally the job will try execute the step under the account of the SQL Agent, that is not what you want.
Proxy account is a replacement for the credentials for the SQL Agent account (msdn.microsoft.com/en-us/library/ms175834.aspx), also not helpfull in this case.
I remember that on Windows 2000 we used a trick by creating same local accounts with identical username and passwords on all servers to overcome the SSO limitation, it will probably work in your situation.
Yes, you can encrypt/decrypt a column. See Microsoft's walkthrough here:
https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/encrypt-a-column-of-data?view=sql-server-2017
Best practice is to then create a view that decrypts the column and then grant user-level (i.e., SELECT, ALTER, INSERT, UPDATE, etc.) access to the view only because the view must have the symmetric key to decrypt the data. Exposing the key can be a security vulnerability, so you want that locked down as much as possible. A view with limited user access is the best place to allow a key to be exposed (if there is ever a good place to expose a key, which there is not).
But, Ako is correct. Use integrated security.
We're bringing up a webapp on EC2. Our passwords are held with a strong one way hash algorithm (SHA256, many iterations).
But what do people typically do for the rest of the data. Email addresses, birthdays, names and addresses.
We're based in the US and don't keep any financial or healthcare data. Just user profiles -- I believe there are few legal requirements, but what do people actually do.
We run EC2 app servers, MongoDB and and Amazon MySQL RDS instance. Performance is a consideration (we're expecting to have to scale out by necessity).
You could encrypt the rest of the user data before storing it. If it's not protected or sensitive data, and you're not running a site that's likely to be targeted, you can probably rely on standard security techniques when transmitting the data (e.g. SSL). But, if you would like to store the data more securely, here is a resource discussing Public-key cryptography
Here is a resource discussing performance implications of an encrypted MySQL DB:
https://security.stackexchange.com/questions/11683/how-to-improve-performance-of-encrypted-mysql-database-on-linux-backend-server
Here is an example discussing a similar use case:
How to store private encrypted user data in the database, but make them available to other chosen users?
How do you make sure it is secure when there are some devs who can access the machine?
Baring the whole discussion about not storing passwords in files you use the machine's own ACL to prevent them from accessing it.
Make the file readable only by the admin account, or some other account used to run your software. Then you dont give the developers the admin account/process account information.
The bigger question is, if you are concerned about them accessing the file on your machine, why do they have access to said machine? Any developer that is able to replace the code on the server without checks will be able to access your database.
Lets give a nice real world example of why you would want to do something like this.
You hire developers to create a Bank of Stackoverflow website. For whatever reason you store all your clients account information, including SSN, in a single database that needs to be accessed by the Bank of Stackoverflow website.
Do not give developers permission to put code directly onto a live machine
Do not give developers the access information to the database.
All code has to go onto a stage machine to be verified. For the most part it is easy enough to allow developers to use stage databases consisting of fake client information.
It is the responsibility of vetted engineers, to move products from the staged machine to the production machine.
I did not completely understand your problem but I think following article is for you:
Data Storage Security in J2EE