Votre option 1. est une mauvaise idée: en plus des raisons d'expérience utilisateur / relations publiques que vous indiquez, vous donnez également aux attaquants une fenêtre pour intercepter les jetons de réinitialisation de mot de passe et compromettre chaque compte sur votre serveur. Cela ne résout pas non plus votre problème si vous avez même un utilisateur qui est trop paresseux pour se connecter / mettre à jour son mot de passe.

À première vue, les 2. et 3. me semblent bien. Votre n ° 2 n'est pas moins sécurisé que ce que vous faites actuellement, mais 2. signifierait que vous devez continuer à supporter la connexion faible actuelle pour toujours (ou faire quelque chose comme "Après X mois, nous effaçons votre mot de passe et vous oblige à le faire une restauration "qui brise la belle transparence utilisateur que vous voulez, alors ignorons cela).

Considérons le cas où vous avez des utilisateurs dans la base de données qui ne se connecteront plus jamais. Avec les deux 2. et 3. vous devez continuer à prendre en charge l'algue de hachage actuelle dans votre base de code pour toujours juste au cas où ils se connecteraient, mais au moins 3. a l'avantage qu'ils (ou plutôt, vous) êtes protégés contre des attaques par force brute hors ligne si votre base de données est volée.

Puisque vous devrez conserver la colonne "drapeau à l'ancienne" pour toujours, rendez-vous service et faites-en un int pas un booléen de sorte que si jamais vous devez mettre à jour à nouveau votre alg de hachage de mot de passe, vous pouvez enregistrer quel ancien style ils utilisent.

MISE À JOUR: Une question très similaire a été posée ici et est basée sur la discussion de ce fil de discussion.

Si vous pouvez faire l'option 3, je ne vois pas pourquoi vous envisageriez même les autres. C'est de loin la meilleure option. Avec cette option, mon instinct serait d'envisager d'utiliser deux sels différents, un pour l'ancien algorithme et un pour le nouveau avec bcrypt. J'envisage une configuration comme celle-ci:

1. Configurez votre nouveau système de mot de passe comme vous le feriez si vous commenciez aujourd'hui.
2. Créez une nouvelle table séparée contenant des champs pour le nom d'utilisateur (ou id), l'algorithme de hachage (nom ou id), salt.
3. Lors de la connexion, vérifiez si l'utilisateur a un enregistrement dans la table séparée, et si oui, hachez le mot de passe à l'ancienne, puis hachez le résultat de la nouvelle manière et comparez-le avec le hachage bcrypt. S'il correspond, re-salt / hachez le mot de passe de la nouvelle manière et supprimez l'enregistrement de la table séparée.

L'inconvénient est que vous devrez garder le mot de passe en mémoire quelques millisecondes de plus (peu importe) et vous aurez la recherche de table supplémentaire à chaque connexion, à peu près pour toujours, jusqu'à ce que la table séparée soit vide ou jusqu'à ce que les anciens comptes deviennent suffisamment obsolètes pour que vous soyez prêt à leur demander de réinitialiser leur mot de passe eux-mêmes.

Notez que, si votre ANCIEN schéma est haché avec du sel, vous ne pourrez pas utiliser le schéma n ° 3, sauf si vous stockez le sel SÉPARÉMENT.

Normalement, le sel est stocké avec le hachage, et vous utilisez le sel comme entrée de la fonction de hachage - si vous n'utilisez pas exactement le même sel, vous obtiendrez une sortie complètement différente.

Si vous newhash (oldsalt + oldhash, newsalt), alors, même avec le mot de passe correct, vous ne pourrez pas recréer oldhash (puisque vous n'avez pas oldsalt), et vous ne pourrez pas générer le hachage final. La même chose s'applique à tout ce qui a des paramètres (par exemple, bcrypt a un paramètre "cost" - il doit être défini lors du chiffrement, et est intégré dans la sortie, pour être utilisé lors de la validation du mot de passe).

AUSSI : comme cela a été mentionné par d'autres, si vous stockez que le hachage est de style "ancien" ou "nouveau", envisagez plutôt de stocker le "schéma" - où, par exemple 0 est le "vieux", et 1 est bcrypt (notez que je n'utilise pas "nouveau" - il est "nouveau" maintenant, ne sera pas "nouveau" pour toujours!). Une manière courante de faire ceci est d'avoir un marqueur au début du hachage (c'est peut-être déjà le cas!). bcrypt utilise l'un des préfixes standard suivants: "$ 2a $", "$ 2b $", "$ 2x" ou "$ 2y $". Selon les sorties possibles de votre "ancien" algorithme, vous devrez peut-être créer votre propre préfixe pour les marquer, ou vous pourrez peut-être vous en tirer avec 'tout ce qui ne commence pas par' $ 'est l'ancien algorithme.

Et enfin, comme vous êtes manifestement préoccupé (à juste titre!) par la sécurité des anciens mots de passe, je suggère de forcer tout le monde à changer de mot de passe, en leur envoyant des instructions avec un jeton (NE PAS! ENVOYER UN LIEN! Vous ne voulez pas que vos utilisateurs cliquent sur un lien! Dites-leur simplement de se connecter à l'endroit habituel). Ensuite, demandez le jeton ET leur mot de passe. Sinon, quelqu'un qui a volé un mot de passe dans le passé peut changer le mot de passe et obtenir un «nouveau» mot de passe valide.

ENFIN: avoir une date d'expiration - si les mots de passe ne sont pas modifiés à cette date, ils devraient être invalidés. Cette date doit figurer dans l'e-mail, et pas trop loin dans le futur (une semaine? Dépend du temps que mettent vos clients pour répondre). Après cela, ils devront suivre les procédures de «réinitialisation du mot de passe».

Je ne sais pas quel est votre schéma d'encodage de mot de passe, mais si ce n'est pas trop mal, il est probable que la structure du mot de passe dans l'ancien et le nouveau format soit différente.

J'ai déjà vu quelque chose comme cela dans un ancien système BSD lorsque le système est passé d'un encodage de mot de passe traditionnel à un encodage plus sécurisé. Le nouveau a commencé avec une séquence de caractères qui ne pouvait pas exister dans l'ancien schéma, donc chaque fois qu'un utilisateur avec un ancien mot de passe se connectait, son mot de passe en texte clair était validé à l'aide de l'ancienne méthode et retravaillé silencieusement et stocké dans la base de données de mots de passe la nouvelle méthode. Au bout d'un mois, aucun ancien mot de passe n'était présent dans la base de données, sans que l'utilisateur final ne remarque quoi que ce soit.

Ce serait quelque part entre votre deuxième et troisième méthode.

Je sais que dans un vrai système Web de production, les choses peuvent maintenant être bien pires, car les utilisateurs peuvent attendre des semaines voire des mois avant de se reconnecter. Mais (en fonction de l'activité réelle) cela peut être atténué par le fait qu'un utilisateur qui ne s'est pas connecté depuis plusieurs mois peut avoir oublié son mot de passe - ou vous pouvez lui dire qu'il l'a fait ... Cela signifie que j'attendrais un peu plus longtemps ici probablement 3 ou 6 mois et après cette période, je réinitialiserais tous les anciens mots de passe à une valeur interdite, forçant l'utilisateur à réinitialiser son mot de passe lors de la prochaine connexion ... via l'écran mot de passe oublié .

Les bonnes choses ici sont:

• transparent pour les utilisateurs normaux
• aucun changement de schéma de base de données - à condition que le champ du mot de passe puisse accepter les deux styles
• les utilisateurs occasionnels seront simplement traités comme s'ils avaient oublié leur mot de passe après des mois sans l'utiliser

L'inconvénient est que cela vous oblige à implémenter simultanément les deux méthodes d'authentification + une mise à jour automatique de tous mot de passe de style.

Vous n'avez pas mentionné la langue que vous utilisez. Php a ses problèmes avec diverses fonctions qui devraient retourner false alors qu'il devrait retourner true dans certains cas, ou d'autres fonctions qui semblent faire le travail mais manquent de logique pour gérer toutes les entrées possibles valides possibles.

Mais c'est la bonne façon de faire ce dont vous parlez en php même si vous n'utilisez pas php. Le code de haut niveau peut vous laisser un point de départ pour le coder à vos fins.

http://php.net/manual/en/function.password-needs-rehash.php

  $ password = 'rasmuslerdorf'; $ hash = '$ 2y $ 10 $ YCFsG6elYca568hBi2pZ0.3LDL5wjgxct1N8w / oLR / jfHsiQwCqTS'; // Le paramètre de coût peut changer avec le temps à mesure que le matériel s'améliore $ options = array ('cost' = > 11); // Vérifier le hachage stocké par rapport au mot de passe en texte brutif (password_verify ($ password, $ hash)) {// Vérifier si un algorithme de hachage plus récent est disponible // ou si le coût a changé if (password_needs_rehash ($ hash, PASSWORD_DEFAULT, $ options)) {// Si tel est le cas, créez un nouveau hachage et remplacez l'ancien $ newHash = password_hash ($ password, PASSWORD_DEFAULT, $ options); } // Connectez l'utilisateur}  

Ce que je ferais serait votre # 2 avec ce qui a été mentionné en utilisant un int. Après avoir lu la documentation sur PASSWORD_DEFAULT, cela pourrait changer lorsque de meilleurs algorithmes sont trouvés et qu'ils doivent supprimer l'actuel pour des raisons d'insécurité au fur et à mesure que php est mis à jour.

Informez les utilisateurs des failles de sécurité de l'ancien système d'authentification et suggérez-leur de changer / réinitialiser leur mot de passe afin d'utiliser le nouveau système d'authentification. Si, après une période prédéterminée (dont les utilisateurs peuvent être informés dans les «petits caractères» quelque part), certains utilisateurs n'ont toujours pas changé / réinitialisé leur mot de passe, désactivez leur compte et envoyez-leur un e-mail les expliquant comment activez-le à nouveau. De cette façon, vos utilisateurs réguliers auront l'impression qu'on leur "demande" de changer leur mot de passe, pas "on leur dit" de changer leur mot de passe, il est donc peu probable qu'ils réagissent négativement à la demande même s'ils changent leur mot de passe (ce qui, espérons , si votre e-mail de conseil est suffisamment convaincant) et vous n'aurez pas à supporter à jamais l'ancien système d'authentification pour les quelques utilisateurs qui n'ont jamais réussi à changer leur mot de passe.