Plusieurs approches, la plus classique:
Entre le client et le serveur (à configurer côté serveur):
- chiffrage systématique en HTTPS de tout ce qui transite entre un client et ton serveur. Ce qui évitera les attaques type "man in the middle". Il te faut acheter un certificat SSL auprès d'un presta de confiance, il y en a plein, les plus petits commencent vers 50€/an chez OVH ou gandi par ex. Les plus gros sont vers 1500€/an, chez verisign par exemple.
Tout dépend de ce dont tu as besoin comme garantie, ceux à 50€ souvent suffisent largement.
Pour les tests, tu peux chiffrer en local une clef perso, tu auras un message d'alerte de ton navigateur, mais rien d'autre (a éviter d'utiliser cette clef une fois le système mis en place avec de vrais clients)
Côté client:
- Rien à faire de spécial, le HTTPS est déjà là pour ca.
Côté serveur:
- Quand un client créé un compte, on hash son mot de passe, ya trois niveaux de sécurité assez classiques:
- le plus sécure: on génère un salt pour chaque user, ce salt est stocké en BDD a côté du mot de passe hashé, il est unique et suffisamment random (il y a dans chaque languages de quoi obtenir des nombres randoms, genre SecureRandom en java), ne pas utiliser des nombres aléatoires classiques, souvent pas assez random justement...
- le plus classique: un salt pour tous les utilisateurs, c'est le plus classique car celui qui offre le meilleur rendement vitesse/sécurité. Cela dit, si un mec s'attaque réellement à ton système, il peut se mettre à faire des rainbow table avec le salt, vu qu'il ne change pas, c'est donc plutôt pas si sécure que ca, vaut mieux celle du dessus si possible)
- le plus risqué: on stocke le hash directement sans salt.
Rapidos en code ca donne (version sécure):
Code :
- $salt = super_hardcore_random_generator();
- $password = $_POST["password"];
- $hash = hash("sha256", $salt.$password);
- // On stocke $salt et $hash qui sont nécessaire pour le login
|
- Quand un utilisateur veut se logger:
- le plus sécure: on récupère en BDD l'utilisateur qui a le bon loggin. On prend le mdp qu'il vient d'envoyer, on prend le salt venu de la BDD, et on créer le hash comme lors de la création de l'utilisateur, et compare avec le hash venu de la BDD. Si c'est ok, l'utilisateur est loggé.
- le plus classique: on prend le mdp venu du client, on prend le salt "global", et on créer le hash, on test directement en BDD que l'on a un couple login/password qui va bien, on valide ou non en conséquence.
- le plus risqué: on prend le mdp venu du client, on le hash, et on compare login/hash dans la base de données...
En code (version sécure):
Code :
- $login = $_POST["login"];
- $password = $_POST["password"];
- $user = sql("SELECT login, salt, password FROM user WHERE login = ? LIMIT 0,1", $login);
- $hash = hash("sha256", $user["salt"].$password);
- // En partant du principe que $user["password"] contient le hash précédemment calculé avec le salt plus haut
- if ($hash === $user["password"]) {
- }
|
Avantages divers:
- HTTPS te garantis que, malgré que les données ne soit pas cryptés du côté de l'utilisateur, elles ne sont pas pour autant lisible jusqu'a l'arrivée à ton serveur (l'autre sens, du serveur au client, est tout aussi vrai).
- un hash, a la particularité de détruire le mot de passe initial, et il n'est pas possible de revenir en arrière, donc, dans ta base de données, tu as une suite de lettres sur le mot de passe, dont personnes ne peut remonter au vrai mot de passe (ni toi/admin d'ailleurs). Ca garanti une bonne qualité.
POUR AUTANT, certaines personnes font ce que l'on appelle des rainbow tables: tu prends un algo de hash genre SHA1, et tu génères toutes les possibilités, genre SHA1("a" ), puis SHA1("b" ) et ainsi de suite. Ils stockent ce couple clef/valeur (donc ils stockents "a" = "ALDDMSD..." ), et ainsi de suite.
=> ca fait que si un utilisateur utilise un mot de passe trop court, ou trop facile à deviner, il est possible d'obtenir le mot de passe initial depuis le hash. Soit, pas du tout ce que tu souhaites.
Le salt, qu'il soit sécure ou non, sert pour ce point là. En rajoutant une suite de caractère random devant le mot de passe de l'utilisateur, le principe de la rainbow table s'effondre, car il est très dur de faire ca quand, même si l'utilisateur fournit un mot de passe à 1 caractère, le hash en réalité dérive de 10/20 caractères grace au salt que tu as mis devant le mdp...
Voila, avec ca t'a une base digne de ce nom 
Pour résumer:
- HTTPS entre le client et le serveur
- salt + stockage du hash(salt + password) en BDD, et avec ca tu as un truc qui fait face au attaques intermédiaire, et autres personnes qui pourraient voler la BDD et tenter de se faire passer pour certains utilisateurs.
Ah, et quand un utilisateur perd un mot de passe, tu regénères le salt et un nouveau mot de passe, et renvoi un joli mail avec le mot de passe déchiffré sans le salt bien sur
Message édité par Devil'sTiger le 16-09-2015 à 00:17:07
).
