web-dev-qa-db-fra.com

Sécurité des mots de passe dans les bases de données - aujourd'hui encore la meilleure pratique?

Duplicata possible:
Quelle méthode de hachage de mot de passe dois-je utiliser?

Il y a une tonne d'excellents articles sur la sécurité des mots de passe dans les bases de données sur le débordement de pile et sur d'autres sites et comme je suis complètement nouveau dans ce domaine, j'ai passé pas mal d'heures à essayer d'en savoir plus à ce sujet ces derniers jours. Cependant, il y a tellement de suggestions différentes et de meilleures pratiques que je suis toujours très confus ...

De plus, il y a encore beaucoup de messages plus anciens de 2007-2010, etc. J'ai vu à quelle vitesse les choses changent, je ne sais pas si c'est encore courant de l'utiliser comme ils le suggèrent. Donc, je voulais résumer ce que j'ai trouvé dans les messages et ensuite demander si cette méthode que je trouvais était une bonne pratique ...

Donc, ce n'est pas un guide, mais un résumé, je sais que c'est très très basique et s'il y a des erreurs veuillez me corriger!

  1. Juste pour mentionner: vous ne devez jamais stocker de mots de passe en texte brut :)
  2. Vous avez des mots de passe de hachage "à sens unique", donc personne ne peut jamais voir le texte brut. Lorsque l'utilisateur entre le mot de passe, vous le hachez de la même manière et le comparez avec le passe haché dans la base de données.
  3. En plus de hacher un mot de passe, vous devez le saler. Vous ajoutez le sel à la chaîne de mot de passe ordinaire et hachez la nouvelle chaîne. Si le mot de passe simple est faible, l'ajout de sel le rend plus long et plus fort.
  4. Le sel devrait en outre être aléatoire (j'ai lu que le terme "sel" signifie qu'il est de toute façon aléatoire, sinon il était appelé "clé"?). C'est pour éviter les attaques de table Rainbow, car l'attaquant devrait créer une table pour chaque sel, ce qui est beaucoup plus cher en temps, etc. Aussi, si deux utilisateurs ont le même mot de passe, vous ne le reconnaîtrez pas si vous utilisez des sels aléatoires.
  5. Le sel n'est pas un secret! Il est stocké dans la base de données à côté du mot de passe haché. Cependant, ce n'est peut-être pas la meilleure idée d'utiliser un horodatage, l'adresse e-mail de l'utilisateur ou tout autre élément connecté à l'utilisateur en tant que sel aléatoire. C'est par exemple mentionne que les utilisateurs ont tendance à utiliser les mêmes mots de passe sur plusieurs sites/services. Donc, le sel devrait être une chaîne aléatoire, j'ai lu mieux serait 64 bits?
  6. L'étape suivante consiste à ajouter une itération au processus de hachage (1000 boucles ou plus), de sorte que le sel est ajouté au mot de passe et ils sont ensuite hachés encore et encore, ce qui signifie qu'une fraction de seconde seulement pour que l'utilisateur attende lors de la connexion mais résume si vous avez quelque 10 000 entrées dans votre base de données.
  7. Cela peut être un léger avantage, si vous ajoutez une clé de site, stockée par ex. comme var globale en plus du sel. Cependant, vous devez toujours supposer que les attaquants ont également accès à votre système de fichiers.
  8. Algorithmes de hachage: j'ai trouvé avec certitude qu'il n'est plus sûr d'utiliser MD5, SHA1 et d'autres méthodes faibles ...

Donc, il y a différentes opinions sur l'utilisation de SHA256, SHA512? Devriez-vous utiliser hash_hmac? Certains disent oui: ( http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ ) certains disent que l'utilisation des bibliothèques est la seule manière sécurisée ... et puis une ou deux fois dans un article que j'ai lu pour ne pas utiliser les bibliothèques comme bcrypt ou bubble fish ??

Est-il vraiment nécessaire d'utiliser une bibliothèque ou est par exemple une méthode comme celle-ci suffit:

function hash_password($password, $nonce) {

  for ($i = 0; $i < 5000; $i++) {
    $hashed_pass = hash_hmac('sha512', $hashed_pass . $nonce . $password, $site_key);
    }
  return $hashed_pass;
}

Beaucoup de gens disent de ne pas inventer votre propre algo, donc j'ai un peu peur juste d'utiliser quelque chose d'auto-inventé.

Je peux imaginer que c'est difficile à prévoir, mais combien de temps une méthode utilisée jusqu'à présent peut-elle être considérée comme suffisamment sûre?

MISE À JOUR: Alors, merci pour tous vos excellents commentaires. Il y a un point principal qui manque, comme je vois et beaucoup d'entre vous l'ont dit: la sécurité par mot de passe, ce qui signifie qu'un mot de passe fort est la base. Je pense avoir compris le message, merci encore! :)

MISE À JOUR 2: Juste pour terminer, j'ai trouvé le code suivant sur http://www.lateralcode.com/creating-a-random-string-with-php/ que j'utilise pour générer un sel aléatoire :

function Rand_string( $length ) {
    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!§$%&/().-:;_#+*[]{}="; 

    $size = strlen( $chars );
    for( $i = 0; $i < $length; $i++ ) {
        $str .= $chars[ Rand( 0, $size - 1 ) ];
    }

    return $str;
}

$random_salt= Rand_string(20);
phpmysqlhash
47
Chris

Informations générales:

Belle question mais tout ce que je peux dire, c'est que cela dépend totalement de l'utilisation. Si vous ne l'utilisez que pour un petit site Web, il y a de fortes chances que seuls des "script kiddies" vous rendent visite, dans ce cas, un simple SHA1 avec du sel est tout à fait suffisant aujourd'hui également. Dans ce cas, 5-8-10 ans ou peut-être même plus est totalement bon, les script kiddies n'y entreront pas vraiment s'ils voient qu'ils ne peuvent pas entrer facilement. Si votre site est attaqué pour une raison quelconque - site monétaire, etc., vous devez utiliser les dernières fonctions disponibles. Dans ce cas, je risquerais même d'utiliser une fonction non officielle mais déjà portée. En ce moment, il y a une compétition SHA3, pour les websties qui auront beaucoup d'argent, j'utiliserais l'un des 5 concurrents de ceux-ci.

Les points que je dis importants sont:

1. utilisez un sel aléatoire, peut-être même 20 caractères. Il est beaucoup plus difficile de casser les mots de passe, et même s'ils sont cassables, cela prend trop de temps pour en valoir la peine.
2. utilisez SHA-1, SHA-2 ou WHIRLPOOL. Avec du bon sel, le MD5 est également correct, mais je suggère toujours ces derniers.
. vous pouvez utiliser n'importe quelle excellente cryptographie si les mots de passe des utilisateurs sont triviaux. Vous devez vous assurer qu'ils utilisent des mots de passe non-dictionnaire, longs avec des majuscules, des lettres minuscules, des chiffres et des symboles sinon il est facilement cassable par la force brute. Vous pourriez penser qu'ils pourraient être obligés de changer de mot de passe chaque année.

Au code:

Boucler plusieurs fois pourrait être utile mais je ne pense pas que 5000 soient nécessaires. 3 pour une sécurité normale est bon, ou 100, peut-être que 1000 pourrait fonctionner, mais je pense que 5000 est tout simplement trop. SHA-256 est bon, mais vous pouvez utiliser un algorithme spécialement développé pour cela, voir les commentaires.

2
axiomer

Vous avez oublié une petite chose:

Fiabilité du mot de passe.

Juste 2 mots qui surpondèrent tout votre brillant sujet.

Il y a en effet des centaines de sujets sur Stackoverflow vous disant d'utiliser tel ou tel algorithme de hachage et sels aléatoires.
.

Quant aux pauvres utilisateurs qui ne se souviennent pas $#%H4df84a$%#R mots de passe - faites-leur simplement utiliser non pas un mot de passe mais un mot de passe.

Is it a good day today, Winkie? Utilise différentes lettres majuscules ainsi qu'un mot de passe de la complexité recommandée mais beaucoup plus facile à retenir.

Bien sûr, la phrase ne doit pas être aussi courante que les mots de passe courants comme "Joe" ou "123".
"Bonjour", "Oh mon Dieu! Ils ont tué Kenny!" les phrases doivent être évitées.
Mais en ajoutant de la personnalité, ce serait bien:
Oh My God! They moved Cthulhu! semble assez

Une autre chose à mentionner est une communication sécurisée entre le serveur et le navigateur
Sans lui, un mot de passe simple peut facilement être "détecté" sur l'un des routeurs impliqués dans la communication.

SSH ou une implémentation de autorisation Digest n'est pas moins essentiel.

10
Your Common Sense

Une fonction de hachage à usage général (MD5, SHA1, SHA256) avec un bon hachage peut être suffisamment sécurisée pour la plupart des sites Web plus petits, compte tenu de la puissance de calcul actuelle. Cependant, la loi de Moore garantira que même les bons mots de passe seront exposés à des attaques par force brute dans un proche avenir. Le problème est que les fonctions de hachage peuvent être calculées beaucoup trop rapidement. La meilleure solution consiste à utiliser bcrypt ou PBKDF2 avec un nombre élevé d'itérations. Bcrypt vs PBKDF2 a été discuté sur http://security.stackexchange.com .

Certaines personnes pourraient penser que c'est excessif pour la plupart des sites, mais rappelez-vous que les mots de passe sont réutilisés tout le temps et que le stockage des mots de passe est généralement quelque chose que vous ne changerez pas jusqu'à ce qu'il y ait un problème.

Recommandations:

  1. Utilisez bcrypt ou PBKDF2. N'UTILISEZ PAS de candidats SHA3. Ils peuvent contenir des failles de sécurité qui n'ont pas encore été découvertes.
  2. Utilisez un sel aléatoire pour vous protéger contre les attaques de table arc-en-ciel.
  3. Forcer les utilisateurs à sélectionner une phrase secrète.

Plus d'informations

5
tony

La fonction hash_hmac() serait un bon choix, elle peut même surmonter les problèmes d'un algorithme de hachage plus faible. Le seul problème est qu'il est trop rapide. Cela signifie qu'avec suffisamment de puissance CPU (cloud), la création de différentes tables Rainbow devient possible, c'est la raison de l'itération. Si vous avez besoin de cette haute sécurité, vous pouvez mesurer le temps dont vos itérations ont besoin, puis calculer le nombre d'itérations nécessaires pour un temps donné.

Éditer:

Itérer peut résoudre ce problème, il doit être fait de manière à ce que l'on puisse augmenter le nombre d'itérations plus tard, sans invalider les hachages existants. Ceci est nécessaire pour s'adapter au nouveau matériel futur, mais nécessite de stocker les paramètres de hachage avec le hachage.

L'algorithme de hachage bcrypt a été conçu pour répondre à cette demande, j'ai écrit un petit exemple de la façon d'utiliser bcrypt avec PHP 5. , j'ai essayé de le commenter, donc on peut comprendre ce qui se passe.

2
martinstoeckli