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.
Related
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 am developing an android application through which i am sending a mail via GMAIL API.
To send mail via GMAIL API i have to give them my ID and password.
GMailSender m = new GMailSender("myemailhere#gmail.com",
"mypasswordhere");
and i know writing password like this is not at all safe as my password could easily be stolen by extracting my apk and alsostoring the password in strings.xml is also not secure as xml can also retrieved.
my question is-
Is there any other way to write password in my file so that it remain secure??
The short answer is not. You shouldn't store your password anywhere in the code or in any file.
Even if you encrypt it like someone said you will have to store it's decryption algorithm/key somewhere in the code, which will be easily reverse engineered.
No,It's not safe to store passwords on the device.
small advice is always store passwords in char[] in encrypted form rather than storing in a String whenever it is mandatory to store.
Since Strings are immutable in Java if you store password as plain text it will be available in memory until Garbage collector clears it and since Strings are used in String pool for re-usability there is pretty high chance that it will be remain in memory for long duration, which pose a security threat. Since any one who has access to memory dump can find the password in clear text and that's another reason you should always use an encrypted password than plain text. Since Strings are immutable there is no way contents of Strings can be changed because any change will produce new String. So Storing password in character array clearly mitigates security risk of stealing password.
Storing passwords is not considered safe, and shouldn't be done if at all avoidable. There are a few considerations, if you have to for some reason.
The best place to store such things is in private SharedPreferences. These are not readable by anything but the app, or rooted devices. Do not store on external storage!!!
Encryption can always be undone, but if you have to, then it would be better than nothing, requiring more work to undo. Use a key which is unique to each device.
Some sort of a token, such as is used by Oauth, could be a solution. This isn't perfectly secure either, but it could be.
Google provides more secure APIs for it's functions. You really should look in to that.
I am using jBCrypt for hashing the password and storing it in database. As it is one way algorithm we cannot get the password (original plain password string).
When the user forgets the password I guess we cannot provide the password instead we can only ask the user to set the new password. Is my opinion Correct?
Is there any way to retrieve the plain text password back when hashed with jBCrypt (from the hashed one? :-) .. I don't think so ... )
No, there isn't. That's the whole point of using a hash function.
There is a method - brute force cracking till you have a match. But that not an option.
Anyway - I wouldn't trust any service that will be able to tell me "hej dantuch, seems you forgot you password, so it was YOUR_SECRET_PASSWORD"... It'd mean it was stored as plain text or something like that.
Okay, I am working on an application and I want to store a file on the user's SD Card, but I want the file encrypted. I've researched several sites that use the DES encryption to encrypt files and data, but I am confused about something. All the examples I'm seen use a line like this:
SecretKey key = KeyGenerator.getInstance("DES").generateKey();
The problem I am having is that I get my key to encrypt and obviously I need the same key to decrypt. But its seems like a paradox because if I store my key in a file or in a database, can't someone get the key and decrypt my file? Maybe I am missing something, but is there a way to generate a key using a supplied pass phrase? And why would someone not want to use a passkey if they must store the generated key somewhere else?
I think there are two cases:
You trust the user - let the key be dependent on some input (password / passphrase). and encrypt / decrypt the data with it.
You don't trust the user - then you're in trouble, you might obfuscate the encryption / decryption algorithm, but as long as the mechanism + key is stored on the device, you will have this problem.
This applies to both symmetric and asymmetric encryption.
First of all, please don't use DES. It has been broken from many years. Use AES instead.
The problem I am having is that I get
my key to encrypt and obviously I need
the same key to decrypt.
If you use symmetric cryptography techniques this is it. Otherwise have a look to asimmetric encryption.
But its seems like a paradox because
if I store my key in a file or in a
database, can't someone get the key
and decrypt my file?
Yes, someone could do it.
Maybe I am missing something, but is there a way to generate a key using a supplied pass phrase?
You don't use a the key using a passphrase. Usually you do the following things:
key generation
encrypt the key generated with a symmetric key derived from a passphrase
And why would someone not want to use
a passkey if they must store the
generated key somewhere else?
There could be several reasons. For example you can store the key in a removable device, and you want simply connect it to your computer for retrieving the key, without entering the passphrase.
Having a passphrase has its disadvantage too: passphrase must be remembered, can be guessed, if it's too long probably you'll write it down (and that's pretty the same thing then storing it in a file )
EDIT:
to generate a key from a password have a look at PBKDF2 (related post).
Yeah, it is possible to use a pass-phrase to encrypt.
But first, dump DES. Use AES-128.
Accept the pass-phrase from the user and and generate the hash using SHA-256 or SHA-512. Trim the hash to 128 bits for AES-128. Refer this post.
Java AES and using my own Key
Use a salt when you can.
Regarding the storage of password part. Store the hash and not the password. This way you can prevent the attacker from generating the key. Ask the user to enter strong password. And don't forget that your salt must be very strong too.
So, in the end, you store only the hash of the password. The password is not stored and the key to decrypt will not be stored(It will be generated at run-time)
Hope it helps.
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.