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.
Related
As an ordinary method, I always used to save MD5 of passwords in database while there are many websites that decode the MD5 hashed data to its original data (using rainbow database).
I wonder if it is more safe to modify the output of MD5 function (e.g. omitting the last character of MD5 output to create a new hashed data)? or there is a logic behind the MD5 that makes is more safe than every modified version?
No this doesn't do much good to make your passwords more secure. It adds a bit of "security by obscurity", but when we hash passwords, we prepare for the case where the attacker knows the hashes and the algorithm.
The problem with MD5 in general and with derivations is, that they can be calculated ways too fast. With common hardware you can calculate 8Giga MD5/s, which makes brute-forcing too easy. Todays password cracker tools do not only offer plain MD5 hashes, you can calculate also derivations, e.g. md5(strtoupper(md5($pass))) out of the box.
For a secure storing of passwords you need a slow hash function like BCrypt, PBKDF2 or SCrypt with a cost factor. Of course they should be salted with a unique salt per password.
Perhaps you should consider a different hashing algorithm instead?
https://security.stackexchange.com/questions/4789/most-secure-password-hash-algorithms
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.
I have oracle database to move on to new postgresql server.
Some tables are having field sesitive and those are all encryted through DBMS_OBFUSCATION_TOOLKIT.DESENCRYPT/DESDECRYPT.
The problem is here. The size of postgresql's encrypted data size(bytea type) should be the same with oracle's.
I tried to get it done with aes(encrypt/decrypt) which takes almost three times larger than raw data.(oracle takes 16byte with des algorithm, postgresql takes 33byte with aes and the raw data is of 13byte.)
I tried the postgresql crypt also, but the manual doesn't metion the way of decrypting it back limiting 8byte of raw data size.
Now i really need encrypt method which takes as small encryted data size as possible and provides decrypt method also.
Is there a good way or the other options for me???
Thanks in advance.
Crypt and DES are old cyphers and should not be used
Plain old DES is an obsolete algorithm. You can't really usefully compare it to AES128; it's like complaining that a SHA256 hash is bigger than an MD5 hash - yep, it is, but only one of them might slow the attacker down for a while. DES was widely considered weak even in 1999 and should never be used in new applications. Do not use it.
I don't think it's a good idea to seek an encryption method that "provides the smallest data size possible" - because it's basically a waste of time to encrypt data using DES. Why not use ROT13 (caesar cypher)? The "encrypted" result is the same size as the input, pity the encryption can be broken by a 3-year-old.
crypt is of a similar vintage. The old UNIX crypt hashing algorithm is ... elderly ... and totally unsuitable for any new application. Hashes should be SHA256 at minimum, really.
Crypt is a one-way hash
As for not being able to figure out how to decrypt crypted data: crypt isn't an encryption algorithm, it's a cryptographic hash function or "one way hash". One way hashes are suitable for verifying that data is unmodified, comparing to a stored salted hash for password authentication, for use in challenge-response authentication, etc. You cannot decrypt crypted data.
Deal with the size
Use a decent cryptographic function and live with the size increase. bf or aes128 are about the weakest you can reasonably use.
Personally I prefer to do my encryption/decryption in the app, not in the DB. If it's done in the DB the keys can be revealed by pg_stat_statements, in the logs by log_statement or errors, etc. Better that the key never be in the same place as the stored data at all.
Most programming languages have good cryptographic routines you can use.
It's hard to offer any more advice as you haven't really explained what you're encrypting, why, what your requirements are, what the threat(s) are, etc.
Passwords?
If you're storing passwords, you're probably doing it wrong.
If possible, let someone else do the authentication:
OAuth or OpenID for Internet
SSPI, Kerberos/GSSAPI, Active Directory, LDAP bind, SASL, HTTP DIGEST, etc for intranet
If you really must do the auth yourself, add a salt to the passwords and hash the result. Store the hash and the salt. When you must compare passwords, salt the new plaintext from the user with the same salt you used for the stored hash, hash the new password+salt, and see if the hash is the same as what you stored. If it is, they gave the right password.
You almost certainly don't need to recover cleartext passwords. Implement a secure password reset instead. If you really, really must, use a decently secure algorithm like aes to encrypt them and think carefully about key storage and management. See other posts on SO about key storage/management with pgcrypto.
See also:
Secure method for storing/retrieving a PGP private key and passphrase?
Depending on how your postgresql was built, it may have DES support in the pgcrypto module. It depends on if Postgres was configured with OpenSSL support as it relies on OpenSSL to do DES (while with other more modern algorithms it implements them itself).
PGCrypto Algorithms
If openssl support was included and you specify DES as the algorithm to encrypt and decrypt, the data should be the same as you get from Oracle (although you may need to specify padding options).
As Craig says though, the DES algorithm is weak and one of the reasons it is weak is because the output ciphertext is so small.
For my iPhone application, Apple wants to know if my password encryption (md5) is greater then 64-bit symmetric or greater then 1024-bit symmetric. I have not been able to find it online, so I am wondering if anyone knows the answer. In addition, is this considered an appropriate encryption technology for passwords, or should I use something different?
Thanks for any help!
MD5 is a hashing function, thus by definition it is not reversible. This is not the case for encryption (either symmetric or asymmetric), which has to be reversible to be useful.
To be more precise, hashes are one-way functions, in that an infinite number of inputs can map to a single output, thus it is impossible to obtain the exact input, with certainty, that resulted in a given output.
However, it may be possible to find a different input that hashes to the same output. This is called a collision.
Generally, hashing passwords instead of storing the plain text (even encrypted) is a good idea. (Even better if using a salt) However, MD5 has known weaknesses (and large collections of rainbow tables that aid in finding collisions), thus it would be a good idea to switch to something like SHA-1 or one of the SHA-2 family of hashes.
However, to answer your original question, there is really is no way to compare MD5 or any hash against any type of encryption; they have no equivalents because it's like comparing apples and oranges.
md5 isn't really symmetric or asymmetric encryption because it isn't reversible either symmetrically or asymmetrically. It's a Message Digest (secure hash) algorithm.
It's not encryption, it's a digest. If you didn't salt it, it's not particularly secure, but they're asking you the wrong question.
What exactly are you doing with MD5 and passwords? There are standard ways of doing things here, and it's always better to use one, but without knowing what you want to do it's hard to point you at a relevant standard.
It is NOT encryption at all.
Apple asks the question about the use of MD5 for hashing passwords to see if it requires authorization for export from the Department of Commerce/Bureau of Industry and Security.
The answer for that purpose is that using MD5 for password protection is not controlled as strong encryption (like symmetric algorithms in excess of 64 bits) in accord with the Technical Note to 15 CFR part 774, Supplement 1, ECCN 5A002, paragraph a.1, which describes using encryption for password protection. However, it may still be controlled under ECCN 5A992.
http://www.bis.doc.gov/encryption/ccl5pt2.pdf
The other answers are not helpful in the context of why the question was asked.
Also, you may want to call the Department of Commerce/Bureau of Industry and Security at 202-482-0707 and ask about your specific application.
Hash function most of times is a way to compress your data. They are one-way hash functions, meaning that are difficult to reversed(having the hash function=digest of a message it is difficult to find the original message that is converted to the specific hash value). On the other hand, are very easy to implemented because there is no need of any type of key.
It is not a symmetric or asymmetric algorithm. These kind of algorithms are used to encrypt and not to hash data. Encryption is used for confidentiality reasons, to protect data from attackers where they try to read someone's.
Encryption or cipher algorithms need keys to perform their tasks in contrast to hashes where they do not need any kind of key. Hashes are not used for confidentiality reasons but for integrity reasons even if they do not have enough strength. MD5 is one type of a hash function where exists many others because MD5 is not strong enough
I think MD5 is used for better security.... if we tell about any encryption or decryption algorithm, they are just for converting any plain text into cipher text... but on the other hand MD5 provides an uniqueness on that plain text that would be sent by any source(Alice)...so we can say that for better security or for providing envelop on plain text MD5 should be used before using any encryption algothim(symmetric or asymmetric).
As the numerous other guys on here have mentioned, MD5 is not a symmetric or an asymmetric algorithm.
Instead it comes under a different branch in cryptography all together. It's one of the smallest hashing algorithms available in the .Net framework. At a mere 16bytes for its keysizes, which should be 128 bit. Something that you learn your bread and butter with.
So yes it is greater than 64bit which is only 8bytes in size.
The maximum key size the common symm' enc' algs use is 256bit (Rijndael Managed).
If you want to be looking at keysizes greater than that, then you can use the RC2 symm' enc' algs which supports variable key sizes. Something that you can experiment with?
If you want higher than 1024bit, then you need to be looking at Asymm' Enc' Algs like the RSACryptoServiceProvider class which supports key sizes going upto 16K in Bits I think?
If you want to use passwords, then you need to use Keyed Hashing Algs, like anything HMAC' something, they should be Keyed Hashing Algorithms or MacTripleDes. These all use secret keyes to encrypt the hash that is generated from the data you supply. The keys are created by using passwords and salt values via the RFC2898DerivesBytes class. <-- Don't forget that RC2, Rijndael, AES, DES and etc all can be set-up to use passwords to help derive the secret keys. In case you are thinking that the opening sentence of this paragraph is a little misleading. So i added this just to be sure in the event that hashing is not what you need altogether.
*REMEMBER THAT THERE ARE UNIQUE INHERITANCE HIERARCHIES IN .net's Cryptography NameSpace.
So MD5 is the base Abstract class all MD5 Derived classes are to derive from. .Net provides one such derived class that is called MD5CryptoServiceProvider class. Which is essentially a managed wrapper class that makes call to windows unmanaged Crypto-Libraries API. MD5 is known in MS official textbooks under the umbrella term as a Non-Keyed Hashing Algorithm. *
There are plenty of options available to you.
: ) Enjoy !
I remember a guy telling me that if I let him change 4 bytes he can make a file have any checksum he wants (CRC-32).
I heard mention of salting a hash. I am wondering if someone had his file match my file would salting the MD5 or SHA-1 hash change the result so both files no longer collide? Or does it change the end hash value only?
You are mixing up two different uses of hash values:
Checksumming for guarding against random (non-malicious) errors.
Computing cryptographical message digests for storing passwords, signing messages, certificates ...
CRCs are a good choice for the first application, but totally unsuited for the second, because it is easy to compute a collision (in math-speak: CRCs are linear). This is what your friend is essentially telling you.
MD5 and SHA1 are cryptographic hashes intended for the second kind of application. However, MD5 has been cracked and SHA1 is considered weak these days. Still, even though MD5 can be cracked it takes a long time to find MD5 collisions (days to weeks).
As for salt, it makes the computation of the cryptographic hash local by mixing in some random non-secret value, this value is called the salt. This prevents computing global tables which make it easy to compute possible values (e.g. passwords) from the hash value. The computation of the tables is extremely expensive, but without salt the cost would be amortized over many cracked passwords.
The attack (against CRC-32) is irrelevant if the hash you are using is not CRC-32 - MD5 and SHA-1 are not vulnerable to that kind of attack (yet).
The current attacks against MD5 are where an attacker creates two documents with the same hash.
Salts are used for password verification - they prevent an attacker performing an offline attack against the password database - each user's password has a salt attached to the plain-text before the hashing - then a pre-computed rainbow table of plaintext <-> hashed text is useless.
Adding salt to your hash function doesn't really serve any purpose if the digest function has been compromised, because the salt will have to be made public to be used, and the attacker can adjust their file to factor this in too.
The solution to this problem is to use a secure hash function. MD5 has shown to be vulnerable to hash collision, but I believe SHA-1 has not (so far).
Salting is usually used in password hashes to avoid dictionary attacks. There are plenty of web based reverse hash dictionaries where you enter the hash (say: 1a79a4d60de6718e8e5b326e338ae533) and get back the text: "example". With salt, this becomes next to impossible. If you prepend a password with random salt, the dictionary attack become more difficult.
As for collisions, I don't think you need to worry about entire files having the same md5 or sha1 hash. it's not important. The important use of the hash is to prove the file you receive is the same as the file that was approved by someone who is an authority on the file. If you add salt to the file, you need to send the salt so the user can verify the hash.
This actually makes it easier for the attacker to spoof your file because he can provide a false salt along with the false file. The user can usually tell if the file is faked because it no longer serves the purpose it is supposed to. But how is the user supposed to know the difference between the correct salt and the attacker's salt?