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.
Related
I'm trying to develop a standalone software for windows in java. My goal is to have a completely standalone software which can encrypt some data and decrypt them when the user inserts a correct password. Following the standalone mindset I would love to avoid using some DB to store the data (mandatory installation of a MySQL DB sounds horrible to me), so I decided to store the data in a simple txt file, converting my java storing-data class to JSON and saving this string in the file. Obviously I would encrypt the string before saving it. The most weak part of my project (or at least in my opinion) is the login. I've come up with this idea:
using PBE from java.crypto to encrypt and decrypt data
a check string for checking the user password like "this is my check string"
I encrypt my check string using a particular algorithm, a particular salt and a particular first time password like "admin". Then I store my encrypted check string in a separate txt file. The first time the user execute the application he can log with "admin" password and then change it.
the authentication process is this: the user inputs his password, and my program tries to decrypt my check string using that password. If the decrypted string equals the original check string the log in is successful. On the contrary it gives an error message to retry cause the password is wrong.
My idea seems somehow solid to me (at least for a non professional point of view) but I've read that you can extract the source code from an exe file and this would mean that anyone can spoil my secret check string, my salt and my encryption algorithm (cause this data are all written explicitly in one of my java classes).
Since this is my first time with java.crypto and in general with a standalone authentication problem, I would love to receive some advices from someone more experienced. Anyway I have some experience with MYSQL and db in general, but I would love to have a light and not that expensive way to store data, cause i know that storing in txt files is quite "naive". Anyway I'm accepting any type of advice, especially cause I've no experience with this type of problem.
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.
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
We are encrypting our PDF with the following iText code. However, someone was able to edit our pdf (I am not sure how).
pdfWriter.setEncryption(null, null, PdfWriter.ALLOW_SCREENREADERS
| PdfWriter.ALLOW_COPY | PdfWriter.ALLOW_PRINTING,
PdfWriter.ENCRYPTION_AES_128);
Is there a better way for us to secure the pdf to prevent this?
PDF Encryption and restriction of information relies purely on the goodwill of the authors of the viewer software to enforce that restriction.
Generally speaking, every application that has enough information to display the PDF has enough information to print the PDF, there's nothing really you can do about it.
Since there are plenty of open-source PDF viewers out there, it's very easy to produce a viewer that simply ignores those restrictions.
See this explanation of the PDF encryption mechanism for more detail.
If your PDF is encrypted using 128 bits AES, then it is safe from someone that would not know the key, the most plausible explanation is that someone has had access to the key.
You may think about signing the PDF using RSA, that is a good way to make sure it has not been compromised.
Encryption which prevents the viewing of a pdf works if the password is long enough.
The DRM features which allow viewing but disable other features such as printing, editing,... only work if the reader co-operates. The user can use a hacked or third party reader to circumvent such restrictions.
Add a user password. It's the only one that really matters. As you have no doubt gathered from the other answers, the owner password is a bit of a joke.
The USER password is strong crypto... up to 256-bit AES IIRC, though the original PDF crypto spec only allowed for 40-bit encryption due to US export restrictions. Anything stronger than 40-bit was considered a "munition". Goofy laws.
The OWNER password is not, it's more courtesy than anything else. PDF libraries try to support it to one degree or another, but open source PDF libraries are a quick code change away from being "pdf crackers".
A blank user password means "use the predefined string of bytes listed in the PDF Specification that anyone can download". The contents of the PDF are still encrypted, but everyone knows the password, so it doesn't do you much good. PDF viewers/libraries substitute this string of bytes when given no password.
PS:
When calling setEncryption:
a null open password means "a blank password" as I described above
a null owner password means "generate a random one for me".
A random owner password means "no one can legitimately modify the PDF".. but that does not mean "no one can modify the PDF".
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.