I'm trying to recover my lost data in chrome Extension "OneTab"
The extension uses level DB to store the data
I tried https://filext.com/file-extension/LDB
It opened partially the file and it seems to have the URL's
I have a good reason to believe one of the .ldb files have the data
But The encryption makes the file useless
So how can I decrypt the binaries and retrieve my data?
How can I apply AES encryption to hadoop? Is it possible? If not, help me encrypt the data file in hadoop
The latest versions of hadoop supports encryption. We can create encrypted zones and the data that we transfer to these zones will be encrypted automatically and the data retrieved from this zone will be decrypted automatically. This is also known as REST data encryption. The detailed steps are given in the apache website. This doesn't need any change in the code that access this data.
This can be also equated to server side encryption.
If you want custom encryption to be applied to the files in hdfs, it will be little complex, because you have to apply the encryption/decryption logic in all the programs that uses these data. If the data is encrypted using custom encryption logic, the RecordReader and RecordWriter classes needs to be modified to work with the data.
Could anyone point me to documentation of encryption options available for couchbase? With SQL Server we have the option to encrypt data at table or db level. Is it possible to encrypt couchbase data in a similar way?
I believe that Gazzang is what you want to look at in regards to data encryption for Couchbase:
Gazzang for Couchbase offers a powerful, policy-driven solution that enables you to encrypt your data stored in Couchbase Server. With Gazzang, data files in Couchbase Server are encrypted on disk. This ensures that your data is not compromised if your database is stolen, copied, lost, or otherwise improperly accessed.
Source and more information on Gazzang: http://www.couchbase.com/couchbase-server/connectors/gazzang
You could also use file system encryption - windows provides the option.
Are there any non-terrible ways of storing secret keys for Google App Engine? Or, at least, less terrible than checking them into source control?
In the meantime, Google added a Key Management Service: https://cloud.google.com/kms/
You could use it to encrypt your secrets before storing them in a database, or store them in source control encrypted. Only people with both 'decrypt' access to KMS and to your secrets would be able to use them.
The fact remains that people who can deploy code will always be able to get to your secrets (assuming your GAE app needs to be able to use the secrets), but there's no way around that as far as I can think of.
Not exactly an answer:
If you keep keys in the model, anyone who can deploy can read the keys from the model, and deploy again to cover their tracks. While Google lets you download code (unless you disable this feature), I think it only keeps the latest copy of each numbered version.
If you keep keys in a not-checked-in config file and disable code downloads, then only people with the keys can successfully deploy, but nobody can read the keys without sneaking a backdoor into the deployment (potentially not that difficult).
At the end of the day, anyone who can deploy can get at the keys, so the question is whether you think the risk is minimized by storing keys in the datastore (which you might make backups of, for example) or on deployer's machines.
A viable alternative might be to combine the two: Store encrypted API keys in the datastore and put the master key in a config file. This has some potentially nice features:
Attackers need both access to a copy of the datastore and a copy of the config file (and presumably developers don't make backups of the datastore on a laptop and lose it on the train).
By specifying two keys in the config file, you can do key-rollover (so attackers need a datastore/config of similar age).
With asymmetric crypto, you can make it possible for developers to add an API key to the datastore without needing to read the others.
Of course, then you're uploading crypto to Google's servers, which may or may not count as "exporting" crypto with the usual legal issues (e.g. what if Google sets up an Asia-Pacific data centre?).
There's no easy solution here. Checking keys into the repository is bad both because it checks in irrelevant configuration details and because it potentially exposes sensitive data. I generally create a configuration model for this, with exactly one entity, and set the relevant configuration options and keys on it after the first deployment (or whenever they change).
Alternately, you can check in a sample configuration file, then exclude it from version control, and keep the actual keys locally. This requires some way to distribute the keys, though, and makes it impossible for a developer to deploy unless they have the production keys (and all to easy to accidentally deploy the sample configuration file over the live one).
Three ways I can think of:
Store it in DataStore (may be base64 encode to have one more level
of indirection)
Pass it as environment variables through command-line params during deployment.
Keep a configuration file, git-ignore it and read it from server. Here this file itself can be a .py file if you are using a python deployment, so no reading & storing of .json files.
NOTE: If you are taking the conf-file route, dont store this JSON in the static public folders !
If you are using Laravel and want to store your keys in Datastore - this package can make that easy while managing performance using caching. https://github.com/tommerrett/laravel-GAE-secret-manager
Google app engine by default create credential for app engine and inject it in side the environment.
Google Cloud client libraries use a strategy called Application Default Credentials (ADC) to find your application's credentials. When your code uses a client library, the strategy checks for your credentials in the following order:
First, ADC checks to see if the environment variable GOOGLE_APPLICATION_CREDENTIALS is set. If the variable is set, ADC uses the service account file that the variable points to.
If the environment variable isn't set, ADC uses the default service account that Compute Engine, Google Kubernetes Engine, Cloud Run, App Engine, and Cloud Functions provide, for applications that run on those services.
If ADC can't use either of the above credentials, an error occurs.
So point 2 means if you grant the permissions to your service account using IAM Admin you do not have to worry about the passing json keys it will aromatically works.
eg.
Suppose your application running in App Engine Standard and it wants the access to the Google Cloud Storage. To do this you do not have to create new service account just grant the access to the ADC.
REF https://cloud.google.com/docs/authentication/production#finding_credentials_automatically
I am using firebird server 2.50. As far as I know there is no way to encrypt a database in Firebird. So how to secure the user data?
Manually encrypting all data before saving would cause trouble since i will not be able to use something like "starting with".
I use CentOs for Database servers. These servers are communicating with an Application Server which runs on Windows Server 2008.
Encryption is one kind of several protection measures which can be done against potential adversaries. And there are other methods too. You need common security analysis before you go with decision whether to encrypt or not, and if not than what. You have to look who are adversaries, where they could hit, etc-etc-etc. Blind use of encryption may be waste of resource/time/money/etc. Do security analysis first.
DB encryption is possible in version 3:
With Firebird 3 comes the ability to encrypt data stored in database. Not all of the database file is encrypted:
just data, index and blob pages.
To make it possible to encrypt a database you need to obtain or write a database crypt plug-in.
Refer to Firebird-3.0.0_Alpha1-ReleaseNotes for details