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.
Related
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.
I use the Linkchecker module on my website but the database stores my urls as a urlhash. I'm not familiar with this kind of security, so is there anyway I can revert these strings back to the original url?
Hashing is a one-way process, designed to create signatures or fingerprints that are easily comparable by a machine.
Reverting hashes to their original strings is almost impossible (depending on the hashing algorithm) and involves reverse engineering and number crunching.
So, to answer your question in short: no this is not possible.
see a similar discussion on md5
I'm weighing the pros and cons of using "Authentication from Scratch" (as implemented in this Railscast) vs. using Devise.
I'm using a custom datastore, so using Devise isn't as simple as just following the README. It would require writing a custom ORM adaptor, which is far from trivial.
Given all this, the Railscast Auth from scratch seems much easier to implement.
So how secure is it?
Update: I should have pointed out that I'm using Parse.com as my datastore. This means they take care of hashing passwords and constraining uniqueness of usernames.
They both work by using bcrypt to generate a salted hash of the password, the only difference is that devise (by default) uses a higher cost for the hash (i.e. it would take more cpu cycles to brute force it), but of course you could easily add that to the railscast code, so roughly equivalent in that respect.
The railscast version does seem to be vulnerable to timing attacks as just doing == won't give you a constant time compare operation. In a nutshell a timing attack works because a password where the hash was completely wrong would take less time for == to reject than a password where first half of the bytes were correct (and so == had to consider more bytes before bailing). It may seem that any such difference would be erased by noise from variations in network latency and so on but people have mounted real attacks to recover keys using these approaches.
You could obviously borrow the secure compare bit from devise though, but it does go to show that there are non obvious issues involved.
Obviously devise gives you a lot more than just authentication!
That screencast uses the bcrypt-ruby library, which is a Ruby implementation of bcrypt, which is based on the Blowfish cipher. The benefit of bcrypt is that it's computationally expensive to crack a password generated by this system, and that the cost of generating these passwords can be increased as required in order to make it more secure, at the expense of the computation time it would take to generate time.
For more information, check out the BCrypt::Password RDoc.
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.