Tout va dépendre de l'expertise du prestataire tiers qui a mis en place leur système. Je vais suggérer deux points de faille qui peuvent arriver, et qui l'ont déjà été. Et ne nécessiteraient aucunement le concours du client pour mettre en oeuvre l'escroquerie.
Vue la taille du mot de passe (6 chiffres), une recherche exhaustive est triviale s'il y a eu une fuite de couples identifiants / mot de passe simplement hashés. J'ose espérer que la banque utilise un cryptosystème quand même plus fort en utilisant en plus un paramètre de chiffrement extérieur au fichier contenant ces couples.
La génération du code d'authentification ("code SMS" par exemple) doit suivre des procédés bien précis pour être sûre. Il peut arriver que les implémentations ne respectent pas strictement ces procédés. Soit par bug du développeur, soit par "ruse" en pensant être fort et que modifier l'algo le rendrait plus sûr car personne ne saura.
Maintenant que tu connais deux façons possibles, ça apporte quoi? Parce que décrire serait trop complexe pour le néophyte et/ou serait une source d'investigation de l'entreprise lésée qui corrigera bien sûr sans rien dire.
Vue la taille du mot de passe (6 chiffres), une recherche exhaustive est triviale s'il y a eu une fuite de couples identifiants / mot de passe simplement hashés. J'ose espérer que la banque utilise un cryptosystème quand même plus fort en utilisant en plus un paramètre de chiffrement extérieur au fichier contenant ces couples.
La génération du code d'authentification ("code SMS" par exemple) doit suivre des procédés bien précis pour être sûre. Il peut arriver que les implémentations ne respectent pas strictement ces procédés. Soit par bug du développeur, soit par "ruse" en pensant être fort et que modifier l'algo le rendrait plus sûr car personne ne saura.
Maintenant que tu connais deux façons possibles, ça apporte quoi? Parce que décrire serait trop complexe pour le néophyte et/ou serait une source d'investigation de l'entreprise lésée qui corrigera bien sûr sans rien dire.
