Et dans ce monde ultra-sécurisé ou la banque mets en place une double authentification (qui casse plus les... qu'autre chose)
Mais pour le moment il est estimé que c'est largement plus efficace qu'un mot de passe même de 1000 caractères (le problème n'est pas sa longueur). Et perso je ne vois pas trop la complexité, c'est sur mon tel avec empreinte donc très rapide à valider le popup qui arrive sur mon tel.
C'est même plutôt un bon exemple (quand les banques ne font pas n'importe quoi avec leur app, certes, bon j'ai une banque où je ne met pas l'empreinte car ça permet aussi l'accès à mes comptes, ce que je ne veux pas pour... des raisons de sécurité trop faible de mon point de vue dans ce cas, et cette banque ne sépare pas les 2, donc bon le code, ça va aussi).
C'est en fait plutôt un exemple pas trop mal de sécurité adaptée aux utilisateurs par rapport au niveau de risque.
J'espère que l'auteur du journal à désactivé le sans contact de sa CB (perso je l'ai fait [...] Même si d'un autre côté je paie souvent en liquide,
Alors d'une il y a une limite de paiement, et de 2 avec le sans contact et contrairement au liquide on retrouve facilement qui encaisse, et en pratique il y a bien moins de problème qu'avec le liquide.
Pareil, la sécurité a été adaptée, pas trop chiante tout en étant au niveau de sécurité limitant l’intérêt de "voler". Pas pour rien que ça marche, contrairement à d'autres projets qui ont merdé car soit niveau de sécurité insuffisant soit niveau de sécurité trop chiant.
Et c'est bien le problème que soulèvent les réactions, on voit un dogmatisme en plus d'une réponse qui montre ne pas avoir lu le commentaire (car le sujet était déjà abordé, et "bizarrement" pas de contre-argumentation sur ce que j'avais déjà écrit en avance sur leur réaction), et de vouloir du "sécurisé top secret même si c'est chiant" partout.
Pour revenir au sujet, la base de données n'est pas locale (et personne n'a démontré qu'il n'y avait pas de limite par jour pour dire que ce n'est pas un problème pour casser) et si elle se fait voler on réinitialise de suite les mot de passe dès qu'on apprend la fuite (au pire quelques personnes se plaignent avant qu'on comprenne que la base a été volée) et donc la valeur de la base de donnée est bien faible.
Si l'auteur du journal utilise déjà ce qu'il a comme possibilité (mot de passe aléatoire de 12 caractères non réutilisé ailleurs par lui), il a déjà une protection largement supérieure à la valeur de ce qu'il veut protéger, ou il faudra démontrer le contraire.
[^] # Re: Sécurité adaptée
Posté par Zenitram (site web personnel) . En réponse au journal Mutuelle et mot de passe. Évalué à 0.
Un peu HS mais bon, allons-y:
Mais pour le moment il est estimé que c'est largement plus efficace qu'un mot de passe même de 1000 caractères (le problème n'est pas sa longueur). Et perso je ne vois pas trop la complexité, c'est sur mon tel avec empreinte donc très rapide à valider le popup qui arrive sur mon tel.
C'est même plutôt un bon exemple (quand les banques ne font pas n'importe quoi avec leur app, certes, bon j'ai une banque où je ne met pas l'empreinte car ça permet aussi l'accès à mes comptes, ce que je ne veux pas pour... des raisons de sécurité trop faible de mon point de vue dans ce cas, et cette banque ne sépare pas les 2, donc bon le code, ça va aussi).
C'est en fait plutôt un exemple pas trop mal de sécurité adaptée aux utilisateurs par rapport au niveau de risque.
Alors d'une il y a une limite de paiement, et de 2 avec le sans contact et contrairement au liquide on retrouve facilement qui encaisse, et en pratique il y a bien moins de problème qu'avec le liquide.
Pareil, la sécurité a été adaptée, pas trop chiante tout en étant au niveau de sécurité limitant l’intérêt de "voler". Pas pour rien que ça marche, contrairement à d'autres projets qui ont merdé car soit niveau de sécurité insuffisant soit niveau de sécurité trop chiant.
Et c'est bien le problème que soulèvent les réactions, on voit un dogmatisme en plus d'une réponse qui montre ne pas avoir lu le commentaire (car le sujet était déjà abordé, et "bizarrement" pas de contre-argumentation sur ce que j'avais déjà écrit en avance sur leur réaction), et de vouloir du "sécurisé top secret même si c'est chiant" partout.
Pour revenir au sujet, la base de données n'est pas locale (et personne n'a démontré qu'il n'y avait pas de limite par jour pour dire que ce n'est pas un problème pour casser) et si elle se fait voler on réinitialise de suite les mot de passe dès qu'on apprend la fuite (au pire quelques personnes se plaignent avant qu'on comprenne que la base a été volée) et donc la valeur de la base de donnée est bien faible.
Si l'auteur du journal utilise déjà ce qu'il a comme possibilité (mot de passe aléatoire de 12 caractères non réutilisé ailleurs par lui), il a déjà une protection largement supérieure à la valeur de ce qu'il veut protéger, ou il faudra démontrer le contraire.