Re: [FRnOG] [MISC] Message ANSSI
Bonjour, Le 16 janv. 2015 à 22:02, Pierre Jaury pie...@jaury.eu a écrit : On 01/16/15 21:11, Emmanuel Thierry wrote: Justement si on veut de la sécurité on ne fait *pas* de NFC, parce que : * Pas ou peu de crypto, parce qu'il faut l'alimenter le bouzin, et avec le peu de puissance qu'on peut lui passer par les ondes ça va être compliqué de faire de la grosse crypto * Une attaque MITM est inévitable. Avec un peu de matos je passe à côté de toi dans le bus, et plouf, je transfère ton authentification par 3G à 200km de là. Pour l'instant ça ne vaut pas le coup pour les 20€ du paiement sans contact, mais le principe est tout à fait possible. * Pas de confirmation par l'utilisateur (et là aussi pour le paiement sans contact c'est inadmissible) Donc si on veut une CNI sûre, il faut qu'elle soit en carte à puce et qu'elle demande un PIN à l'utilisateur. A moitié d'accord. NFC dans sa spec actuelle ne verra peut-être pas 2020, mais on fait de l'ECC-320 sans difficulté, pareil pour RSA ; c'est suffisant pour les prochaines années et la puissance transmise n'est virtuellement pas limitée pour de futures technos. Le media importe donc peu de ce côté. Y compris pour un périphérique passif ? Je ne mets pas en cause la spécification en elle-même, je ne doute pas qu'elle prévoit des évolutions crypto. Je veux bien qu'un téléphone soit capable de faire des opérations de crypto complexes (lorsqu'il est utilisé en périphérique NFC) mais est-ce qu'un périphérique passif alimenté par les ondes de son pair est capable de faire les mêmes opérations de crypto ? Par contre, il faut (que ce soit pour le paiement ou quelque device sans contact que ce soit) une validation physique, sur le device et non sur le terminal. Ca travaille déjà sérieusement à du NFC sur ISO7810 avec écran embarqué et bouton de confirmation de la transaction et je ne vois pas de limite physique à porter ça sous forme de pin ou autre authentification. Toujours sans alimentation autonome ? ;) Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/
RE : [FRnOG] [MISC] Message ANSSI
Je partage cette analyse (alimentation ? périphérique passif qui perturbe un champs ce qui permet sa detection). Dans le même ordre d'idée, dans nos villes : smartcities (c'est à la mode) : http://pro.01net.com/editorial/567581/sigfox-deploie-un-reseau-radio-bas-debit-pour-le-machine-to-machine/ l'article date mais idée qui avance et services existent : s'appuyer sur des objets peu intelligents, ne nécessitant pas de réseaux complexes (l'opposé de l'approche Linky pour les compteurs énergie). En revanche, big data assuré ! Par exemple enfouir dans les places de parking aérien des objets qui vont communiquer 10 ans. Indiquent si une masse métallique est au dessus ou si place libre. Réactualisation par passage très peu fréquents d'un détecteur qui repère ce qui est actif, remplacement des défectueux. Irréaliste ? on fait bien des circuits google streetview ! même qu'au passage ils repéraient les box wifi (arrêté parait il). ... virtuellement pas limitée pour de futures technos. Le media importe donc peu de ce côté. Y compris pour un périphérique passif ? Je ne mets pas en cause la spécification en elle-même, je ne doute pas qu'elle prévoit des évolutions crypto. Je veux bien qu'un téléphone soit capable de faire des opérations de crypto complexes (lorsqu'il est utilisé en périphérique NFC) mais est-ce qu'un périphérique passif alimenté par les ondes de son pair est capable de faire les mêmes opérations de crypto ? Par contre, il faut (que ce soit pour le paiement ou quelque device sans contact que ce soit) une validation physique, sur le device et non sur le terminal. Ca travaille déjà sérieusement à du NFC sur ISO7810 avec écran embarqué et bouton de confirmation de la transaction et je ne vois pas de limite physique à porter ça sous forme de pin ou autre authentification. Toujours sans alimentation autonome ? ;) Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
On Fri, 2015-01-16 at 01:48 +0100, Emmanuel Thierry wrote: Le 15 janv. 2015 à 14:11, Florent Daigniere a écrit : On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote: Bonjour, L'ANSSI vous parle http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html --- La question c'est de savoir si ça vaut la peine de les écouter :) Certaines des recommandations tombent sous le sens.. d'autre sont complètement farfelues Au contraire ça me parait très équilibré, avec une approche aussi bien sur l'hébergement que sur le code en lui même. Le seul problème que je vois est qu'il ne sera probablement jamais lu par les gens qui en ont vraiment besoin... ça frustre les spécialistes et ça n'aide pas les gens qui n'y connaissent rien. Les recommendations devraient être plus simple: R19 - Les identifiants de session doivent être imprévisibles aléatoires il faut des notions de statistiques pour comprendre entropie il faut des notions de théorie de l'information R20 - TLS de partout Exemples : R19 Les identifiants de session doivent être aléatoires et d’une entropie d’au moins 128 bits. - 128bits pour une attaque en ligne... c'est beaucoup et complètement arbitraire Il faut bien placer une limite, qui par ailleurs soit durable dans le temps. En même temps 128bits d'entropie ce n'est pas vraiment compliqué à générer. Là n'est pas la question; quand on est aussi précis que ça dans une recommendation, qu'il y ait une bonne raison derrière. Là il n'y en a pas et le vocabulaire utilisé est un vocabulaire de spécialiste. Le bon contrôle contre les identifiants de session trop courts c'est de limiter la durée de vie de celle ci. R20 Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès lors que l’on associe une session à des privilèges particuliers. - ce n'est pas réducteur du tout comme approche. C'est bien connu, l'authentification ça ne sert que dans un sens ;) L'idée dans ce cas est surtout de protéger les credentials de l'utilisateur et la confidentialité des informations. Et c'est bien ce que je reproche a cette recommendation. TLS ça sert avant tout a authentifier le site auquel on est connecte. TLS ça se déploie sur tout le site, pas uniquement post-authentification (pour la raison mentionnée au dessus) Je crois que c'est clair dans le texte : En chiffrant les communications au moyen de TLS, on empêche un attaquant qui « écoute » le réseau d’apprendre les identifiants de sessions. Certains sites ont recours à TLS uniquement pour la page d’authentification. Cela protège certes le mot de passe mais pas l’identifiant de session. Par ailleurs ils parlent des certificats client en R4, mais pour l'administration seulement, parce que ça parait compliqué de faire installer par chaque utilisateur un certificat. Cordialement Emmanuel Thierry signature.asc Description: This is a digitally signed message part
Re: [FRnOG] [MISC] Message ANSSI
Salut Le 16/01/2015 12:06, Florent Daigniere a écrit : Les recommendations devraient être plus simple: Y'a du cou plus récent comme guide/reco. 16 janvier 2015 http://www.ssi.gouv.fr/fr/menu/actualites/proteger-son-site-internet-des-cyberattaques.html Protéger son site Internet des cyberattaques Avec Fiche des bonnes pratiques en cybersécurité Fiche d’information pour les administrateurs de site Pour moi ça reste de bon outils de sensibilisations (et je connais pas mal de tpe/pme qui devrait effectivement lire ceci). M -- Manu Jacquet --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
Le certificat personnel, j’y croirai quand il sera stocké sur un truc fiable qu’on a toujours sur soi (CNI, CB, …) et transmis au PC en NFC ou autre. L’usine à gaz que c’est aujourd’hui, surtout en cas de changement d’ordinateur, ce qui dans le cas du Grand Public est rarement un évènement qui a été souhaité mais plutôt un mauvais moment à passer. La priorité du Grand Public, c’est généralement de se lamenter sur les 47654 photos des enfants qui ont été perdus dans le crash de l’ancien PC, et pas trop de savoir comment on migre le certificat. Le 16 janv. 2015 à 15:39, Wallace wall...@morkitu.org a écrit : Le 16/01/2015 08:50, nico...@ncartron.org a écrit : On Fri Jan 16 01:48:21 2015 GMT+0100, Emmanuel Thierry wrote: [...] Par ailleurs ils parlent des certificats client en R4, mais pour l'administration seulement, parce que ça parait compliqué de faire installer par chaque utilisateur un certificat. C'est ce que faisait le site des impôts il y a quelques années, bonjour la galère en cas de réinstallation d'OS =) Heureusement ce n'est plus le cas. C'est bête mais je préférais ce système. Même au RIPE qui s'adresse à des personnes techniques à du le retirer. Sauvegarder un fichier et son mot de passe dans un trousseau et correctement le sauvegarder si des gens techniques savent pas faire ça de nos jours j'ai comme un doute sur leurs mots de passes. Ils doivent être tous facilement mémorisables donc faibles. Après que le tout à chacun trouve le certificat trop dur à installer / sauvegarder bon à la rigueur mais au moins qu'on laisse le choix aux gens. J'aimerais tellement un certificat pour mon interface banque / opérateur ... plutôt que ces mots de passe visuels où tout le monde derrière toi le voit ou la personne qui est volontairement à côté de toi pour travailler sur un élément va facilement le retenir à force de t'y connecter ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
Le 16/01/2015 16:14, Wallace a écrit : Le 16/01/2015 16:02, David Ponzone a écrit : Le certificat personnel, j’y croirai quand il sera stocké sur un truc fiable qu’on a toujours sur soi (CNI, CB, …) et transmis au PC en NFC ou autre. Ce jour là j'arrêterais les certificats alors. Un objet fiable qu'on a sur soit oui mais où j'ai totalement le contrôle sinon non. Ma CB ou CNI c'est juste noway. Je précise car on va forcément poser la question. Si c'est un tiers qui fait ce token alors je n'ai pas confiance car rien ne me dit qu'il ne garde pas une copie des clefs générées avant de les stocker. Qu'on ne me parle pas de tiers de confiance (état, entreprise à certificat, association oeuvrant pour notre bonheur), non je n'ai pas confiance. C'est comme faire des clefs chez le serrurier et qu'il en fasse une copie pour lui tout en ayant votre adresse. Après tout personne ne génère de clef GPG ou SSH par des tiers alors pourquoi dans ce cas là passer par quelqu'un d'autre? signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Message ANSSI
Le 16 janv. 2015 à 16:02, David Ponzone david.ponz...@gmail.com a écrit : Le certificat personnel, j’y croirai quand il sera stocké sur un truc fiable qu’on a toujours sur soi (CNI, CB, …) et transmis au PC en NFC ou autre. L’usine à gaz que c’est aujourd’hui, surtout en cas de changement d’ordinateur, ce qui dans le cas du Grand Public est rarement un évènement qui a été souhaité mais plutôt un mauvais moment à passer. La priorité du Grand Public, c’est généralement de se lamenter sur les 47654 photos des enfants qui ont été perdus dans le crash de l’ancien PC, et pas trop de savoir comment on migre le certificat. Tellement vrai ce que tu dis... :) Le jour ou pourrais avoir son certificat numérique ayant la même fiabilité qu'une CNI (je ne dis pas la même sécurité hein, mais fiabilité)... Là on pourras parler de certificat personnel. Pour l'instant on n'as rien qui soit faible, facile pour Mme Michu, donc c'est mort. Surtout que lorsqu'on pose la question t'as sauvegardé tes trucs? lorsqu'on vient te voir avec puisque tu t'y connais en informatique...?, la réponse est non à 80% (bon on a gagné 10% depuis 10 ans, avant c'est 90% voire 99%...); donc le certificat à la con (vu de mme michu) évidement qu'il n'est jamais sauvegardé... Xavier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
Bonjour, Il y avait eu une tentative de mettre en place une CNIe. Le Conseil Constitutionnel l'avait déclarée contraire à la Constitution au motif que la loi n'était pas assez protectrice de la vie privée (qui est un principe à valeur constitutionnelle (CC 18/01/1995)): 14. Considérant que l'article 3, d'une part, permet que la carte nationale d'identité comprenne des « fonctions électroniques » permettant à son titulaire de s'identifier sur les réseaux de communication électroniques et de mettre en oeuvre sa signature électronique et, d'autre part, garantit le caractère facultatif de ces fonctions ; que les dispositions de l'article 3 ne précisent ni la nature des « données » au moyen desquelles ces fonctions peuvent être mises en oeuvre ni les garanties assurant l'intégrité et la confidentialité de ces données ; qu'elles ne définissent pas davantage les conditions dans lesquelles s'opère l'authentification des personnes mettant en oeuvre ces fonctions, notamment lorsqu'elles sont mineures ou bénéficient d'une mesure de protection juridique ; que, par suite, le législateur a méconnu l'étendue de sa compétence ; qu'il en résulte que l'article 3 doit être déclaré contraire à la Constitution ; http://www.conseil-constitutionnel.fr/decision/2012/2012-652-dc/decision-n-2012-652-dc-du-22-mars-2012.105165.html Le communiqué de presse est également intéressant : http://www.conseil-constitutionnel.fr/conseil-constitutionnel/francais/les-decisions/acces-par-date/decisions-depuis-1959/2012/2012-652-dc/communique-de-presse.105166.html Voir également le rapport annuel du Conseil d'Etat au sujet du numérique et des droits fondamentaux : http://www.ladocumentationfrancaise.fr/var/storage/rapports-publics/144000541/.pdf Cordialement, Raphaël Le 16/01/2015 16:14, Wallace a écrit : Le 16/01/2015 16:02, David Ponzone a écrit : Le certificat personnel, j’y croirai quand il sera stocké sur un truc fiable qu’on a toujours sur soi (CNI, CB, …) et transmis au PC en NFC ou autre. Ce jour là j'arrêterais les certificats alors. Un objet fiable qu'on a sur soit oui mais où j'ai totalement le contrôle sinon non. Ma CB ou CNI c'est juste noway. Par contre que ça reste sur mes ordis où tous les disques sont chiffrés ça me pose pas de soucis. On l'utilise en interne pour accéder à des interfaces propres aux employés, tout le monde adore car plus de mot de passe à retenir / copier-coller. Révoquer un accès c'est juste super pratique pour le faire sur plusieurs interfaces en même temps. Par contre sur nos téléphones pour le moment on ne franchit pas le pas car on a pas entièrement la main dessus et les navigateurs mobiles aiment pas notre autorité de certification privée. L’usine à gaz que c’est aujourd’hui, surtout en cas de changement d’ordinateur, ce qui dans le cas du Grand Public est rarement un évènement qui a été souhaité mais plutôt un mauvais moment à passer. La priorité du Grand Public, c’est généralement de se lamenter sur les 47654 photos des enfants qui ont été perdus dans le crash de l’ancien PC, et pas trop de savoir comment on migre le certificat. Le coup des photos c'est malheureux mais faut que tout le monde y passe pour qu'il accepte les conseils de sauvegarde. Après que ça soit photo / doc super important / certificat / whatelse de valeur le restaurer n'est pas plus compliqué que de double clic dessus (en tout cas avec Firefox, j'ai pas testé les autres). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
Le problème de la CNI avec de la crypto embarquée tient surtout à l'usage qui en est fait. Si c'est correctement encadré, que les process sont propres, pour de la pure authentification institutionnelle (c'est ce qui importe à Mme Michu pour 95% de son usage de l'informatique, les mots de passe boîte mail Orange et Facebook sont les mêmes à 6 chiffres, le reste c'est payer ses impôts et consulter ses remboursements de sécu), le respect de la vie privée n'entre pas tellement en jeu et la sécurité n'en est que renforcée (j'aime bien recevoir mes mots de passe par la poste, mais va falloir arrêter un jour). Par contre, qui dit payer ses impôts avec sa CNI en 2015 (c'est déjà le cas dans plusieurs pays si je ne raconte pas de connerie) dit s'identifier auprès d'EDF, des gros FAI et de tous ceux qui auront le poids de négocier des assouplissements d'ici à 2016, c'est aussi envisager qu'en 2018 les paquets IP (v6 ? :D) pas signés deviendront suspects. J'avais déjà envisagé et causé un peu dans le milieu carte à puce d'un système dont l'utilisateur a le contrôle : carte à microproc quelconque (JCOP ou qui sait un OS national :) achetable en grande surface (ou un poil moins libéral, mais si possible pas trop gérée techniquement par le gouvernement) et où l'utilisateur peut autoriser l'installation des applications qu'on lui soumet. Il va chercher sa CNI à la mairie ? il n'a qu'à insérer sa carte dans la machine, saisir le PIN d'installation d'appli et les certifs officiels sont chargés. Il vient de s'abonner à la FNAC ou d'acheter un navigo ? même topo. Bien entendu, le schéma de gestion d'applets sur le carte devrait différer des classiques d'aujourd'hui qui ne sont pas trop orientés multiples applis de plusieurs niveaux de sécu, mais c'est tout à fait envisageable techniquement. Sur le plan utilisation par contre, pour le moment on m'a surtout ri au nez :) Alerte au passage : ce fil est à la dérive, heureusement qu'on est sur misc. On 01/16/15 16:25, Raphaël Stehli wrote: Bonjour, Il y avait eu une tentative de mettre en place une CNIe. Le Conseil Constitutionnel l'avait déclarée contraire à la Constitution au motif que la loi n'était pas assez protectrice de la vie privée (qui est un principe à valeur constitutionnelle (CC 18/01/1995)): 14. Considérant que l'article 3, d'une part, permet que la carte nationale d'identité comprenne des « fonctions électroniques » permettant à son titulaire de s'identifier sur les réseaux de communication électroniques et de mettre en oeuvre sa signature électronique et, d'autre part, garantit le caractère facultatif de ces fonctions ; que les dispositions de l'article 3 ne précisent ni la nature des « données » au moyen desquelles ces fonctions peuvent être mises en oeuvre ni les garanties assurant l'intégrité et la confidentialité de ces données ; qu'elles ne définissent pas davantage les conditions dans lesquelles s'opère l'authentification des personnes mettant en oeuvre ces fonctions, notamment lorsqu'elles sont mineures ou bénéficient d'une mesure de protection juridique ; que, par suite, le législateur a méconnu l'étendue de sa compétence ; qu'il en résulte que l'article 3 doit être déclaré contraire à la Constitution ; http://www.conseil-constitutionnel.fr/decision/2012/2012-652-dc/decision-n-2012-652-dc-du-22-mars-2012.105165.html Le communiqué de presse est également intéressant : http://www.conseil-constitutionnel.fr/conseil-constitutionnel/francais/les-decisions/acces-par-date/decisions-depuis-1959/2012/2012-652-dc/communique-de-presse.105166.html Voir également le rapport annuel du Conseil d'Etat au sujet du numérique et des droits fondamentaux : http://www.ladocumentationfrancaise.fr/var/storage/rapports-publics/144000541/.pdf Cordialement, Raphaël Le 16/01/2015 16:14, Wallace a écrit : Le 16/01/2015 16:02, David Ponzone a écrit : Le certificat personnel, j’y croirai quand il sera stocké sur un truc fiable qu’on a toujours sur soi (CNI, CB, …) et transmis au PC en NFC ou autre. Ce jour là j'arrêterais les certificats alors. Un objet fiable qu'on a sur soit oui mais où j'ai totalement le contrôle sinon non. Ma CB ou CNI c'est juste noway. Par contre que ça reste sur mes ordis où tous les disques sont chiffrés ça me pose pas de soucis. On l'utilise en interne pour accéder à des interfaces propres aux employés, tout le monde adore car plus de mot de passe à retenir / copier-coller. Révoquer un accès c'est juste super pratique pour le faire sur plusieurs interfaces en même temps. Par contre sur nos téléphones pour le moment on ne franchit pas le pas car on a pas entièrement la main dessus et les navigateurs mobiles aiment pas notre autorité de certification privée. L’usine à gaz que c’est aujourd’hui, surtout en cas de changement d’ordinateur, ce qui dans le cas du Grand Public est rarement un évènement qui a été souhaité mais plutôt un mauvais moment à passer. La priorité du Grand Public, c’est
Re: [FRnOG] [MISC] Message ANSSI
Le 16/01/2015 17:00, Pierre Jaury a écrit : Alerte au passage : ce fil est à la dérive, heureusement qu'on est sur misc. Non, t'inquiète pas, c'est pas politique ;) -- Manu Jacquet --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
On Friday 16 January 2015 16:18:39 Wallace - wall...@morkitu.org wrote: Le 16/01/2015 16:14, Wallace a écrit : Le 16/01/2015 16:02, David Ponzone a écrit : Le certificat personnel, j’y croirai quand il sera stocké sur un truc fiable qu’on a toujours sur soi (CNI, CB, …) et transmis au PC en NFC ou autre. Ce jour là j'arrêterais les certificats alors. Un objet fiable qu'on a sur soit oui mais où j'ai totalement le contrôle sinon non. Ma CB ou CNI c'est juste noway. Je précise car on va forcément poser la question. Si c'est un tiers qui fait ce token alors je n'ai pas confiance car rien ne me dit qu'il ne garde pas une copie des clefs générées avant de les stocker. Qu'on ne me parle pas de tiers de confiance (état, entreprise à certificat, association oeuvrant pour notre bonheur), non je n'ai pas confiance. C'est comme faire des clefs chez le serrurier et qu'il en fasse une copie pour lui tout en ayant votre adresse. Après tout personne ne génère de clef GPG ou SSH par des tiers alors pourquoi dans ce cas là passer par quelqu'un d'autre? L'analogie du serrurier malhonnête est mal choisie car elle se transpose mal au monde du numérique. D'abord parce que personne ne pense qu'une serrure ne protège contre le carreau pété qui permets de passer par la fenêtre et ensuite parce qu'avec un double de clé on peut entrer sans effraction mais la disparition de l'écran plat 120cm du salon se remarque rapidement. Tandis que dans le monde numérique et de la sécurité, d'une part la clé c'est aussi bien la serrure, que la porte, que les murs, que les carreaux, c'est toute la maison et d'autre part avec une copie de la clé il est possible de dupliquer tout le contenu de la maison sans que ça saute aux yeux. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
Le 16 janv. 2015 à 16:02, David Ponzone a écrit : Le certificat personnel, j’y croirai quand il sera stocké sur un truc fiable qu’on a toujours sur soi (CNI, CB, …) et transmis au PC en NFC ou autre. Justement si on veut de la sécurité on ne fait *pas* de NFC, parce que : * Pas ou peu de crypto, parce qu'il faut l'alimenter le bouzin, et avec le peu de puissance qu'on peut lui passer par les ondes ça va être compliqué de faire de la grosse crypto * Une attaque MITM est inévitable. Avec un peu de matos je passe à côté de toi dans le bus, et plouf, je transfère ton authentification par 3G à 200km de là. Pour l'instant ça ne vaut pas le coup pour les 20€ du paiement sans contact, mais le principe est tout à fait possible. * Pas de confirmation par l'utilisateur (et là aussi pour le paiement sans contact c'est inadmissible) Donc si on veut une CNI sûre, il faut qu'elle soit en carte à puce et qu'elle demande un PIN à l'utilisateur. Cordialement Emmanuel Thierry L’usine à gaz que c’est aujourd’hui, surtout en cas de changement d’ordinateur, ce qui dans le cas du Grand Public est rarement un évènement qui a été souhaité mais plutôt un mauvais moment à passer. La priorité du Grand Public, c’est généralement de se lamenter sur les 47654 photos des enfants qui ont été perdus dans le crash de l’ancien PC, et pas trop de savoir comment on migre le certificat. Le 16 janv. 2015 à 15:39, Wallace wall...@morkitu.org a écrit : Le 16/01/2015 08:50, nico...@ncartron.org a écrit : On Fri Jan 16 01:48:21 2015 GMT+0100, Emmanuel Thierry wrote: [...] Par ailleurs ils parlent des certificats client en R4, mais pour l'administration seulement, parce que ça parait compliqué de faire installer par chaque utilisateur un certificat. C'est ce que faisait le site des impôts il y a quelques années, bonjour la galère en cas de réinstallation d'OS =) Heureusement ce n'est plus le cas. C'est bête mais je préférais ce système. Même au RIPE qui s'adresse à des personnes techniques à du le retirer. Sauvegarder un fichier et son mot de passe dans un trousseau et correctement le sauvegarder si des gens techniques savent pas faire ça de nos jours j'ai comme un doute sur leurs mots de passes. Ils doivent être tous facilement mémorisables donc faibles. Après que le tout à chacun trouve le certificat trop dur à installer / sauvegarder bon à la rigueur mais au moins qu'on laisse le choix aux gens. J'aimerais tellement un certificat pour mon interface banque / opérateur ... plutôt que ces mots de passe visuels où tout le monde derrière toi le voit ou la personne qui est volontairement à côté de toi pour travailler sur un élément va facilement le retenir à force de t'y connecter ... --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
On 01/16/15 21:11, Emmanuel Thierry wrote: Justement si on veut de la sécurité on ne fait *pas* de NFC, parce que : * Pas ou peu de crypto, parce qu'il faut l'alimenter le bouzin, et avec le peu de puissance qu'on peut lui passer par les ondes ça va être compliqué de faire de la grosse crypto * Une attaque MITM est inévitable. Avec un peu de matos je passe à côté de toi dans le bus, et plouf, je transfère ton authentification par 3G à 200km de là. Pour l'instant ça ne vaut pas le coup pour les 20€ du paiement sans contact, mais le principe est tout à fait possible. * Pas de confirmation par l'utilisateur (et là aussi pour le paiement sans contact c'est inadmissible) Donc si on veut une CNI sûre, il faut qu'elle soit en carte à puce et qu'elle demande un PIN à l'utilisateur. A moitié d'accord. NFC dans sa spec actuelle ne verra peut-être pas 2020, mais on fait de l'ECC-320 sans difficulté, pareil pour RSA ; c'est suffisant pour les prochaines années et la puissance transmise n'est virtuellement pas limitée pour de futures technos. Le media importe donc peu de ce côté. Par contre, il faut (que ce soit pour le paiement ou quelque device sans contact que ce soit) une validation physique, sur le device et non sur le terminal. Ca travaille déjà sérieusement à du NFC sur ISO7810 avec écran embarqué et bouton de confirmation de la transaction et je ne vois pas de limite physique à porter ça sous forme de pin ou autre authentification. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
R2... et on installe PulseAudio/X/... par défaut sur une distrib serveur Cordialement, Jean-Yves Le 15 janvier 2015 15:01, Stephane Martin stephane.mar...@vesperal.eu a écrit : Les milliers de sites défacés depuis lundi semblent indiquer que ce qui tombe sous le sens… n’est pas évident pour tout le monde. R3 en particulier. (Qui a mis à jour son Drupal ?) Ou R10… X-Powered-By on le voit trop souvent, avec la version exacte de PHP. R19… Le terme d’entropie est sans doute mal employé. 128bits comme *taille* du cookie de session ça semble cohérent. R20 est formulé bizarrement. L’idée générale c’est probablement que les credentials et le cookie de session passent sur un canal chiffré, et non pas en clair. Cordialement, Stéphane Le 15 janv. 2015 à 14:11, Florent Daigniere florent.daigni...@trustmatta.com a écrit : On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote: Bonjour, L'ANSSI vous parle http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html --- La question c'est de savoir si ça vaut la peine de les écouter :) Certaines des recommandations tombent sous le sens.. d'autre sont complètement farfelues Exemples : R19 Les identifiants de session doivent être aléatoires et d’une entropie d’au moins 128 bits. - 128bits pour une attaque en ligne... c'est beaucoup et complètement arbitraire R20 Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès lors que l’on associe une session à des privilèges particuliers. - ce n'est pas réducteur du tout comme approche. C'est bien connu, l'authentification ça ne sert que dans un sens ;) R24 Pour les actions sensibles, mettre en place des mécanismes permettant de s’assurer de la légitimité de la requête. - on parle de click-jacking, ... mais pas d'anti-CSRF --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
On Fri Jan 16 01:48:21 2015 GMT+0100, Emmanuel Thierry wrote: [...] Par ailleurs ils parlent des certificats client en R4, mais pour l'administration seulement, parce que ça parait compliqué de faire installer par chaque utilisateur un certificat. C'est ce que faisait le site des impôts il y a quelques années, bonjour la galère en cas de réinstallation d'OS =) Heureusement ce n'est plus le cas. -- Nicolas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
Le 15 janv. 2015 à 14:11, Florent Daigniere a écrit : On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote: Bonjour, L'ANSSI vous parle http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html --- La question c'est de savoir si ça vaut la peine de les écouter :) Certaines des recommandations tombent sous le sens.. d'autre sont complètement farfelues Au contraire ça me parait très équilibré, avec une approche aussi bien sur l'hébergement que sur le code en lui même. Le seul problème que je vois est qu'il ne sera probablement jamais lu par les gens qui en ont vraiment besoin... Exemples : R19 Les identifiants de session doivent être aléatoires et d’une entropie d’au moins 128 bits. - 128bits pour une attaque en ligne... c'est beaucoup et complètement arbitraire Il faut bien placer une limite, qui par ailleurs soit durable dans le temps. En même temps 128bits d'entropie ce n'est pas vraiment compliqué à générer. R20 Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès lors que l’on associe une session à des privilèges particuliers. - ce n'est pas réducteur du tout comme approche. C'est bien connu, l'authentification ça ne sert que dans un sens ;) L'idée dans ce cas est surtout de protéger les credentials de l'utilisateur et la confidentialité des informations. Je crois que c'est clair dans le texte : En chiffrant les communications au moyen de TLS, on empêche un attaquant qui « écoute » le réseau d’apprendre les identifiants de sessions. Certains sites ont recours à TLS uniquement pour la page d’authentification. Cela protège certes le mot de passe mais pas l’identifiant de session. Par ailleurs ils parlent des certificats client en R4, mais pour l'administration seulement, parce que ça parait compliqué de faire installer par chaque utilisateur un certificat. Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote: Bonjour, L'ANSSI vous parle http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html --- La question c'est de savoir si ça vaut la peine de les écouter :) Certaines des recommandations tombent sous le sens.. d'autre sont complètement farfelues Exemples : R19 Les identifiants de session doivent être aléatoires et d’une entropie d’au moins 128 bits. - 128bits pour une attaque en ligne... c'est beaucoup et complètement arbitraire R20 Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès lors que l’on associe une session à des privilèges particuliers. - ce n'est pas réducteur du tout comme approche. C'est bien connu, l'authentification ça ne sert que dans un sens ;) R24 Pour les actions sensibles, mettre en place des mécanismes permettant de s’assurer de la légitimité de la requête. - on parle de click-jacking, ... mais pas d'anti-CSRF signature.asc Description: This is a digitally signed message part
Re: [FRnOG] [MISC] Message ANSSI
Les milliers de sites défacés depuis lundi semblent indiquer que ce qui tombe sous le sens… n’est pas évident pour tout le monde. R3 en particulier. (Qui a mis à jour son Drupal ?) Ou R10… X-Powered-By on le voit trop souvent, avec la version exacte de PHP. R19… Le terme d’entropie est sans doute mal employé. 128bits comme *taille* du cookie de session ça semble cohérent. R20 est formulé bizarrement. L’idée générale c’est probablement que les credentials et le cookie de session passent sur un canal chiffré, et non pas en clair. Cordialement, Stéphane Le 15 janv. 2015 à 14:11, Florent Daigniere florent.daigni...@trustmatta.com a écrit : On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote: Bonjour, L'ANSSI vous parle http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html --- La question c'est de savoir si ça vaut la peine de les écouter :) Certaines des recommandations tombent sous le sens.. d'autre sont complètement farfelues Exemples : R19 Les identifiants de session doivent être aléatoires et d’une entropie d’au moins 128 bits. - 128bits pour une attaque en ligne... c'est beaucoup et complètement arbitraire R20 Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès lors que l’on associe une session à des privilèges particuliers. - ce n'est pas réducteur du tout comme approche. C'est bien connu, l'authentification ça ne sert que dans un sens ;) R24 Pour les actions sensibles, mettre en place des mécanismes permettant de s’assurer de la légitimité de la requête. - on parle de click-jacking, ... mais pas d'anti-CSRF --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Message ANSSI
On 01/15/15 15:01, Stephane Martin wrote: R19… Le terme d’entropie est sans doute mal employé. 128bits comme *taille* du cookie de session ça semble cohérent. 128 bits d'entropie c'est peut-être beaucoup demander, mais avec du hardware moderne ce n'est pas un gros souci pour l'appli moyenne. 64 bits suffisent peut-être amplement à lutter contre une attaque en ligne (et c'est de mémoire la reco du NIST), mais le double n'est pas déconnant et pas si farfelu que ça. En revanche, recommander des cookies de taille 128 bits, c'est la porte ouverte aux md5 et autres hash de contenu tout à fait prédictible (md5(microtime() quand tu nous tiens). Dixit une connaissance récemment (si, si, true story) : « pour mes cookies, je hash le username et la date, mais en sha512, donc pas de souci ». -- Pierre Jaury @ kaiyou http://kaiyou.fr/contact.html --- Liste de diffusion du FRnOG http://www.frnog.org/
