If I have the following code $senha = md5("senha") and I send it to the $senha database, it should be possible to retrieve this MD5 in the database and show "password" back on an information update form, / p>
Is this possible or a string encrypted in MD5 can not be decrypted?
This is not possible.
The MD5 string does not have the information that was encrypted in its contents. It is a unique representation of the original string but its contents do not have an encrypted version of the original content.
MD5 is referred to as a unidirectional function, ie once encrypted it has no way to decrypt.
To understand better it can be said that what is stored in the database is not the password but the MD5 representation of it. When you enter the password again the MD5 will generate the same string and it will work, but the password is lost / changed by the new string encrypted in MD5.
An MD5 string has 128 bits, regardless of the size of the original content. That means there are 2 128 possible hashes.
You can take a look here at a good question and answers in English in SOen
MD5 is a technique for generating a hash a>. It is a code that looks for a unique representation of an information (there are no guarantees that there are no collisions - even code for two different information). It is not meant to encrypt information. This should have been clear from what has already been said here in comments and answers. This is used to create a data access difficulty.
The problem with MD5 is that it is possible to break the security of it . It is not something simple to do but is possible . If you really want to do this, it's good to prepare not only to study the subject a lot but also to be willing to get what you want. Breaking security is not the same as discovering your original content.
There is no reason to reverse a password encoding other than to do something illegal. If you are wanting to break a password that you can (even on your systems, in every way) breaking a password may be illegal. If you have lost your password, create another, do not try to find out what the password was.
If you just want to compare to see if the password sent to the system is valid then you should apply the MD5 hash in it and compare the two hashes . Anyway simply using pure MD5 is not good practice (read the link above).
If you need to encrypt something that depends on reversal, decryption, for some reason, you should use an algorithm that allows this ( symmetric encryption ). Of course, such an algorithm has its shortcomings in terms of security. Reversible algorithms have the basis of security by hiding the encryption key. If someone has the key, the encryption is compromised. Then the problem is to protect the key well. But as far as I know, no one has been able to solve this problem better.
In cases where this is important it is common to use keys that complement each other to carry out the operation. This is used in encryption for content and communication encoding as used in SSL, file encryption, and pay-TV channels ( asymmetric encryption ).
In some cases the key may change frequently making your discovery and use more difficult. When someone discovers the key it is no longer used. Of course this is most useful in unstable content (TV broadcasting for example). It is possible to apply to a disk file but it is laborious to do this in a minimally secure way.
Breaking security often uses several techniques together. And the most used is the social engineering , is to use 171 ( origin of the popular term) to get what you want. Humans are much easier to dribble than equipment, rather than math.
Try this .
MD5, speaking in popular language, is a single-path hash .
There is no information to reverse the hash to the original value.
Several websites offer solutions to "reverse" the hash a few years ago and this causes some confusion because anyone who does not understand the subject eventually believes that MD5 is reversible. What these sites offer is called rainbow table . The technique consists of the same logic as a
force .
Rainbow tables are just a database containing strings and their values in MD5.
This scheme works only for hashes without a "jump".
The logic is simple. A script automatically generates, in an "infinite loop," all kinds of possible character combinations. Within this loop repetition, the MD5 hash of that combination is also generated and saved in a database, which has a nickname known as "rainbow table".
Currently, several sites guarantee to have combinations of 5 full characters and almost completing 6 characters.
To understand better, see an example of the logic involved:
Combinations of size 1 characters and their MD5
a -> 0cc175b9c0f1b6a831c399e269772661
b -> 92eb5ffee6ae2fec3ad71c777531578f
c -> 4a8a08f09d37b73795649038408b5f33
And so it goes on until it generates the MD5 of all character types, including multibyte numbers and characters
あ -> 8c0c3027e3cfc3d644caab3847a505b0
い -> 655dcb0e6519c34baf6d9d53e1932389
う -> 31e55ff7f86aaee740277059a9983d89
□ -> 8c8586b6fb99a8815eeec4ea97e6222d
It seems easy to generate hashes, however, you have to create the combinations. Here is an example of size 2:
ab -> 187ef4436122d1cc2f40dc2b92f0eba0
ac -> e2075474294983e013ee4dd2201c7a73
ba -> 07159c47ee1b19ae4fb9c40d480856c4
bc -> 5360af35bde9ebd8f01f492dc059593c
ca -> 5435c69ed3bcc5b2e4d580e393e373d3
cb -> d0d7fdb6977b26929fb68c6083c0b439
So far it seems easy, but imagine 5 combinations. How many possible combinations are there in 5 houses?
abcde -> ab56b4d92b40713acc5af89985d4b786
acbde -> e0e56a95aff0ee48fc44e8a4faf69adb
adbce -> a44a7eb2135809f67ce273e0de8b52cb
Even with size 5, it does not seem difficult if you only deal with Roman alphabet and numbers, but remember that you should also include special / multibyte characters. At that point the combinations go from trillions of records.
How do these sites return the value of a hash?
Only querying the database.
select original from rainbowtable where hash = 'ab56b4d92b40713acc5af89985d4b786'
This would return "abcde" if it has already been previously saved in the database.
Therefore, it is recommended to avoid short passwords, less than 6 characters and also passwords containing simple characters.
Simple password example, where, of course, rainbow tables sites already have their hashes:
abc
111
123
abc123
senha
passord
user
admin
123456
111111
When creating a password, try to do at least something like this:
j&SCjV:Kd#A!6VN7x=eY
Mix special characters, uppercase and lowercase letters, numbers. Finally, the larger and more complex the smaller the possibility of existing in a rainbow table or being broken by brute force .
Password Recovery
It should be possible to retrieve this MD5 in the database and display "password" from back in an information update form, do not you?
A website that returns the original password to the user is unsafe. When you find a site that does this, avoid using it if you have important information, especially financial transactions.
A website that can see the password entered by the user, violates privacy and basic security standards because even a hosting server administrator or the site programmer can be malicious and obtain the passwords of the users.
An aggravating factor in this is that most users use the same password for everything. Email services, social networking accounts, even a credit card password.
That is, if you can get the password, you will have the passport for almost all or all of the accounts that this user has on third party services.
The same 1234 password, which is used on facebook, also uses credit card, debit card, email and various services. Unfortunately the user relinquishes his own security for "practicality".
(The term * facebook is a simple example. Of course facebook does not allow such a password)
At this point comes the responsibility of service providers to force the user to create complex passwords. The complexity depends on the service business model.
Final note , there are also raibow tables from other hashes such as sha1, des, crypt16, among others.
When you encrypt a password and write to the database, you do not need to decrypt to see if it is correct. You should encrypt the one that was entered at the time of authentication and compare with the one that was written to the database.
select *
from user
where usuario = usuario_informado
and senha = md5(senha_informada)