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?
Related
I have a client who is wanting to store uploaded images of customers credit cards on the server.
Is there a best practices guide for preventing outside access to the images or protecting from an attack?
Currently using a few htaccess to prevent users from accessing folder but it doesn't feel very secure.
Storing actual images of credit cards is a terrible idea.
Get legal help
These are just minimum guidelines not hard fast rules that you can take into court.
At minimum the raw data would have to be encrypted.
Your better off creating a database, and having the data transcribed or OCR into normal fields.
I am sure the PCI-DSS has guidance for what level and type of encryption is needed to protect the database.
A database is better because the actually data lives outside the reach of the web server. Then the PHP would have to give a secure username and password to access the data because it has to authenticate against the database.
The username and password would have to be manually entered by the end user or site administrator to access the data.
There is a lot of hardening your going to have to do to make it acceptable.
Here is a starting point.
https://security.stackexchange.com/questions/59520/how-to-store-credit-card-information-for-repeated-transactions-and-still-be-pci
Ask more question in the security community at stack exchange.
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.
I'm new to couchDB and still reading tutorials. My question is if it is the normal way to represent every user of my application as a new database user, as it seems to be explained that way everywhere I look?
Let's say I have an online game with many different players - would I create a new "database user" for every player who registers? Or would I make my own database "players" and create a sign-in logic in the app? Not being used to document-driven DB's it seems strange to me not to distinguish between db-users and users of my application...
You could do it either way. First about couchdb users
Users in couchdb are stored in a special _users database
Database permissions are handled by a special _security document. This is specific to every database.
In security documents you add users that you have already stored in the _users database previously.
So you can certainly create a database per user. Before doing that ask yourself if the data that you store in each database is truly independent. Because you can't run map reduce queries across databases. So if you are planning to do aggregation across data for different users then this approach will not work.
Couchdb can also help you with app level authentication. Since couchdb uses a cookie based authentication:
Store your "business logic users" in the special _users database.
Authenticate it with the _session endpoint.
Extract the cookie header and sent it with your application headers.
All the logic for authentication is implemented for you by couchdb. All you have got to do is manipulate headers. Send the cookie from your application and when authenticating with couchdb send it with couchdb's headers.
If you prefer to write entire session management in your application that is fine too. In this case simply store the users in your database and verify that they exist before authenticating them. Like you would do with another database.
The benefit of using couchdb is that it is secure by default --using pbkdf2 encryption scheme to encrypt passwords.
If you instead want to manage all docs using a single database, but still implementing read/write ACLs, you can check the Chatty Couchapp Tutorial app from Smileupps App Store
It's a pure couchapp, relying on CouchDB only as its backend. The tutorial is still work in progress but the couchapp is fully working and you can download its source code.
It implements role/user based read/write ACLs using a single CouchDB database. This way you don't have to setup N replications where N depends on the number of your users. You only have one database containing all your data, easy to be queried on the fly(with temporary views) and for maintenance operations. Of course you can decide to increase the number of database, depending on type of your data and use cases.
A single couchapp contains all the necessary code for frontend, admin dashboard and server side API implementing business rules
The user, depending on his roles have different access to different sections. i.e. he can access the frontend website, but not the admin dashboard.
You can install the free trial, then download the source code with Smileupps deployment tools, change it, upload it back and check your changes.
Is there any merit in creating an obscure azure storage account name by using the max number of random chars/nums that is allowed when creating one from the portal?
I know that they are still going to be publicly visible and accessible with the keys but is there any benefit in this? Admin is going to be trickier from the portal having accounts with randomly generated names naturally. Is there such a malicious practice of "scanning" storage account names to find ones that exist to potential abuse or is there mechanisms to prevent that? I am aware that obfuscation does not equal security and only means to delay and not prevent but I can't see any other way to secure a storage account to a specific IP address/range presently.
Is this something you would/wouldn't recommend to do in practice? Am I just being overly cautious and in fact the access keys on their own are indeed a good level of security.
I am no security expert, but IMHO, you are being over cautious... with the name, that is..
Having said that, it is always a good security policy to rotate the access keys at a given frequency. The very reason why these services support primary and secondary access keys is to enable the scenario for key rotation... and think of it as similar to systems enforcing a user to change their password every X days.
The frequency could be anything you prefer, or your in house security experts suggests as acceptable.
Although initially needs effort investment, automating the key rotation process is obviously best.
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).