We are planning a desktop client application with Adobe AIR. The client app will be delivered to our customers with a database, which contains monthly updated marketing data provided by our company. As different customers will buy different sets of data from us, for example, a customer is only interested in marketing data in a specific product category, while another customer need all data in a certain region. After a customer installs this client app, new data will be emailed to the customer every month.
So, the requirement is to keep the data accessible only by the customer who bought it. After reading through AIR's secure local store and database encryption feature, I came up with the following design: each customer will have his own secret key (stored in AIR's secure local store), the secret key is used to encrypt the data that the customer has purchased. Of course, the monthly data that we sent to the customer will be encrypted using the same secret key.
So my questions are: is AIR's database encryption and secure local store secure enough for this use case? If someone gets the encrypted database file, can he decrypt the DB?
I think the encrypted stores in AIR are as safe as the OS itself. I would worry more about the other parts of the design. For example, how are you installing the secret key on each client?
The trend nowadays is to build a thin-client and have everything accessed through the internet. The client-specific data would be provided by your server after authentication. This approach might prove to be easier to deploy.
Overall, I think your approach sounds solid.
Related
I am wondering what the functional benefits are of applying Tri-Secret Managed Key security in Snowflake warehouses?
From what I understand:
the Tri-Secret method let's you define your own key
revoking that key will make it impossible for Snowflake to decrypt your data
But is the level of encryption in any way more secure?
The only difference I see is that a Snowflake key and your own key are combined.
Prohibiting access to that key will make it impossible for Snowflake to decrypt, rendering your data useless.
And then what? How to recuperate from that?
Also see: https://www.snowflake.com/blog/customer-managed-keys/
This is from Snowflake themselves. What they essentially say, is:
you have more control, but you must supply Snowflake with that key otherwise they can't do their work
you can shut out Snowflake from accessing your data if you mistrust them
if there is a data leak, you can prevent further leakage (but why not shutdown all access in that case, except for reverified trusted parties???)
I am stymied by this functionality.
The only response I get from local Snowflake representatives is that the Dutch financial laws/regulations prescribe or at least imply the need for this.
Regards, Richard.
Let me start by making the most important statement here: Don't use customer managed keys, unless you really need to use them.
Think of the worst case scenario: If you don't have an incredible resilient platform to securely store your own keys, then you risk losing all your data if you ever lose your keys.
Let me quote now some 3rd parties on when customer managed keys should be used:
Google says:
Customer-managed encryption keys are intended for organizations that have sensitive or regulated data that requires them to manage their own encryption key.
Meaning: Customer managed keys are intended for organizations that are required to use them. Don't follow this path, unless you are required too.
Or why would some companies start using their own keys, or stop using them — from CIO.com:
If you’re considering whether bringing your own keys – which also means securing your own keys – is right for your business, the first question to ask is are you ready to become a bank, because you’ll have to run your key infrastructure with the same rigor, down to considering the travel plans of officers of the company. If you have three people authorized to use the smart card that gives access to your key, you don’t ever want to let all three of them on the same plane.
Same article about Microsoft customers on the automotive industry:
“They all start by saying ‘I want to be in control,’ but as they see the responsibility and they understand to what extreme lengths Microsoft taking this responsibility, they say ‘why don’t you just do it.’ They don't want to be the weaker link in a chain.”
And NY financial institutions:
Even some New York financial institutions, who initially wanted BYOK that ran against their own on-premises HSMs decided against that when they considered what could go wrong, says Paul Rich from Microsoft’s Office 365 team. “An HSM could have been powered down, taking out a vast swathe of user base. They quickly got the idea that this is potentially a great denial of service attack that malicious insider or attacker performs on the company. These are our most sophisticated customers who are highly sensitive that this is a big responsibility but also a threat of potential destruction, whether that’s accidental or malicious.”
So you should only use customer managed keys if you already understand why they would be beneficial for your use case - and only if you are ready to incur the cost of securely managing them. Otherwise, just let Snowflake handle all these complexities for you.
On the other hand, benefits of using tri-secrets from the Snowflake announcement post:
Customer-managed keys provide an extra level of security for customers with sensitive data. With this feature, the customer manages the encryption key themselves and makes it accessible to Snowflake. If the customer decides to disable access, data can no longer be decrypted. In addition, all running queries are aborted. This has the following benefits for customers: (a) it makes it technically impossible for Snowflake to comply with requests for access to customer data, (b) the customer can actively mitigate data breaches and limit data exfiltration, and (c) it gives the customer full control over data lifecycle.
On the same blog post you'll notice that Snowflake tri-secret customer keys are managed by AWS's KMS. This gives you the above benefits, without having to deploy your own infrastructure to manage your keys. You still need to carefully consider your responsibility for safeguarding your key.
AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys. AWS KMS is integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs.
The blog post hasn't been updated to reflect that also GCP and Azure can be used to manage the keys, as stated in the docs:
Tri-Secret Secure lets you control access to your data using a master encryption key that you maintain in the key management service for the cloud provider that hosts your Snowflake account: AWS: AWS Key Management Service (KMS); Google Cloud: Cloud Key Management Service (Cloud KMS); Microsoft Azure: Azure Key Vault.
Synonyms for future research you might want to perform: BYOK, CMEK.
How to create a simple database with Clients' Info (email addresses, phone, affiliation) and different Campaigns’ drive Info (current interests, ongoing research..etc). The database should allow a user to log daily information such as:
Date of when the client was contacted;
Date of when the client have contacted me back;
status of interaction (interested client, not interested, considering it...etc)
action required on the current status (with automated alerts to prompt and action);
log date of action taken;
data analysis to see evolution of ongoing and past exchange of emails with clients;
Multiple users using the same database;
Checking that there are no repeated clients (email ID verification)
Considering various e-mails addresses for the same person and checking all of them for duplicate contacts purpose;
importing current database from excel (including duplicates and consider that the same client can be included in different campaigns but never contacted twice in the same here)
create simple interface to access database and perform all daily actions such as log information, and upload news contacts with themes information for each campaign drive details.
Important: I don't know much about programming and this should be something simple to develop and use. Any ideas?
It sounds like you are looking for more than just a database (E.G., a place to store stuff) and are looking at a solution UI, DB, Reports, etc. Assuming this is correct and that you want to use Microsoft technologies (there are tons of other alternatives Ruby on Rails, Java, PHP, MySql, Mongo, etc.) I would suggest learning about Nerd Dinner written by Microsoft in ASP.NET MVC3 using SQL Server for the RDBMS as the concept matches some of your requirements above.
My web application stores external website login/passwords for interaction with them. To interact with these websites I need to use the original password text, so storing just the hash in my database is not going to work.
How should I store these passwords?
Edit:
I am concerned if someone gets access to my server. If I use some kind of 2-way encryption and they have server access then they can just check how the passwords are decrypted in my backend code.
It seems to me that you want to store passwords in a similar fashion as Firefox and Chrome. So why not look at how they do it?
This is how Chrome does it:
http://www.switchonthecode.com/tutorials/how-google-chrome-stores-passwords
If you MUST do this, you should use a two-way encryption. There are a lot algorithms (ciphers) for this, but basically you encrypt your data with an encryption key, and use the same key for decrypting them again.
Choosing the right cipher depends on which are supported by the programming language of your choice, but examples are:
Blowfish
3DES
Skipjack
They come in different complexity and some are harder to crack than others. You should realize though, that no two-way encryption is safe from cracking, given enough time. So it all depends on, how sensitive these passwords are.
/Carsten
Decide what you are protecting them against. Options include (but are not limited to): Accidental disclosure, disclosure by you, disclosure in transmission, disclosure due to code error, disclosure due to physical theft of hardware, etc.
If this is a web application, and each user is storing his/her own set of passwords, then you might encrypt these passwords with their login password to your application. If this is an application that each user installs separately, and which keeps its own local database, you could have an optional master password (like Firefox does).
If you are just ensuring that the data is safe if the hardware is stolen, you might use a full disk encryption solution like TrueCrypt or PGP WDE, or Ubuntu, Debian, or Fedora's built-in approach, and require a PIN or password on every boot.
If you just care about secure transmission, have code to ensure that you use transport security, and don't worry about encrypting the data in your database.
I would go about this in the following way.
Protect data against hardware being stolen:
Use disc encryption as discussed in previous posts.
Protecting data if server is compromised (hacked):
I would use two different servers for this project, one worker server and one front server.
A) Worker server
This has the DB with passwords etc,
it also connects to other services.
To connect to worker server, users
can do it through an API. API should
have on function, insertUserData,
which allows userdata to be inserted,
API escaped all the input.
API uses
a DB user which only has input
privilegies on the userData table.
This would be the only way to contact
this server.
Only allow SSL
connections.
This server in turn runs chron jobs that connect to external services, pulls data from them and populate it's DB. Use a different DB with different user privileges.
This server runs another chron JOB which connects to the front server and pushes new data to front server.
Minimal amount of services running
Only SSH/SCP from your IP, tight firewalling. Block if connections exced X / min etc as they only would do an occasional insert.
NO FTP etc.
B) Front server
Receives data from Worker server, never uses the passwords itself. Only way to contact worker server is through API mentioned above, only for new user information. This is where all users login to see their information etc.
The problem with doing it all on the same server, if you get hacked the hacker can sit and sniff all incoming data / passwords etc.. so even if they are stored / encrypted / decrypted securely, with some patience he would sniff them all.
When the application is first run, it will generate a random key. This key will be used to encrypt and decrypt sensitive data. Store the key in a local file, and set the file permissions so that nobody else can read it. Ensure that the user running the web server has no login access (this is a good idea anyway).
Possible ways to break this system:
Get root access.
Get sudo access.
Deploy a malicious application on the web server - this application will then have access to the key, and may be able to send it elsewhere.
As long as you take reasonable precautions against all of these, you should be OK.
EDIT: Come to think of it, you could just store the sensitive data right in the key file. Encryption would provide an extra layer of security, but it wouldn't be a very strong layer; if an attacker gets access to the file, chances are good that he also has access to the DB.
I have a service which process emails in a mailbox and once processed, stores some information from the email in the database. At the minute the schema looks something like:
ID
Sender
Subject
Body (result of being parsed/stripped to plain text)
DateReceived
I am building a web front-end for the database and the main purpose of storing the emails is to provide the facility for users to look back and see what they have sent. However, another reason is for auditing purposes on my end.
The emails at the moment are being moved to specific mailbox folders. So what I plan to start doing is once the email is processed, record it in the database and delete the email from the mailbox instead of just moving it.
So a couple of questions...
1) Is it a good idea to delete the actual email from exchange? Is it better to hold onto it just in case?
2) To keep the size of the fields down I was stripping the HTML out of the emails, is this a bad idea? should I just store the email as it is received?
Any other advice/suggestions would be great.
In both cases I think you should hold onto the original emails. Storage is cheap, but if disk space is really an issue look to compression rather than excision to solve it.
Both your of your use cases (historical record and audit) will be better served by storing the complete unabridged email in the database. Once you start tampering with the data, albeit "just" removing formatting, it becomes difficult to prove that you haven't edited it in other, more significant ways. Especially if you have deleted the original email instead of archiving it.
You don't say what business you're in, but the other thing to remember is whether there are any data retention policies active within your organisation or in the wider jurisdiction. Compliance is becoming gnarlier all the time.
I would maintain the messages on the Mailbox on a specific folder as you are doing and probably wouldn't even save anything on a database given you can access the Mailbox from within your application.
The Exchange team over the years has developed several APIs for accessing the Mailbox's contents.
With Exchange Server 2007 and 2010, the recommended API would be Exchange Web Services which can be used from any language/environment that is capable of accessing Web Services.
If you are developing with a .Net language (C#, VB.NET for instance), your best bet would be EWS Managed API.
If you are really going to do something meaningful with the body, you can save the results as named properties (extended properties in EWS parlance) on the message itself.
There are other APIs with corresponding functionality for previous versions of Exchange.
If I am building a CRM web application to sell as a membership service, what is the best method to design and deploy the database?
Do I have 1 database that houses 100s of records per table or deploy multiple databases for different clients?
Is it really an issue to use a single database since I believe sites like Flickr use them?
Multiple clients is called "multi-tenant". See for example this article "Multi-Tenant Data Architecture" from Microsoft.
In a situation like a CRM system, you will probably need to have separate instances of your database for each customer.
I say this because if you'd like larger clients, most companies have security policies in place regarding customer data. If you store their customer data in the same database as another customer, you're running the risk of exposing one companies confidential data to another company (a competitor, etc.).
Sites like Flickr don't have to worry about this as much since the majority of us out on the Interwebs don't have such strict policies regarding our personal data.
Long term it is easiest to maintain one database with multiple clients' data in it. Think about deployment, backup, etc. However, this doesn't keep you from having several instances of this database, each containing a subset of the full client dataset. I'd recommend to grow the number of databases after you have established the usefulness/desirability of your product. Having complex infrastructure is not necessary if you have no traffic....
So, I'd just put a client id in the relevant tables and smile when client 4 comes in and the extent of your new deployment is one insert statement.