Le mieux est de ne pas réinventer la roue. Mais, je comprends, dans le monde PHP, il peut être difficile de trouver un composant de haute qualité qui le fait déjà (même je suis presque sûr que les frameworks implémentent de telles choses et que leurs implémentations sont déjà testées, solides, révisées par le code, etc. )
Si, pour certaines raisons, vous ne pouvez pas utiliser un framework, voici quelques suggestions:
Utilisez PBKDF2 ou Bcrypt si vous le pouvez . C'est fait pour ça.
Justification: les deux algorithmes peuvent ralentir arbitrairement le processus de hachage, ce qui est exactement ce que vous voulez lorsque vous hachez des mots de passe (des alternatives plus rapides signifient une force brute plus facile). Idéalement, vous devez ajuster les paramètres afin que le processus devienne de plus en plus lent au fil du temps sur le même matériel, tandis qu'un nouveau matériel plus rapide est publié.
Si vous ne pouvez pas, au moins n'utilisez pas MD5 / SHA1. Jamais. Oublie ça . Utilisez SHA512 à la place, par exemple. Utilisez aussi du sel.
Justification: MD5 et SHA1 sont trop rapides. Si l'attaquant a accès à votre base de données contenant les hachages et possède une machine (pas même particulièrement) puissante, le forçage brutal d'un mot de passe est rapide et facile. S'il n'y a pas de sels, les chances que l'attaquant trouve le mot de passe réel augmentent (ce qui pourrait nuire davantage si le mot de passe était réutilisé ailleurs).
En PHP 5.5.0 et versions ultérieures, utilisez password_hash
etpassword_verify
.
Justification: appeler une fonction fournie par le framework est facile, donc le risque de faire une erreur est réduit. Avec ces deux fonctions, vous n'avez pas à penser à différents paramètres tels que le hachage. La première fonction renvoie une seule chaîne qui peut ensuite être stockée dans la base de données. La deuxième fonction utilise cette chaîne pour la vérification du mot de passe.
Protégez-vous de la force brute . Si l'utilisateur soumet un mauvais mot de passe alors qu'il a déjà soumis un autre mauvais mot de passe il y a 0,01 seconde, c'est une bonne raison de le bloquer. Alors que les êtres humains peuvent saisir rapidement, ils peuvent probablement pas que rapides.
Une autre protection serait de fixer une limite de pannes par heure. Si l'utilisateur a soumis 3600 mots de passe erronés en une heure, 1 mot de passe par seconde, il est difficile de croire qu'il s'agit d'un utilisateur légitime.
Raisonnement: si vos mots de passe sont hachés de manière non sécurisée, la force brute peut être très efficace. Si les mots de passe sont stockés en toute sécurité, la force brute gaspille toujours les ressources et la bande passante du réseau de votre serveur, ce qui réduit les performances des utilisateurs légitimes. La détection de la force brute n'est pas facile à développer et à obtenir, mais pour tout système, mais minuscule, cela en vaut la peine.
Ne demandez pas à vos utilisateurs de changer leur mot de passe toutes les quatre semaines. Ceci est extrêmement ennuyeux et diminue la sécurité, car il encourage la sécurité post-it.
Justification: l'idée que forcer les mots de passe à changer toutes les n semaines protège le système de la force brute est fausse. Les attaques par force brute réussissent généralement en quelques secondes, minutes, heures ou jours, ce qui rend les changements de mot de passe mensuels non pertinents. D'un autre côté, les utilisateurs se souviennent mal des mots de passe. Si, par ailleurs, ils doivent les changer, ils tenteront soit d'utiliser des mots de passe très simples, soit de simplement noter leurs mots de passe sur les post-its.
Auditez tout, à chaque fois. Stockez les ouvertures de session, mais ne stockez jamais les mots de passe dans le journal d'audit. Assurez-vous que le journal d'audit ne peut pas être modifié (c'est-à-dire que vous pouvez ajouter des données à la fin, mais pas modifier les données existantes). Assurez-vous que les journaux d'audit sont soumis à une sauvegarde régulière. Idéalement, les journaux devraient être stockés sur un serveur dédié avec des accès très restrictifs: si un autre serveur est piraté, l'attaquant ne pourra pas effacer les journaux pour cacher sa présence (et le chemin emprunté pendant l'attaque).
Ne me souviens pas des informations d'identification de l'utilisateur dans les cookies, sauf si l'utilisateur demande à le faire (la case "Se souvenir de moi" doit être décochée par défaut pour éviter les erreurs humaines).