This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it possible to decrypt md5 hashes?
In my website, I'm using md5 encryption for the password. So it's saving in the encrypted form in the database. For doing the password recovery, how can I decrypt the encrypted password ??
Please Help :)
As others described quite well, you cannot easily 'decrypt' an MD5 hash.
I guess the best way to do your password recovery is like this:
A user can request password recovery
by providing his email address (it should be unique so users can be identified by email address).
an email is sent to his address with a
link containing a unique hash (which
you have generated when sending the
email and saved it to the db).
when the link is clicked by the user (and
of course the unique hash is checked
to be equal with the one in the db)
you can show a form which lets them
choose a different password.
Another route that some people use is to simply ask for the email address, generate a new password and send it to the user. The problem with this one is that someone who knows only your email address can request a password change. He won't know the new pass, and you will get it by email, but still it is very inconvenient for the user.
MD5 is a hash-based encryption. What that means, is that there is no way to get back the original value. You have created something that is a "checksum" of the original data. You can use the MD5 algorithm to encrypt something else, and then compare that to the MD5'd version of the data, but you can never get back the original.
It would be similar to me saying: 5 + 3 + 2 = 10. The original data is 5, 3, and 2. But the "hash" is 10. There is no way to get the original data from the hash, but if someone supplies the correct input ( 5, 3, 2 ), I can hash it, and confirm that it matches hash that I have on file, 10.
I think MD5 is a one way hashing algorithm. What that means is that once you encrypt it, the data cannot be decrypted. (I'm sure a good hacker will disagree though)
Anyways, for passwords you can save the encrypted version of the password in the database. When a user attempts to log in, encrypt the entered password using the same MD5 algorithm, and compare the encrypted version of the password against the encrypted password stored in the database.
Once you're comfortable with this approach, you can start looking at the concept of adding salt to the hashed password.
Also, there are other hashing algorithms than just MD5. If you're using .NET, there's a bunch in the framework, such as SHA512Managed. Each one has its trade offs, such as speed to hash, security, etc. Pick one that fixes your particular problem.
You can't decrypt a md5 password! The only way would be to brute force it!
If you want to do password recovery make a random string witch will be sent to the user by email (or any other way) and set as a md5'd password... Just an idea
EDIT:
Why would you encrypt a password to keep it safe if you can decrypt it? Makes no sense! -> You could the basically leave the password unencrypted!
It's not easy, but you're best bet would be to use a rainbow table as the MD5 has does have vulnerabilities.
There are several online versions, which you may or may not be able to trust (or work).
You can try to search in a MD5 hash database like:
http://www.md5-hash.com/
http://www.md5decrypter.com/
others....
Chances are small but you can try.
Related
So I am encrypting fields in the database, but I don't think i can encrypt the user's username or email because I use those fields to find the user. I could hash them instead, but since I don't think I can use a unique salt per username/email someone could just use a rainbow table to find the hidden username/email.
I guess this it is ok to not encrypt them? I would like to make the website as secure as possible. Would hashing them make sense? I could find a user by their _id instead of username/email, but I wouldn't have their _id until I find the user.
What I am doing currently:
const user = await new db.userModel({
email: email,
username: username,
stuff: cryptr.encrypt(stuff),
});
////
const user = await db.userModel.findOne({
email: email
}).exec();
EDIT: I guess hashing would not make sense, since I cannot un-hash the username/email. Not sure what I was thinking.
This question should really be asked on infosec Stackexchange.
Encryption is usually pointless as a defense against hackers, because you need to access the key to use the encrypted database. That means that you need to save it next to the database. If your server becomes compromised, then the hacker will simply decrypt the database with the key. Of course it's better than doing nothing, because it is possible (maybe improbable) that the hacker will compromise only the database. Horatiu Jeflea hovewer mentions other important reasons to encrypt the database, which you should especially consider if you are not working on the project alone.
Hashing usernames is only possible if you don't need to display them, but usernames are usually public anyway, so it improves security very little.
Hashing emails is an interesting problem. You asked for them for a reason. You presumably need to contact your users. If you hash them, you won't be able to do it and if you don't need to do it, then you don't need to (and shouldn't) save them in the first place. If however they are only part of the authentication process, then it would be possible solution.
Rainbow tables can't really break modern hashing algorithms, although the biggest mitigation is aforementioned salt, which will make it MUCH harder for most attack on the hash. You also have to make sure that you are not using vulnerable ones like md5, but safe one like sha256 or sufficient bcrypt. You should hash the passwords with one of those. Also note that you could use the same salt for all the hashed fields and the salt could even be (this would reduce the security little bit) one of the public fields (username?). There are very little excuses for not using salt.
In summary: you can't hash them and encryption is probably not worth it unless you can sufficiently isolate the key, or need it because of something else than external hackers
I guess this it is ok to not encrypt them?
In most cases, yes. Passwords should be hashed (+ salt..) and sensitive data should be encrypted. But username or email in most cases should not be sensitive.
But let's assume they will be encrypted in DB.
You are storing encrypt(username) in your DB, so in order to search for that, instead of using username, use encrypt(username). Of course sorting may cause some headaches, but finding the user should be efficient.
Think of encrypting (in your case) not about hackers, but about people who are reading those records. For example developers who are investigating a production issue or a DBA, you want some (not all) fields hard for them to read. Storing the key on a different machine, best in a Key Management Tool, will add an extra security layer.
I have problem in encrypting my plain text in C.
I am able to write and read the file in C
Inside the text:
ID Promo Points Password Name
1 NONE 0 awdawdawd daw
Which in this case it just print password in plain text, Is it possible to encrypt the data any method, which shows like this:
ID Promo Points Password Name
1 NONE 0 ENCRYPTEDDATA daw
Of course the password wont be "ENCRYPTEDDATA", I just want it avoid plain text which user can easily see the file.
The reason I create file cause I need to read it from the file and make a login function.
My program itself able to decrypt the password when in request of checking id and password.
It can use any method only the program can encrypt and decrypt the data
Any solution guys?
If possible I also need to limit the encrypted text
You should hash password with strong hash function like SHA2 and store the hash in your file rather than storing it in plain
Hashing might be better in this case than encryption, as for encryption you will have to worry about storing key somewhere securely.
When your login function needs to validate incoming password, you can just hash incoming password and match it against the hashed password from you file
If you want to protect your login then you should use a password hash, also known as a Password Based Key Derivation Function. These functions are often, but not always, based on a secure hash. You should not use a cryptographic hash such as SHA-2 for this purposes.
Common password hashes are PBKDF2, bcrypt, scrypt and Argon2. Argon2 is the most advanced one as winner of the password hashing competition. A password hash differs from a normal hash in two important aspects:
it uses key strengthening techniques to make it harder for adversaries to use a dictionary or brute force attack (in the form of an iteration count or work factor and possibly additional memory / threading related parameters);
it uses a salt - stored with the password hash - to avoid rainbow table attacks and to avoid duplicate hash values - which would show that an identical password is being used.
So although Pras is right about not using encryption I would not recommend a secure hash unless you are sure that the password is large enough and unique. In general those restrictions can nor should be enforced on password based authentication systems.
I'm working on a website (PHP + MySQL) that I've got to upgrade. Passwords are stored in the database in MD5, and I'd like it to be something more secure, like SHA-256.
I've already red this question about "converting" password hashes, but I got an other idea, and I'd like to know if it brings a security problem or not.
Currently, the passwords are checked in php by hashing (in MD5) the given password and compare it with the hash stored in database, ie: if(md5($password) == $hash)
Let's assume that I hash all the MD5 hashes in SHA-256. I'd have the sha-256 hash of a md5 hash.
Side note: I know it's not more secure to rehash a hash, that's not the point of my question
When a user wants to connect, I'd just have to change the md5($pass) in hash('sha256', md5($password), false) to make it match the value stored in database (assuming $password is the right one)
It seemed a good idea to me as I don't need to keep track of the md5 hash after conversion, ad this doesn't need me to create any new column in my table. I know that this is not going to give me the SHA-256 hash of the original password stored with md5 hash, but this is not my goal. It's just to change the encryption method. Moreover, brute-forcing it seems inefficient, as it is very unlikely that dictionary would have hashes of words...
Does this way of doing it is flawed?
Simple hashing of passwords is insufficient, it is subject to rainbow tables and is to fast.
Instead in PHP use Safe Password Hashing: password_hash() and password_verify() or a comparable function such as PBKDF2, Bcrypt or script. These function are more secure because of two additions: a repetition count and a random salt. It's all about raising the work factor the attacker must perform.
After all, the point is to have a secure system. Just making it more inconvenient for an attacker is not the answer, there are hacking programs out there to take advantage of poor password security.
So from what I have seen it is impossible to decrypt any hashing algorithm such as MD5 or SHA-1 without brute forcing it or using rainbow tables. This seemed to confuse me on a few aspects of using hashes. These confusing points are:
What would be the point of hashing in the first place if they cant be decrypted?
How would hashed passwords be able to be used in a database?
Also since people say it is like the modulo operation, what, if anything, is preventing multiple inputs to equate to the same hash?
If somebody simply does SHA1 or MD5 on a password, then they get almost no protection.
That's why it's important to understand the right way to handle "password hashing". Please read Our password hashing has no clothes
To answer your questions:
You can verify the user without "decrypting the hash": you simply "hash" the user entered password (along with salt and other parameters) upon login and verify that it matches the expected result that is stored in the database.
See 1 and the Troy Hunt link
People who say it is like a modulo operation are making a bad analogy: they are non-experts on this subject. Anyway, the properties of the "hash" function make it hard to find collisions, and the salt prevents two users with the same password from having the same password "hashes" in the database.
Other resources:
Salted password hashing - Doing it right
Method to Protect Passwords in Databases for Web Applications -- advanced reading: solves other problems with current solutions to protecting passwords. If you wonder why I put "hash" in quotes above, this will explain it.
It's not like a modulo. A hash is reasonably guaranteed to be unique based on the input. If you enter your passwords in a database as hashes, then all you need to do is to hash the password entry and check it against what you have stored in the database. This way, you are not storing readable passwords in the database which are openly visible to others. Normally, you would have a private key, some salt and something unique like a timestamp included in your hashing algorithm to ensure that it cannot be easily spoofed.
This may help you further:
http://searchsqlserver.techtarget.com/definition/hashing
Even if the process of hashing is basically non decryptable, the problem as pointed before is that each hash is nearly unique, so that means using websites like md5decrypt which contains a lot of different words and their encrypted hashes, one may find the password he is looking for.
That is if the password isn't strong enough in the first place. Obviously one shouldn't use the password "password" for instance because it will probably be found in most of the websites like md5decrypt.
What you should do to protect passwords on your website is actually simple. First, don't use old hashes like md5 or sha1. Use at least sha256, and if you've enough sql storage, sha384 or sha512. You should know that most of the online hashes database are only about the most commonly used hashes (let's say md5,sha1,sha256 in most cases). So you should find a hash type that isn't very represented on online database.
Then you should (you have actually to) use salt when encrypt users passwords, that is add some word, letters, whatever, to the password before you encrypt it, then store that salt somewhere so you can still allow people to log in. You could also add a pepper to the salt to make the all thing stronger.
While using the salt, try to find a way that hackers won't think about, for instance double the salt, or triple it, or try different ways to concat the salt and the actual password, etc. You could also make a double encryption with double salt, like sha512(sha384()), which would be almost impossible to find.
But, please, do not store unencrypted passwords !
I'm developing simple software that does aes256-cbc encryption of a file. I'm using GNU/Linux and libgcrypt-1.5.0. The IV is randomly generated with the OpenSSL rand function and the IV is stored before the ciphertext in the output file. I'm using the PKCS#7 padding method.
Now I am in doubt about how to proceed:
It is better to use sha256 repeated 50,000 times of the inputed password to encrypt the file, or it is better to use the password given by the user?
If I want to check the correctness of the inputed password, I have to store it into the encrypted file (obviously encrypted). Is it correct to do this?
Use PBKDF2 to derive a key as indiv suggested.
Use PBKDF2 with a different salt to derive an authentication key and append a MAC to your encrypted data (after encryption is more secure than before encryption). Verify the MAC in order to check whether the password is correct or not, and that the data has not been tampered with. If you are unsure when choosing a MAC, use HMAC with SHA-512 (assuming you are using AES-256 as per your question).
Instead of using PBKDF2 twice with different paddings, you can use a single invocation of PBKDF2 to generate both the encryption and the authentication keys at the same time, by generating a key of the combined size of your encryption key and authentication key in one go.
Note that depending on the padding for deciding whether the key was good can result in CBC padding oracle attacks. For file encryption such attacks might not be applicable, depending on the exact circumstances, but it seems prudent practice to use a proper MAC for data authentication anyway, since you also want to prevent bit flipping attacks and other malicious modifications to your data.
Neither choice is correct. You need to use an algorithm made for deriving a key from a password, like PBKDF2. See the function gcry_kdf_derive.
1.It is better to use sha256 repeated 50,000 times of the inputed password to encrypt the file, or it is better to use the password given by the user?
You never use the "raw" password directly as a key. The key needs to be strectched in something hardened against brute forcing attacks. Look at the String-to-Key (S2K) stuff, or a Password Based Key Derivation Function (PBKDF) with a memory-hard hash like scrypt.
2.If I want to check the correctness of the inputed password, I have to store it into the encrypted file (obviously encrypted). Is it correct to do this?
No. You use an authenticated encryption mode like GCM. Authenticated encryption modes are specially built for the task and provide both confidentiality and authenticity.
Under the password, the encrypted file will verify or it won't. Don't concern yourself with the reason why. Otherwise, you're setting up an oracle which may undo everything from Step 1 (which may or may not be applicable here).