Question:
Si un fournisseur voit les 4 derniers caractères de mon mot de passe, peut-il le voir en entier?
rhymsy
2015-09-17 19:51:51 UTC
view on stackexchange narkive permalink

J'ai des domaines / sites Web ainsi que des e-mails avec Bluehost. Chaque fois que j'ai besoin d'assistance, ils ont besoin des 4 derniers caractères de mon mot de passe principal pour le compte. Ils ne peuvent pas me dire comment ils stockent le mot de passe, donc je suis intrigué par la façon dont ils pourraient stocker en toute sécurité mon (mes) mot (s) de passe et voir toujours les 4 derniers caractères. Voyent-ils le mot de passe complet en texte brut?

Tous les scénarios sont possibles.
C'est avec un hébergeur réputé, donc bien que nous ne puissions pas savoir avec certitude que cela a été fait de manière intelligente, nous pouvons (probablement) supposer qu'ils le font au moins en toute sécurité. Cependant, il n'y a vraiment pas de moyen sûr de le faire.
La prochaine fois que vous aurez besoin d'aide, donnez-leur 4 autres chiffres. Comme l'a dit @Begueradj, tous les scénarios sont possibles. Cela comprend le théâtre de sécurité.
@emory En fonction du niveau de sécurité, il est possible que leur donner délibérément les mauvais 4 chiffres entraîne le verrouillage du compte du demandeur.
@immibis bon point. appelez-les et demandez de l'aide en utilisant les informations d'identification d'un autre utilisateur. Puis, quand ils demandent les 4 derniers, inventez quelque chose. S'ils continuent à apporter leur soutien, il y a de fortes chances qu'ils n'aient pas de système pour les 4 dernières vérifications et demander tout cela était pour le spectacle.
@immibis, ce que vous suggérez, c'est que ** toute personne ** peut verrouiller le compte d'une autre personne en appelant simplement et en donnant les mauvaises informations?
On dirait que je traiterais les quatre derniers chiffres de mon mot de passe comme un code PIN d'authentification à deux facteurs et créerais un mot de passe fort * sans * ces quatre derniers chiffres. IE, «agrafe de batterie de cheval correcte 7684» comme mot de passe.
Si j'expérimentais exactement ce que vous décrivez, j'arrêterais d'utiliser Bluehost dès que possible.
@Chipperyman,, nous ne pouvons certainement rien supposer. Ils peuvent avoir une large clientèle et donner également des numéros de carte de crédit, vous ne le savez tout simplement pas.
@emory comment diable demanderait-il une partie de votre mot de passe, "être pour le spectacle"? La seule chose qui montre est leur incompétence totale en matière de sécurité.
@Octopus de la même manière que le fait de retirer ses chaussures à l'aéroport protège l'aviation, en récitant 4 chiffres à un représentant de service qui peut ou non être en mesure de les vérifier peut «protéger» bluehost. Certains utilisateurs assimilent incohérence à la sécurité. Donnez-leur ce qu'ils veulent.
-1
@Octopus personne ne suggère que c'est une bonne pratique de sécurité.
Les quatre derniers caractères sont bien sûr "3456" ou "w0rd" ou "apple"
Pour tous ceux qui prêchent, c'est une "mauvaise décision impossible" - D'un point de vue commercial, cela peut être un cas d'utilisation totalement valable. Si leur mot de passe DB est piraté, ce sera mauvais pour l'entreprise. Chaque utilisateur sera informé de la "faille de sécurité, veuillez changer votre mot de passe" - s'ils ont stocké 4 chiffres de manière non sécurisée, les mots de passe seront piratés plus rapidement. Les dommages à la réputation seront donc un peu plus importants, mais comme il s'agit de toute façon d'un scénario à risque élevé à faible probabilité, l'impact global sur le budget-risque peut être très faible. Et l'avantage pour les utilisateurs de ne pas oublier leur extra-code peut être plus grand.
En tant qu'ancien employé de Bluehost, je peux vous dire qu'ils ne connaissent pas tout le mot de passe. Il y a juste une boîte dans laquelle l'agent tape les quatre derniers chiffres du mot de passe, puis le système le vérifie par rapport au mot de passe qu'il a dans le fichier. S'il correspond, il deviendra vert et sera enregistré, sinon, il deviendra rouge et marquera également le journal. Même s'ils connaissaient le mot de passe, tout ce que fait l'employé est enregistré sur le compte et peut ensuite être consulté si quelque chose est présumé se produire. Quant au stockage du mot de passe et au cryptage, ça me bat, mais je n'ai jamais entendu parler de
@Mansav Pourtant, la seule façon qui pourrait fonctionner est si le mot de passe est stocké non chiffré quelque part.
@Daniel techniquement, ils pourraient avoir 2 hachages, un pour le mot de passe complet et un pour les 4 derniers caractères. Cela réduirait encore la sécurité, mais pas autant.
Ils pourraient stocker les 4 derniers caractères sous forme de valeur distincte dans la base de données (en clair ou haché) - ce qui facilite la vérification.
Ils pourraient simplement multiplier toutes les valeurs puis les stocker en texte brut.Bien sûr, cela signifie que de nombreux mots de passe seront valides, mais je pense que c'est un bon compromis.Quelque chose d'autre que la multiplication peut avoir été utilisé pour obtenir un hachage de nombreuses collisions.
Neuf réponses:
Steve Sether
2015-09-17 20:12:43 UTC
view on stackexchange narkive permalink

Il y a plusieurs possibilités.

  1. Ils pourraient stocker le mot de passe complet en texte clair, et n'afficher que les 4 derniers caractères à la personne d'assistance.

  2. Ils pourraient hacher le mot de passe deux fois. Une fois que vous avez haché le mot de passe complet, et de nouveau avec seulement les 4 derniers. Ensuite, la personne de support tape les 4 derniers pour voir si cela correspond à la valeur hachée. Le problème avec ceci est qu'il est plus facile de forcer brutalement les mots de passe complets puisque les 4 derniers caractères sont dans un hachage séparé, ce qui réduit l'entropie.

  3. Ils pourraient hacher le mot de passe complet, et stocker les 4 derniers inplaintext. Évidemment, cela rend beaucoup plus facile la force brute du mot de passe si un attaquant accédant à la base de données de mots de passe connaît les 4 derniers chiffres.

  4. Quelque chose d'autre où les 4 derniers caractères sont stockés dans certains façon qui est découvrable, comme le cryptage que Mike Scott mentionne ci-dessous. Si le secret pour déverrouiller les 4 personnages peut être découvert, c'est aussi mauvais que du texte en clair.

Tous les scénarios sont très mauvais et réduisent considérablement la sécurité du système. Il n'est pas possible de savoir quel scénario ils utilisent, mais chacun d'eux montre un manque de considération pour les failles de sécurité. Je vous conseillerais de faire preuve de prudence s'il s'agit d'un site sur lequel vous vous souciez de la violation de votre compte.

Il y a au moins une autre option. Ils peuvent hacher le mot de passe complet et enregistrer les quatre derniers caractères avec un cryptage symétrique, afin que leur logiciel puisse les déchiffrer pour la personne de support. Toujours mauvais, mais pas tout à fait aussi mauvais.
Et la plupart des bons sites sortent tout de suite et disent des choses comme «Personne d'ici ne vous demandera jamais votre mot de passe». Cela signifie, bien sûr, même pas les quatre derniers chiffres ...
Je viens de vérifier le formulaire de changement de mot de passe sur mon compte Bluehost. Malheureusement, le site Web vous permettra d'utiliser des mots de passe aussi courts que 8 caractères, ce qui signifie que ces quatre derniers chiffres peuvent considérablement affaiblir certains mots de passe. (Je suppose que pour des mots de passe suffisamment longs, laisser les quatre derniers caractères être découverts ne réduit pas suffisamment votre entropie pour être une préoccupation pratique?)
À toutes fins utiles, stocker un hachage des 4 derniers équivaut également à stocker du texte brut. Avec les GPU modernes, vous pouvez forcer brutalement cet espace en un rien de temps.
Un bon scénario: le mot de passe est divisé. Les premiers caractères sont hachés avec un sel et les 4 derniers sont hachés avec un autre sel.
@Ismael: Cela réduit encore le temps de rupture de `O (2 ** (n + k))` à `O (2 ** n + 2 ** k)` ... ce qui est ** vraiment vraiment mauvais **. À peu près aussi loin d'un "bon scénario" que vous pouvez l'imaginer (certes encore mieux que de stocker du texte en clair)
@IsmaelMiguel Si vous hachez quatre caractères, un sel ne vous sauvera pas. En supposant que ces personnages soient choisis parmi un ensemble d'environ 90, il n'y a que 65 millions de possibilités, et ils peuvent être forcés assez rapidement (à moins qu'ils n'utilisent quelque chose comme bcrypt avec un facteur de travail suffisamment élevé pour ralentir les opérations à le point où l'utilisateur remarque le décalage).
Que faire si les quatre derniers caractères sont stockés à l'aide d'un hachage avec un nombre élevé de collisions, car il sera utilisé pour une simple vérification en un seul essai? Si ce hachage est forcé brutalement, il générera de nombreux faux résultats qui n'aideront pas trop à obtenir le mot de passe complet.
@MikeScott Sinon, comment stockeriez-vous un hachage de 4 caractères? Je pensais qu'il était sous-entendu qu'il était censé rendre l'opération aussi lente que possible.
@IsmaelMiguel Vous n'architectureriez pas votre système de telle manière que vous stockiez des hachages cryptographiques de quatre chaînes de caractères du tout - il n'y a pas de bonne façon de le faire, alors ne le faites pas.
@MikeScott Fine fine fine fine fine fine fine fine fine fine fine fine. Mais comment protégeriez-vous une broche à 4 caractères?
Notamment, l'option la moins sécurisée est aussi la plus simple, et donc malheureusement la plus probable.
Si j'ai bien compris, ils vous permettent probablement seulement de «saisir» le mot de passe à quatre chiffres par téléphone. Je me demande si cela réduit considérablement la sécurité car on ne peut pas faire des milliers de tentatives par seconde via la voix sur téléphone :). Le "deuxième" mot de passe pourrait être stocké sur une base de données avec un accès en lecture seule. Je me demande quelles seraient les implications sécuritaires d'un tel scénario.
Si les 4 derniers caractères sont stockés en tant que chiffre de contrôle (similaire au hachage de collision élevé décrit ci-dessus), cela n'affaiblirait pas de manière significative le hachage du mot de passe réel, qui peut être stocké en toute sécurité.
@Kevin: si les n-4 premiers caractères du mot de passe constituent un mot de passe «assez bon» pour un certain but et les 4 derniers ne donnent aucune indication sur les autres alors bien sûr, révéler les 4 derniers caractères ne pose aucun problème à cet effet. Ainsi, par exemple, si vous avez généré au hasard le mot de passe à l'aide de votre gestionnaire de mots de passe, il se peut qu'il contienne déjà 4 caractères excessifs et sinon, l'ajout de 4 caractères au-delà de ce que vous utilisez habituellement vous assurera.
... mais c'est toujours ridicule de la part du fournisseur, car il n'a pas expliqué les conséquences à l'interrogateur. Ils auraient pu à la place demander un «mot de passe» de support à 4 caractères distinct. Bien sûr, si vous faites cela, il y a toujours un risque que les utilisateurs vous donnent 4 caractères à partir de leur mot de passe principal, ce n'est pas simple de les convaincre du contraire. Vous pouvez donc le générer pour eux, mais ils ne s'en souviendront pas, etc. Ou vous pouvez vous connecter et appuyer sur un bouton pour générer un code d'assistance temporaire, mais cela n'aide pas les personnes dont le problème d'assistance est qu'elles sont verrouillées de leur compte ...
@IsmaelMiguel Vous devez stocker la broche dans un TPM matériel. C'est ce que font les banques.
@Navin Ne sont-ils pas en lecture seule? En outre, comment changeriez-vous le code PIN de, par exemple, votre compte? (Dans mon cas, au lieu d'une carte de crédit, j'ai ce livre que le guichet automatique lit, comme une carte à bande magnétique géante. Comment serait-il stocké, à votre avis?)
Certaines banques émettent une carte de crédit avec un code PIN qui bloque physiquement l'accès à la puce après un nombre limité d'essais. Ils _peuvent_ avoir une puce de ce type par client et y stocker en toute sécurité les 4 derniers caractères. Mais ils ne le font probablement pas.
Les tentatives de force brute @CommuSoft, ne sont de toute façon jamais effectuées via l'interface prévue. Ce serait bien trop lent. Le problème viendrait quand / si quelqu'un avait accès à la base de données. Le stocker séparément du hachage principal n'aide pas, et ne le rend pas non plus en lecture seule.
@ChrisMurray: Je le sais. A propos de la lecture seule: j'ai fait une erreur, qu'en est-il d'une base de données avec accès en écriture seule pour la connexion via le serveur. Cela créerait un obstacle supplémentaire à contourner.
@CommuSoft, Impossible de le faire écrire uniquement, car le système de support doit pouvoir vérifier le mot de passe donné par rapport à lui.
@ChrisMurray: Je veux dire que le serveur de base de données a deux connexions: une au (serveur Web) qui est en écriture seule. Un second attaché à «l'intranet» qui peut réussir à lire le contenu. Évidemment, il est possible d'essayer de pirater les droits d'accès, mais cela rend au moins un pas plus difficile. De toute évidence, un appareil qui n'a qu'un moyen d'écrire des données ne fait qu'augmenter l'entropie dans l'univers.
Et si j'ai le mot de passe abcdef. Ils hachent tous sauf les quatre derniers caractères (ab), puis hachent les quatre derniers caractères (cdef). Cela signifie qu'il y a deux hash qui pourraient être totalement indépendants avec un sel différent. Lorsque vous vous connectez, vérifiez les deux hachages, mais le service client n'en vérifie qu'un.
@the_lotus C'est possible aussi, et tout aussi mauvais. Il existe de nombreuses façons de le faire, mais toutes vont compromettre le processus de hachage. Je ne connais aucun moyen de le faire d'une manière qui ne compromette pas la sécurité, et il peut même être impossible de le faire à moins que vous ne vous appuyiez sur quelque chose comme un TPM.
@CommuSoft Je dirige une entreprise qui traite beaucoup de transactions et c'est exactement ce que je fais! Le serveur Web ne peut * écrire * que dans la base de données qui stocke les SSN, les clés privées bitcoin, etc. Seule une personne ayant un accès physique peut * lire * à partir de la base de données.
"Tous les scénarios sont très mauvais" Veuillez mettre en évidence cette partie de votre réponse. Faites-le aussi noir que possible, aussi grand que possible et aussi majuscule que possible.
Une autre option pour votre liste est que cela pourrait être fait à l'aide d'un HSM + mots de passe cryptés symétriquement. Correctement mis en œuvre, cela n'est pas dangereux (c'est ce que de nombreuses / toutes les banques font avec les codes PIN des cartes par exemple.)
@GustavoRodrigues Cela augmenterait également la probabilité d'une fausse confirmation d'identité positive.
J'ai également vu une autre approche (parfois utilisée pour les certificats) - tous les codes PIN seraient stockés sur un ordinateur séparé, connecté uniquement via une simple liaison série. La seule opération possible est "Envoyer le code PIN -> Lecture réussie / échec". À moins que quelqu'un n'accède à l'ordinateur * physiquement *, c'est aussi sûr que possible. Et nous savons tous ce que vous pouvez faire avec un ordinateur une fois que vous y êtes physiquement :)
N'oubliez pas que lorsque vous discutez du forçage brutal des 4 caractères, ils sont donnés verbalement à un représentant de service; ne pas être essayé des milliers à la fois automatiquement.
@Daniel Nous supposons que le pirate a pénétré dans le système que le représentant du service utilise pour vérifier les quatre caractères, probablement en s'emparant de la base de données sous-jacente. Et donc, la vitesse du forçage brutal n'est limitée que par la vitesse de leur matériel et la difficulté des algorithmes utilisés.
WhiteWinterWolf
2015-09-17 20:10:35 UTC
view on stackexchange narkive permalink

Il est toujours difficile de répondre à de telles questions car nous ne sommes pas dans les secrets de Bluehost, nous ne pouvons donc que deviner et faire des suppositions.

Cependant, le comportement que vous décrivez reste possible sans stocker de mot de passe clair:

  • Lorsque vous créez un nouveau compte ou réinitialisez votre mot de passe, le mot de passe est envoyé au serveur, très probablement sous une forme claire protégée par TLS,
  • Le serveur générera alors deux hachages différents pour le même mot de passe:
    • Le premier hachage prend votre mot de passe complet et est utilisé pour l'authentification habituelle,
    • Le second hachage ne prend que les quatre derniers caractères de votre mot de passe,
  • Lorsque vous contactez leur équipe de support, vous leur indiquez vos quatre derniers caractères, ils les tapent sur leur logiciel, puis leur logiciel calculera en interne un hachage, le vérifiera et affichera le résultat au technicien d'assistance.
Pourquoi utiliseraient-ils une partie de votre mot de passe pour cela? C'est à cela que servent les codes PIN de sécurité.
@Octopus: Comme dit, nous ne sommes pas dans les secrets de Bluehost, donc je ne peux certainement pas répondre "pourquoi", je ne peux que deviner "comment". Et très probablement, même la plupart des employés de Bluehost ne pourraient sincèrement pas répondre "pourquoi" ce système a été conçu comme ça: à un moment donné, quelques personnes, gestionnaires et chefs de projet, se sont réunis dans une pièce et ont décidé que c'était la meilleure option, seulement ils sauraient exactement les avantages et les inconvénients qui ont été discutés au cours de cette réunion.
bishop
2015-09-19 00:40:16 UTC
view on stackexchange narkive permalink

BlueHost conseille des règles raisonnables pour les mots de passe forts, donc ils emploient probablement au moins une personne qui sait ce qu'il fait.

En supposant que cela, BlueHost utilise peut-être une implémentation de Partage secret de Shamir ou une variante de ce thème. Shamir est théoriquement sûr, donc je ne sauterais pas immédiatement à la conclusion (comme l'ont fait d'autres réponses) que tout système faisant cela est intrinsèquement moins sûr.

D'un autre côté, l'implémentation de Shamir n'est pas triviale, toutes les autres réponses pourraient donc s'appliquer également. Puisque la sécurité est en fin de compte une question de confiance , si vous ne vous sentez pas en sécurité avec ce schéma, je vous suggère de trouver un autre fournisseur!

Ou qu'ils ont pu ** copier ** une liste de règles raisonnables de quelqu'un d'autre. Comme c'est malheureusement le cas ici. Il est clairement copié à partir d'une [ancienne page Microsoft sur les mots de passe] (https://web1.tcdsb.org/CCRFProduction/images/Strong%20Passwords.pdf). Ils ne l'ont même pas adapté pour s'adapter à leur site Web, comme la phrase «Password Checker est une fonction non-enregistrement _ sur ce site Web_» (lien vers le vérificateur de mot de passe de Microsoft), ou la discussion des mots de passe vides sur différentes versions de Windows (qui est hors de portée pour bluehost).
Compte tenu de ces indices et qu'ils ne reconnaissent même pas que ce contenu provient d'un article de Microsoft de 2006 (aurait-il été si difficile de dire «Microsoft recommande les conseils suivants pour créer un conseil sécurisé»?), Je doute fortement qu'ils aient l'autorisation du propriétaire des droits d'auteur (Microsoft, probablement) pour le copier. Mais plus important que la violation du droit d'auteur (suffisamment problématique pour qu'une entreprise soit impliquée dans), je pense que nous pouvons inverser la conclusion de l'évêque et arriver à la conclusion qu'ils n'emploient pas une seule personne qui sait à ce sujet (ou du moins 't).
Ce qui me rend encore plus méfiant à l'égard de la sécurité dans cette entreprise. S'ils se sont trompés pour un conseil de mot de passe _unimportant_, ** comment puis-je être sûr qu'ils ont bien fait les choses pour les grandes décisions? ** Surtout après avoir pris connaissance de leur pratique déjà douteuse consistant à «utiliser les 4 derniers caractères de mot de passe» pour le téléphone vérification…
@Angel Belle recherche, et d'accord: en l'absence de toute autre preuve de conscience de la sécurité, je doute de leurs motivations et de leur mise en œuvre.
Je ne vois pas pourquoi ce serait plus sûr. Le seul moyen pour que cela soit plus sûr, c'est que vous pouvez fournir à la personne du service d'assistance une «partie» qui doit être conçue à partir d'eux. En dehors de cela, vous forcez maintenant simplement les 4 personnages avec les autres parties connues jusqu'à ce que vous obteniez un secret qui correspond. Même dans une situation où k + 2 pièces sont nécessaires, avec k pièces dans le système, k personnes du helpdesk et 1 secret uniquement connu du client, vous vous retrouvez avec au plus k pièces possibles, que vous pouvez tester par rapport à un autre secret pour déterminer quelle partie ne fonctionne pas, et doit donc être la partie du client.
kasperd
2015-09-17 23:13:03 UTC
view on stackexchange narkive permalink

Je ne peux pas vous dire exactement comment ils stockent le mot de passe. Mais à partir de votre description de leur processus, nous pouvons montrer que le mot de passe doit être stocké de manière non sécurisée.

Je suppose que lorsqu'ils demanderont les quatre derniers caractères, ils pourront en fait vérifier l'exactitude de ce que vous leur avez dit (en d'autres termes, ils ne sont pas simplement du bluff).

Cela signifie qu'ils ont des données qui leur permettront de vérifier les personnages que vous leur avez dit dans un court laps de temps. Les mêmes données peuvent être utilisées dans une attaque par force brute pour casser les quatre derniers caractères du mot de passe. Quatre personnages sont certainement trop courts pour arrêter un attaquant déterminé.

Une fois que l'attaquant a les quatre derniers caractères, une autre attaque peut être montée sur les personnages précédents. Pour cette attaque par force brute, les quatre derniers caractères du mot de passe n'ajoutent aucune sécurité, vous avez donc au mieux la sécurité équivalente d'un mot de passe de quatre caractères plus court qu'il ne l'est réellement.

Il pourrait être possible de contourner le vulnérabilité en choisissant un mot de passe sécurisé puis en ajoutant quatre caractères supplémentaires choisis complètement indépendamment du mot de passe choisi au départ. Ce sera sécurisé s’ils ne peuvent vérifier que les quatre derniers caractères et non un suffixe de longueur arbitraire.

S'ils sont en fait capables de vérifier un suffixe de longueur arbitraire et pas seulement ceux d'exactement quatre caractères, le stockage des mots de passe serait encore plus faible. Ce serait à peu près aussi peu sûr que de le stocker sous forme de texte brut, et dans ce cas, vous ne pouvez pas le contourner en choisissant un mot de passe plus fort.

En effet, si vous pouvez vérifier un suffixe de longueur arbitraire, la partie est terminée. Il ne faut que 256 suppositions (ou moins) pour vérifier le dernier octet, puis 256 autres suppositions pour vérifier les deux derniers octets connaissant le dernier octet, et ainsi de suite jusqu'à ce que vous connaissiez le mot de passe complet en 256 * n suppositions. Comme vous le dites, cela pourrait aussi bien être du texte brut en ce qui concerne une attaque hors ligne sur le hachage stocké.
hogarth45
2015-09-17 20:02:00 UTC
view on stackexchange narkive permalink

Comme vous le savez, un mot de passe doit être haché avant d'être stocké, vous devez donc vous demander la météo ou non, ils stockent les 4 derniers caractères à des fins d'autorisation verbale, puis hachent le mot de passe avant de le stocker, ou ils sont juste en le stockant en clair.
Je suppose que ce dernier.

emory
2015-09-18 09:19:45 UTC
view on stackexchange narkive permalink

Je ne pense pas que ce soit probable, simplement possible.

Chaque fois qu'OP a besoin d'assistance, il demande les 4 derniers chiffres de son mot de passe. Ils le salent et le hachent et stockent le sel et le hachage et suffisamment d'informations pour reconstruire le support dans une table de support spéciale.

Ensuite, quand OP se connecte (avec le mot de passe complet), ils peuvent consulter la table de support et calculer les hachages. Ensuite, ils commettent les "supports" vérifiés et répudient les "supports" falsifiés.

Cela suppose bien sûr que

  • le support est quelque chose qui peut être commis ou répudié à un moment ultérieur

  • le processus de demande des 4 derniers ne fuit pas d'informations (quelqu'un vous demandant les 4 derniers ne se qualifie pas car nous ne pouvons pas effacer de manière fiable ses souvenirs) .

Je ne peux pas imaginer une situation où cela aurait un sens commercial. Mais si c'était le cas, je pense que je donnerais à mes utilisateurs un mot de passe spécial à 4 chiffres "support" à la place.

Et les "supports" stockés non encore vérifiés sont toujours une aide précieuse pour les crackers, s'ils peuvent être volés avec les mots de passe complets hachés.
@BenVoigt oui, forcer brutalement les 4 derniers chiffres est faisable, donc les saler n'ajoute pas beaucoup de valeur. Alternativement, si l'attaquant peut observer quels supports sont validés ou répudiés et que l'attaquant peut automatiser les demandes de support sans déclencher de coupure, alors l'observateur peut probablement forcer en ligne les 4 derniers.
Si l'utilisateur fait un tas de demandes d'assistance puis oublie son mot de passe, les demandes d'assistance sont validées ou rejetées. S'il est commis, alors l'attaquant peut faire un tas de demandes d'assistance puis prétendre que l'utilisateur "oublie son mot de passe". S'il est répudié, l'attaquant peut répudier les demandes d'assistance de l'utilisateur réel.
CoffeDeveloper
2015-09-23 15:52:32 UTC
view on stackexchange narkive permalink

Ils peuvent voir le mot de passe complet? Oui, il est tout à fait possible qu'ils puissent deviner le mot de passe (si les 4 derniers chiffres sont une date ou des parties d'un mot. Si le mot de passe est haché en entier, il suffit de connaître 4 chiffres pour lancer une attaque par force brute. ou même en essayant de faire une heuristique sur la fonction de hachage pour voir comment 4 chiffres se propagent en arrière réduisant de beaucoup la plage de mots de passe possibles.

Devinez ce mot de passe: 

  ** ******* ange

Ou celui-ci: 

  **** 1994

Il Il est également possible qu'ils soient hacker et exploitent l'API de support client (le cas échéant) pour accéder aux informations des utilisateurs, cette tâche est même facilitée en connaissant 4 chiffres.

Ils ne devraient pas le faire, en aucun cas donner une partie du mot de passe à un inconnu une bonne option même (SURTOUT, si après avoir été viré, il peut essayer de nuire aux utilisateurs, et il existe de nombreux exemples historiques) si cela fait partie du support client.

Un client le support ne doit avoir aucun moyen d'accéder au mot de passe d'origine et doit agir via une API ad-hoc pour éviter ne pas faire de mauvaises choses (le support ne devrait toujours pas pouvoir accéder à toutes les données).

De plus, si le support client doit demander 4 chiffres du mot de passe, vous ne pouvez pas envoyer un e-mail aux utilisateurs avec des avertissements tels que "ne jamais donner votre mot de passe parce que nous ne le demandons pas "parce que vous le demandez réellement et former vos utilisateurs à donner des détails personnels peut les aider à se faire prendre par des e-mails de phishing.

S'ils veulent vraiment vérifier l'authenticité de l'utilisateur, ils devraient utilisez des trucs comme des codes SMS, des questions secrètes ou simplement des clés envoyées par e-mail.

Néanmoins, je pense que c'est beaucoup moins cher d'envoyer un e-mail ou un SMS que de payer 1 à 2 minutes à quelqu'un faisant la même chose ( sauf si elle est vraiment sous-payée).

Si un service a vraiment besoin de vérifier l'identité de l'utilisateur pour quelque chose d'important, j'utiliserais probablement un flux de webcam à partir duquel un opérateur peut voir le visage de l'utilisateur, puis lui demanderais de faire des actions spécifiques (comme écrire un mot sur papier et montrer lui retour) afin d'empêcher quelqu'un d'autre d'utiliser une vidéo enregistrée).

Cela ne sera bien sûr pas aimé par les utilisateurs pour des raisons de confidentialité ^^

Votre réponse ne répond pas à la question. En passant, je ne crois pas que quiconque ici préconise qu'un tel système soit la meilleure pratique ou même acceptable, mais ce n'est pas vraiment le sujet ici.
Maintenant, il répond ^^, j'ai oublié de mettre cette partie car j'étais trop occupé à écrire la "partie supplémentaire" de la réponse. @Selenog
@Selenog et à ce stade, le vote négatif doit être révoqué?
Falantar
2018-12-21 04:45:43 UTC
view on stackexchange narkive permalink

Comme d'autres l'ont dit, il existe de nombreuses façons pour ce fournisseur de protéger les «quatre derniers chiffres» de votre mot de passe. Cependant, à chaque fois que vous diffusez ne serait-ce qu'une partie de votre mot de passe, vous vous ouvrez à la compromission de votre compte. Une des choses que personne ne semble avoir mentionnée est que les 4 derniers chiffres de votre mot de passe que vous saisissez dans le journal de discussion ne sont probablement pas chiffrés. De toute évidence, les journaux de discussion doivent être facilement accessibles. Même si vous suivez les règles de base de complexité des mots de passe, vous venez de réduire la longueur effective de votre mot de passe de 4 caractères. Imaginez maintenant si c'est un mot de passe que vous utilisez dans d'autres endroits avec une sécurité plus légère (ce que malheureusement beaucoup de gens font).

TL: DR C'est une pratique ridicule et je resterais loin d'eux à tout prix

Je dirais que c'est de l'idiotisme visible.Les idiotismes non visibles peuvent être plus problématiques (par exemple, pour permettre à la société de développement de logiciels ce qu'elle embauche pour développer son système de relation client, pour voir les mots de passe de toute façon cryptés avant leur cryptage).
rocccccc
2015-09-17 22:03:20 UTC
view on stackexchange narkive permalink

Ils peuvent stocker un hachage de votre mot de passe complet, plus un hachage des quatre derniers caractères suivis de 12 caractères générés aléatoirement. Si la façon dont ils génèrent les caractères aléatoires est aussi sûre que le processus de hachage, cela devrait être aussi sûr que de stocker votre mot de passe par lui-même.

Cela ne marcherait pas. Comment vérifieriez-vous les quatre derniers caractères par eux-mêmes?
N'est-ce pas la même chose que de saler le mot de passe de queue de 4 caractères avec 12 caractères de sel? Le problème est que 4 caractères sont si petits que le sel n'empêche pas une recherche par force brute. Plus de sel n'empêche toujours pas une recherche par force brute.
Le nombre arbitraire de caractères supplémentaires ajoute vraiment à l'absurdité de cette réponse.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...