[Sécurité] article généraliste

[Ter Rowan]

en cherchant un peu, j'ai trouvé cette ressource sur la sécurité. Vous en pensez quoi ?

[Xenos]

Salut,

cela ressemble à la traduction de ce qu'on peut trouver sur le site de l'OWASP. L'article me semble bon, bien que je l'ai juste survolé. En revanche, je trouve certaines solutions malvenues, principalement l'approche "blacklist" des deux premières failles (injection et XSS). L'approche "whitelist" est clairement privilégiée et conseillée (simplement car la blacklist présente le défaut d'être forcément en retard par rapport aux attaques).


J'ajouterai aussi que si l'utilisateur veut mettre un mot de passe moisi ("1234"), le site ne devrait pas le lui interdire, seulement lui signaler. S'il se fait voler son compte, c'est son problème: il était prévenu.
Je m'éloigne un peu du sujet, mais toujours dans le domaine des mdp, comme ils sont hashés, toute chaine binaire est acceptable en entrée y compris les caractères spéciaux... La seule limite peut être la longueur de chaine. C'est très emm*dant d'avoir un site qui dit "votre mdp est trop simple!" puis qui continue par "votre mdp contient des caractères spéciaux interdits" quand on veut complexifier ce pass >.<

[Xenos]

Je remonte un peu ce sujet, mais comme je viens de voir un autre site qui le faisait, je pense qu'il serait bon de le rappeler (bien que nombre d'entre nous le sache déjà):

Stocker les mots de passe

Je viens de recevoir ce mail, ayant "oublié" mon mot de passe sur un jeu:

Votre pseudo : Xenos
Votre mot de passe : test

N'hésitez pas à vous rendre dans la rubrique contact si vous avez la moindre question ou le moindre problème.

Il ne faut JAMAIS stocker un mot de passe en clair.
Voici un récent tutoriel de Developpez.com pour apprendre à stocker les mots de passe correctement via PHP 5.5.
Pour l'accent anglais, computerphile propose aussi une vidéo sur ce thème.

Le MD5 n'est plus très sûr: il existe des collisions (mêmes entrées générant les mêmes hashs), mais pas encore de moyen vraiment fonctionnel de trouver une entrée correspondant à un hash salé. Il pourra être suffisant pour un petit jeu.
Mieux vaut passer aux plus gros calibres que sont Sha et BCrypt. Le premier est plus rapide, mais le second permet d'avoir la complexité que l'on souhaite.
Il en existe d'autres (PBKDF2, scrypt...).
Dans tous les cas, ne pas oublier d'y ajouter son grain de sel, aléatoire


De façon simple: il n'est pas normal de pouvoir récupérer son mot de passe, surtout quand un pass est généralement utilisé sur plusieurs sites par le joueur.

Il faut proposer:

• Soit la possibilité de le réinitialiser directement, mais dans ce cas on risque de perdre tous ses comptes si on se fait piquer son e-mail
  
• Soit proposer un "token" qui servira de mot de passe temporaire, ce qui permettra au joueur légitime (connaissant le mdp original mais s'étant fait pirater son mail) de conserver son compte
  

Ressource SO:
Storing hashed password

[Ekilio]

Bonjour,

Petite correction par rapport à ton message : non, sha1 n'est pas sûr. Pas plus que md5. Globalement, vu la puissance des ordinateurs actuels, c'est exactement la même chose de stocker en md5/sha1 (avec ou sans sel) et de stocker en dur.

Petit rappel : le sel sert à éviter les collisions, pas les attaques en bruteforce. Hors actuellement, avec un algo bien fait, il suffit de quelques secondes pour un mot de passe de 10 caractères avec des caractères non-alphanumériques.

La seule méthode fiable pour stocker un mot de passe, c'est le passage par du blowfish, qui est implémentée dans le cadre de la fonction password_hash de php (mais tous les langages ont une implémentation). L'intérêt de cette méthode, c'est que le blowfish est un algorithme volontairement lent : il faut de base une seconde pour faire un test. Du coup, le bruteforce devient impossible.

Pour le reste on est d'accord, on ne stocke pas un mot de passe en dur.

[Xenos]

Oui, je n'ai pas précisé pour sha, c'est une erreur. Les SHA-0 et SHA-1 sont mauvais depuis un moment.

Pour le sel, je ne suis pas tout à fait d'accord. Ou alors je comprends mal les termes. A mon sens, le sel sert à éviter d'avoir la même signature si deux personnes ont le même mot de passe, et d'éviter l'usage de dictionnaires (rainbow table).
Le sel consiste à obtenir deux sorties différentes pour une même entrée.
A l'inverse, la collision consiste à trouver deux entrées qui ont la même sortie (le même hash).
Le sel permet également d'éviter l'usage de "rainbow table", aka un dictionnaire avec le hash de chaque mot de passe classique.

C'est pas la seule méthode fiable en pratique, car les algorithmes comme SHA-256 sont également robustes.

Pour la lenteur "anti-brute force", il faut aussi faire attention qu'elle peut devenir un "trou à DDoS"


Savez-vous si l'ajout d'un "sleep(1000)" limiterait vraiment le brute force sur la page de connexion?

[Ekilio]

Salut,

Concernant le sel, on est d'accord sur les rainbow table ; mais c'est également le cas pour les collisions. Je m'explique : le but de la collision est d'avoir une entrée différente de l'initiale qui aura la même sortie. Mais si on ajoute du sel à l'entrée initiale, la collision ne sert plus à rien puisqu'elle sera différente : même si on connait l'entrée différente qui donne la même sortie, quand on va la tester ça ne va pas marcher.

La lenteur anti-brute force ne devient pas un trou à DDoS si c'est correctement utilisé (on peut régler la difficulté de l'algorithme). En soit, un DDoS restera possible, mais comme sur n'importe quel site web.

Enfin, je suis dubitatif sur le sleep(1000). Ralentir le site n'est pas un outil pour éviter le brute force, parce que si quelqu'un (par une autre faille, genre Heartbleed) récupère ta base de données, le sleep sert à rien. Autant utiliser directement la fonction prévue pour ça (password_hash) qui fait déjà ce ralentissement de base et le fait de manière plus propre.

[niahoo]

Concernant le sel, on est d'accord sur les rainbow table ; mais c'est également le cas pour les collisions. Je m'explique : le but de la collision est d'avoir une entrée différente de l'initiale qui aura la même sortie. Mais si on ajoute du sel à l'entrée initiale, la collision ne sert plus à rien puisqu'elle sera différente : même si on connait l'entrée différente qui donne la même sortie, quand on va la tester ça ne va pas marcher.

C'est du Proust, ou je ne m'y connais pas !