Bonjour,
Ma banque utilise un serveur vocal pour m'authentifier quand je veux réaliser une opération par téléphone (genre un virement qui dépasse le montant maximum autorisé en ligne). Je dois saisir, sur le clavier de mon téléphone, mon identifiant (entièrement numérique), taper #, puis saisir mon mot de passe en ne tapant qu'une fois sur la touche qui comporte le symbole requis (par exemple, pour un L je tape sur la touche 5) et taper # pour finir.
Précision : seuls les chiffres et les lettres sont permis dans le mot de passe (pas de symboles spéciaux, inexistants sur un clavier de téléphone).
Est-ce que cela n'implique pas de stocker les mots de passe en clair (ou avec du "sel" ce qui est un peu mieux mais à peine) ?
Parce que sinon le serveur doit essayer toutes les combinaisons de mots de passe compatibles avec ma saisie. Chaque touche de téléphone ayant au moins 4 symboles possibles, ça me paraît peu crédible.
# en clair ? avec du sel ?
Posté par jemore . Évalué à 5.
Il est certainement stocké de manière hashé, et avec du sel.
Par exemple, si ton mot de passe est "toto34", la banque stockerait le hash de ce mot de passe salé, et le hash du mot de passe mobile (qui devient alors "868634" ) salé.
Donc non, cela n'implique pas de stocker le mdp en clair. Il suffit de stocker le hash du mot de passe mobile.
[^] # Re: en clair ? avec du sel ?
Posté par mahikeulbody . Évalué à 4.
Ah oui mais c'est bien sûr !
[^] # Re: en clair ? avec du sel ?
Posté par gUI (Mastodon) . Évalué à 3.
Du coup ça diminue l'entropie ? Au lieu de 26 lettres on n'en a plus que 10.
Après ce serait amusant de tenter un mot de passe "synonyme" sur le site web pour savoir si il y a 2 stockages de hash séparés ou pas.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: en clair ? avec du sel ?
Posté par mahikeulbody . Évalué à 3.
Je ne sais pas s'ils sont "séparés" mais je suis prêt à parier que le serveur vocal ne consulte que la base des hash "numériques", tandis que le serveur web ne consulte que la base des hash "normaux".
Mais je pourrais essayer, effectivement.
[^] # Re: en clair ? avec du sel ?
Posté par gUI (Mastodon) . Évalué à 2.
Je pense comme toi, ce serait évidemment la bonne façon de faire mais… amusons-nous un peu :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# deux hash d'un même mot de passe
Posté par mahikeulbody . Évalué à 4.
Si la base des hashs de mot de passe est compromise, cela ne facilite pas le travail d'avoir à sa disposition le hash classique mais aussi le hash de l'équivalent numérique "clavier téléphonique" ?
[^] # Re: deux hash d'un même mot de passe
Posté par ted (site web personnel) . Évalué à 4.
Si. On peut essayer de casser le mot de passe mobile en premier, vu qu'il est plus faible, puis après ça casser le mot de passe entier en retirant tous les caractères qui n'en font pas partie. Ça limite à 3 possibilités par lettre lors du deuxième bruteforce, et en plus tu connais la longueur du password.
On peut aussi arguer que la connexion téléphonique n'est pas sécurisée. Je ne sais pas si il y a un minimum de chiffrement en GSM (je crains que non), mais au minimum ton opérateur téléphonique peut écouter et récupérer ton password mobile.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: deux hash d'un même mot de passe
Posté par mahikeulbody . Évalué à 2.
J'imagine que c'est pour ça que malgré l'authentification via le serveur vocal, ils demandent quand même d'autres informations comme le montant courant des différents comptes (si l'opération demandée est sensible).
Ceci dit, c'est mieux que l'identification basée uniquement sur des questions confidentielles.
NB. L'expression "password mobile" peut induire en erreur : il s'agit du password saisi avec les touches d'un téléphone, pas nécessairement un téléphone mobile.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.