Catégorie : Sécurité informatique

  • TLS et vie privée

    Pour répondre à David :

    TLS does not provide privacy. What it does is disable anony­mous access to ensure autho­rity. It changes access patterns away from decen­tra­li­zed caching to more centra­li­zed autho­rity control.
    That is the oppo­site of privacy. […] TLS is NOT desi­rable for access to
    public infor­ma­tion, except in that it provides an ephe­me­ral form of message inte­grity that is a weak repla­ce­ment for content inte­grity.

    Je suis convaincu que ces gens ont réflé­chi à la ques­tion plus long­temps et plus sérieu­se­ment que moi, mais je ne peux m’em­pê­cher de poser les ques­tions :

    Parler de vie privée c’est parler de confi­den­tia­lité. Vis à vis de qui ? De même, à partir de quand parle-t-on d’ano­ny­mat ?

    Consi­dé­rer que TLS est inutile pour accé­der à une infor­ma­tion publique me semble très étrange. La confi­den­tia­lité n’est pas dans le fait que cette infor­ma­tion soit publique, mais à ce que je consulte ou ce que j’en­voie dans le détail.

    Savoir que j’ac­cède à Face­book est une chose. Savoir quel profil j’uti­lise et ce que j’écris en est une autre, quand bien même les textes en ques­tions sont ne sont pas d’ac­cès restreint. Je ne souhaite pas forcé­ment que l’uni­ver­sité de mon fils puisse lire ce qu’il y écrit via le WIFI local.

    Savoir que j’ac­cède à Wiki­pe­dia est une chose. Savoir que les pages que j’y lis parlent de certains problèmes de sexua­lité en est une autre. Je ne souhaite pas forcé­ment que mon employeur puisse savoir ce que j’y lis pendant ma pause de midi.

    Savoir que je consulte la presse est une chose. Savoir quels sont les articles poli­tiques que je lis et ce que je commente en est une autre. Suivant le pays où je suis, je ne souhaite pas faci­li­ter une éven­tuelle analyse au niveau de mon four­nis­seur d’ac­cès ou du gouver­ne­ment.

    Bref, je suis conscient que l’im­plé­men­ta­tion actuelle des navi­ga­teurs peuvent en théo­rie faci­li­ter le tracking à partir du serveur. Je ne suis pas certain que la tech­nique soit mise en œuvre telle­ment d’autres méthodes plus simples sont effi­caces. La confi­den­tia­lité que ça m’ap­porte compense large­ment ce surcoût.

    La démo­cra­ti­sa­tion de TLS est pour moi une vraie bonne nouvelle.

    I have no objec­tion to the IESG propo­sal to provide infor­ma­tion *also* via https. It would be better to provide content signa­tures and encou­rage mirro­ring

    Je ne nie pas que ça puisse être inté­res­sant, mais l’usage est pour moi tota­le­ment diffé­rent. En fait, à réflé­chir, l’es­sen­tiel des cas où j’ai besoin de garan­tir l’in­té­grité du message sont ceux où j’ai besoin d’une authen­ti­fi­ca­tion, donc où le chif­fre­ment de TLS est aussi néces­saire.

    Propo­ser HTTPS en alter­na­tive me semble aussi une fausse bonne idée. Sur mes deux derniers exemples, j’ai poten­tiel­le­ment non seule­ment besoin que le contenu de ma requête soit confi­den­tielle, mais aussi que mon besoin de confi­den­tia­lité le soit aussi. Que j’uti­lise d’un coup TLS me fera paraitre « louche », ce que juste­ment j’au­rais souhaité éviter. Je l’ai d’ailleurs vu récem­ment dans la presse lors de mises en accu­sa­tion : le fait que les suspects aient utilisé des commu­ni­ca­tions cryp­tées faisait partie des éléments à charge, même sans savoir ce qu’ils ont échangé. Dange­reux, au mieux.

    Plus prag­ma­tique : Il serait facile de bloquer HTTPS pour la plupart des sites publics comme Wiki­pe­dia, Doctis­simo, Twit­ter ou Le Monde, obli­geant les gens à se rabattre sur HTTP. Même les geeks les plus au fait des problèmes ont tendance à accep­ter de dégra­der la commu­ni­ca­tion en clair quand le chif­fre­ment ne passe pas. Rendre TLS option­nel revien­drait à le reti­rer là où juste­ment il est le plus néces­saire.

    Le fait que le web avance pas à pas vers un « TLS unique­ment » est un gros pas en avant pour la confi­den­tia­lité vis à vis de mon envi­ron­ne­ment direct.

    TLS everyw­here is great for large compa­nies with a finan­cial stake in Inter­net centra­li­za­tion. It is even better for those provi­ding iden­tity services and TLS-outsour­cing via CDNs. It’s a shame that the IETF has been abused in this way to promote a campaign that will effec­ti­vely end anony­mous access, under the guise of promo­ting privacy.

    Bref, il y a des choses à faire. Par exemple s’as­su­rer de réduire l’iden­ti­fi­ca­tion possible du navi­ga­teur entre deux requêtes ? (le navi­ga­teur utilise-t-il le même certi­fi­cat à chaque fois ? si c’est ça le problème, il y a certai­ne­ment moyen de faire des rota­tions régu­lières, et de ne pas parta­ger un même certi­fi­cat entre diffé­rentes desti­na­tions).

    Quant à mon anony­mat, il est bien plus vidé de son sens à cause de mon IP qu’à cause du tracking : si j’ai vrai­ment besoin, je peux utili­ser un navi­ga­teur ou un profil diffé­rent pour certaines acti­vi­tés, mais mon IP demande un effort plus impor­tant pour être chan­gée.

    L’autre ques­tion est de savoir auprès de qui est-ce que je cherche le plus à être anonyme, et ce que repré­sente mon iden­tité. Google saura proba­ble­ment me relier à mon email. Mon FAI et mon employeur savent me relier à mon iden­tité civile

    Bref, travaillons à amélio­rer les problèmes de tracking. Ils ne me semblent cepen­dant pas inhé­rents à la tech­no­lo­gie TLS (me trompe-je ?). Ne jetons en tout cas pas le bébé avec l’eau du bain. Surtout si nous n’avons rien à la place.

    Roy T. Fiel­ding nous rappelle le prin­ci­pal danger de TLS et de « SSL partout » : la centra­li­sa­tion des auto­ri­tés de certi­fi­ca­tion. Et par exten­sion du Web.

    C’est un vrai problème, mais qui commence à être dépassé. Le nombre d’au­to­ri­tés de mon Fire­fox se rapproche des 200. Si on consi­dère que ces auto­ri­tés délèguent elles-mêmes à de multiples sous-auto­ri­tés, qui parfois font elles aussi de même, on est loin d’une centra­li­sa­tion déran­geante pour la vie privée. En fait il y a tant de délé­ga­tion que le prin­cipe même d’au­to­rité de confiance devient assez théo­rique.

    Il reste un problème de confiance (auto­rité) et un problème commer­cial. DANE et letsen­crypt sont deux initia­tives qui me font croire qu’on va lais­ser ça derrière nous à moyen (pour letsen­crypt) ou long terme (pour DANE).

    Un client qui sait ne pas réuti­li­ser inuti­le­ment le même certi­fi­cat, qui véri­fie le serveur à l’aide de DANE les écueils de confi­den­tia­lité suivants seront surtout dans SNI, DNS et IP.

  • Des cher­cheurs piratent à distance un robot de chirur­gie

    Une équipe de cher­cheurs de l’uni­ver­sité de Washing­ton est parve­nue à pira­ter un robot de chirur­gie télé­com­mandé à distance en exploi­tant plusieurs failles de sécu­rité, notam­ment via la connexion Inter­net qui relie le prati­cien au robot. S’il faut évidem­ment renfor­cer la protec­tion du système, les solu­tions tech­niques exis­tantes ne sont pas forcé­ment compa­tibles avec les besoins de la chirur­gie robo­tique télé­opé­rée.

    — Futura Sciences

    Le problème c’est que ça ne surpren­dra aucun infor­ma­ti­cien. C’est même quasi­ment une certi­tude pour tous ceux là.

    Et ça me fait peur que le corps médi­cal puisse décou­vrir ça, ou que ce type de service ne soit pas sur des liai­sons spécia­li­sées, distinctes d’In­ter­net.

    À l’heure où les États-Unis créent des virus infor­ma­tiques pour impac­ter à distance le programme nucléaire de l’Iran, je n’ose penser à l’arme que ces robots hospi­ta­liers peuvent deve­nir.

  • Les FAI devront livrer à l’Etat toutes les infos sur leurs réseaux

    Dans le cadre de ce contrôle, qui pourra avoir lieu une fois par an (ou plus souvent en cas de défaillances), les FAI et héber­geurs concer­nés devront four­nir à l’ANSSI ou au pres­ta­taire privé agréé « notam­ment la docu­men­ta­tion tech­nique des équi­pe­ments et des logi­ciels utili­sés dans ses systèmes ainsi que les codes sources de ces logi­ciels« 

    En clair : En plus des boites noires et des accès directs, il est demandé tous les moyens pour que l’État puisse s’in­tro­duire de force dans les systèmes, en dehors des accès prévus pour ça. Sous couvert d’en véri­fier la sécu­rité, mais même la marmotte ne croit plus à l’em­bal­lage arti­sa­nal du choco­lat dans le papier d’alu. Ayez confian­ce…

    — via Nume­rama

  • Google Drops Support for Secu­rity Ques­tions

    Google Drops Support for Secu­rity Ques­tions

    …et fran­che­ment il était temps. Ces systèmes de ques­tions person­nelles sont tota­le­ment aber­rants. Bref, merci.

    Il s’agit géné­ra­le­ment de ques­tions dont on peut trou­ver la réponse avec un mini­mum de recherches sur le net. Les amis et les proches connaissent déjà toutes les réponses ou peuvent les obte­nir rela­ti­ve­ment faci­le­ment à force de discus­sion.

    À l’in­verse, mon profes­seur préféré ? La rue de là où j’ai habité petit ? J’au­rais plusieurs réponses possibles. J’hé­site à chaque fois. Il est même possible que certains de mes proches répondent plus rapi­de­ment que moi-même à ces ques­tions – tout en donnant la bonne réponse.

    Un ou plusieurs numé­ros de télé­phone, un ou plusieurs emails, une liste de codes de secours à usage unique… Google fait très bien tout ça. L’avan­tage de ces solu­tions c’est que même si quelqu’un usurpe le compte, le service client peut les réuti­li­ser pour authen­ti­fier le vrai proprié­taire des données.

    Tout au plus on pour­rait imagi­ner de deman­der au service de confir­mer cumu­la­ti­ve­ment par plusieurs moyens, du genre mon télé­phone de bureau, plus le numéro person­nel de mes parents, plus l’email de ma femme. Peu probable que quelqu’un réus­sisse à avoir accès aux trois simul­ta­né­ment sans que je n’en ai connais­sance. Si je perds vrai­ment tous mes accès, cette diffi­cul­tés sera surmon­table.

    Visi­ble­ment des gens se permettent de remettre en ques­tion les pratiques dont le coût est supé­rieur au béné­fice : Je vois des banques désor­mais sans ces claviers virtuels inutiles et je me rappelle Mozilla qui avait arrêté de deman­der le renou­vel­le­ment régu­lier des mots de passe.

    Bon, tout n’est pas gagné partout : Linke­din ne véri­fie pas les emails des nouveaux comptes, et ça ouvre de jolies failles chez tous ceux qui ont un « authen­ti­fie-moi avec Linke­din ».

    Photo d’en­tête sous licence CC BY par Zuerichs Stras­sen

  • We’ve streng­the­ned our passs­word complexity requi­re­ments

    1. We’ve streng­the­ned our passs­word complexity requi­re­ments. We’ve noti­ced that the recur­ring pass­word expi­ra­tion often results in the use a poor or weak pass­words. The new pass­word requi­re­ments are:

    • Mini­mum length for 16 charac­ters
    • Mini­mum of 4 words when using a pass­phrase (a sequence of unre­la­ted words)
    • Maxi­mum length of 100 charac­ters
    • No pass­words that reuse the same words too many times, contain a birth­date suffix/prefix, etc.

    We stron­gly encou­rage the use of pass­phrases, instead of a tradi­tio­nal pass­word with multiple charac­ter classes. Example pass­phrases are displayed on the pass­word reset site.

    2. We’re remo­ving pass­word expi­ra­tion enti­rely. After chan­ging your LDAP pass­word one last time, it will no longer expire. The only reason you will need to change your change your LDAP pass­word in the future is if it has been acci­den­tally leaked, or if one of your compu­ters/mobile device were lost, stolen, or compro­mi­sed.

    Je ne saurais trop remer­cier Mozilla d’avoir sauté ce pas, quand bien même je ne suis pas concerné. Les poli­tiques de mots de passe n’ont géné­ra­le­ment ni queue ni tête, et l’obli­ga­tion de chan­ger régu­liè­re­ment de mot de passe est proba­ble­ment la superbe mauvaise idée du siècle en termes de sécu­rité.

    Je râle encore contre tous ces sites qui ont une procé­dure de réini­tia­li­sa­tion mais qui t’em­pêchent de saisir de nouveau un mot de passe que tu avais oublié préa­la­ble­ment.

    Juste un point pour Mozilla : Pour les appa­reils perdus ou volés, la solu­tion est plus la possi­bi­lité d’avoir des mots de passe unique dédiés. Le mot de passe géné­rique n’est utile que là où il est tapé régu­liè­re­ment.

    Partout où le mot de passe est à demeure (par exemple la confi­gu­ra­tion du client email), le système devrait permettre d’uti­li­ser un mot de passe unique, dédié. Si l’ap­pa­reil est compro­mis on ne change pas le mot de passe géné­rique, on se contente de « griller » le mot de passe dédié dans la liste des auto­ri­sa­tions.

    Google le fait très bien pour ceux qui ont activé l’au­then­ti­fi­ca­tion en deux étapes.

  • Hygiène de sécu­rité

    Hygiène de sécu­rité

    Aujourd’­hui on véri­fie la sécu­rité.

    Les services en ligne « sensibles »

    Même en ne gardant que le prin­ci­pal, il faut penser à :

    • votre boite email (qui sert à la récu­pé­ra­tion des mots de passe de tous les autres comptes),
    • votre service de nom de domaine,
    • celle de secours (qui sert à la récu­pé­ra­tion du mot de passe de la boite prin­ci­pale),
    • votre service de backup,
    • vos services de stockage ou synchro­ni­sa­tion en ligne,
    • votre héber­geur de serveur en ligne si vous en avez.

    [ ] La première étape c’est s’as­su­rer d’avoir des mots de passe « sûrs ». Ça veut dire suffi­sam­ment longs et complexes.

    Suivant les préfé­rences c’est au moins huit carac­tères aléa­toires entre chiffres lettres et symboles, au moins 12 carac­tères avec des lettres rela­ti­ve­ment aléa­toires, ou au moins 15 carac­tères mini­mum si vous avez des suites de mots communs.

    Le l34t sp33k, l’in­ver­sion des carac­tères, l’ajout d’une année, et globa­le­ment la plupart des varia­tions auxquelles vous pour­riez penser sont testables en moins de quelques minutes donc n’ajoutent pas de complexité signi­fi­ca­tive.

    [ ] Seconde étape, s’as­su­rer que ces mots de passe sont uniques et vrai­ment diffé­rents (pas de simples varia­tions du même).

    Au grand mini­mum, s’as­su­rer d’avoir un mot de passe pour les services très sensibles diffé­rent du mot de passe que vous tapez tous les jours pour les services moins impor­tants. Ce mot de passe sensible ne devra être tapé que dans des espaces correc­te­ment sécu­ri­sés.

    [ ] Quand vous le pouvez, acti­vez l’ »authen­ti­fi­ca­tion en deux étapes ». C’est possible au moins pour Google, Gandi, Drop­box, iCloud. C’est fran­che­ment peu gênant vu la sécu­rité que ça apporte, ne pas le faire est limite une faute.

    [ ] Les « ques­tions secrètes » pour récu­pé­rer des comptes dont vous avez oublié les mots de passe sont de vraies plaies pour la sécu­rité. En géné­ral il est très facile d’en trou­ver la réponse.

    À vous de voir si vous préfé­rez tricher et mettre de fausses réponses (au risque de ne pas vous en souve­nir) ou si vous avez une grosse faille à cet endroit là. C’est le moyen d’ac­cès de la plupart des usur­pa­tions courantes.

    L’ac­cès depuis vos postes

    Tablette, télé­phone (même les « pas smart »), micro-ordi­na­teur, NAS de la maison…

    [ ] Tous doivent avoir un mot de passe à l’al­lu­mage et à la sortie de veille. Tous, pas d’ex­cep­tion.

    Sur les smart­phones et tablettes vous avez parfois la possi­bi­lité de mettre un « schema ». Ça fonc­tionne assez bien et c’est plutôt simple à déver­rouiller. Si vous n’avez pas d’autre choix, utili­sez le code PIN.

    Pour les autres les mots de passe doivent respec­ter les mêmes règles que pour les services en ligne.

    [ ] Tous ceux qui le peuvent doivent avoir un disque chif­fré. Micro-ordi­na­teurs, tablettes et smart­phones le permettent quasi­ment tous.

    Le coût en perfor­mance ou en batte­rie est quasi­ment nul sur les proces­seurs des 5 dernières années qui ont des circuits dédiés pour ces calculs.

    Sans ça n’im­porte qui avec très peu de connais­sances infor­ma­tiques peut passer outre votre mot de passe.

    Parfois il existe une procé­dure de récu­pé­ra­tion si jamais vous oubliez vos mots de passe, de façon à déver­rouiller le disque. Sur Apple par exemple ça utilise le compte iCloud. Dans ces cas, le compte utilisé pour la procé­dure de récu­pé­ra­tion doit être consi­déré comme sensible avec les mêmes règles que plus haut.

    [ ] Les mises à jour sont confi­gu­rées pour être télé­char­gées auto­ma­tique­ment, et instal­lées dès qu’elles sont dispo­nibles.

    [ ] Si vous enre­gis­trez vos mots de passe dans votre navi­ga­teur pour ne pas les ressai­sir à chaque fois, ce dernier doit avoir un « mot de passe maître ».

    Si en plus ces données sont synchro­ni­sées en ligne, le mot de passe qui gère le compte de synchro­ni­sa­tion doit être consi­déré comme sensible avec les mêmes règles que plus haut.

    [ ] Vous avez une poli­tique de backup auto­ma­tisé et testé pour toutes vos données impor­tantes. Bien entendu le compte qui permet d’ac­cé­der aux données de backup est à consi­dé­rer comme sensible.

    La machine qui reçoit les backup doit avoir un disque chif­fré et si vous faites appel à un service tiers le chif­fre­ment des données doit se faire côté client pour que le pres­ta­taire ne puisse pas déco­der les données.


    Tout ça est un mini­mum, main­te­nant imagi­nez quelqu’un qui connait la réponse à la ques­tion secrète de votre opéra­teur télé­pho­nique. À partir de ça il peut réini­tia­li­ser le mot de passe pour accé­der à votre compte. Là il a une inter­face pour lire et écrire des SMS. Il demande alors la réini­tia­li­sa­tion du mot de passe de votre boite email prin­ci­pale, qui se fait via SMS. À partir de là il réini­tia­lise le mot de passe de votre service de stockage en ligne, de backup, et de votre banque. Le voilà avec de quoi récu­pé­rer vos photos, même si vous les avez effacé, et peut être même de quoi faire des vire­ments. Situa­tion fictive mais on a vu des attaques bien plus inven­tives.

    Si vous avez lu jusqu’au bout (sérieu­se­ment ?) je suis curieux de savoir quelle propor­tion de ces bonnes pratiques vous vali­dez, ou si vous respec­tez tout en détail pour l’in­té­gra­lité de vos maté­riels et comptes sensibles.

    Photo d’en­tête sous licence CC BY-NC-SA par Steve Crane

  • TLS par défaut

    Il ne fallait qu’une heure pour le faire mais je ne l’avais jamais inves­tie jusqu’à présent. C’est main­te­nant fait : Cet espace utilise une connexion HTTP sécu­ri­sée par défaut.

    Le lien HTTP non sécu­risé redi­rige direc­te­ment vers la partie sécu­ri­sée. Cette dernière envoie l’entête HSTS pour bloquer ce choix.

    Remon­tez-moi toute diffi­culté.

  • Défi­nir son API : authen­ti­fi­ca­tion

    Je lis le PDF gratuit de Apigee à propos du design des API web. Si les autres PDF gratuits du site sont assez creux, celui là pose de bonnes ques­tions qui font écho avec mes propres reflexions.

    Je le prends dans le désordre et pour reprendre mes erreurs passées ou celles que j’ai vu chez les autres :

    • Pas de système de session avec point d’en­trée spéci­fique pour le login. Ça demande au client de se préoc­cu­per de l’ex­pi­ra­tion de la session et de son main­tient. Pour des appels isolés ça veut dire faire deux requêtes (login + action) au lieu d’une, avec un délai de réponse finale allongé et une charge plus impor­tante pour le serveur. Sauf besoin spéci­fique, il faut rester en state­less : Chaque connexion contient ses propres infor­ma­tions d’au­then­ti­fi­ca­tion.
    • Pas d’au­then­ti­fi­ca­tion par IP, comme je le vois trop souvent. Outre que c’est un poten­tiel problème de sécu­rité, c’est juste quelque chose de diffi­ci­le­ment main­te­nable et c’est toujours au dernier moment quand on veut faire un correc­tif, une migra­tion ou une bascule vers le serveur de secours en urgence qu’on se rend compte du problème.
    • L’au­then­ti­fi­ca­tion HTTP Digest me semble être une mauvaise réponse à tous les problèmes. Pour amélio­rer légè­re­ment la résis­tance aux inter­cep­tions, il faut stocker le mot de passe en clair côté serveur. Une authen­ti­fi­ca­tion HTTP Basic avec du TLS pour sécu­ri­ser la commu­ni­ca­tion me semble bien plus perti­nent, et aussi plus simple à réali­ser.
    • Le système fait maison est toujours la pire solu­tion, même si vous pensez savoir ce que vous faites. C’est un NO GO commun à toute problé­ma­tique qui touche la sécu­rité. Vous avez plus de chances de vous tirer une balle dans le pied qu’autre chose, et pour le même prix ce sera toujours plus complexe quand vous commu­nique­rez avec des tiers.
    • OAuth 2 a la mauvaise idée d’être plus une boite à outils qu’une solu­tion finie. Même les gros groupes se prennent les pieds dans le tapis avec ça. On rejoint un peu le système fait maison. OAuth a ses défauts, mais globa­le­ment est une sphère contrô­lée que vous devriez préfé­rer.

    Au final il reste le choix entre l’au­then­ti­fi­ca­tion HTTP Basic, l’au­then­ti­fi­ca­tion par certi­fi­cat client avec SSL/TLS, ou OAuth 1.0. Ma grille de choix est la suivante :

    • OAuth s’il s’agit d’avoir une authen­ti­fi­ca­tion à trois pattes. Hors de ques­tion d’im­po­ser à l’uti­li­sa­teur final de saisir ses mots de passes dans un logi­ciel tiers. Pour une API qui veut créer un écosys­tème de logi­ciels clients (type twit­ter) c’est le choix quasi­ment imposé. Oui il y a des diffi­cul­tés pour le mobile ou pour ce qui n’est pas « navi­ga­teur », mais ces ques­tions sont désor­mais large­ment docu­men­tées. Pensez bien que choi­sir ce type d’au­then­ti­fi­ca­tion demande un réel travail (par exemple trou­ver l’er­go­no­mie pour permettre à l’uti­li­sa­teur d’au­to­ri­ser et reti­rer l’au­to­ri­sa­tion d’ap­pli­ca­tions tierces sur votre propre système)
    • HTTP Basic par défaut pour quasi­ment toutes les autres situa­tions. C’est simple côté client, simple et maitrisé côté serveur, supporté partout et pour tout, suffi­sam­ment sécu­risé si on passe par du SSL/TLS.
    • Et les certi­fi­cats clients avec SSL/TLS ? C’est une solu­tion qui semble plus inté­res­sante que l’au­then­ti­fi­ca­tion HTTP mais qui se révèle complexe pour pas mal d’in­ter­lo­cu­teurs. La valeur ajou­tée ne semble pas valoir la complexité supplé­men­taire si vous n’in­te­ra­gis­sez pas avec des entre­prises de taille signi­fi­ca­tive. J’y croyais beau­coup, mais fina­le­ment j’ai peu d’ar­gu­ment face à la simpli­cité du HTTP Basic.

    Et vous ? vous utili­sez quoi pour l’au­then­ti­fi­ca­tion de vos services ?

  • Triple vali­da­tion de mot de passe

    Non véri­fié mais ça semble une bonne idée :

    Face­book stores three hashes of your pass­word (let’s say it’s « pAss­word »):
    * « pAss­word » – the pass­word as it is
    * « PaSSWORD » – the pass­word, case inver­ted, in case you have caps lock on
    * « PAss­word » – the pass­word with its first letter capi­ta­li­zed, for those with mobile devices that insist on Capi­ta­li­zing Every­thing

    Comme indiqué dans un commen­taire, il n’y a pas forcé­ment besoin de stocker trois mots de passe chif­frés, on peut se conten­ter de modi­fier le mot de passe en clair par deux fois pour le faire corres­pondre aux diffé­rents types d’er­reur si le premier essai ne fonc­tionne pas.

    Pour la version « verrouillage majus­cule activé », je leur souhaite bonne chance dès qu’on touche au numé­rique ou aux ponc­tua­tions. Suivant l’agen­ce­ment clavier ça peut donner des centaines de combi­nai­sons. Heureu­se­ment que les gens n’uti­lisent pas de mots de passe sérieux.

  • Pour le paie­ment, les Austra­liens choi­sissent les empreintes digi­tales

    Le numé­rique et les nouvelles tech­no­lo­gies relèvent encore du fantasme pour certains. Ils ont plus l’im­pres­sion de vivre dans la science fiction qu’a­vec les réali­tés.

    Pour le paie­ment, les Austra­liens choi­sissent les empreintes digi­tales. C’est génial, on a l’im­pres­sion de vivre dans le futur, mais c’est peut être le seul avan­tage. Qui s’est posé la ques­tion des contraintes à vali­der ?

    Les empreintes digi­tales ça se vole et ça se fausse sans avoir une équipe qui s’ap­pelle Mission Impos­sible. La sécu­rité réelle est loin de ce qu’on imagine. Les empreintes digi­tales ce n’est pas pérenne non plus. On peut s’abi­mer le doigt : C’est souvent tempo­raire mais parfois perma­nent ou régu­lier. Oh, et on peut se servir de votre doigt après vous avoir donné un bon coup sur la tête.

    Le système de code secret n’est pas parfait non plus mais il a quelques avan­tages. Ceux qui font de la haute sécu­rité avec biomé­trie asso­cient toujours cette biomé­trie avec un système de code secret.

    Plutôt qu’en­vi­sa­ger le progrès tech­no­lo­gie comme un rêve de science fiction, et si nous nous occu­pions à résoudre les vrais problèmes de tous les jours ? Par exemple permettre de payer par carte les petits paie­ments, ou permettre à chacun de rece­voir des paie­ments par carte sur son compte bancaire sans avoir à monter un site de commerce élec­tro­nique avec des abon­ne­ments bancaires bien chers. Savoir si on utilise du NFC, de la biomé­trie ou un code secret, c’est fina­le­ment un faux problème.