Encryption security in php

Asked

Viewed 1,009 times

5

I know there are other things that help keep a system secure, but I would like to know specifically about one: information encryption.

For example, the password is information that in my projects I always try to make it encrypted in the bank. My question is the following, the encryption that php provides as md5, sha1, base64_encode are already safe by itself or the combination of them makes them stronger?

To illustrate, the excerpt below:

$senha1 = md5($_POST['senha']);

$senha2 = sha1(md5($_POST['senha']));  

For some reason the variable $senha2 is safer to use than the variable $senha1?

I would like to know this, because I intend to apply in my projects.

  • 4

    MD5 and SHA1 are remarkably insecure compared to other methods, I advise to take a look at the bcrypt

  • I think my question in this case differs in some aspects from the question marked as possible duplicate. I’m being direct about the encryption, which I can use in another situation. The related question asks about how to make a secure system and this can go beyond encryption.

  • And with this talk of insecure, they’ll end up saying that they’re useless and do not play any important role, I recommend you read this.

3 answers

9


You do not store passwords in the database, instead you store their hash, and use this as a comparison at the time you have to log in.

MD5 and SHA1 are of one-way, you cannot break, but there are tables ready that have a multitude of MD5 and its meanings, as well as SHA1, I would say that SHA1 is a little safer by being little thing slower.

To make it difficult for a weak password to be exposed if your database is leaked, use some salt.

[salt]+[hash-da-senha]

Salt: Random string generated automatically and used to generate the hash result of your password, is usually saved in the database next to the hash generated.

Example of implementation

// Entrada do usuário
$input = 'minhasenha123';

// Gera o hash da senha do usuário
$hash = password_hash($input, PASSWORD_BCRYPT); 

// Hash gerado (cada vez será único)
echo $hash;

// Deve ser armazenado no banco e usado para comparação.

Let’s assume that the above code produced the following result:

$2y$10$OOCtogTSo0egjw1ZUHXndei8h/sZGNQh.iKBn9L2T4VbYvSGFEnP.

Each time it runs is unique, but we saved the hash in the database, and now we will use it to compare the login.

// Entrada do usuário no login
$input = 'minhasenha123';

/**
 * Código para pegar a hash do banco correspondente
 * ao usuário que tentou fazer login
 *
 * Aqui para exemplo, vamos usar a string, mas em sua aplicação
 * deve-se comparar qual usuário solicitou, se ele existe,
 * trazer a hash da senha usuário para uma variável, e compara-la
 * com o input do login
 */

$hash = '$2y$10$OOCtogTSo0egjw1ZUHXndei8h/sZGNQh.iKBn9L2T4VbYvSGFEnP.';

// Faz a verificação

if (password_verify($input, $hash))
{
    echo 'Usuário logado';
}
else
{
    echo 'Senha inválida';
}

I also recommend you use the PASSWORD_BCRYPT that is slower and more robust (yes, slower, it is essential to purposefully decrease performance when the subject is cryptography, so your system is less vulnerable to brute force attacks).

Note: The function password_hash is available in 5.5 or higher versions of PHP.

This is the simplest implementation and has enough security.

5

Information security is a much more complex issue than choosing this or that model.

Security is always something connected to us humans. Passwords, for example, only need to exist to prevent that those who do not own such information may have free access to them.

Passwords are like locks on any door. In a safe or low-risk environment, there is no need for complex locks. No one puts a lock on the dog’s house. On the other hand, no one will put a lock on the door of a bank vault.

Any encryption model has flaws. The safer, the more expensive to maintain.

No use having a 4096-bit password encryption system if the password moves open between the form and the access code.

The most basic security model of a WEB system passes mainly through the data point of origin. If there is a real need for security, you have to start with the environment that should be SSL. Only from this should one think about opting for this or that access key model.

For systems with low risk of leaking useful information, using md5 or sha1 already solves.

In time, base64 is not hash and should never be used as encryption. It serves to transform a string with characters harmful in strings with purely ASCII characters.

2

md5 and sha1 although they are single-handed (cannot be reversed), there are several Rainbow Tables with multiple passwords generated with these hashes.

A technique that could be applied would be the use of salt, which is a concatenation of a text before its password, and only then applied the hash, to generate hashes different from those already existing in Rainbow Tables.

The problem with that is that any malicious person with your salt can still generate a Rainbow table, so I believe the safest way today is to use dynamic salt with algorithms that are relatively heavy for mass generation but fast enough not to disrupt common use.

Today these techniques are used in function bcrypt

Browser other questions tagged

You are not signed in. Login or sign up in order to post.