I have a old database where password is in Hashed format,i need to decrypt hashed password.Is there any method in membership to decrypt hash password.
The hash is probably designed to be one way. If you know the hashing algorithm used you could use brute force, but otherwise no, there is no way to "decrypt" the password.
Related
I was looking about how to salt a password in PowerShell, as SHA512 is not the safest way to store them, I want to add a salt to reduce bruteforcing.
Is there any way to add a salt to a password and then store it, to next at the moment on authenticate use the appropiate salt?
For example let's say my password is "foo" and the website is using a md5 hash on passwords with a unique salt appended to it.
So when I register my password will be stored as "foo" with a salt appended to it and then md5 hashed.
Then when I send a login request the website will append a salt to "foo" and then md5 hash it, but how will the website know what the correct unique salt to use is?
How will the website magically know the correct unique salt to append to my password which is then md5 hashed, to verify the password I entered is equal to the md5 hashed salted password in the database?
This is the usual process of handling passwords:
User registers with a password.
A new data record is created for their user ID (which can come in the form of username or email, etc.)
Their password is handled:
A salt is generated for them, and that salt is saved in the data record. It's very common and recommended that the salt is visible right next to the password hash.
The password is combined with the salt (typically a library handles even this step for you, as any little nuance like appending salt matters a lot in security).
The password is hashed using a function designed for password hashing. This is usually quite computationally expensive to frustrate brute force attempts.
The password hash is stored in the data record, and the original password is discarded.
Then when they log in, there's no magic here:
The data record is looked up using their user ID.
The password they give is combined with the salt from the data record and then hashed.
If it matches the hash stored, they are granted access.
Some notes:
Password hashing is expensive. I don't think it's uncommon for it to take more than 1 whole second of computing time. Imagine the processing load if a thousand people are logging in at once.
A lot of things can go wrong if you aren't using a decent library to handle password hashing. Writing any of the steps yourself is not recommended.
It's common for libraries to output a coded string that contains everything you need to verify against a password, such as a version code, the hash, and the salt used.
How can I Decrypt the code which is Encrypted by md5 method in PostgreSQL.
eg: md5("logesh") returns '82e05c4839aba7c637881489bec50dd1'
How can I decrypted this code.
You can't. MD5 isn't encryption. It's a one-way cryptographic hash function. With enough compute power and/or storage you can brute force md5 to figure out what the plaintext might have been but it's only one possible plaintext for that hash. It's designed to be both slow and difficult to reverse, and impossible to reverse 1:1. There are known MD5 collisions.
PostgreSQL's use of "encrypt" in WITH ENCRYPTED PASSWORD is somewhat incorrect, it should really be WITH HASHED PASSWORD. But too late to change it now.
If you want encryption look into pgcrypto which offers AES-128 routines, etc. Or do your encryption and decryption client-side where key exposure in logs, pg_stat_statements etc isn't such a concern.
I know about storing passwords as salted hashes and I know it is even safe enough for Linux.
But even before I knew this, I was wondering if it is safe to store a password in an AES container encrypted with the password itself.
In case my question got incomprehensible, some pythonish pseudo code:
AES(data=password, key=password)
No, that is not as safe as using a Password Based Key Derivation Function. The most important issue with passwords are dictionary and brute force attacks - trying passwords, in other words. Now the outcome of AES(data=password, key=password) is always the same value (as the calculation does not contain any salt). This means that building a rainbow table is possible. Furthermore, AES is a very fast, so it is very easy for attackers to check many passwords.
So you are much better off using a PBKDF such as PBKDF2, bcrypt or scrypt, with a high iteration count and at least 64 bits of random salt.
Ok, I’m trying to understand the reason to use salt.
When a user registers I generate a unique salt for him/her that I store in DB. Then I hash it and the password with SHA1. And when he/she is logging in I re-hash it with sha1($salt.$password).
But if someone hacks my database he can see the hashed password AND the salt.
Is that harder to crack than just hashing the password with out salt? I don’t understand …
Sorry if I’m stupid …
If you don't use a salt then an attacker can precompute a password<->hash database offline even before they've broken into your server. Adding a salt massively increases the size of that database, making it harder to perform such an attack.
Also, once they've broken in they can guess a commonly used password, hash it, and then check all of the passwords in the database for a match. With a different salt for each user, they can only attack one password at a time.
There's an article at Wikipedia about salts in cryptography.
Another intention behind the use of a salt is to make sure two users with the same password won't end up having the same hash in the users table (assuming their salt are not the same). However, the combination of a salt and a password may lead to the same "string" or hash in the end and the hash will be exactly the same, so make sure to use a combination of salt and password where two different combination won't lead to the same hash.
If an attacker creates a giant table of hash values for plaintext passwords, using a salt prevents him from using the same table to crack more than one password. The attacker would have to generate a separate table for each salt. Note that for this to actually work propertly, your salt should be rather long. Otherwise the attacker's precomputed table is likely to contain the salt+password hash anyway.