Moi j'aimerais bien avoir une explication technique, comment est-il possible d'ignorer une année bissextile ?
Je n'ai aucune statistique, mais je pense qu'une grosse part des bugs sont des cas stupides qui ont été ignorés pour aller plus vite ou parce que pas pertinent à une époque puis ça l'est devenu, ou parce que cachés au fond d'une complexité de code.
Ceux qui concernent les années bissextiles sont plus exposés médiatiquement mais au final ça reste des bugs comme des millions d'autres qui ont lieu tous les jours mais qui sont moins accessibles au grand public.
j’avoue ne pas comprendre d’où viennent les chiffres de 228 (dans le premier cas) et 244 (dans le second).
Ce n'est pas évident mais c'est plus ou moins expliqué dans la 1ère bulle. Chaque petit carré correspond à un bit. Et la position du carré donne une indication d'où ça vient.
Pour le premier cas :
- L'utilisateur choisit un mot peu commun => 16 bits. Ici Randall suppose donc une liste de 65536 mots dans laquelle on choisit.
- L'utilisateur choisit de mettre la 1ère lettre en majuscule ou non => 1 bit
- Pour chaque lettre où c'est faisable, l'utilisateur choisit d'écrire en leet ou pas => 3 bits (le calcul est un peu simpliste ici car les 3 bits dépendent en fait du mot initial)
- L'utilisateur rajoute un caractère spécial => 4 bits (donc dans une liste de 16 caractères)
- L'utilisateur rajoute un chiffre => 3 bits (c'est un peu plus, mais c'est arrondi)
- L'utilisateur peut choisir d'inverser le caractère spécial et le chiffre => 1 bit
Au total, on retrouve bien les 28 bits module quelques approximations.
Dans le deuxième cas :
- L'utilisateur choisit un mot commun => 11 bits. Ici Randall suppose cette fois une liste plus réduite de 2048 mots
- Il répète 4 fois => 44 bits
Un point important des 2 méthodes, c'est que les choix doivent tous être des choix au hasard (donc pas l'utilisateur qui sort de sa tête un mot). Sinon, l'entropie diminue fortement.
En tous cas une chose est sûre, me semble-t-il, c’est que dans les deux cas l’entropie est plus faible qu’un mot de passe de la même longueur utilisant le même ensemble de caractères et qui serait vraiment aléatoire
Oui complètement. On parle souvent pour simplifier de l'entropie d'un mot de passe, mais en vrai on devrait parler de l'entropie d'une méthode de génération de mot de passe. Je ne rentre pas dans les détails, car il faudrait un journal pour ça, mais l'idée c'est de la mesurer dans le pire des cas, en supposant que l'attaquant connaisse parfaitement la méthode de génération et les biais de l'humain qui l'utilise. Ça permet d'avoir une idée de la robustesse d'une méthode qu'on communique massivement pour être appliquée par un grand monde.
Et du coup, si ta méthode c'est de générer un mot de passe de la même longueur qu'un des précédents, oui ton entropie va être beaucoup plus importante, même si théoriquement tu pourrais retomber sur les même mots de passe.
On devrait peut-être enseigner les méthodes de choix d’un mot de passe vers le CE2-CM1.
Il faudrait surtout enseigner qu'un mot de passe, même très robuste, ce n'est pas la panacée, et que le minimum pour protéger un service non trivial c'est du MFA.
Le 44 bit d’entropie est évidemment à relativiser si l’attaquant sais que cette méthode est utilisée
L'entropie est de 44 bits si l'attaquant sait que cette méthode est utilisée, qu'il connaît la liste de mots initiale et le nombre de mots choisis.
Ce qui est discutable, c'est si 44 bits suffisent ou pas. Mais cet algorithme s'adapte bien, il suffit de prendre une plus grande liste de mots et/ou plus de mots pour augmenter l'entropie jusqu'à la valeur désirée.
Ce n'est pas pour rien qu'on utilise le SHA256 (et ses cousins comme le SHA512) en cryptographie. Trouver une préimage est complètement hors de portée à l'heure actuelle
Oui SHA256 est utilisé en cryptographie. Oui il est résistant aux attaques de preimage.
Mais non, ça n'en fait pas un algorithme idéal pour le hachage des mots de passe. Ce qui te sauve, c'est qu'en entrée, tu as une partie aléatoire avec une bonne entropie.
Il y a les Tile Trackers aussi qui marchent avec Android.
Ça permet de recevoir une notification sur son téléphone en cas d'éloignement du tracker, ça permet de le faire sonner s'il n'est pas trop loin. Par contre la géolocalisation nécessite qu'il y ait quelqu'un avec l'application Tile pas trop loin. Il n'y a pas de chiffres précis, mais à mon avis on est très très loin du maillage des iPhone. Peut-être que dans un parc d'attractions avec une grande densité de personnes, ça suffit, mais impossible à savoir sans chiffres précis.
Un autre inconvénient, c'est que ça fait une société de plus à qui envoyer en permanence ta géolocalisation.
Il me semble que les métadonnées ne permettent pas d'identifier les personnes qui communiquent puisqu'il s'agit d'une clé générée localement et transmise "de la main à la main" entre elles. Donc même Olvid ne sait pas qui sait
La clef publique du destinataire est stockée sur le serveur. Si le modèle de menace est un geek qui a accès au serveur, on est d'accord : ça ne permet pas d'identifier les personnes qui communiquent. Mais si le modèle de menace c'est la vraie vie et la NSA qui essaye d'identifier les membres du gouvernement français qui communiquent, ça n'est pas très efficace (à moins que d'autres contre mesures ne soient implémentées).
Ils ont peut-être quelques dizaines de personnes à identifier. En notant les moments où ces personnes pianotent sur leurs téléphones, celles où elles ne le font pas et en corrélant avec ce qui passe sur le serveur, ça va aller vite pour identifier à qui est telle clef publique (très très vite pour ceux qui utilisent beaucoup le service, plus long pour ceux qui l'utilisent moins).
A noter que même sans ça, vu que la NSA a sûrement déjà une bonne idée de qui communique avec qui à quel moment/quelle fréquence, elle pourrait arriver à un bon taux de découverte.
Une technique que j'ai vue ailleurs c'est de ne pas utiliser l'alphabet français (et surtout pas l'anglais…). Si l'attaquant sait que tu es français et compte sur une attaque par dictionnaire, prendre des mots de swahili (pas d'accents, peut s'écrire juste avec de l'ASCII), basque, breton ou même d'italien peut aider.
Non, mauvaise idée.
Comme dit plus haut, une bonne technique doit rester fiable y compris si ton attaquant sait ce que tu utilises pour générer tes mots de passe. Avec la technique xkcd, tu peux même donner ta liste de mots à l'attaquant, ça ne pose pas de souci. Si tu as une liste de 2048 mots, tu as 11 bits d'entropie par mot. Tu prends autant de mots que nécessaire pour arrivée à l'entropie totale voulue, et tu as un mot de passe suffisamment fort sans faire aucune hypothèse sur les connaissances ou non de ton attaquant.
Concernant le désalignement de config MX, l'avez-vous remonté ? On a peut-ête qqchose à corriger.
Oui et j'ai eu la réponse du support à l'instant. C'est la config envoyée par email qui est bonne.
Concernant les stickers on les a reçus, mais on ne les a pas encore envoyés. Ça risque d'être plus énergivore de vérifier à qui on doit ou pas les envoyer que de les envoyer à tout le monde.
Les humains sont de mauvais générateurs et ont tendance à appliquer les mêmes schémas.
Si ton schéma est une collection de mots que tu peux écrire comme tu veux et dans plus d'une langue, crois-moi, ça complique la tâche et ça facilite la mémorisation du mot de passe.
Je ne suis pas sûr de comprendre ta remarque dans le contexte d'une réponse à mon message.
Si tu parles de la technique XKCD 936, un point important pour qu'elle fonctionne est que les mots (et la langue si tu veux la rajouter) doivent être choisis aléatoirement. Si tu laisses une personne générer le mot de passe par elle-même, ça ne fonctionne plus aussi bien. Nous sommes très mauvais pour choisir au hasard, même si nous nous en donnons l'illusion. L'entropie du couple mot/langue choisi serait plus faible que ce à quoi on peut s'attendre. Ça pourrait se compenser par une augmentation du nombre de mots, mais du coup l'aspect pratique devient moins vrai.
Parce qu'il faut partir du principe que l'attaquant connaît ta méthode de génération de mot de passe.
Pourquoi ? Je vois 2 principales raisons :
- Les humains sont de mauvais générateurs et ont tendance à appliquer les mêmes schémas. Si tu appliques une certaine méthode, tu n'es probablement pas le seul. Et si une masse critique est atteinte, alors cette méthode sera ciblée spécifiquement, surtout si elle est triviale comme dans ce cas.
- Tu auras probablement un jour un mot de passe qui fuitera. A partir de là, c'est facile pour l'attaquant de tester des variantes sur d'autres sites.
J'ai bien conscience qu'il y a plus pratique mais ça correspond aux mots de passe générés par les générateurs de mots de passe.
Mon keepassxc est configuré par défaut pour générer des mots de passe comme le xkcd (plus exactement 5 mots au hasards dans un dico français). Tout simplement parce que parfois je dois taper, ou dicter un mot de passe. C'est rare, mais quand ça arrive je suis bien content d'être dans un cas où j'ai pu rester sur cette configuration.
Le support est réactif et patient, même avec un pas doué comme moi.
L'interface de configuration fait un peu peur. Y a plein d'options, mais pour les néophytes comme moi, la plupart sont inutiles. J'ai eu plus de mal à trouver ce que je cherchais qu'avec le concurrent honni qui commence par un G.
Un petit désalignement sur la configuration des enregistrements MX envoyée par mail et celle disponible sur l'interface d'administration. A priori rien de grave.
J'en profite pour poser 2 petites questions :
- Si j'ai bien compris les stickers ne sont pas encore prêts. Personnellement, ils ne m'intéressent pas plus que ça. Si j'envoie un mail pour ne pas les recevoir, ça vous arrange ou au contraire ça vous fait de la gestion supplémentaire pour gérer un cas particulier ?
- Est-ce que dans le futur, c'est possible de prévoir du MFA pour le webmail (et donc un mot de passe différent de l'IMAP & co)?
Bien sûr que si, le nombre compte, ne serait-ce que par la nourriture.
On est d'accord, ça compte. Mais ça ne veut pas dire que la diminution de la population est un axe d'amélioration prioritaire.
Si là aujourd'hui on arrêtait d'un coup de faire des enfants sans rien changer à notre mode de vie, on continuerait d'aller droit dans le mur avec aucune chance de limiter le réchauffement à +1.5°C avant l'extinction de l'espèce humaine.
Par contre, si on arrivait à changer drastiquement nos modes de vie tout en gardant la natalité actuellement, la documentation scientifique montre que c'est faisable.
Le point important c'est que l'impact des enfants est directement lié à celui des parents. Si celui des parents diminue, celui des enfants va diminuer mécaniquement et du coup ça devient un levier moins pertinent.
Ça c'est pour la théorie. Maintenant en pratique, on ne va pas arriver à changer notre mode de vie suffisamment, donc la diminution des naissances pourrait jouer un rôle.
Mais là j'ai du mal à croire que le discours "puisqu'on ne veut pas changer nos modes de vie, faisons moins d'enfants pour diminuer la casse" ait un quelconque effet.
* ceux qui ne veulent pas agir vont évidemment l'ignorer
* le dire à ceux qui veulent bien agir, c'est leur faire la morale parce qu'ils n'agissent pas sur un point mineur pour compenser partiellement le fait que d'autres n'agissent pas sur ce qui est réellement impactant
Et pour la pluie ma foi un kway ca va bien aussi :-)
Ça dépend.
Quand tu emmènes des enfants à l'école le matin sous forte de pluie c'est clairement insuffisant. Ils ont les jambes trempées et pas de possibilité de se changer.
Les solutions à base de jambières ne sont pas idéales non plus. Le matin c'est la course, tu n'as pas envie de passer encore plus de temps à préparer les enfants et une fois sur place il faut les retirer sous la pluie.
Du coup, je peux comprendre l'attrait du toit. Quoique s'il y a un peu de vent avec la pluie, ça ne sert plus à rien.
Je suis pas client, donc je peux pas vraiment dire, mais il me semble que certaines sociétés garantissent une intervention dans un temps "relativement court".
C'est quoi relativement court ?
Le temps d'intervention c'est :
* 30s avant que l'alarme ne se déclenche
* Des vérifications obligatoires par la société de sécu pour lever le doute de faux positif. Un agent qui regarde la caméra de sécurité (en espérant que ça ne soit pas la nuit) pour constater qu'il y a bien quelqu'un, qui appelle le domicile, qui se fait une conviction que le gars qui répond "j'ai un trou de mémoire je vais retrouver le code" ment, ça doit bien prendre 30 secondes s'il est perspicace et qu'il n'était pas en train de se faire son café au moment où l'alarme a sonné.
* Temps moyen de l'intervention de la police une fois contactée : 6 minutes et 48s.
Donc en gros, pour être gentil, une intervention c'est 7 minutes environ après le début du cambriolage.
Et le temps moyen d'un cambriolage ? 3 minutes en France d'après mon moteur de recherche.
Donc pour que l'intervention soit utile, il ne suffit pas de garantir un temps "relativement court", il faut un temps beaucoup plus court que la moyenne.
Ceci dit, ça ne veut pas dire que ça ne sert à rien, il est fort possible que la phase de vérification ait un effet protecteur en faisant fuir les cambrioleurs. Mais compter sur la phase d'intervention me paraît très optimiste.
Mais on n'est soumis à rien de plus. En particulier, si tu n'as pas signé le CLUF, tu peux bien prendre une photo de ton numéro de licence et le diffuser sur Internet, sans violer quelque loi que ce soit.
Tu restes soumis à une obligation de loyauté envers ton employeur. Je n'ai aucune idée d'à quoi sert un numéro de licence, mais si c'est une information privée, tu n'as pas le droit de la diffuser sans l'accord de ton employeur.
Ok je viens de relire l'article et je pense que ta confusion vient vraiment du changement de notation.
Par défaut, quand tu écris un nombre sans précision, tu es dans la notation qui est associée au développement décimal. Dans cette notation 0,9999… est une écriture valide du nombre qui s'écrit 1 dans cette même notation.
Par contre dans cette notation, il n'existe pas de nombre 99999…9 !
L'article Wikipedia parle d'une autre notation, le complément en base 10. Dans celle-ci, 9999…9 est un nombre, celui qui s'écrit -1 dans la notation usuelle.
Si je prends un exemple plus simple: 14 en base 5, ça vaut 9 en base 10. Cependant, si tu croises quelqu'un qui te dit "j'ai un résultat contre intuitif : 14 = 9", tu vas lui dire que c'est faux.
Là c'est le même principe, ce n'est pas parce qu'il existe un système de notation dans lequel -1 s'écrit 999…9, que ça veut dire que -1 = 99999…999.
Alors oui, on sort de la représentation usuelle, mais ça n'est pas non plus absurde comme le 42 que tu sors pour te faire plaisir.
Je ne dis pas que c'est absurde, je dis que ce n'est pas défini par défaut. Rien ne t'empêche de le définir ou de préciser un cadre mathématique dans lequel c'est défini, mais sans ça, ça ne veut rien dire. Si d'autres commentaires n'avaient pas porté sur des prolongations de sommations elles aussi unusuelles, je pense que j'aurais clairement dit que c'est faux (sous-entendu avec les mathématiques usuelles).
Si en additionnant y à x, je tombe sur 0, c'est assez logique de dire que y est égal à -x.
Dans un anneau oui. Sauf que là, ton x n'est pas défini : ce n'est pas un entier, ni une série convergente. L'addition n'est pas définie non plus et donc parler d'un résultat égal à 0 n'a pas de sens. A partir de là, c'est dur d'appliquer une quelconque logique.
Là, je ne suis pas l'argument.
J'essaye de comprendre d'où vient le résultat 9999..999 =-1. Comme tu parlais de complément à 2, je me suis dit que tu es parti du principe que 111111…1 = -1 dans cette implémentation et que tu as transposé ça dans la notation usuelle en prenant 9 à la place du 1. Et il y a plusieurs erreurs à ça dont l'une qui consiste à mélanger les notations.
Plus drôle et moins intuitif, c'est si on rajoute les 9 de l'autre côté:
…9999 est égal à -1
En effet, si on ajoute …9999 et 1, la retenue se décale à l'infini et on trouve bien 0 !
Rajouter des 9 devant crée une série divergente. Dire d'en rajouter à l'infini n'a donc pas de sens si tu ne précises pas comment faire. Donc tu peux dire que chez toi, par définition, ça vaut -1, c'est tout aussi vrai et intéressant que si moi je dis que ça vaut 42 ou que quelqu'un dit que ça vaut les numéros du loto de demain.
(c'est d'ailleurs la base de l'idée de la représentation en complément à 2 pour les entiers en machine…)
Non.
1) La représentation en complément à 2 porte sur un nombre fixes de chiffres, on ne peut pas en rajouter à l'infini.
2) Cette convention d'écriture est différente de l'usuelle. "-1" usuelle s'écrit "11111….1111" en complément à 2. Ca ne veut absolument pas dire qu'il y a une quelconque relation entre "111111…..1111" en écriture usuelle et "-1" en écriture usuelle.
C'est un peu comme si je disais que 4 en base 10, ça vaut 100 en base 2 et que du coup 4 est égal à 100 tout le temps. Ce sont deux notations différentes, qui ne doivent pas être mélangées.
3) Le principe d'utiliser le complément pour les nombres négatifs fait que ça simplifie l'addition d'entier tant que tu restes dans la plage qui peut être représentée.
Ça ne découle pas d'une quelconque propriété mathématique qui dirait que si tu rajoutes suffisamment de chiffres tu obtiens -1
Ce qu'il faut comprendre, c'est que le "+" dans "1 + 2" et le "+" dans "1 + 2 + 3 + …" ce n'est pas la même opération. D'un côté c'est l'addition dans les réels, de l'autre côté c'est une super-sommation stable, linéaire et régulière.
Super-sommation oui, mais dans son billet, David Louapre démontre qu'il n'existe pas de super-sommation à la fois stable, linéaire et régulière pour 1+2+3+… Du coup, faire cette somme a au final peu d'intérêt et l'utiliser pour un calcul physique est bien un tour de passe passe.
En fait ce n'est pas le cas. Les calculs sur l'énergie du vide se font sans ce tour de passe-passe. Il se trouve juste que si tu admets que la somme vaut -1/12 , tu peux les faire plus rapidement/facilement et arriver au même résultat.
Ça fait beaucoup parler, mais au final ça ne prouve rien du tout. Si j'admets que 0=1, je peux faire les calculs encore plus rapidement.
Question bête : dans le référentiel de l’observateur au centre de cette sphère, le voyage sera long, même carrément impossible. Mais étant données les transformations de Lorentz, combien durerait le voyage dans le référentiel tournant (oui, tourner va être délicat aussi) ?
Aujourd'hui, le "tour" de l'univers observable c'est grosso modo 3*10 ⁵⁴. Si on considère que le voyage consiste à faire le tour d'aujourd'hui (en étant magiquement téléporté dessus à la vitesse qui va bien), le temps nécessaire dans le référentiel d'un terrier, c'est
tout simplement t=3*1054/v. En prenant v=0.99c, c'est grosso modo 1046 s, soit 2*1028 fois le temps écoulé depuis le big bang.
Si le voyage se déroulait en ligne droite à vitesse constante, le temps dans le référentiel du voyageur serait donné par la transformation de Lorentz. Avec v=0,99c, le facteur de Lorentz vaut environ 7. Le voyage mettrait donc 7 fois moins de temps.
Si le voyage se déroule en cercle, le calcul dépasse mes compétences. Mais vu le rayon de courbure de la trajectoire, ça ne me surprendrait pas que ça ne change pas grand chose au résultat.
[^] # Re: hostname
Posté par NicolasP . En réponse au journal [Message de service] Changement d'adresse IP publique pour le site LinuxFr.org. Évalué à 10 (+30/-0).
C'est vraiment dommage qu'on fasse tous la même opération. Il faudrait inventer un système où ça se propage automatiquement.
[^] # Re: Comment est-ce possible ?
Posté par NicolasP . En réponse au lien Un 29 février ? C'est quoi ça ? C'est nouveau ?. Évalué à 5 (+4/-0).
Je n'ai aucune statistique, mais je pense qu'une grosse part des bugs sont des cas stupides qui ont été ignorés pour aller plus vite ou parce que pas pertinent à une époque puis ça l'est devenu, ou parce que cachés au fond d'une complexité de code.
Ceux qui concernent les années bissextiles sont plus exposés médiatiquement mais au final ça reste des bugs comme des millions d'autres qui ont lieu tous les jours mais qui sont moins accessibles au grand public.
[^] # Re: Caractère spécial
Posté par NicolasP . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 3 (+2/-0).
Ce n'est pas évident mais c'est plus ou moins expliqué dans la 1ère bulle. Chaque petit carré correspond à un bit. Et la position du carré donne une indication d'où ça vient.
Pour le premier cas :
- L'utilisateur choisit un mot peu commun => 16 bits. Ici Randall suppose donc une liste de 65536 mots dans laquelle on choisit.
- L'utilisateur choisit de mettre la 1ère lettre en majuscule ou non => 1 bit
- Pour chaque lettre où c'est faisable, l'utilisateur choisit d'écrire en leet ou pas => 3 bits (le calcul est un peu simpliste ici car les 3 bits dépendent en fait du mot initial)
- L'utilisateur rajoute un caractère spécial => 4 bits (donc dans une liste de 16 caractères)
- L'utilisateur rajoute un chiffre => 3 bits (c'est un peu plus, mais c'est arrondi)
- L'utilisateur peut choisir d'inverser le caractère spécial et le chiffre => 1 bit
Au total, on retrouve bien les 28 bits module quelques approximations.
Dans le deuxième cas :
- L'utilisateur choisit un mot commun => 11 bits. Ici Randall suppose cette fois une liste plus réduite de 2048 mots
- Il répète 4 fois => 44 bits
Un point important des 2 méthodes, c'est que les choix doivent tous être des choix au hasard (donc pas l'utilisateur qui sort de sa tête un mot). Sinon, l'entropie diminue fortement.
Oui complètement. On parle souvent pour simplifier de l'entropie d'un mot de passe, mais en vrai on devrait parler de l'entropie d'une méthode de génération de mot de passe. Je ne rentre pas dans les détails, car il faudrait un journal pour ça, mais l'idée c'est de la mesurer dans le pire des cas, en supposant que l'attaquant connaisse parfaitement la méthode de génération et les biais de l'humain qui l'utilise. Ça permet d'avoir une idée de la robustesse d'une méthode qu'on communique massivement pour être appliquée par un grand monde.
Et du coup, si ta méthode c'est de générer un mot de passe de la même longueur qu'un des précédents, oui ton entropie va être beaucoup plus importante, même si théoriquement tu pourrais retomber sur les même mots de passe.
Il faudrait surtout enseigner qu'un mot de passe, même très robuste, ce n'est pas la panacée, et que le minimum pour protéger un service non trivial c'est du MFA.
[^] # Re: Caractère spécial
Posté par NicolasP . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 3 (+2/-0).
L'entropie est de 44 bits si l'attaquant sait que cette méthode est utilisée, qu'il connaît la liste de mots initiale et le nombre de mots choisis.
Ce qui est discutable, c'est si 44 bits suffisent ou pas. Mais cet algorithme s'adapte bien, il suffit de prendre une plus grande liste de mots et/ou plus de mots pour augmenter l'entropie jusqu'à la valeur désirée.
[^] # Re: C'est alléchant mais
Posté par NicolasP . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 3 (+2/-0).
Oui SHA256 est utilisé en cryptographie. Oui il est résistant aux attaques de preimage.
Mais non, ça n'en fait pas un algorithme idéal pour le hachage des mots de passe. Ce qui te sauve, c'est qu'en entrée, tu as une partie aléatoire avec une bonne entropie.
[^] # Re: Samsung
Posté par NicolasP . En réponse au message Alternatives aux airtags. Évalué à 2 (+1/-0).
Il y a les Tile Trackers aussi qui marchent avec Android.
Ça permet de recevoir une notification sur son téléphone en cas d'éloignement du tracker, ça permet de le faire sonner s'il n'est pas trop loin. Par contre la géolocalisation nécessite qu'il y ait quelqu'un avec l'application Tile pas trop loin. Il n'y a pas de chiffres précis, mais à mon avis on est très très loin du maillage des iPhone. Peut-être que dans un parc d'attractions avec une grande densité de personnes, ça suffit, mais impossible à savoir sans chiffres précis.
Un autre inconvénient, c'est que ça fait une société de plus à qui envoyer en permanence ta géolocalisation.
[^] # Re: Petit joueur
Posté par NicolasP . En réponse au journal Combattre la procrastination en publiant mes travaux non finis. Évalué à 10 (+20/-0).
Ça a l'air intéressant, je lirai demain.
[^] # Re: Trolesque
Posté par NicolasP . En réponse au lien Olvid la sécurité à la française c'est chez les américains. Évalué à 2.
La FAQ : https://olvid.io/faq/serveur-et-open-source/.
[^] # Re: Trolesque
Posté par NicolasP . En réponse au lien Olvid la sécurité à la française c'est chez les américains. Évalué à 10. Dernière modification le 17 décembre 2023 à 21:49.
La clef publique du destinataire est stockée sur le serveur. Si le modèle de menace est un geek qui a accès au serveur, on est d'accord : ça ne permet pas d'identifier les personnes qui communiquent. Mais si le modèle de menace c'est la vraie vie et la NSA qui essaye d'identifier les membres du gouvernement français qui communiquent, ça n'est pas très efficace (à moins que d'autres contre mesures ne soient implémentées).
Ils ont peut-être quelques dizaines de personnes à identifier. En notant les moments où ces personnes pianotent sur leurs téléphones, celles où elles ne le font pas et en corrélant avec ce qui passe sur le serveur, ça va aller vite pour identifier à qui est telle clef publique (très très vite pour ceux qui utilisent beaucoup le service, plus long pour ceux qui l'utilisent moins).
A noter que même sans ça, vu que la NSA a sûrement déjà une bonne idée de qui communique avec qui à quel moment/quelle fréquence, elle pourrait arriver à un bon taux de découverte.
[^] # Re: Pas tout compris
Posté par NicolasP . En réponse au lien Collection de sites qui ont des consignes de mots de passe à la noix . Évalué à 3.
Non, mauvaise idée.
Comme dit plus haut, une bonne technique doit rester fiable y compris si ton attaquant sait ce que tu utilises pour générer tes mots de passe. Avec la technique xkcd, tu peux même donner ta liste de mots à l'attaquant, ça ne pose pas de souci. Si tu as une liste de 2048 mots, tu as 11 bits d'entropie par mot. Tu prends autant de mots que nécessaire pour arrivée à l'entropie totale voulue, et tu as un mot de passe suffisamment fort sans faire aucune hypothèse sur les connaissances ou non de ton attaquant.
[^] # Re: Retour d'expérience
Posté par NicolasP . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 3.
Oui et j'ai eu la réponse du support à l'instant. C'est la config envoyée par email qui est bonne.
Oui je peux comprendre, pas de souci :).
[^] # Re: Pas tout compris
Posté par NicolasP . En réponse au lien Collection de sites qui ont des consignes de mots de passe à la noix . Évalué à 3.
Je ne suis pas sûr de comprendre ta remarque dans le contexte d'une réponse à mon message.
Si tu parles de la technique XKCD 936, un point important pour qu'elle fonctionne est que les mots (et la langue si tu veux la rajouter) doivent être choisis aléatoirement. Si tu laisses une personne générer le mot de passe par elle-même, ça ne fonctionne plus aussi bien. Nous sommes très mauvais pour choisir au hasard, même si nous nous en donnons l'illusion. L'entropie du couple mot/langue choisi serait plus faible que ce à quoi on peut s'attendre. Ça pourrait se compenser par une augmentation du nombre de mots, mais du coup l'aspect pratique devient moins vrai.
[^] # Re: Pas tout compris
Posté par NicolasP . En réponse au lien Collection de sites qui ont des consignes de mots de passe à la noix . Évalué à 4.
Parce qu'il faut partir du principe que l'attaquant connaît ta méthode de génération de mot de passe.
Pourquoi ? Je vois 2 principales raisons :
- Les humains sont de mauvais générateurs et ont tendance à appliquer les mêmes schémas. Si tu appliques une certaine méthode, tu n'es probablement pas le seul. Et si une masse critique est atteinte, alors cette méthode sera ciblée spécifiquement, surtout si elle est triviale comme dans ce cas.
- Tu auras probablement un jour un mot de passe qui fuitera. A partir de là, c'est facile pour l'attaquant de tester des variantes sur d'autres sites.
[^] # Re: Pas tout compris
Posté par NicolasP . En réponse au lien Collection de sites qui ont des consignes de mots de passe à la noix . Évalué à 9.
Mon keepassxc est configuré par défaut pour générer des mots de passe comme le xkcd (plus exactement 5 mots au hasards dans un dico français). Tout simplement parce que parfois je dois taper, ou dicter un mot de passe. C'est rare, mais quand ça arrive je suis bien content d'être dans un cas où j'ai pu rester sur cette configuration.
[^] # Re: Retour d'expérience
Posté par NicolasP . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 10.
Mon retour d'expérience :
J'en profite pour poser 2 petites questions :
- Si j'ai bien compris les stickers ne sont pas encore prêts. Personnellement, ils ne m'intéressent pas plus que ça. Si j'envoie un mail pour ne pas les recevoir, ça vous arrange ou au contraire ça vous fait de la gestion supplémentaire pour gérer un cas particulier ?
- Est-ce que dans le futur, c'est possible de prévoir du MFA pour le webmail (et donc un mot de passe différent de l'IMAP & co)?
[^] # Re: Toit
Posté par NicolasP . En réponse à la dépêche Le vhélio sort en v1.0.0. Évalué à 8.
On est d'accord, ça compte. Mais ça ne veut pas dire que la diminution de la population est un axe d'amélioration prioritaire.
Si là aujourd'hui on arrêtait d'un coup de faire des enfants sans rien changer à notre mode de vie, on continuerait d'aller droit dans le mur avec aucune chance de limiter le réchauffement à +1.5°C avant l'extinction de l'espèce humaine.
Par contre, si on arrivait à changer drastiquement nos modes de vie tout en gardant la natalité actuellement, la documentation scientifique montre que c'est faisable.
Le point important c'est que l'impact des enfants est directement lié à celui des parents. Si celui des parents diminue, celui des enfants va diminuer mécaniquement et du coup ça devient un levier moins pertinent.
Ça c'est pour la théorie. Maintenant en pratique, on ne va pas arriver à changer notre mode de vie suffisamment, donc la diminution des naissances pourrait jouer un rôle.
Mais là j'ai du mal à croire que le discours "puisqu'on ne veut pas changer nos modes de vie, faisons moins d'enfants pour diminuer la casse" ait un quelconque effet.
* ceux qui ne veulent pas agir vont évidemment l'ignorer
* le dire à ceux qui veulent bien agir, c'est leur faire la morale parce qu'ils n'agissent pas sur un point mineur pour compenser partiellement le fait que d'autres n'agissent pas sur ce qui est réellement impactant
[^] # Re: Toit
Posté par NicolasP . En réponse à la dépêche Le vhélio sort en v1.0.0. Évalué à 3.
Ça dépend.
Quand tu emmènes des enfants à l'école le matin sous forte de pluie c'est clairement insuffisant. Ils ont les jambes trempées et pas de possibilité de se changer.
Les solutions à base de jambières ne sont pas idéales non plus. Le matin c'est la course, tu n'as pas envie de passer encore plus de temps à préparer les enfants et une fois sur place il faut les retirer sous la pluie.
Du coup, je peux comprendre l'attrait du toit. Quoique s'il y a un peu de vent avec la pluie, ça ne sert plus à rien.
[^] # Re: Tous les anges s'appellent Martin
Posté par NicolasP . En réponse au journal Avoir l'alarme à l'oeil. Évalué à 5.
C'est quoi relativement court ?
Le temps d'intervention c'est :
* 30s avant que l'alarme ne se déclenche
* Des vérifications obligatoires par la société de sécu pour lever le doute de faux positif. Un agent qui regarde la caméra de sécurité (en espérant que ça ne soit pas la nuit) pour constater qu'il y a bien quelqu'un, qui appelle le domicile, qui se fait une conviction que le gars qui répond "j'ai un trou de mémoire je vais retrouver le code" ment, ça doit bien prendre 30 secondes s'il est perspicace et qu'il n'était pas en train de se faire son café au moment où l'alarme a sonné.
* Temps moyen de l'intervention de la police une fois contactée : 6 minutes et 48s.
Donc en gros, pour être gentil, une intervention c'est 7 minutes environ après le début du cambriolage.
Et le temps moyen d'un cambriolage ? 3 minutes en France d'après mon moteur de recherche.
Donc pour que l'intervention soit utile, il ne suffit pas de garantir un temps "relativement court", il faut un temps beaucoup plus court que la moyenne.
Ceci dit, ça ne veut pas dire que ça ne sert à rien, il est fort possible que la phase de vérification ait un effet protecteur en faisant fuir les cambrioleurs. Mais compter sur la phase d'intervention me paraît très optimiste.
[^] # Re: Faut signer le CLUF au boulot ?
Posté par NicolasP . En réponse au message Imposer aux salariés ou usagers de signer un contrat tiers ?. Évalué à 3.
Tu restes soumis à une obligation de loyauté envers ton employeur. Je n'ai aucune idée d'à quoi sert un numéro de licence, mais si c'est une information privée, tu n'as pas le droit de la diffuser sans l'accord de ton employeur.
[^] # Re: et dans l'autre sens ?
Posté par NicolasP . En réponse au journal [HS] combien fait 0,12 à l'infini ?. Évalué à 5.
Ok je viens de relire l'article et je pense que ta confusion vient vraiment du changement de notation.
Par défaut, quand tu écris un nombre sans précision, tu es dans la notation qui est associée au développement décimal. Dans cette notation 0,9999… est une écriture valide du nombre qui s'écrit 1 dans cette même notation.
Par contre dans cette notation, il n'existe pas de nombre 99999…9 !
L'article Wikipedia parle d'une autre notation, le complément en base 10. Dans celle-ci, 9999…9 est un nombre, celui qui s'écrit -1 dans la notation usuelle.
Si je prends un exemple plus simple: 14 en base 5, ça vaut 9 en base 10. Cependant, si tu croises quelqu'un qui te dit "j'ai un résultat contre intuitif : 14 = 9", tu vas lui dire que c'est faux.
Là c'est le même principe, ce n'est pas parce qu'il existe un système de notation dans lequel -1 s'écrit 999…9, que ça veut dire que -1 = 99999…999.
[^] # Re: et dans l'autre sens ?
Posté par NicolasP . En réponse au journal [HS] combien fait 0,12 à l'infini ?. Évalué à 2.
Je ne dis pas que c'est absurde, je dis que ce n'est pas défini par défaut. Rien ne t'empêche de le définir ou de préciser un cadre mathématique dans lequel c'est défini, mais sans ça, ça ne veut rien dire. Si d'autres commentaires n'avaient pas porté sur des prolongations de sommations elles aussi unusuelles, je pense que j'aurais clairement dit que c'est faux (sous-entendu avec les mathématiques usuelles).
Dans un anneau oui. Sauf que là, ton x n'est pas défini : ce n'est pas un entier, ni une série convergente. L'addition n'est pas définie non plus et donc parler d'un résultat égal à 0 n'a pas de sens. A partir de là, c'est dur d'appliquer une quelconque logique.
J'essaye de comprendre d'où vient le résultat 9999..999 =-1. Comme tu parlais de complément à 2, je me suis dit que tu es parti du principe que 111111…1 = -1 dans cette implémentation et que tu as transposé ça dans la notation usuelle en prenant 9 à la place du 1. Et il y a plusieurs erreurs à ça dont l'une qui consiste à mélanger les notations.
[^] # Re: et dans l'autre sens ?
Posté par NicolasP . En réponse au journal [HS] combien fait 0,12 à l'infini ?. Évalué à 3.
Rajouter des 9 devant crée une série divergente. Dire d'en rajouter à l'infini n'a donc pas de sens si tu ne précises pas comment faire. Donc tu peux dire que chez toi, par définition, ça vaut -1, c'est tout aussi vrai et intéressant que si moi je dis que ça vaut 42 ou que quelqu'un dit que ça vaut les numéros du loto de demain.
Non.
1) La représentation en complément à 2 porte sur un nombre fixes de chiffres, on ne peut pas en rajouter à l'infini.
2) Cette convention d'écriture est différente de l'usuelle. "-1" usuelle s'écrit "11111….1111" en complément à 2. Ca ne veut absolument pas dire qu'il y a une quelconque relation entre "111111…..1111" en écriture usuelle et "-1" en écriture usuelle.
C'est un peu comme si je disais que 4 en base 10, ça vaut 100 en base 2 et que du coup 4 est égal à 100 tout le temps. Ce sont deux notations différentes, qui ne doivent pas être mélangées.
3) Le principe d'utiliser le complément pour les nombres négatifs fait que ça simplifie l'addition d'entier tant que tu restes dans la plage qui peut être représentée.
Ça ne découle pas d'une quelconque propriété mathématique qui dirait que si tu rajoutes suffisamment de chiffres tu obtiens -1
[^] # Re: J'ai lu que le titre mais...
Posté par NicolasP . En réponse au lien Il y aurait de l'énergie dans le vide. Évalué à 4.
Super-sommation oui, mais dans son billet, David Louapre démontre qu'il n'existe pas de super-sommation à la fois stable, linéaire et régulière pour 1+2+3+… Du coup, faire cette somme a au final peu d'intérêt et l'utiliser pour un calcul physique est bien un tour de passe passe.
[^] # Re: J'ai lu que le titre mais...
Posté par NicolasP . En réponse au lien Il y aurait de l'énergie dans le vide. Évalué à 2. Dernière modification le 16 juillet 2023 à 10:46.
En fait ce n'est pas le cas. Les calculs sur l'énergie du vide se font sans ce tour de passe-passe. Il se trouve juste que si tu admets que la somme vaut -1/12 , tu peux les faire plus rapidement/facilement et arriver au même résultat.
Ça fait beaucoup parler, mais au final ça ne prouve rien du tout. Si j'admets que 0=1, je peux faire les calculs encore plus rapidement.
[^] # Re: 0,18................... ?
Posté par NicolasP . En réponse au journal [HS] combien fait 0,12 à l'infini ?. Évalué à 2.
Aujourd'hui, le "tour" de l'univers observable c'est grosso modo 3*10 ⁵⁴. Si on considère que le voyage consiste à faire le tour d'aujourd'hui (en étant magiquement téléporté dessus à la vitesse qui va bien), le temps nécessaire dans le référentiel d'un terrier, c'est
tout simplement t=3*1054/v. En prenant v=0.99c, c'est grosso modo 1046 s, soit 2*1028 fois le temps écoulé depuis le big bang.
Si le voyage se déroulait en ligne droite à vitesse constante, le temps dans le référentiel du voyageur serait donné par la transformation de Lorentz. Avec v=0,99c, le facteur de Lorentz vaut environ 7. Le voyage mettrait donc 7 fois moins de temps.
Si le voyage se déroule en cercle, le calcul dépasse mes compétences. Mais vu le rayon de courbure de la trajectoire, ça ne me surprendrait pas que ça ne change pas grand chose au résultat.