Modelo de almacenamiento encriptado

SSL/SSH proteje los datos que viajan desde el cliente al servidor: SSL/SSH no proteje los datos persistentes almacenados en una base de datos. SSL es un protocolo para proteger los datos mientras viajan en el cable.

Una vez un atacante gana acceso directamente a su base de datos (sobre pasando el servidor web), los datos sensibles podrían ser divulgados o mal utilizados, a menos que la información esté protegida en la base de datos por sí misma. Encriptando los datos es una buena forma de mitigar esta amenaza, pero muy pocas bases de datos ofrecen este tipo de encripción de datos.

La forma más fácil para trabajar en este problema, es crear primero su propio paquete de encripción, y utilizarlo desde de sus scripts de PHP. PHP puede guiarle en esto con muchas extensiones, tales como Mcrypt y Mhash, cubriendo así, una amplia variedad de algoritmos de encripción. El script encripta los datos antes de insertarlos dentro de la base de datos, y los desencripta cuando los devuelve. Vea las referencias para ejemplos adicionales de como funciona la encripción.

En caso de datos que deben estar ocultos, si no fuera necesario usar su representación real (es decir, que no se mostrarán), quizás convenga utilizar hashing. El ejemplo más típico de hashing es cuando se almacena el hash MD5 de una contraseña en una base de datos, en lugar de almacenar la contraseña en sí misma. Vea también las funciones crypt() y md5().

Ejemplo #1 Utilizando campos de contraseña con hash


// Almacenando la contraseña con hash
// $random_chars se obtuvo, p.ej., usando /dev/random
$query  sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
pg_escape_string(crypt($password'$2a$07$' $random_chars '$')));
$result pg_query($connection$query);

// Consultando si el usuario envió la contraseña correcta
$query sprintf("SELECT pwd FROM users WHERE name='%s';",
$row pg_fetch_assoc(pg_query($connection$query));

if (
$row && crypt($password$row['pwd']) == $row['pwd']) {
'Bienvenido, ' htmlspecialchars($username) . '!';
} else {
'La autenticación ha fallado para ' htmlspecialchars($username) . '.';

add a note add a note

User Contributed Notes 5 notes

seigoryu at hotmail dot de
2 years ago
I would strongly recommend using SHA-2 or better the new SHA-3 hash algorithm. MD5 is practically unusable, since there are very well working rainbow tables around the whole web. Almost the same for SHA-1. Of course you should never do a hash without salting!
3 years ago
Using functions to obfuscate the hash generation does not increase security. This is security by obscurity. The algorithm used to hash the data needs to be secure by itself.

I would not suggest to use other data as salt. For example if you use the username, you won't be able to change the values without rehashing the password.

I would use a dedicated salt value stored in the same database table.

Why? Because a lot of users use the same login credentials on different web services. And in case another service also uses the username as salt, the resulting hashed password might be the same!

Also an attacker may prepare a rainbow table with prehashed passwords using the username and other known data as salt. Using random data would easily prevent this with little programming effort.
8 years ago
A better way to hash would be to use a separate salt for each user. Changing the salt upon each password update will ensure the hashes do not become stale.
mrgarett at gmail dot com
5 months ago
I am not sure if this method is secure but i encrypt a users password with mcrypt and save the random character salt to a file that is protected by the web server. The filename is there unique id + date registered encrypted with standard md5.

For extra security if the ip address is not the normal ip address i send a little notification to there email.
Fairydave at the location of
9 years ago
I think the best way to have a salt is not to randomly generate one or store a fixed one. Often more than just a password is saved, so use the extra data. Use things like the username, signup date, user ID, anything which is saved in the same table. That way you save on space used by not storing the salt for each user.

Although your method can always be broken if the hacker gets access to your database AND your file, you can make it more difficult. Use different user data depending on random things, the code doesn't need to make sense, just produce the same result each time. For example:

if ((asc(username character 5) > asc(username character 2))
   if (month the account created > 6)
      salt = ddmmyyyy of account created date
      salt = yyyyddmm of account created date
   if (day of account created > 15)
      salt = user id * asc(username character 3)
      salt = user id + asc(username character 1) + asc(username character 4)

This wont prevent them from reading passwords when they have both database and file access, but it will confuse them and slow them up without much more processing power required to create a random salt
To Top