I’ve a web application (asp.net mvc) and I need to encrypt some data that will be stored in the database.
Since I’m using BCrypt for the user password, I was thinking on using it as well to encrypt other data… what do you think? Is BCrypt just for passwords or can I use it as well for other data? Or maybe there is a best way to do it?
Thanks in advance!
BCrypt does not encrypt anything. It is a HASHING algorithm that uses Blowfish internally, but does not actually encrypt your data.
The main difference:
Hashing is an algorithm that takes data of variable size and generates a fixed-size representation of that data. The original data, unless stored elsewhere, is lost AND cannot be retrieved.
Encrypting is an algorithm that takes data of variable size and generates a similarly-sized chunk of data. The original data, unless stored elsewhere (thereby voiding the purpose of encryption), is lost. It CAN, however, be retrieved. The Encryption process uses a separate piece of data called a Key. Provided the associated decryption algorithm is used, the same key will decrypt the data and the original information can be retrieved.
So:
Before anyone can answer your question, you must first understand what you are asking. Do you, in fact, need to store encrypted information, or rather is it hashed information? If you merely need to store sensitive information, but never need to return the original value back to the user, then continue using BCrypt, as it will hash your data (thereby making it unreadable, but still comparable). If, on the other hand, you want to store sensitive information that you one day may need to supply to someone (for instance, a credit card number), then look into sql encryption algorithms.
As you explore the world of security, you will quickly find that it is very painful, but very important. For instance: SLaks brings up a good point. If you encrypt your data, somewhere, somehow, you need to store your key. But if that key is found, then someone can steal all of your data! You must find a way to properly encrypt your data while hiding the key from the public. There are several ways of doing this; google around a bit before you commit to one, as it may not be as secure as you think.
Microsoft has some good recommendations: http://technet.microsoft.com/en-us/library/ms345262.aspx
You did not specify what flavor of sql you are using, so a flavor-specific answer cannot be supplied.
Related
I have been reading many different posts, threads, etc. regarding the best practices to store level data to be used throughout a game application (level boundary data, images, characters, time, etc.).
Many have suggested that using a Property List (.plist) is appropriate, as it is quite simple to store the game info then read it when needed. While this is easy to create and refer to, plist files are not exactly secure in any way, aside from simple AES encrypting the string contents.
Another method would be perhaps to hard code this data into a separate class file, titled LevelData.m and refer directly to the class to read the level data, as storing it this way should be "safer", as (from what I am aware of) users do not have direct or any access at all to these class files once an application has been packaged and distributed through, say the iOS App Store.
I have also read to use SpriteKit's built in NSCoding, where the data can be archived into a file (or NSData object) and later unarchived from that archive.
My question, can anyone suggest the best approach, or perhaps one that I haven't mentioned? YES, I understand they are all perfectly valid methods to saving big data, particularly non-trivial, and somewhat repetitive data that just needs to be read, and all have their pros and cons in terms of security measures. I am merely just trying to find the safest way to store this data without the user being able to tamper it in any way from other people who may have encountered a similar issue and have found the ideal solution.
NOTE: I'm sure that hosting this data server side and retrieving the data upon application launch would be the ideal secure approach. However, I am just looking to see which method should be the best practice in terms of security strictly through storing data on the device. Thanks!
If you are distrusting the users, how about signing the data which's integrity you distrust and validate the signature using public key encryption (with a pinned certificate in the binary)?
Thus, only data with a valid signature from you can be used.
Yet, after all, if a user dissembles your binary and modifies the public key, that doesn't work either.
As always with those problems, the question is: how hard are you making it for an adversary to break your security meassures - and what hardness is useful?
I know you got an answer already but I personally use a GameData Singleton class with NSCoding. I than save the encoded/archived data into iOSs Keychain (instead of NSUserDefaults, NSBundlePath etc).
To save into keychain you can use this helper
https://github.com/jrendel/SwiftKeychainWrapper
which is the one I use for my apps. Its works very similar to NSUserDefaults and is therefore very easy to use.
You can also get a more complex and feature rich one here.
https://github.com/matthewpalmer/Locksmith
Because Spring deprecated the old interface
org.springframework.security.crypto.password.PasswordEncoder;
I looked for alternatives that work with
org.springframework.security.authentication.encoding.PasswordEncoder;
My search points me to: https://stackoverflow.com/a/18678325
I tested bcrypt and I was interested how it works.
The explanation at https://stackoverflow.com/a/6833165 points me to one question.
If $2a$10$ZaDBCZaI59IMdKuBiRdubuMa2h/itIYIwqLHpS1q245ISD90xsjkW contains all information about the type of encoding and the salt and so on, and this is stored in my database why is it save?
If someone has this "hash" he can easily decrypt it with brute force.
Within my previous project I used a SHA encode with a system wide secret salt. In this scenario the hash stole from the database can't easily be decrypted.
So why is bcrypt preferred to a SHA with system wide salt?
2 points:
Bcrypt is designed to resist brute force attacks by having a configurable complexity that makes the process arbitrarily slow. Refer to wikipedia for more details
Using the same hash for all passwords, as your existing system does, may be vulnerable to differential attacks, since each password in the database is known to contain a shared component.
Why should we not store the passwords or keys for encryption in source code for an iPhone App?
Is there any possibility for people to reverse engineer code and find the stored keys? or if the hard code values are stored in a location which is easily accessible?
If you store keys in source code, yes they can be reverse engineered. You can make this even harder by making the key "generated" through a generator function but this is still an extra level of obfuscation. A really motivated attacker can get through that. Another drawback of this approach is that the same key will work on all instances of your application, unless the generator function generates a key deriving from some hardware constants.
Again, you have to do an analysis of how secure you want your application to be and how much effort you want to put into security. Security is always a trade off. It is not worthwhile to spend a lot of effort on security, when the probability or cost of an attack are extremely unlikely.
A more secure approach would be to create a random key and then store it in a secure storage on the device. I am not terribly familiar with the iOS Api and if such functionality is offered. On Windows there is something called DPAPI that provides this, for example.
Anything that gets into users' hands is accessible. Obfuscation of keys does part of the work, but doesn't eliminate the problem completely.
Hi i would like to know best encryption technique for text file encryption and ecryption.
My Scenario:
I have software having two type of users Administartor and Operators. Our requirement is to encrypt text file when Administrator enter data using GUI and save it. That encrypted file would be input for Operator and they just need to select it and use that file. Here file should be automatically decrypt data for further calculation when Operator select those files.
Please help me which encryption/ decryption technique should i use?
A golden rule when doing crypto is to understand that cryptography as a whole it is very difficult.
There are a multitude of different approaches/algorithms to choose from, and no single algorithm/method can be said to be the best one. It all depends on your needs and possibilities to affect application distribution etc.
An example of a potentially problematic situation is that in your scenario the decryption "key" needs to be distributed with the application(s) and might make it insecure. This is generally referred to as the "Key Distribution" problem.
A good place to start reading about crypto is http://en.wikipedia.org/wiki/Cryptography.
As for ready made stuff for Delphi there are a few good packages available:
DEC v5.2 - http://blog.digivendo.com/2008/11/delphi-encryption-compendium-dec-52-for-d2009-released/
DCPCrypt - http://www.cityinthesky.co.uk/cryptography.html
Torry's pages also has a long list of components:
http://www.torry.net/pages.php?id=519
http://www.torry.net/pages.php?id=312
I strongly recommend you use some of the existing implementations and not start to do your own, since creating a secure working crypto algo is very very difficult.
When moving an encryptet message from place/appliction to another, one of the problems you have to consider is where to store the encryption/decryption keys.
As i se your scenario, it seems like it is build in your applications. If so remember to use al sorts of tricks to hide it: Password strings should be split in several bits and onlys appended in a protected memoryspace, that has to be marked as non-pageable (else password could be seen in the pagefile).
The same rules for the content that is unencrypted (the text-file). It's best that it never is saved (even temporaly) unencrypted to disk. If it is saved, the overwrite the date with garbage after use, before deleting it.
Another approch (specialy if you already use compression components), is that the (text) file, can be compressed using a password.
Truthfully, there is no "best" technique. It basically depends on the sensitivity of the data you're trying to protect and the number of people who might access this data. What might be "best" for me might be pure overkill for your project.
In your case, you could use any dual-key encryption method. Or asymmetric key. Basically, the administrator has one key and the operator has the other. The administrator can then encrypt files, but he won't be able to decrypt them again, unless he has an operator key. The operator can decrypt the file and -if need be- encrypt a file that only an administrator can access. (Asymmetrical keys encrypt in both ways.)
There are several solutions that make use of these asymmetrical keys. The one that would be best is the one that you could add to your project in the easiest way while still offering enough protection for your needs.
Building your own asymmetrical key algorithm is possible too, if you're a real Math Wizard. The calculations are complex and involve extremely high prime numbers in most solutions. As K. Sandell said, find a good, existing solution that matches your needs in the best way.
I want to store large files (videos, sounds) and access them via Database. I am balancing now between filesystem (references to files would be stored in DB) and pure DB (which could be enormously large after time).
I have to protect the content too, so I thought, that DB solution suits better for this purpose. (probably it is not a good idea).
On the other hand I have got hint to encrypt files to protect them, if I choose to use file system.
How should I do this?
P.S
please see the question What database should I choose not to worry about size limit?
P.P.S
Under protection I mean encrypt videofile/soundfile using a crypt algorithm. When the application need to read them, it have to decrypt files...
In that way the stolen files are useless unless appropriate decrypt algorithm is present.
I thought to use RAR secured with password. As far as I know it is very hard to break it, when password is long enough. (Maybe I am wrong).
I am not familiar about MD5....
I can not protect files against theft, but I want to prohibit to read it freely.
One approach would be to create a background process with an elevated security token that would it access a section of the filesystem only available to administrators and that process. On Windows you'd create a "service". They call it "daemon" on *nix, I believe.
That service could then expose an API via pipes, sockets, or a shared memory region where the unelevated, user-mode database tool could get and set files.
There's no way to completely prevent system administrators from accessing a file directly, so if that is a requirement, you're out of luck. On Windows administrators have a special privilege that allows them to take ownership of any securable item such as a file or directory. Once they're owners, they can do anything they want to the securable item. There's just no way around that.
I have implemented both approaches in different projects with different requirements and constraints. And I would strongly recommend to keep all the contents in the database, storing the media files in large blobs. Eventhough that will require very large tables, that should not be a problem for the latest versions of the most well known databases.
I recommend DB2. DB2 since version 9 supports very large tables. The maximum is monstrously large. 512000 petabytes, half a zettabyte.
You need to accept that the choice between storing the files in the database vs. in the file system ultimately doesn't matter much - in both scenarios they can be read trivially from outside, unless there is some encryption. That moves the problem from where to store the data to how to store the secret key to decrypt encrypted data, in your application.
This is a hard problem. There's probably nothing you can develop that can't be cracked by a determined attacker in a rather short time. It depends on the audience of your program whether that's a real concern; if it is, then you can't do much. It takes a single successful crack to access your data and make it accessible to all interested in it. The attacker will go for the weakest part, which isn't the hard-to-break file encryption, but your application.
Use a DB (firebird or -embedded) and keep large content out of it.
If it is encryption you are worrying about, do this at the filesystem level instead of the db level.
All modern OSes have support for encrypted filesystems
There are merits in both approaches.
If you want to have the files separately in the filesystem, I would encrypt each one individually. A password-protected RAR or ZIP file would be as good a method as any.
Use a different password/decryption key for each file, and store the password in the database along with each file name.
The following is suggested without knowing the specifics of your application.
As you mention that you can not protect against theft, just about the only option to make sure the multimedia files are safe (unusable) by anyone other than the "owner" you need to encrypt them using a cipher like AES or BlowFish and a secure secret Key. These algorithms are different from MD5 that you mention. MD5 is a HASH algorithm.
For Delphi a rather good encryption library is DCPcrypt forund at http://www.cityinthesky.co.uk/cryptography.html. If has both HASH and Cipher algorithms.
Your problem will be Cipher KEY Management, namely "What password to use for encryption?". The simplest solution without thinking about this would be to use the users own password, untill you realize that the user may change the password. If the user does that you need to Decrypt and ReEncrypt every single multimedia file associated with the user.
To answer the actual question about key management I'd suggest reading up on key management. As I'm no expert on cryptography I hope someone more versed in the crypto world can help here... Link: http://en.wikipedia.org/wiki/Key_management.
I think it all depends on a few things:
Where do the files come from initially
How will the files be accessed (over the network or locally)
Who do you want to protect the files from
If the initial files come from "you" (the developer) then encrypted database blobs would probably be the best way as most dbs' come with some form of encryption.
If the files come from the user of the software, then using the file system would suffice - possibly using an temporary directory to store and retrieve files if used over the network, but actually storing the files in a non-shared location so that network users don't have access to all the files.
Just a few thoughts.
Local file protection, web project protection, and secure email, Record-level security in databases (DB2, Oracle, Firebird, MS SQ:, My SLQ etc.). Creating encryption systems from primitives etc. Look for File Protect System - SE or SPE or PE.