🚲 Tanguy Ortolo a écrit 12509 commentaires

Je ne vois pas trop en quoi clavier virtuel et clavier physique diffère sur le point « observation par dessus l’épaule ».

Il me semble plus facile de suivre les mouvements d'un pointeur de souris à l'écran (lents, parce que l'utilisateur doit faire un effort pour repérer la position, aléatoire, de chaque chiffre), que les frappes de touche (rapides, parce que l'utilisateur utilise sa mémoire mécanique de la position des touches).

Quant au keyloggers, j’ai du mal à croire qu’il n’existe pas de "clickloggers" permettant de capter le code secret de la même manière…

Le clicklogger en question enregistrera sans problème qu'on a cliqué à telle position sur l'écran, mais pour déterminer ce qu'il y avait d'affiché à cet endroit, il faut y coupler une caputre d'écran, ce qui est un poil plus contraignant qu'un simple keylogger. Rien d'infaisable, évidemment, mais c'est nettement plus chiant, et nettement moins automatique à analyser.

Par ailleurs il serait tout à fait envisageable d’avoir un clavier virtuel possédant lettres et signes ponctuation.

Positionnées aléatoirement aussi ? Là, tu va faire fuir tes clients, qui en auront vite marre de passer cinq minutes à saisir leur mot de passe…

pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.

Alors, déjà, l'idée d'utiliser un token, c'est d'ajouter dans l'authentification quelque chose qui est de l'ordre de la propriété physique (en plus d'un code qui relève de la connaissance). Pour info, ces tokens utilisent un algorithme pour générer un code à partir d'un secret (l'algorithme standard pour cela s'appelle TOTP), mais tant que ça ne sort pas de l'appareil en question, ça relève bien de la propriété. En revanche, dès qu'on s'amuse à utiliser ça avec un générateur de code sur téléphone par exemple, ça s'approche un peu plus de la connaissance.

Autrement, il y a une alternative au token algorithmique, qui est la grille de codes : c'est une carte en papier, avec un tableau dont les colonnes et les lignes sont numérotées, et qui contient dans chaque case un code unique choisi de façon aléatoire. Par rapport à un token, ça ne coûte presque rien, ça n'utilise pas d'algorithme, pas de secret partagé (en fait c'est l'ensemble de la grille qui est un secret partagé), ni d'électronique d'aucune sorte, et c'est donc invulnérable aux attaques qui portent sur ces caractéristiques. Mais à moins de changer régulièrement de grille, ça peut être vulnérable à une réutilisation d'un code déjà passé qui aurait été intercepté.

pourquoi les banques n'autorisent elles pas les mot de passe avec une suite de caractères (chiffres, lettres, symboles) ? (Je me doute que derrière ça doit avoir un impact sur les gros systèmes qui hébergent les applis métier)

Certaines l'autorisent, en tout cas le CIC et le Crédit Mutuel (c'est le même groupe). En revanche, cela les empêche d'imposer une saisie de chiffre à la souris (vulnérable à l'observation par dessus l'épaule et à l'interception par un démon local mais pas aux key loggers), et leur implique donc de permettre la saisie du clavier (peu vulnérable à l'observation par dessus l'épaule, mais vulnérable aux key loggers et à l'interception par un démon local).

Je ne sais pas comment on définit une machine qui fournit un travail, mais en tout cas, il ne me semble pas raisonnable de mettre un four dans cette catégorie, ça me semble plutôt être un outil. Le four ne produit rien quand on l'allume, il chauffe, mais ça ne sert à rien si on ne met pas un truc à cuire dedans. C'est comme des plaques de cuisson, une casserole, une perceuse, une voiture…

Contester un paiement, c'est facile. Mais contester une partie d'un paiement, c'est infaisable. Le coup des options payantes est tout à fait pertinent, imaginons un fournisseur de téléphonie mobile qui t'abonne d'office à un service de nouvelles sportives par SMS, gratuit le premier mois. Tu ne l'as jamais demandé, mais lui considère que tu y as souscris, même si c'est faux, c'est ce qu'ils ont noté dans leur base de données. Souscrire ainsi un client à un service sans qu'il l'ait demandé, c'est parfaitement interdit, mais c'est fait et c'est comme ça, libre à toi de les attaquer en justice si tu as le temps.

Toujours est-il qu'après un mois, il va commencer à majorer ta facture coût de ce service. Deux possibilités :

• si tu paies par un moyen à ton initiative, chèque ou virement, tu peux leur écrire pour contester la facture, et leur régler ce que tu leur dois vraiment, donc minoré du coût de ce service non demandé ; à ce moment, le fournisseur aura le choix entre :
  • considérer cela comme un défaut de paiement, suspendre l'abonnement, lancer une procédure de recouvrement de créance et perdre un client ;
  • accepter de retirer l'abonnement au service non demandé et conserver un client ;
• si tu paies par prélèvement, ils auront déjà prélevé le montant indûment majoré, ce qui ne laisse que deux options :
  • annuler le prélèvement, et se retrouver en défaut de paiement intégral pour ce mois, avec le fournisseur qui déclenchera alors probablement une suspension d'abonnement et une procédure de recouvrement de créance, puisque quand un client ne paie pas du tout, il n'y a rien à perdre ;
  • écrire au fournisseur pour lui demander un remboursement de la somme indûment prélevée, et espérer…

Ça s'appelle une fourniture de service, pas du salaire.

J'ai déjà rejeté et révoqué des mandats ou paiements SEPA en ligne, la banque ne demande rien, tu le fais et ça se met en place directement et voilà.

Non, ce que tu as fait, c'est mettre annuler des prélèvements, et mettre des créancier en liste noire. Ta banque peut à tort appeler ça une révocation, ça n'en est pas une, pour la simple raison que ce n'est pas ta banque qui a le mandat, mais le créancier. Pour le révoquer, c'est à lui qu'il faut écrire, et c'est à lui de prendre en compte cette révocation en cessant de prélever, puisque tout nouveau prélèvement serait un prélèvement sans mandat valide, qui passerait très bien mais en totale violation avec le règlement SEPA, lui faisant risquer une radiation globale.

Au cas où ça n'apparaîtrait pas assez clairement dans ce que je viens d'écrire, la prise en compte d'une révocation de mandat dépend uniquement du bon vouloir du créancier. Comme on peut s'attendre à ce que certains ne prennent pas en compte les révocations, les banques proposent souvent une possibilité de bloquer un créancier, de sorte que les prélèvement qu'il pourra tenter seront refusés.

Cela m'est arrivé récemment avec l'assureur d'un prêt immobilier. Ayant remboursé mon prêt par anticipation, j'écrivis à l'assureur pour lui signaler que le prêt était terminé, que par conséquent ma police d'assurance prenait également fin, et qu'ayant déjà réglé la dernière cotisation, je ne leur devais plus rien. Dans la même lettre, je leur signifiai la révocation de leur mandat de prélèvement, leur rappelant qu'ils n'avaient plus rien à prélever sur mon compte, et qu'ils n'avaient désormais plus le droit de le faire. Eh bien, ça ne loupa pas, quelques semaines après, je reçus de leur part une lettre où ils se plaignaient que leur tentative de prélever une nouvelle cotisation avait échouée, que j'étais en défaut de paiement et que si ça continuait ils allaient faire appel à un cabinet de recouvrement, de sorte que je dus leur répondre pour leur rappeler que je n'étais plus client, que cette cotisation était indue, que leur mandat de prélèvement avait été révoqué, que leur tentative était en violation du règlement SEPA et que, en gros, je ne paierai pas. Au vu de leur dernière réponse, je crois qu'ils ont bien compris et laissé tomber l'idée de me soutirer quoi que ce soit.

Bref, tout ça pour dire qu'avec les prélèvements SEPA, il y a deux risques :

• de se faire débiter par un créancier inconnu, donc a fortiori sans mandat, ce qui est du vol pur et simple ;
• de se faire débiter par un créancier qui n'a pas bien compris qu'on n'est plus client et qui n'a pas pris en compte ma révocation de son mandat (c'est en fait très, très fréquent, un fournisseur n'ayant aucun intérêt à correctement prendre en compte le départ de clients).

Les deux cas sont des violation du règlement SEPA ; pour le premier, une annulation de la transaction frauduleuse suffit, mais pour le second, qui risquerait de se répéter, seule une liste noire permet d'en venir à bout.

Un TIP SEPA, c'est un mandat de prélèvement. Valable pour un seul prélèvement, mais le créancier peut s'amuser à l'utiliser plusieurs fois, c'est interdit, mais ça marche.

Correction, avec SEPA, par défaut, tout créancier, aussi bien le Trésor Public qu'EdF, peut déjà piocher à son bon vouloir. C'est interdit sans mandat signé par le client, mais c'est tout de même possible. Certaines banques permettent de bloquer les prélèvements sauf pour une liste définie par le client, mais pas toute.

Les mieux est encore de consulter la norme POSIX. Et effectivement, seq ne fait pas partie des utilitaires standard… Je ne sais pas comment faire ça sans.

Attention, c'est du Bash, ou du Zsh, mais plus du simple shell POSIX.

Sans pipe ni recourcs à xargs:

commande $(for i in $(seq 1 100); do printf 'arg '; done)

Un truc qu'il suffit d'installer pour que ça marche, c'est un peu l'esprit du client officiel, Certbot. Bon, il faut aussi le lancer. Mais il est conçu pour les cas simple, et il ne faut pas rêver, un client qu'il suffit d'installer et qui marche dans tous les cas, même avec plusieurs serveurs derrière un proxy inverse, un NAT, avec des ports différents et je ne sais quoi encore, ça n'existera pas. Pour les installation qui dépassent le simple serveur domestique, il faut plutôt compter sur les clients alternatifs qui permettent une grande personnalisation.

Paperwork n'est-il pas en Python ? Parce qu'il y a des bindings Python pour DjVuLibre.

Pour Tesseract, apparemment il y a une libtesseract, mais je ne sais pas ce que ça vaut.

Dans ce cas, tu pourrais prendre en charge le DjVu en lecture, pour importer des fichiers réalisés extérieurement.

Comme tu dis un problème se pose lorsqu'on te demande des originaux et ta solution parait pertinente.
Dernièrement j'ai arrêté de stocker un pdf mais je passe par un jpeg avec un facteur de qualité de 97, au final je n'ai pas trop regardé la perte de qualité mais dans tous les cas ça prends moins de place.

Avant même de regarder la qualité de la compression, il faut déjà s'occuper de la finesse de la numérisation. Si c'est du 100 ou 150 dpi, ça va se voir tout de suite, parce que ce sera pixelisé façon fax. En 200 dpi, ça se verra mais pas forcément immédiatement. En 300 dpi, ça se verra en étant un peu attentif. Et en 600 dpi, ce sera invisible sauf à vraiment chercher très attentivement, et encore. En supposant une impression à 300 dpi.

Salut,

J'ai une suggestion de fonctionnalité : une prise en charge du format DjVu, qui est parfaitement adapté pour les documents numérisé, et qui peut également être OCRisé.

Par exemple, mon cas d'usage pour le DjVu est le suivant. Je souhaite à numériser mes documents avec une qualité suffisante pour qu'une fois réimprimés, un humain ne se rende pas spontanément compte qu'il s'agit d'une copie¹, même s'il pourra toujours le remarquer en l'examinant attentivement. Dans la mesure où nous ne décelons plus facilement les points à partir de 300 dpi, il faut pour cela numériser à 600 dpi. Essayez de stocker ça sous la forme d'un PDF, et vous obtiendrez quelque chose de très lourd, avec en prime une compression avec perte. Essayez cela en DjVu, et vous obtiendrez quelque chose de moins de 100 kio.

Pour info, DjVu est vraiment faire pour cela, avec plusieurs niveaux d'optimisation :

• le document est séparé en arrière-plan (image en couleur) et premier plan (texte bitonal) ;
• l'arrière-plan est codé avec une compression par ondelettes ;
• le premier-plan est codé à la façon du JBIG, avec notamment une reconnaissance des formes répétées (la même lettre à plusieurs endroits de la page).

Pour produire un document DjVu à partir d'images (TIFF dans mon cas), j'utilise didjvu, puis ocrodjvu avec tesseract pour y ajouter une couche de texte par OCR. Les documents DjVu peuvent être lus avec Evince, donc probablement avec le bibliothèque Poppler.

Notes :

1. Il ne s'agit pas de faire un faux ou de prétendre qu'il s'agit d'un original. Simplement, lorsqu'on me demande sans plus de précision un document dont je n'ai qu'un exemplaire, il est évidemment hors de question de fournir l'original, aussi je fournis donc une copie, sans précision à ce sujet. Il est arrivé qu'on me refuse un dossier parce qu'en le voyant, mon interlocuteur avait rapidement remarqué qu'il s'agissait d'une copie : dans ce cas, avec une meilleure qualité, on peut augmenter les chances qu'il accepte un tel dossier.

• Démarrer le système d'installation en UEFI, et surtout pas en BIOS. En effet, après avoir installé GRUB, il doit le déclarer à la carte mère en passant des appels UEFI qui vont bien, et pour ça, il faut avoir démarré en UEFI, sinon c'est impossible, et on se retrouve avec GRUB installé mais absent du menu de démarrage proposé par la carte mère, et avec donc aucun moyen de le lancer.

Pour info, pour que ta clef USB soit démarrable en UEFI :

• elle doit être partitionnée en GPT, ou éventuellement MBR (c'est plus rare, mais c'est possible) ;
• elle doit avoir une partition de type “EFI System Partition”;
• cette partition doit être formatée en FAT32 (c'est le seul système qui soit pris en charge par tous les UEFI, mais ceux de chez Apple lisent également le HFS+) ;
• il doit y avoir sur ce système un fichier /EFI/BOOT/BOOTX64.EFI (pour un PC en 64 bits ; le nom serait différent pour une autre architecture) ;
• ce fichier doit être un exécutable UEFI pour PC en 64 bits, en pratique ce sera GRUB ou un autre chargeur de démarrage, voire un noyau Linux avec l'emballage UEFI qui va bien.

C'est ça, on l'a forcé à verrouiller son bouquin, bien sûr. Parce que le publier sur son site Web, c'était sûrement interdit. Non, utiliser la DRM Adobe, c'est un choix qu'il a fait sciemment et volontairement, ou qu'il a ignoré ou délégué volontairement, et on peut dont tout à fait lui reprocher.

Tu as acheté un truc sous DRM, par nature pénible à lire et plein de limitations. Tu peux contacter le service client de la boutique où tu l'as acheté, et leur demander un remboursement : ils sont habitués, l'essentiel des demandes de support d'un libraire en ligne concerne des problèmes avec les DRM, et ils ne font aucune difficulté à rembourser l'achat.

Souviens-toi simplement que, la prochaine fois, il faudra vérifier si le bouquin que tu achètes n'est pas sous DRM, et, s'il l'est, ne pas l'acheter, et aller commander la version papier à la place, qui sera simple d'utilisation et respectueuse de tes droits.

Tout à fait d'accord avec ceci :

De manière générale c’est le problèmes des systèmes où le lien entre personne physique et clef de chiffrement est établi et contrôlé par un acteur tiers, comme WhatsApp, ou en utilisant des mécanismes peu fiables, comme le contrôle du numéro de téléphone.

J'y pense depuis des mois, et il faudrait que je rédige un article plus détaillé, parce que je suis assez ennuyé par tous ces systèmes de communication qui vantent un chiffrement de bout en bout, sans complexité pour l'utilisateur, et prétendent n'avoir aucun moyen de déchiffrer les communications, même si on leur demande très très fort.

C'est bien simple, si vous n'avez à aucun moment validé la clef de votre correspondant en le rencontrant directement et en échangeant au moins un hachage de cette clef, ou si le code du logiciel n'est pas accessible, compilable et utilisable après compilation maison, l'affirmation précédente est simplement fausse : le fournisseur a tout à fait moyen de déchiffrer les communications. En effet :

• si vous n'avez pas de moyen de valider sérieusement la clef d'un correspondant, sur demande des autorités, le fournisseur du service peut s'être placé en homme du milieu sans que ça se voie ;
• si on ne peut pas vérifier le code, puis le compiler pour utiliser sa version vérifiée, même en validant les clef, le fournisseur peut tout à fait s'être placé en homme du milieu, et afficher malgré tout des hachages de clefs valides, alors que le logiciel utilise d'autres clefs à la place.

Ce n'est pas lié à la privatisation, mais à la possibilité de virer un client, autrement dit, à la régulation. On peut très bien privatiser un service et l'ouvrir à la concurrence en imposant des règles aux fournisseurs dudit service, c'est ce qui se fait pour les banques avec le droit au compte par exemple. Cela pourrait tout à fait se faire pour les assurances santé.

À toutes fins utiles, je me permets de rappeler que l'assurance santé obligatoire est :

1. un service qui n'est pas fourni par un unique acteur mais par plusieurs qui disposent pour l'essentiel d'un monopole restreint à un serveur d'activité, ainsi la CPAM pour les salariés du privé, et d'autres pour les fonctionnaires, pour les professions libérales, etc. ;
2. un service potentiellement concurrentiel, avec au moins un secteur d'activité où il y a effectivement concurrence entre deux fournisseurs : les études supérieures.

Ton avocat te le rappellera sans doute, mais dans ce que tu leur demandera, il faut que tu chiffres tout, absolument tout ce qu'ils t'auront coûté, ce qui inclut évidemment le matériel, les vêtements, les réparations et les soins, mais aussi :

• l'invalidité temporaire ;
• les taxis, bus et autre pendant tout le temps où tu ne pouvais plus te déplacer à vélo ;
• le temps que tu auras passé sur cette affaire ;
• les timbres que tu auras achetés pour leur écrire moult courrier ;
• les dommages moraux, plus difficiles à évaluer mais qui doivent être compensés par une indemnisation ;
• les honoraires de ton avocat, évidemment.

Eh bien ils sont complètement cons, chez cette assurance. Avec un accident voiture contre vélo, ils n'ont aucune chance de gagner, faire obstruction jusqu'au procès, ça ne peut que leur coûter plus cher. Tout ça pour un remboursement somme toute de faible montant par rapport à ce que leur coûte des accidents voiture contre voiture… Franchement, pour un assureur, il faut vraiment être con pour perdre du temps et de l'argent à essayer de rapiner sur un accident avec un vélo.

Alors la lenteur, c'est simplement leur marque de fabrique il faut croire. J'avais un prêt immobilier chez eux, qu'il avaient mis 4 mois à valider, manquant presque de me faire louper la date de la vente. Je viens de le faire racheter par une autre banque, et il leur a fallu 2 mois et deux rappels de ma part pour m'envoyer un papier nécessaire à cela (un décompte de remboursement anticipé total), heureusement que j'avais pris de l'avance. Maintenant que mon prêt chez eux est remboursé, eh bien ils ne l'ont toujours pas remarqué de sorte qu'il apparaît toujours dans me comptes, et je ne serais pas surpris qu'ils essaient de me débiter une nouvelle échéance (sauf que ça va foirer, vu que je n'ai pas sur mon compte l'argent qu'il faut pour payer de nouvelles échéances indues).

Bien content de me barrer de cette banque…