Bonne initiative, mais n'attaque pas le problème de fond.
On est sur un processus de longue durée (deux décennies), dont les appli' bancaire ne sont qu'une étape, pour un secteur.
La "sécurité" signifie ici "contrôle" (de l'usager, non pas le contrôle de l'usager sur ses fonds ou son accès à ses fonds). Et ce contrôle est déjà passé par plusieurs étapes:
De la passphrase simple au SMS, puis du SMS à l'OTP, puis de l'OTP à l'appli, puis de l'appli à l'OS qui prépare l'étape suivante: puces sécurisées pour collecter fingerprints, selfie et autres données biométriques.
L'extension s'est elle-aussi faite suffisamment progressivement: Pour le paiement par carte d'abord, ensuite étendu aux opérations dites "sensibles" dans l'espace en ligne (virements) puis la connexion à l'espace en ligne. (Ce alors même que la DSP2 concoctée par le lobby bancaire promouvait la 2FA en tant que palliatif au fait que le numéro de CB ne peut pas faire office d'identifiant lors d'un paiement)
Il faut reprendre la chronologie pour comprendre son aberration:
Vice numéro un: dans les années 2000, les banques doivent permettre le paiement par internet et laissent les clients s'authentifier avec un secret qui n'en est pas un: les données de la CB (qui n'est ni quelque chose que l'on connaît exclusivement, ni quelque chose dont la possession garantie à elle seule la légitimité à l'opération [c'est le propre d'un objet])
Pour pallier à ce faux secret: vice numéro 2: un code à usage unique. D'abord envoyé par SMS, puis sous la pression de Google (la hype autour du SS7), à l'OTP.
L'occasion était trop belle pour ne pas pousser pour plus de contrôle et imposer des app'.
(=> Le corollaire étant que la 2FA pour une authentification, à la différence d'un paiement, ne s'est jamais justifiée sauf par l'argument "Mme Michu utilise toujours le même mot de passe sur tous ses sites web, depuis 40 cyber-cafés")
D'ailleurs la 2FA n'est jamais rien d'autre qu'un second shared-secret sauf qu'il faut un CPU pour le dériver. Dans la DB du validateur il est dans la table {mfa_secrets} juste à côté de la table {users}). Mais devoir dériver mathématiquement un shared secret, ça incite fortement le client à être très bon en calcul mental ou avoir une calculette (autrement dit un smartphone). Serait-ce possible que le 2FA ait conçu inventé pour le smartphone ? (alternativement, on pouvait juste utiliser la colonne "passphrase" dans {users})
Le problème de fond (déjà soulevé) est qu'une politique de sécurité doit se baser sur une analyse des risques rationnelle qui ne peut pas être monolithique et unilatérale.
Or actuellement, c'est le fait du prince de la DSI d'une banque. Elle doit revenir aux usager (avec ou sans iphone, avec ou sans clef GPG, avec ou sans 2FA, etc...) car ils sont les seuls légitimes à arbitrer entre sécurité (empêcher l'accès à un tiers) et accessibilité/résilience (accéder à ses fonds en cas d'urgence [hôpital, à l'étranger, pas de batterie/4G, téléphone volé, ...]
D'ailleurs si l'on en revient aux fondamentaux, et même en considérant la philosophie biaisée de la DSP2 à propos de la 2FA pour les paiements en ligne, alors il y a une solution simple:
- La CB est l'objet
- L'usager associe une passphrase à sa CB auprès de sa banque.
- la banque valide valide la passphrase lors de la MFA => deux facteurs. Objet et mémoire de l'usager.
Concernant les secteurs, ils vont bien au-delà des banques: transfert de fonds (selfie chez Wise/Western Union etc...) mais aussi administration (identité numérique laposte). Les services (gaz/électricité) ne sont pas loin. Payer des services d'hébergement (ou de VPN) devra se faire de plus en plus avec des validations d'identité.
Il faut aussi mettre ça en parallèle avec la guerre aux VPN (Boursorama interdit l'usage du VPN pour des "raisons de sécurité" à l'instar de la BPCE qui fait régulièrement des tentatives d'extension dans ce sens, par petits pas).
De nombreux hébergeurs sont invités (par prestataires en "DDoS prevention") à couper d'emblée leur réseau aux VPN quand bien même leurs clients souhaiteraient permettre un accès vraiment universel à leur sites/services.
On pourrait rajouter la guerre aux humains avec les captchas à tour de bras. (Rappelons que vérifier une captcha pour un GET coûte plus de cycles CPU que de renvoyer la ressource depuis un cache : ce n'est donc pas pour lutter contre les "abus" que celles-ci existent mais bien dans le cadre d'une collecte d'information et de contrôle progressif du trafic)
Quand on pense qu'il y a même certains prestataires des paiement qui sont derrière Cloudflare (et donc que le numéro de CB qu'ils "collecte en SSL super-sécurisé" se balade en fait en clair sur le réseau du proxy...) ou que les conseillers bancaire accorde une valeur une signature manuscrite sur un scan :|
Le principe même de la 2FA est une quête sans fin, car si le mot de passe ne suffit pas, rien suffira jamais car tout le reste peut être hacké. (C'est très pratique que ça puisse l'être car ça force à rajouter une couche de complexité et de contrôle). D'ailleurs se qui compte n'est pas le fait que ça puisse être hacké mais le récit qui en est fait et les transformations à sens unique qui en sont obtenues. Le SMS pouvait être intercepté... certes, en 2G du SDR. On est passé à la 5G et personne n'est pourtant revenu au SMS. (De temps à autre on nous sort une histoire anecdotique de sim-swap pour garder la pression en faveur de l'OTP/smartphone)
Quant au Droit c'est une blague qui a déjà quelques siècles. Tout ceux qui étaient avant-hier les fervent défenseurs de la liberté d'expression et de la neutralité du net, adoraient, hier, la censure-de-facebook/Google/Twitter-pour-lutter-contre-la-désinformation et argumentaient que "Facebook est un réseau privé qui a donc le droit de choisir ses utilisateurs" (lorsqu'il s'agit de censurer les antivaxx-fachistes-...). Demain ils adoreront la "banque privée qui vous garantit le droit... d'aller voir ailleurs si vous n'êtes pas contents".
Et ne mentionnons pas tous les ravis de la crèche de la 2FA (certains en font même des listes de vertu: https://2fawebsites.github.io/) et autres libertariens du passe-sanitaire qui ont acheté à peu près chaque narrative sécuritaire des GAFAM pendant deux décennies. Oh, oui, je veux ma clef de chiffrement de disque dans une TPM (mais "opensource"). Oh oui, je veux renouveler mon certificat SSL toutes les 2 semaines (mais seulement avec les gentils de LetsEncrypt), oh oui je veux du CORS/COOP/COEP dans mon navigateur, et puis aussi ses 1000 autorités de certification (mais avec de la certificate transparency!) et puis protéger les mineurs sur internet grâce à de la validation d'identité, etc etc etc...
Tout ça pour dire qu'il serait temps d'avoir un peu moins de naïveté technologique et un peu plus de hauteur de vue sur des cycles longs parce qu'au rythme actuel, l'étape du contrôle biométrique lors de l'allumage de la box sera atteinte au tournant des années 2035... et comme toujours... "par le plus grand des hasards et sans préméditation"
# bonne initiative
Posté par gibs . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 4 (+4/-0).
Bonne initiative, mais n'attaque pas le problème de fond.
On est sur un processus de longue durée (deux décennies), dont les appli' bancaire ne sont qu'une étape, pour un secteur.
La "sécurité" signifie ici "contrôle" (de l'usager, non pas le contrôle de l'usager sur ses fonds ou son accès à ses fonds). Et ce contrôle est déjà passé par plusieurs étapes:
De la passphrase simple au SMS, puis du SMS à l'OTP, puis de l'OTP à l'appli, puis de l'appli à l'OS qui prépare l'étape suivante: puces sécurisées pour collecter fingerprints, selfie et autres données biométriques.
L'extension s'est elle-aussi faite suffisamment progressivement: Pour le paiement par carte d'abord, ensuite étendu aux opérations dites "sensibles" dans l'espace en ligne (virements) puis la connexion à l'espace en ligne. (Ce alors même que la DSP2 concoctée par le lobby bancaire promouvait la 2FA en tant que palliatif au fait que le numéro de CB ne peut pas faire office d'identifiant lors d'un paiement)
Il faut reprendre la chronologie pour comprendre son aberration:
Vice numéro un: dans les années 2000, les banques doivent permettre le paiement par internet et laissent les clients s'authentifier avec un secret qui n'en est pas un: les données de la CB (qui n'est ni quelque chose que l'on connaît exclusivement, ni quelque chose dont la possession garantie à elle seule la légitimité à l'opération [c'est le propre d'un objet])
Pour pallier à ce faux secret: vice numéro 2: un code à usage unique. D'abord envoyé par SMS, puis sous la pression de Google (la hype autour du SS7), à l'OTP.
L'occasion était trop belle pour ne pas pousser pour plus de contrôle et imposer des app'.
(=> Le corollaire étant que la 2FA pour une authentification, à la différence d'un paiement, ne s'est jamais justifiée sauf par l'argument "Mme Michu utilise toujours le même mot de passe sur tous ses sites web, depuis 40 cyber-cafés")
D'ailleurs la 2FA n'est jamais rien d'autre qu'un second shared-secret sauf qu'il faut un CPU pour le dériver. Dans la DB du validateur il est dans la table
{mfa_secrets}juste à côté de la table{users}). Mais devoir dériver mathématiquement un shared secret, ça incite fortement le client à être très bon en calcul mental ou avoir une calculette (autrement dit un smartphone). Serait-ce possible que le 2FA ait conçu inventé pour le smartphone ? (alternativement, on pouvait juste utiliser la colonne "passphrase" dans{users})Le problème de fond (déjà soulevé) est qu'une politique de sécurité doit se baser sur une analyse des risques rationnelle qui ne peut pas être monolithique et unilatérale.
Or actuellement, c'est le fait du prince de la DSI d'une banque. Elle doit revenir aux usager (avec ou sans iphone, avec ou sans clef GPG, avec ou sans 2FA, etc...) car ils sont les seuls légitimes à arbitrer entre sécurité (empêcher l'accès à un tiers) et accessibilité/résilience (accéder à ses fonds en cas d'urgence [hôpital, à l'étranger, pas de batterie/4G, téléphone volé, ...]
D'ailleurs si l'on en revient aux fondamentaux, et même en considérant la philosophie biaisée de la DSP2 à propos de la 2FA pour les paiements en ligne, alors il y a une solution simple:
- La CB est l'objet
- L'usager associe une passphrase à sa CB auprès de sa banque.
- la banque valide valide la passphrase lors de la MFA => deux facteurs. Objet et mémoire de l'usager.
Concernant les secteurs, ils vont bien au-delà des banques: transfert de fonds (selfie chez Wise/Western Union etc...) mais aussi administration (identité numérique laposte). Les services (gaz/électricité) ne sont pas loin. Payer des services d'hébergement (ou de VPN) devra se faire de plus en plus avec des validations d'identité.
Il faut aussi mettre ça en parallèle avec la guerre aux VPN (Boursorama interdit l'usage du VPN pour des "raisons de sécurité" à l'instar de la BPCE qui fait régulièrement des tentatives d'extension dans ce sens, par petits pas).
De nombreux hébergeurs sont invités (par prestataires en "DDoS prevention") à couper d'emblée leur réseau aux VPN quand bien même leurs clients souhaiteraient permettre un accès vraiment universel à leur sites/services.
On pourrait rajouter la guerre aux humains avec les captchas à tour de bras. (Rappelons que vérifier une captcha pour un GET coûte plus de cycles CPU que de renvoyer la ressource depuis un cache : ce n'est donc pas pour lutter contre les "abus" que celles-ci existent mais bien dans le cadre d'une collecte d'information et de contrôle progressif du trafic)
Quand on pense qu'il y a même certains prestataires des paiement qui sont derrière Cloudflare (et donc que le numéro de CB qu'ils "collecte en SSL super-sécurisé" se balade en fait en clair sur le réseau du proxy...) ou que les conseillers bancaire accorde une valeur une signature manuscrite sur un scan :|
Le principe même de la 2FA est une quête sans fin, car si le mot de passe ne suffit pas, rien suffira jamais car tout le reste peut être hacké. (C'est très pratique que ça puisse l'être car ça force à rajouter une couche de complexité et de contrôle). D'ailleurs se qui compte n'est pas le fait que ça puisse être hacké mais le récit qui en est fait et les transformations à sens unique qui en sont obtenues. Le SMS pouvait être intercepté... certes, en 2G du SDR. On est passé à la 5G et personne n'est pourtant revenu au SMS. (De temps à autre on nous sort une histoire anecdotique de sim-swap pour garder la pression en faveur de l'OTP/smartphone)
Quant au Droit c'est une blague qui a déjà quelques siècles. Tout ceux qui étaient avant-hier les fervent défenseurs de la liberté d'expression et de la neutralité du net, adoraient, hier, la censure-de-facebook/Google/Twitter-pour-lutter-contre-la-désinformation et argumentaient que "Facebook est un réseau privé qui a donc le droit de choisir ses utilisateurs" (lorsqu'il s'agit de censurer les antivaxx-fachistes-...). Demain ils adoreront la "banque privée qui vous garantit le droit... d'aller voir ailleurs si vous n'êtes pas contents".
Et ne mentionnons pas tous les ravis de la crèche de la 2FA (certains en font même des listes de vertu: https://2fawebsites.github.io/) et autres libertariens du passe-sanitaire qui ont acheté à peu près chaque narrative sécuritaire des GAFAM pendant deux décennies. Oh, oui, je veux ma clef de chiffrement de disque dans une TPM (mais "opensource"). Oh oui, je veux renouveler mon certificat SSL toutes les 2 semaines (mais seulement avec les gentils de LetsEncrypt), oh oui je veux du CORS/COOP/COEP dans mon navigateur, et puis aussi ses 1000 autorités de certification (mais avec de la certificate transparency!) et puis protéger les mineurs sur internet grâce à de la validation d'identité, etc etc etc...
Tout ça pour dire qu'il serait temps d'avoir un peu moins de naïveté technologique et un peu plus de hauteur de vue sur des cycles longs parce qu'au rythme actuel, l'étape du contrôle biométrique lors de l'allumage de la box sera atteinte au tournant des années 2035... et comme toujours... "par le plus grand des hasards et sans préméditation"