I'm developing a program that needs to load and save data in external files, I have been searching for options and I have chosen to save the data in a binary file.
As I don't want that someone could edit the file easily, I thought about writing in the first line of the file, its md5 sum. In this case, if some data of the file is changed, the sum won't match the one of the first line.
The problem I find then is that if I calculate the MD5, and after that I write the info inside the file, it's obvious that the sum will be different, so, how could I sort this?
If you sugest me a better option than the sum, it will be equally accepted.
Thanks in advance.
What is your threat model?
If you just want to protect against casual fiddling, md5 the main data of the file, then write the md5 sum to the end. To validate, strip off the md5 sum, then md5 only the original file.
If you want to protect against malicious and skilled cracking, you're out of luck; any validation algorithm you use can be replicated, particularly if they have access to the program itself. Even a cryptographic signature could fail if the attacker extracts the key from the program binary.
If it's a big deal, a unix solution is to run as setuid or setgid to a different user and write to a directory which users cannot modify. I'm not sure what a good general Java solution is, but the point remains: users shouldn't be able to modify your data because they were prevented from doing so, not because they were detected trying to.
While it is theoretically possible to make a self-referencing MD5 file (and I recall some have been found), it's a waste of resources. It is generally necessary to store the hash somewhere outside the hashed file (traditionally named md5sums or sha1sums, respectively).
This said, I'd recommend going for SHA-1 in addition to MD5.
Bill: Ted, while I agree that, in time, our band will be most triumphant. The truth is, Wyld Stallyns will never be a super band until we have Eddie Van Halen on guitar.
Ted: Yes, Bill. But, I do not believe we will get Eddie Van Halen until we have a triumphant video.
Bill: Ted, it's pointless to have a triumphant video before we even have decent instruments.
Ted: Well, how can we have decent instruments when we don't really even know how to play?
Bill: That is why we NEED Eddie Van Halen!
Ted: And THAT is why we need a triumphant video.
Bill, Ted: EXCELLENT!
Seriously, you can't calculate the MD5 sum (or some other hash) with the calculated hash embedded, so you have to store the hash somewhere else.
If you just don't want people to easily mess with the file, maybe it's an option to obfuscate it via ROT13 or XOR "encryption" ?
What if you create a container for your data? Through a new class with two properties, CheckSum and Data, you could serialize all your data and put it in the Data property. Then, you calulate the checksum for the serialized data, and use the CheckSum property to store the checksum.
Just ignore the first line when you compute the md5. You should also add a secret salt to make sure it's not to easy to create a new MD5 after editing the content. It depends on your actual need (level of security).
you could store the MD5sum in a database instead, then when you want to see if a file has been changed you check the MD5 sum in the db. alternatively you could store the md5sum of a file in another file.
Related
Im new here, so please correct me on anything!
I was assigned to do a basic java program where i register and authenticate users, storing the username and the password in a .txt file. The password is stored as an MD5 hash. Also, i needed to make another program to try brute-forcing the .txt file to find the passwords, and measure the time needed to do so.
i managed to do that(suffering a bit), and the last step is to find and implement a way to reduce the chances of this brute-forcing to work. I searched a lot about it, and apart from people saying to use another safer method of storing passwords, the only thing i found useful(which i heard of before so i searched for it) was using salts, Which i know that they are concatenated within the password before hashing, and then both hash and salt are stored.
But i dont think this would work in this occasion, as the salt would also be stored in the .txt file, thus, even taking longer due to the bigger possible range of combinations, i could still do a brute force where i try a combination and add the salt in the .txt to it, then hash it and compare to the hash stored in the .txt.
Is this a viable way to make the brute force harder(at least in this assignment, for learning purposes) as it takes more time, or is there any other methods to do so?
thanks in advance!
first of all. md5-Hash is deprecated. Please use sha256 or sha512 instead.
The salt should not stored inside the text file. It is a config parameter of your programm.
Now, you can use your secret salt and the password to generate the hash.
hashedPw = sha256(salt + password)
This avoids that an attacker can retrieve the original password from look it up in an lookup table. (https://crackstation.net/)
Additionally you can encrypt your passwords with AES-Algorithm.
I have the following three lines in my little game which store the id and pass of a new user:
Properties prop = new Properties();
prop.setProperty(id, pass);
prop.store(new FileOutputStream(new File("path/to/project/src/properties.data")), "");
Unfortunately I've noticed that only by changing the properties file extension to txt all the users and passwords become visible and readable by anybody, which is a thing I don't really like. Please let me know of a good easy method to encrypt the file in some way.
The thing is I already searched about this but the answers don't really fit my needs, I don't expect my game files getting attacked by the biggest hackers so using AES or any other big popular libraries would be too much I'd say. What do you think?
First, everybody can read your password file, no matter if the extension is .txt or .data or whatever else. The extension is just a Windows trick to decide with which program to open the file, but it does nothing to the contents.
If you want to encrypt the password file, you'll need a key and / or a password for that, and then you need to figure out where and how to store that. You just postpone the problem.
If the file holds names and passwords of the players in your game, go with #Boris the Spider's advice: instead of saving (encrypted) passwords, just save the password's hash. When someone logs in, calculate the hash of the entered password and compare that to the hash you have saved. If they are equal, the user entered the correct password. See this question and the accepted answer for a possible way to do this.
Here's an excellent article on storing passwords securely. The examples are in C#, not Java, but it's still a helpful discussion:
https://blog.mking.io/password-security-best-practices-with-examples-in-csharp/
I also strongly recommend the book "24 Deadly Sins of Software Security" by Michael Howard and David LeBlanc as a more general overview of common security bugs and how to avoid them.
I faced a similar problem and I took resort in writing an AES encrypted string in file (in my case, users were asked to take encrypted key from administrators to put into property files, so I provided a method to encrypt password to them too) and then decrypting it in the method where I am reading it.
I have searched around for the best methods for encryption in terms of what ciphers to use, methods/etc. I'v decided on using 128Bit AES for the time being. My question lies more in what method is best for encrypting various types of data. In my example, this is for a small game I am making that has map data and associated image data.
I can save the data in any format, but would prefer something simple to read (when un-encrypted). Should I actually save this to the file itself, or should I change the file itself in some way?
Likewise in terms of the image files associated to the game that are saved as PNG or BMP files, any recommendations on how to encrypt those on top of the rest of the files?
My current method for the game data is to just encrypt it in singular lines - and have it load from a file line-by-line. Each line formatting to a different data value to be put into the system (e.g. load part of a map, maybe some item data, etc). Is there a better/faster method of accomplishing this that I may not have found yet?
I was also wondering about actually taking the entire class with the data saved and serializing it - then encrypting it. That way I could load the entire thing in one go straight into a class. Would this be a reasonable idea?
For the images: you can read them using a CipherInputStream / CipherOuputStream. Note that at least older Java versions ignored padding errors for CipherInputStream.
You cannot directly encrypt to lines as the output of a cipher is binary. So you need to encode (using e.g. Base64) if you want to store the result as lines. You may ask yourself if you want things like game data to be in text. I would recommend CBC mode with random IV prefixed to the ciphertext.
If the data is serializable then serializing data could be an option. Personally I'm not a huge fan of serialization in Java due to the many pitfalls. But yes, you can certainly encrypt serialized data easily, it's binary after all.
What I am doing is making a console blackjack for fun. I want to save the money so users can play day by day but I don't want to save it in a text file where the user can easily change the amount as they please.
I already thought of making a hidden file or a encrypted file with a password but I don't like that. I want it to be sort of like when you open some random dll file, all you see is gibberish that you can't understand.
A bulletproof way to prevent users from tampering with their stats is to store stats away from them, on a remote server. This will require users to be online during play, though. OTOH you'd be able to show a ladder of top players and so on.
An encrypted file is probably the best route if you want offline storage. You just need to hide the file properly.
Before modifying the file, read its modification time. After the update, restore the time. The user will have harder time figuring out which file has changed.
Use an innocent file used by your game with a data block inside allowed by format. It could be an XML file storing the encrypted string in a comment. It could be a JPG or PNG file storing the encrypted string in a comment or EXIF section, at a known offset (so you don't need to parse the file). WAV, OGG, MP3 also allow inclusion of non-interpreted data. This is not real steganography when you hide your data inside the actual pixel values and such, and is far easier.
I suppose you understand that a determined cracker with a disassembler and a debugger can crack this scheme. But an average user probably won't bother.
It sounds like you are talking about Steganography, but traditional encryption is probably safer and easier to implement.
You can encrypt the values within the file:
Have a look at: http://dinofilias.com/encrypt.htm
With basic encryption like this as long as the user does not have access to the key, your data is relatively secure.
You can get the effect of having a file that contains gibberish using encryption. Just save the encrypted data as bytes (not converted to ASCII representation). Since the encrypted data can have values between 0x00 and 0xFF, there will be gibberish.
Here is a simple example of how to encrypt text: http://www.exampledepot.com/egs/javax.crypto/desstring.html
I need some way to store a configuration/status file that needs to be changed rapidly. The status of each key value pair (key-value) is stored in that file. The status needs to be changed rather too rapidly as per the status of a communication (Digital multimedia broadcasting) hardware.
What is the best way to go about creating such a file? ini? XML? Any off the shelf filewriter in Java? I can't use databases.
It sounds like you need random access to update parts of the file frequently without re-writing the entire file. Design binary file format and use RandomAccessFile API to read/write it. You are going to want to use fixed number of bytes for key and for value, such that you can index into the middle of the file and update the value without having to re-write all of the following records. Basically, you would be re-implementing how a database stores a table.
Another alternative is to only store a single key-value pair per file such that the cost of re-writing the file is minor. Maybe you can think of a way to use file name as the key and only store value in the file content.
I'd be inclined to try the second option unless you are dealing with more than a few thousand records.
The obvious solution would be to put the "configuration" information into a Properties object, and then use Properties.store(...) or Properties.storeToXML(...) to save to a file output stream or writer.
You also need to do something to ensure that whatever is reading the file will see a consistent snapshot. For instance, you could write to a new file each time and do a delete / rename dance to replace the the old with the new.
But if the update rate for the file is too high, you are going to create a lot of disc traffic, and you are bound slow down your application. This is going to apply (eventually) no matter what file format / API you use. So, you may want to consider not writing to a file at all.
At some point, configuration that changes too rapidly becomes "program state" and not configuration. If it is changing so rapidly, why do you have confidence that you can meaningfully write it to, and then read it from, a filesystem?
Say more about what the status is an who the consumer of the data is...