Sécurité info - Page 40

Bah si justement, c'est bien "toto" qui va le recevoir, c'est tout l'intérêt du système.

SAUF QUE dans les sites vraiment mal foutus ou t'aimerais bien donner toto+spam@truc.com, ben le site est suffisamment mal foutu pour INTERDIRE le foutu + dans le champ email. ca m'est déja arrivé plusieurs fois.

Bah je viens de tester :
Le serveur mail du boulot rejette [MonAdresse]+test@domaine.tld en disant que ça n'existe pas
Le serveur mail de LaPoste.net ne semble pas gérer ça non plus

A priori, ce n'est pas dans la norme (le + semble simplement être un caractère valide qui ne devrait pas être rejeté), mais c'est un truc géré par un certain nombre de serveurs (et pas par tous).

Ah, je pensais que c'était supporté de façon bien plus générale

Pour info la RFC est ici : https://tools.ietf.org/html/rfc5233

Pour moi, c’est dans la norme mais rarement autorisé.

Je suis plutôt d'accord avec Zeph (./1153), le problème vient de l'absence de vérification de l'adresse lors de l'inscription ou de son changement. En fait, on pourrait reproduire l'arnaque avec une autre adresse de la personne. Les gens ont souvent plusieurs adresses et lorsque l'une d'entre elles est utilisée pour un compte, alors il suffit de fournir une autre adresse de la même personne. Avec un peu de chance, la victime ne se souviendra pas de l'adresse qu'elle a utilisée ou ne fera pas attention et entrera le numéro de sa carte.
La sécurité basée sur l'unicité du compte pour une adresse me semble mauvaise et implique l'unicité du compte pour une adresse Pourquoi ne pourrait-on pas avoir plusieurs comptes sur ce site ? Cela dit, je ne sais pas si ça pourrait être utile.

Je ne trouve rien de natif chez postfix, ou sendmail, seulement a coup de script externe.

Ce n'est pas un standard de fait (meme si plus ou moins standardisé par une RFC)

J'ai utilisé cette technique sans le moindre soucis avec gmail et le portail de Nintendo pour me créer mes 3 comptes eshop sur la Switch. Ainsi j'ai accès aux trois eshop.
3 boites email ça aurait été chiant à suivre.

Gmail est tout sauf standard

Godzil (./1177) :
Je ne trouve rien de natif chez postfix, ou sendmail, seulement a coup de script externe.

Ce n'est pas un standard de fait (meme si plus ou moins standardisé par une RFC)

Il semblerait que sendmail supporte cette feature, je n'ai pas essayé : https://byrnejb.wordpress.com/2010/09/17/using-the-plus-addressing-feature-with-sendmail-and-cyrus-imapd/

Sinon je viens également de tester avec une installation Postfix standard et ça fonctionne parfaitement. Cerise sur le gâteau : quand on configure une redirection il conserve les labels, par exemple si "a@machin.com" redirige vers "b@truc.com" alors un mail envoyé à "a+label@machin.com" sera transféré vers "b+label@truc.com".

Au boulot comme chez LaPoste.net, le service utilisé est Zimbra (soit sous forme d'appliance comme chez nous, soit - j'imagine - dans une version plus musclée chez LaPoste.net).
A priori, c'est supporté, mais ça doit être activé pour que ça fonctionne : https://wiki.zimbra.com/wiki/Plus_Addressing

postfix le supporte puisque ca marche chez moi.

Je sais pas, ca n'a pas l'air si simple pour sendmail (pas le temps de lire et comprendre en detail la page pour l'instant)

Je testerais pour postfix c'est ce qui est sur mon serveur de memoire (avec la config de base)

superbe juste

Le retour de Spectre : de nouvelles failles ont été trouvées :
https://www.heise.de/ct/artikel/Exclusive-Spectre-NG-Multiple-new-Intel-CPU-flaws-revealed-several-serious-4040648.html

C'était attendu qu'il y en ait plus que 3, mais un passage direct en quelques mois de 3 à 11 failles publiquement connues veut dire que ça ne va probablement pas s'arrêter là...
Beaucoup de particuliers ne vont pas appliquer les mises à jour, certains ne pouvant de toute façon pas le faire faute d'upgrades du BIOS fournis par les fabricants pour des CM un peu plus anciennes.
Chez les professionnels, une nouvelle fois, on n'aura pas les jours qu'il faut pour appliquer les mises à jour de sécurité comme nous le demanderont urgemment les équipes sécurité (si nous en avons). Ca ne serait pas amusant sinon

Je viens de découvrir un truc assez dingue : apparemment au Royaume-Uni et dans certains autres pays, quand on est appelé sur une ligne fixe et qu'on raccroche mais que l'appelant ne raccroche pas, la communication n'est pas coupée immédiatement, mais après un timeout de 10 secondes à 3 minutes (!).
Ça a été utilisé par des escrocs qui appelaient les gens en disant "allô c'est votre banque, veuillez rappeler immédiatement le numéro habituel de votre agence", attendaient que la personne raccroche puis décroche, envoyaient une fausse tonalité, attendaient que la personne compose le numéro (dans le vide), et se faisaient passer ensuite pour la banque.

Sur le coup je pensais que c'était un journaliste qui avait mal compris, mais il y a au moins une banque qui a mis en ligne un avertissement à ce sujet, et des gens ont confirmé que c'était réel :
https://secure.cbonline.co.uk/media/news-releases/2012/phone-scam-alert
https://security.stackexchange.com/questions/100268/does-hanging-up-on-a-uk-landline-call-not-terminate-the-connection

La vache c'est méga moche

Il m'est déjà arrivé (en France) que la communication ne soit pas coupée après avoir raccroché, mais ce n'était pas systématique ; par contre je ne sais pas si c'était un souci de combiné, de réseau, de timeout ou de je ne sais quoi (ça m'est arrivé en raccrochant pour décrocher immédiatement après et faire un nouveau numéro, alors que mon interlocuteur n'avait pas encore pris le temps de raccrocher).

Il me semble qu'il y a une notion de timeout sur le reseau francais aussi si le raccrochage n'est pas detecté correctement

Nil (./1190) :
Il m'est déjà arrivé (en France) que la communication ne soit pas coupée après avoir raccroché, mais ce n'était pas systématique ; par contre je ne sais pas si c'était un souci de combiné, de réseau, de timeout ou de je ne sais quoi (ça m'est arrivé en raccrochant pour décrocher immédiatement après et faire un nouveau numéro, alors que mon interlocuteur n'avait pas encore pris le temps de raccrocher).

Pour avoir eu le problème pendant des années chez mes grands parents je peux te dire que c'était lié à un défaut d'installation de FT (problème de masse sur un répartiteur externe si je ne dis aps de connerie (j'étais ado quand c'est arrivé donc pas de souvenirs vivides)) et ça concernait un pâté de maison. Ils ont mis des années à résoudre l'incident mais au final ils y sont arrivé

Faille qui concerne les mails chiffrés (OpenPGP, S/MIME) :
https://efail.de/

oui bon attention avec celle la hein, elle serait corrigée depuis 20 ans, et les découvreurs auraient un peu essayé de faire du mega drama genre pétard mouillé:

GnuPG has an official statement out. (ObDisclosure: I was the principal author.) 1/

— Robert J. Hansen (@robertjhansen) May 14, 2018

Called it. This is beyond stupid. And yet *another* example of clickbait, shitty disclosure, and other nonsense from academic security research. Shame. https://t.co/AO9tiWi4Op pic.twitter.com/STXrDaKeMO

— Hector Martin (@marcan42) May 14, 2018

Did I fucking call it? pic.twitter.com/lneoTVnzMv

— Hector Martin (@marcan42) May 14, 2018

ce sont donc des failles des clients email.

Ah oui j'ai pas précisé, mais effectivement la faille est dans les clients mail, pas dans le chiffrement en lui-même. Ceci dit ça reste dangereux.

comme ils disent ca fait un peu quelques années qu'on le sait, que les emails html sémal

Certes, mais de là à laisser fuiter le contenu en clair...

enfin, si je comprends bien, il faut que ce soit l'expéditeur qui forge le HTML pour faire fuiter le message qu'il envoie, non ?

C’est pour tenter de casser la Clef privé qu’ils font ça

Pour autant que je le comprenne, le but n'est pas de casser la clé, mais d'obtenir le contenu déchiffré d'un message chiffré qui a été intercepté (en hackant une boîte mail, avec une attaque man-in-the-middle, peu importe).
L'attaque consiste à modifier le mail pour ajouter le contenu HTML malicieux, et à le renvoyer au destinataire légitime. Le client mail de ce dernier déchiffre le message, et paf.

Je ne pense pas que ça aide significativement à en déduire la clé privée, il me semble que les algos de crypto modernes sont résistants aux attaques basée sur la connaissance d'un même contenu en clair et en version chiffrée (mais les spécialistes habituels confirmeront ou pas).