PHP 5.5.37 is released

Modèle de stockage avec chiffrement

Les protocoles SSL/SSH protègent les données qui circulent entre le serveur et le client : SSL/SSH ne protège pas les données une fois dans la base. SSL est un protocole en ligne.

Une fois que le pirate a obtenu l'accès direct à votre base de données (en contournant le serveur web), les données sensibles, stockées dans votre base sont accessibles directement, à moins que les données de la base ne soient protégées par la base. Chiffrer les données est une bonne solution pour réduire cette menace, mais très peu de bases de données offrent ce type de chiffrement.

Le moyen le plus simple pour contourner ce problème est de créer votre propre logiciel de chiffrement, et de l'utiliser dans vos scripts PHP. PHP peut vous aider dans cette tâche grâce aux nombreuses extensions dont il dispose, comme Mcrypt et Mhash, qui connaissent un large éventail de méthodes de chiffrement. Le script PHP va chiffrer les données qui seront stockées, et les déchiffrer lorsqu'elles seront relues. Voyez la suite pour des exemples d'utilisation de ce chiffrement.

Dans le cas de données vraiment sensibles, si la représentation originale n'est pas nécessaire (pour affichage, ou comparaison), utiliser un hash est une bonne solution. L'exemple classique est le stockage de mots de passe dans les bases de données, après les avoir passés au en hashage de cryptage. Voyez la fonction crypt().

Exemple #1 Utiliser un mot de passe et MD5

// Stockage du mot de passe hashé
// $random_chars récupéré en utilisant /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);

// Interroger le serveur pour comparer le mot de passe soumis
$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']) {
'Bienvenue, ' htmlspecialchars($username) . '!';
} else {
'Identification échouée pour ' htmlspecialchars($username) . '.';
add a note add a note

User Contributed Notes 6 notes

seigoryu at hotmail dot de
3 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!
5 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.
9 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.
about2mount at gmail dot com
1 year ago
It's difficult to post scripts here for all to view on the subject of best security practices. But i would wish to point out that using a salt with a randomized and odd numbered long length salt value is do_able with two Php functions while retrieving and separating the salt when it comes out using simple math functions. But with everything we add we also have to think of the constant standardized login systems we stay behind with.

For one,,, adding and validating two to four passwords is not a bad idea.  Also having no username or email going in. They can be stored after the user logs in after the validation process.  It is possible to store the email on the first signup and only at that time. And if the user loses his passwords then validate by email only upon request within a contact form by a validated phone number stored in the database,, and then via their email account.
Fairydave at the location of
10 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
mrgarett at gmail dot com
1 year 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.
To Top