Existe-t-il un moyen de hacher mon mot de passe, si on me demande seulement de fournir 5 caractères sur plusieurs?
Il existe un système qui, sur un formulaire de connexion, présente environ 40 cases pour les lettres de mot de passe (pour masquer la longueur réelle du mot de passe), et seules celles aléatoires (le même montant à chaque fois) sont modifiables. L'explication est - pour me protéger des enregistreurs de frappe. Semble légitime. Mais cela signifie-t-il que mon mot de passe est conservé en texte brut? Ou existe-t-il un algorithme de hachage connu qui permettrait cela?
Remarque: je ne demande pas si c'est une bonne ou une mauvaise pratique, je pose des questions sur la possibilité/faisabilité/méthode de hachage.
Non - il n'y a aucun moyen pratique de hacher votre mot de passe dans ce cas.
Pour que le site Web fonctionne de cette façon, le hachage devrait vous permettre de vérifier qu'un sous-ensemble de 5 caractères du mot de passe correspond à une certaine valeur. Cela signifie que vous pouvez brutalement forcer ces 5 personnages par eux-mêmes, ce qui est facilement pratique, et une fois que vous connaissez 5 caractères, il est facile de forcer brutalement les autres. Ceci est quelque peu similaire à la faiblesse des mots de passe LANMAN.
Les mots de passe partiels présentent des avantages en termes de sécurité, en particulier contre les enregistreurs de frappe. Les applications bancaires ont parfois un mot de passe normal haché sur le serveur et un code d'authentification supplémentaire, que vous n'entrez que partiellement, et qui n'est PAS haché sur le serveur. Ceci est considéré comme tout à fait acceptable, mais devient moins courant car l'authentification multifacteur est une meilleure solution.
Dans ce cas particulier, il n'est pas clair que ce soit une mauvaise idée. Vous devez peser le risque de compromission du serveur par rapport au risque des enregistreurs de frappe côté client. En fait, c'est le client qui est à plus grand risque . Donc, malgré aller à l'encontre des meilleures pratiques normales, ce site Web n'est pas si stupide après tout.
Comme d'autres l'ont déclaré, toute tentative de résoudre ce problème avec des algorithmes de hachage est vouée à l'échec.
Cependant, je pense qu'il vaut la peine de parler de la façon dont ING peut probablement résoudre ce problème. (Avertissement: je n'ai jamais travaillé pour ING, mais j'ai travaillé pour d'autres grandes banques).
Il est probable qu'ING stocke votre mot de passe dans un Hardware Security Module . Il s'agit d'un matériel inviolable, conçu pour que même l'opérateur du système ne puisse pas extraire vos hachages de mot de passe. En interne, il stocke probablement votre mot de passe en texte clair (ou quelque chose comme du texte brut), mais ne communique qu'avec le monde extérieur via les opérations "veuillez saisir les caractères x, y et z" et limite le nombre de tentatives autorisées.
Dans ce scénario, la sécurité de votre mot de passe dépend du HSM qui est inviolable. Il y a eu des attaques publiées sur les HSM , mais la surface d'attaque est réduite, par rapport aux hachages stockés dans un SGBDR.
Une façon de mettre cela en œuvre consiste à stocker une centaine de hachages de mots de passe partiels. Chaque fois que l'utilisateur se connecte avec un mot de passe partiel, il sera marqué comme utilisé. La liste des hachages peut être régénérée à chaque fois que vous devez entrer un mot de passe complet.
Ce schéma affaiblit la sécurité contre la force brute ou la cryptanalyse, mais il peut protéger contre l'enregistreur de clés si vous devez souvent vous connecter à partir de machines non fiables.
J'avais vu ce système utilisé sur une carte d'argent de voyage, car les voyageurs peuvent souvent avoir besoin d'utiliser le compte à partir d'ordinateurs publics. Pour les opérations bancaires normales, je pense que cela affaiblit simplement la sécurité. Si votre ordinateur personnel habituel est infecté par un enregistreur de frappe, il suffit de quelques connexions pour collecter le mot de passe complet à partir des mots de passe partiels.
Pour renforcer ce schéma de cryptanalyse et d'attaque par force brute, les mots de passe partiels devraient être stockés avec un hachage très lent, comme PBKDF2 avec beaucoup de tours. Et pour entraver la capacité de l'attaquant à forcer brutalement les hachages en parallèle, vous devez forcer le mot de passe partiel à être utilisé dans l'ordre spécifique où ils ont été créés. Par exemple, l'utilisation du nième mot de passe partiel pour crypter la liste des numéros et le sel du n + 1e mot de passe partiel forcerait l'attaquant à résoudre le nième mot de passe partiel avant de pouvoir commencer à travailler sur le n + 1 ' th.
Oui - Il est possible qu'ils hachent simplement toutes les combinaisons qu'ils vont vous montrer.
Bien que je pense qu'ils n'ont pas mis en œuvre cela et stockent votre mot de passe, probablement crypté, mais pas haché.
Un meilleur combo de sécurité en utilisant cette méthode tout en étant conscient de l'espace de stockage:
- Chiffrez le mot de passe en clair et placez-le dans une sorte de stockage à froid.
- Déchiffrez périodiquement le mot de passe pour créer de nouveaux combos et hachez-les.
De cette façon, l'espace de stockage est maintenu raisonnable. Et votre mot de passe non haché devrait être dans une couche plus sécurisée du système.
Il peut ne pas être haché mais il peut être stocké crypté. Théoriquement, ils auraient pu utiliser Schéma de seuil avec les caractères ASCII) comme clés puis vérifier si le résultat correspond au résultat. (théoriquement) vous ne devriez pas avoir besoin de stocker un mot de passe seulement une solution.
PS. Par exemple, voir http://programmingpraxis.com/2011/06/17/adi-shamirs-threshold-scheme/
Supposons que le mot de passe comprenne 40 caractères. Supposons que les caractères puissent être interprétés comme les nombres c_1, c_2, ... c_40 d'un certain champ fini approprié F ( Galois Field ). Supposons également que F ait au moins 40 éléments.
Supposons que nous calculons le polynôme d'interpolation p pour 40 éléments zéro de prédéfinis de F tels que p (a_j) == c_j. Nous stockons maintenant 35 coefficients de ce polynôme plus un hachage (salé) des 5 autres.
Chaque fois que l'utilisateur nous donne 5 des caractères, nous pouvons tirer parti des 35 coefficients connus pour récupérer les 5 coefficients manquants, puis calculer le hachage. Si l'un des 5 caractères est incorrect, nous nous retrouverons avec un polynôme différent et donc un hachage différent. Donc, vous voudrez peut-être stocker le hachage dans un module de sécurité matériel dédié, comme James_plc l'a déjà souligné.
Alors oui, c'est possible. Cependant, si votre magasin sécurisé est compromis, il est au moins aussi simple à casser que le forçage brut d'un mot de passe à 5 lettres.
Pour d'autres algorithmes dans cette direction, vous voudrez peut-être en savoir plus sur partage secret.
Cela signifie-t-il que mon mot de passe est conservé en texte brut?
Il est très probable qu'il soit en texte brut ou crypté, mais ce n'est pas certain.
Par exemple, lorsque vous soumettez initialement votre mot de passe, il peut hacher et enregistrer différentes combinaisons de 5 mots de votre mot de passe et les index de caractères auxquels ils s'appliquent.
Cependant, toute personne ayant accès à ces informations et à l'algorithme de hachage pourrait facilement casser les hachages à 5 caractères et les réassembler pour obtenir votre mot de passe d'origine, donc même s'il est haché, c'est un modèle faible.
Je suppose que vous pouvez stocker une liste de hachages de toutes les combinaisons de caractères X, où X est le nombre de caractères que vous devez fournir.
Ce ne serait pas un hachage très fort si le reste du hachage était formé de personnages connus. Il serait possible de dériver le reste des caractères indésirables à partir d'un sel utilisateur ou dérivé d'une certaine manière des caractères X fournis, mais ce n'est toujours pas le hachage le plus fort.
Je ne vois pas pourquoi l'algorithme d'authentification n'a pas pu stocker toutes les combinaisons de vos sous-chaînes de mot de passe sous forme de hachages par rapport à la liste ordonnée des positions de caractères, donc si votre mot de passe était:
mot de passe
alors il y aurait une table de (clé, hachage) où les clés étaient par exemple.
"1" pour la première lettre uniquement "1,2" pour la première et la deuxième lettre uniquement "4,5,6" pour les quatrième, cinquième et six lettres uniquement
et stocker contre ces clés le hachage d'une chaîne de lettres indiquée, donc contre
'4,5,6' serait le hachage ('swo') de l'exemple de mot de passe.
Le problème avec cela est bien sûr que l'inversion des hachages serait simple à moins qu'ils ne soient salés avec un sel par utilisateur, et même alors, il serait relativement simple de forcer brutalement les hachages de courtes séquences pour des raisons évidentes si la vente était compromise (garder le secret du sel serait une solution à cela).
Je ne sais pas comment ils le feraient autrement ...
Question interessante.
La réponse est que sur le plan de la sécurité, c'est une mauvaise idée, mais qu'il est techniquement possible qu'elle soit hachée.
S'il s'agit d'un sous-ensemble aléatoire de votre mot de passe complet que vous saisissez (comme le premier, le deuxième, le cinquième, le sixième et le dernier caractère une fois, et une sélection aléatoire différente la prochaine fois), vous pouvez le faire en (lors de la sauvegarde initiale) en cassant le mot de passe dans des sous-ensembles prédéterminés, puis hachage.
Essentiellement, ce n'est qu'un moyen sophistiqué pour que les utilisateurs entrent plusieurs mots de passe sans savoir que c'est ce qu'ils font. L'utilisateur sait alors quel mot de passe saisir en fonction des cases disponibles.
Bien qu'il y ait des choses que vous pourriez faire pour le compenser (appliquer des mots de passe initiaux beaucoup plus longs, 3 tentatives de connexion strictes/jour, augmenter le nombre de mots de passe multiples enregistrés et passer à un nouveau après chaque tentative de connexion et ne pas permettre la répétition jusqu'à une connexion réussie , etc.), cela rendrait en général vos mots de passe plus courts (dans votre cas 5 caractères) et donc plus faibles.
En passant, la protection que vous obtiendriez des enregistreurs de frappe serait en tout cas minime. Il suffirait simplement que l'enregistreur de frappe examine réellement plusieurs de vos identifiants et détermine votre mot de passe complet. Une meilleure sécurité de journalisation des clés consisterait à utiliser une authentification à deux facteurs, ce qui ne doit pas être compliqué ou coûteux. Lorsque l'utilisateur se connecte, présentez-lui simplement un code qu'il peut écrire et saisir pour se connecter la prochaine fois.