07-03-2013, 11:15 PM
L'email ne sera pas hashable, le pseudonyme non plus, car un hash détruit la donnée de base:
- Si on connait la donnée de départ, on peut calculer le hash, pas de problème
- Si on ne connait que le hash, pas la donnée de départ, alors on ne peut pas la reconstruire
Tout ce qu'on peut faire, avec les hash, c'est chercher (par brute force ou par des techniques mathématiques fiables, car le brute-force, t'en auras pour des milliards d'années :p) une donnée qui, une fois hashée, donne le même hash (ça s'appelle une collision: on a trouvé une donnée avec le hash qu'on souhaite, mais rien ne dit que cette donnée soit celle de départ).
Exemple de méthode de hash simple: la somme des chiffres.
Soit un nombre quelconque. Son hash est la somme de ses chiffres. Tant que cette somme est supérieure à 9, on recommence.
Par exemple, la donnée 5146532 devient 5+1+4+6+5+3+2=26 qui devient 2+6=8
Le hash de 5146532 est 8.
Si j'entre 5146532 dans ma fonction de hash, je récupère toujours 8.
En revanche, si on me dis "le hash est 8", je ne peux pas savoir que la donnée de départ était 5146532, mais je peux chercher une donnée qui a pour hash 8. Essayons 10, il devient 1+0=1, donc c'est pas le bon hash... J'essaie 11... 12... 17... ah! 17, ca marche! Heu... 17 n'était pourtant aps la donnée de départ, mais elle a le même hash! :o
Donc si c'était un mot de passe, entrer "17" ou "5146532" donnerait le même résultat: le hash étant 8, le mot de passe est considéré comme valide.
En pratique, avec md5 (et encore plus avec sha), les collisions sont bien trop difficiles à trouver pour qu'on puisse découvrir un mot de passe ayant un hash donné (sauf si on calcul le hash de tous les mots du dictionnaire et qu'on cherche, dans ces hash, le hash qu'on veut "rétro-calculer"... Exemple: si "cheval" est mon mot de passe, son md5 est 9f87ec4fda4a91dd564f6bdf1ab301c8, et d'après les sites webs comme gromweb qui ont déjà calculé le md5 d'un tas de mots du dico, on sait que "cheval" a le bon hash, on remonte le mot de passe, d'où la raison pour laquelle il faut utiliser un grain de sel, non-constant si possible).
Bref, tout cela pour dire qu'un hash ne permet pas de retrouver la donnée initiale, donc, si tu hash les mails ou les pseudo, tu ne pourras plus les "décoder".
Si l'e-mail est publiquement affiché sur le site web, inutile de le sécuriser dans le code PHP.
Si l'e-mail est totalement privé (seul l'utilisateur du compte est censé le connaitre), le masquer me semble, là encore, peu utile, car ce ne sera pas par là que les pirates passeront (pour lire ces données, il faudrait pouvoir injecter du code php et donc soit avoir accès au FTP, soit avoir une injection PHP, dans les deux cas, la connaissance du mail d'un joueur ne sera pas ton soucis prioritaire, puisqu'un pirate pourra injecter un code PHP arbitraire :p).
Si vraiment tu tiens à le masquer, tu peux utiliser mcrypt_encrypt et mcrypt_decrypt. En ce cas, le mot de passe qui sert au cryptage ne doit pas filtrer dans le code PHP... Ce qui pose un problème quand tu vas devoir déchiffrer le mail :p
Jouer sur les cryptages dans les codes PHP est, quasiment 100% du temps, inutile car si on a accès au code PHP, on trouvera comment récupérer les clefs de cryptage et on pourra décrypter. En revanche, on ne laisse pas traîner les mots de pass et les données hashables, car ces données ne sont pas censées être "lisibles" par le serveur: le serveur ne doit que manipuler leur hash, et jamais la donnée d'origine, qui sinon pourrait fuir.
- Si on connait la donnée de départ, on peut calculer le hash, pas de problème
- Si on ne connait que le hash, pas la donnée de départ, alors on ne peut pas la reconstruire
Tout ce qu'on peut faire, avec les hash, c'est chercher (par brute force ou par des techniques mathématiques fiables, car le brute-force, t'en auras pour des milliards d'années :p) une donnée qui, une fois hashée, donne le même hash (ça s'appelle une collision: on a trouvé une donnée avec le hash qu'on souhaite, mais rien ne dit que cette donnée soit celle de départ).
Exemple de méthode de hash simple: la somme des chiffres.
Soit un nombre quelconque. Son hash est la somme de ses chiffres. Tant que cette somme est supérieure à 9, on recommence.
Par exemple, la donnée 5146532 devient 5+1+4+6+5+3+2=26 qui devient 2+6=8
Le hash de 5146532 est 8.
Si j'entre 5146532 dans ma fonction de hash, je récupère toujours 8.
En revanche, si on me dis "le hash est 8", je ne peux pas savoir que la donnée de départ était 5146532, mais je peux chercher une donnée qui a pour hash 8. Essayons 10, il devient 1+0=1, donc c'est pas le bon hash... J'essaie 11... 12... 17... ah! 17, ca marche! Heu... 17 n'était pourtant aps la donnée de départ, mais elle a le même hash! :o
Donc si c'était un mot de passe, entrer "17" ou "5146532" donnerait le même résultat: le hash étant 8, le mot de passe est considéré comme valide.
En pratique, avec md5 (et encore plus avec sha), les collisions sont bien trop difficiles à trouver pour qu'on puisse découvrir un mot de passe ayant un hash donné (sauf si on calcul le hash de tous les mots du dictionnaire et qu'on cherche, dans ces hash, le hash qu'on veut "rétro-calculer"... Exemple: si "cheval" est mon mot de passe, son md5 est 9f87ec4fda4a91dd564f6bdf1ab301c8, et d'après les sites webs comme gromweb qui ont déjà calculé le md5 d'un tas de mots du dico, on sait que "cheval" a le bon hash, on remonte le mot de passe, d'où la raison pour laquelle il faut utiliser un grain de sel, non-constant si possible).
Bref, tout cela pour dire qu'un hash ne permet pas de retrouver la donnée initiale, donc, si tu hash les mails ou les pseudo, tu ne pourras plus les "décoder".
Si l'e-mail est publiquement affiché sur le site web, inutile de le sécuriser dans le code PHP.
Si l'e-mail est totalement privé (seul l'utilisateur du compte est censé le connaitre), le masquer me semble, là encore, peu utile, car ce ne sera pas par là que les pirates passeront (pour lire ces données, il faudrait pouvoir injecter du code php et donc soit avoir accès au FTP, soit avoir une injection PHP, dans les deux cas, la connaissance du mail d'un joueur ne sera pas ton soucis prioritaire, puisqu'un pirate pourra injecter un code PHP arbitraire :p).
Si vraiment tu tiens à le masquer, tu peux utiliser mcrypt_encrypt et mcrypt_decrypt. En ce cas, le mot de passe qui sert au cryptage ne doit pas filtrer dans le code PHP... Ce qui pose un problème quand tu vas devoir déchiffrer le mail :p
Jouer sur les cryptages dans les codes PHP est, quasiment 100% du temps, inutile car si on a accès au code PHP, on trouvera comment récupérer les clefs de cryptage et on pourra décrypter. En revanche, on ne laisse pas traîner les mots de pass et les données hashables, car ces données ne sont pas censées être "lisibles" par le serveur: le serveur ne doit que manipuler leur hash, et jamais la donnée d'origine, qui sinon pourrait fuir.