Vous savez l'informatique est un truc absolument génial qui permet de faire plein de trucs marrants et stylés, mais il y a plein de petits pirates qui veulent juste exploser des stacks for fun and profit, shaper le heap pour du code exec, voler vos cookies via des [bb code script]alert('oh no')[/bb] XSS, dumper vos bases avec des SQLinjection et même des fois s'élever en privilèges avec des vaches sales.
La question, c'est qu'est ce qu'on fait? La première solution est de dire: il suffit de bien coder et y'a pas de vulns. C'est parfaitement vrai en théorie, mais de la théorie à la pratique, il y a un gap.
Ensuite, on peut imaginer coller des protections. Prenons un exemple, pour éviter les stack buffer overflow on peut considérer strcpy harmfull (NdM: remplacement par un lien archive.org), ou alors on peut ajouter un stack canary. Quelle est la bonne solution? Est-ce qu'il y a une bonne solution?
On peut continuer à ajouter des patchs, de l'ASLR partout, des canaris, du PIE, des compilos intelligents, etc.. On peut changer de langage de prog pour espérer améliorer les choses, mais est-ce une fuite en avant? On sait qu'il y aura toujours un pirate plus fort que le meilleur des programmeurs: il lui suffit d'une seule faille pour faire effondrer un chateau alors qu'une armée de programmeurs doit être coordonnée et au top en permanence en protégeant tous les points d'entrées.
Je lisais l'autre jour le blog de Tavis Ormandy, et on sent une idée poindre lorsqu'on lit ces posts. Globalement, il est contre les 'reproducible builds' car ça se contourne. Il est contre le 2FA car c'est de la fausse sécurité. Il est contre les antivirus car ça fait du code qui tourne en plus sur une machine, donc ça augmente la surface d'attaque donc ça facilite la vie d'un attaquant donc un antivirus baisse la sécurité d'une machine.
Du coup, ça serait quoi la vraie sécurité? Changer d'OS? Changer de langage de programmation/compilos? Dézinguer la gestion de mémoire actuelle (code et data mélangés)? Modifier le silicium? Ajouter encore plus de barrières (ASAN/UBSAN everywhere everytime)? Tout arrêter et devenir iunfluenceur sur tiktok? Essayer de faiAAAAAAAAA@"~:\x90\x90\x90\x90\x90/bin/sh no control tty
id
uid=0(root) gid=0(root) groupes=0(root)
# HS: Il n'y a *pas* de différence
Posté par fero14041 . Évalué à 10.
Je t'arrête tout de suite:
Il est unanimement reconnu, depuis au moins les débuts de l'informatique, qu'il n'y a pas de différence entre la théorie et la pratique!
(du moins en théorie)
[^] # Re: HS: Il n'y a *pas* de différence
Posté par kalimba . Évalué à 4.
En fait c'est parfaitement faux en théorie, demandez a Alan Turing
# Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par towanda . Évalué à 10.
Juste pour préciser que Tavis Ormandy critique le SMS en second facteur (c'est vrai, on peut amener l'utilisateur à taper son OTP sur un site compromis après tout), mais pas le 2FA en général. Je le cite "You can either educate your users on how to use a password manager, or deploy U2F, FIDO2, WebAuthn, etc. This can be done with hardware tokens or a smartphone."
ça me paraît important à souligner car perso je ne crois pas du tout à "éduquer ses utilisateurs". ça fait 30 ans qu'on dit qu'il faut éduquer ses utilisateurs et ça n'a jamais marché, c'est un vieux mythe pour se donner bonne conscience entre informaticien et rejeter le problème sur les utilisateurs.. Il y a des barrières sur les ponts, on "n'éduque" pas les utilisateurs à ne pas sauter, on met une barrière.
Bref, le 2FA, oui, il le faut aujourd'hui, certes pas par sms.
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par Anonyme . Évalué à 5.
On le dit, mais est-ce qu’on l’a fait sérieusement ?
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par octane . Évalué à 10. Dernière modification le 04 août 2020 à 14:10.
Mais, est-ce que ça doit être fait? Et jusqu'à quel point?
souvent, on entend le bon conseil: quand vous vous loggez sur votre banque, vérifiez le certificat.
woké, merci. Tata Germaine, elle va vérifier la connexion SSL? Les paramètres? Les dates de validité? La CA? C'est le genre de bon conseil, mais qui se révèle inutilisable en pratique.
Ensuite, on dit aussi: faites attention quand vous cliquez sur un lien!!! ZOMG! un lien! Sur
internetle WEB! Le méga conseil! merci mec, je cliquerai plus jamais sur un lien de ma vie. Bon, mon activité surinternetle web va être un peu moins enrichissante, mais je serais secure!Ou par email alors -> vérifiez la PJ. Encore une fois, concrètement, ça veut dire quoi? Non, vraiment, ça veut dire quoi vérifier une pièce jointe de mail? (connaitre l'expéditeur? vérifier l'extension? avoir un AV à jour?)
Je pense vraiment que l'éducation de l'utilisateur c'est un faux problème. Un user devrait pouvoir cliquer sur un un lien, ouvrir une PJ, se logger sur sa banque, jouer en ligne, etc.. sans jamais avoir à se poser des questions de ce genre. (comment faire? je sais pas, mais la solution n'est pas côté user, mais côté dev[ops] et admin sys/réseau.)
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par Kerro . Évalué à 10. Dernière modification le 04 août 2020 à 21:47.
Je trouve que ça ne fonctionne dans aucun cas de la vraie vie, un peu comme une loi universelle. Du coup pourquoi ça devrait fonctionner en informatique ?
exemples :
Un automobiliste devrait pouvoir aller partout où il veut, traverser une route, doubler, sortir d'une place de parking, etc… sans jamais avoir besoin de vérifier quoi que ce soit.
Un skieur en station devrait pouvoir faire comme il l'entend, s'arrêter derrière une bosse, conserver sa vitesse lorsque d'autres personnes sont à proximité, etc… sans jamais se préoccuper de quoi que ce soit.
Un amateur de champignons devrait pouvoir en profiter comme l'entend, cueillir ceux qu'il trouve jolis, ne pas vérifier s'il y a un vers à l'intérieur, etc… sans jamais devoir connaître son sujet.
Une personne devrait pouvoir s'exprimer librement, colporter ce truc si étonnant lu sur Facebook, ne prendre aucune précaution oratoire, laisser libre cours à ses humeurs, etc… sans jamais devoir se poser la moindre question.
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par Zatalyz (site web personnel) . Évalué à 3.
Je suis globalement d'accord… J'adore les questions de sécurité, traquer les failles dans mes installations, mettre des rustines partout et améliorer mes pratiques à mesure que je découvre que "ho non on peut utiliser ça pour entrer chez moi !". Mais… Si moi ça m'amuse, c'est pas le cas des autres personnes qui ont les clés (de la maison, d'un serveur, d'un ordi, d'un site web, etc…). J'ai beau avoir une hygiène numérique correcte (et y'a de la marge de progression parce que j'ai aussi mes moments de flemme), il suffit d'un de mes co-sysadmin qui utilise le même mot de passe partout pour que tout s'effondre, et vite.
En rédigeant des règles de "bonnes pratiques de sécurité" pour ce genre de personnes, je me suis rendue compte que c'était une impasse. Bon, ce n'est pas complètement perdu, tout ce qu'elles appliqueront sera toujours ça de pris, mais plus je demande d'efforts aux autres, plus il y a des risques qu'ils me trouvent un contournement pour se simplifier la vie (genre le même mot de passe utilisé partout). À l'inverse, si je trouve comment augmenter leur confort tout en proposant des solutions qui augmentent aussi la sécurité, ça a des chances de mieux se passer. Ça demande quand même de vérifier, et de voir avec quoi on négocie. Des tests utilisateurs, sans cesse !
Il faut aussi accepter, à un moment, que des failles exploitables resteront présentes, et s'assurer que les backups, eux, sont bien protégés, et redondants.
C'est tout de même assez déprimant…
[^] # Suggestion
Posté par Arthur Accroc . Évalué à 3.
Une idée comme ça : ajouter quelques caractères aléatoires au mot de passe commun, différent pour chaque machine et fournir à chacun une correspondance imprimée entre les machines et la partie ajoutée du mot de passe, à coller en bas de l’écran par exemple.
Pas d’effort de mémorisation supplémentaire pour les personnes censées avoir le mot de passe.
Par rapport à des attaquants locaux, il y aurait toujours la sécurité de la partie principale du mot de passe (ni plus ni moins qu’avant).
Par rapport à des attaquants distants, il faudrait déjà qu’ils aient récupéré le mot de passe de deux machines pour s’apercevoir qu’il n’y a qu’une petite partie du mot de passe qui change (sécurité par l’obscurité un peu limitée, mais c’est quand même moins open bar qu’un mot de passe identique partout).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par Anonyme . Évalué à 6.
Parce qu’on ne résout pas des problèmes de systèmes avec des procédures 1.
Pour reprendre ton exemple de mot de passe identique partout, tu as plusieurs choix :
Vu que tu parles d’utilisateurs familiers avec la technologie (des admin. sys.), tu peux aussi rendre obligatoire la MFA pour les services critiques (ou même globalement), utiliser un bastion ou « jump host » pour réduire la surface d’attaque, utiliser des certificats SSH (avec une durée de vie limitée) plutôt que des mots de passes où des clefs, etc.
C’est seulement déprimant si tu cherches à être totalement infaillible, parce que c’est peine perdu, mais avec une bonne hygiène numérique, comme tu dis, tu éviteras même les failles contre lesquels tu ne t’es pas protégé directement.
j’ai déjà parlé plusieurs fois de ce bouquin ici, mais The Field Guide to Understanding 'Human Error' de Sidney Dekker est un livre qui m’a vraiment ouvert les yeux sur ce genre de problématiques et je le conseille à quiconque s’intéresse de prêt ou de loin à la sûreté des systèmes et aux recherches ou enquêtes post-incidents (au sens large, ça peut aider à comprendre un crash d’avion comme aider à rechercher les causes derrière un
rm -rf /). ↩[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par Colin Pitrat (site web personnel) . Évalué à 6.
En fait la meilleur preuve que ce n'est pas suffisant c'est que même des experts se font avoir de temps en temps.
Il n'y a pas de solution magique pour la sécurité, c'est un tout. L'éducation des utilisateurs en fait partie, le 2FA aussi, l'ASLR, les stack canaries, rust, les firewalls, reduire la surface d'attaque, etc …
Compter sur une seule protection c'est laisser un seul obstacle à l'adversaire.
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Surtout le 2FA SMS ou mail a une faille majeure aujourd'hui: on te vole ton mobilophone, il y a tes comptes bancaires, sociaux, mails et SMS dessus.
C'est bien d'avoir deux clefs pour le coffre, mais attention à ne pas les scotcher sur le coffre.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par Renault (site web personnel) . Évalué à 2.
D'où l'importance de verrouiller le téléphone avec un code pin par exemple et de chiffrer le contenu du système.
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par barmic 🦦 . Évalué à 2.
Je ne sais pas ce qu'il en est d'Apple, mais je trouve Google pas mal. Ils "auditent" ton téléphone pour te dire s'il n'a pas de verrouillage par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel
Posté par Zatalyz (site web personnel) . Évalué à 3. Dernière modification le 08 août 2020 à 16:31.
Moui… petit test rigolo : aller dans une de ces boutiques de réparation de téléphone/vente en vrac de mobiles, expliquer qu'on a bloqué son téléphone et demander s'ils peuvent aider à débloquer.
À l'époque où j'avais réellement bloqué mon téléphone suite à une fausse manip, j'avais été un peu stupéfaite de la vitesse à laquelle on me l'avait débloqué. Le contenu n'était pas chiffré, et peut-être que c'est plus complexe aujourd'hui, ça remonte à quelques années… mais de ce que je vois des pratiques des gens et du fonctionnement des smartphones, je serais surprise que ça soit si complexe que ça de "rentrer". Heureusement, dans la plupart des cas, les téléphones sont juste réinitialisés après avoir été volés, la récupération d'informations privées est assez rare.
Je préfère quand même ne rien avoir d'important sur mon ordiphone. Mon compte framasphère, ok, mais ni mes mails, ni appli bancaire… il y a déjà assez de données privées et potentiellement exploitables sur cette machine !
# Déterminisme
Posté par barmic 🦦 . Évalué à 5.
Je suis pas vraiment d'accord avec :
Un code déterministe est une qualité objective. On peut choisir que ce n'est pas la qualité la plus importante pour nous, mais c'est une qualité objective.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Déterminisme
Posté par Guillaum (site web personnel) . Évalué à 10.
Je ne suis pas d'accord non plus avec lui pour plusieurs raisons. Mais aucune de ces raisons ne concerne (directement) la sécurité.
Je citerais juste sa conclusion:
Je ne suis tellement pas d'accord ici. En supposant que tu as un bon outil pour faire des build reproducibles (je pense ici à nix, il y a d'autres solutions), alors au contraire cela diminue la complexité, puisque que tout ce qui a été mis en place pour faire du reproducible permet normalement de s'affranchir de nombreuses autres questions que tu avais en terme de build. Fini les README de 10 écrans de long qui explique les étapes nécessaires (mais pas suffisantes, je n'ai jamais vu un README complets) pour obtenir ton build. Fini une bonne partie des "chez moi ça marche, pas chez toi ?". Fini les problèmes de bug amusant en production qui n'aurait pas du arriver parce que ce context était testé. Fini la matrice de test dans 200 configurations qui n'arriverons jamais mais qui "représentent" une vague idée de ce que tu va peut-être rencontrer.
A vrai dire je trouve même que mes builds sont moins complexes depuis qu'ils sont reproducibles.
Et le coté reproductible a un avantage en terme de sécurité, c'est que tu peux faire du post mortem dans le même contexte que celui de l'attaque (ou de l'accident / incident / bug critique qui as tué 400 personnes).
# Ce n'est vraiment pas compliqué
Posté par passant·e . Évalué à 10.
La punchline à la mode : la question n'est pas de savoir si on se fera pirater mais quand
Je suis un dev web je fais quoi
Si tu penses "security by design" et que tu intègres les bonnes pratiques de sécurité tu réduis fortement le nombre de personnes pouvant te pirater. En résistant aux attaques de Jean-Kevin et des scanners automatique t'as déjà fait 99.9% du job.
Le reste c'est des personnes très motivées ou avec de gros moyens qui ne devraient pas s'intéresser à toi.
Dans les conseils rapides (tu trouveras facilement de meilleurs conseils en ligne)
TOUJOURS nettoyer le contenu reçu par un utilisateur. Il faut partir du principe qu'il y a en permanence un risque d'attaque. La plupart des attaques que tu donnes en example sont le fait d'une non vérification des données reçues
Les injections SQL peuvent être évitées avec des "prepared statement" mais cela demande un peu plus de travail. Du coup ce n'est souvent pas fait ou fait à moitié
Les motivés (0.1%) ont piraté mon système :-(
Compartimenter l'application pour freiner ou empêcher l'attaquant d'aller plus loin.
Ne pas laisser traîner des binaires - potentiellement vulnérables - inutiles dans le système
Ne pas donner plus de permissions que nécessaire à une application et l'attaquant ne pourra pas - facilement - faire de l'escalade de privilège
Ne pas stocker les données sensibles en clair. Le pirate a accès aux données dans la base mais elles sont chiffrées et la clé privée se trouve sur un autre système.
Avoir des logs c'est bien, sur un système séparé c'est encore mieux et les analyser régulièrement c'est top
Il y a une faille dans mon appli!
La vraie sécurité et d'accepter qu'il n'y a pas de vraie sécurité.
Cela fait un peu pompeux mais l'excès de confiance est souvent fatal :-)
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Ce n'est vraiment pas compliqué
Posté par Christophe B. (site web personnel) . Évalué à 2. Dernière modification le 13 août 2020 à 11:00.
Ah enfin un peu de bon sens
Cela change des "spécialistes" et autres (con)sultants en sécurités
Vous savez ceux qui préconisent des certificats SSL de partout !
même dans les échanges de données sécurisées
Je pratique un peu l'échanges de données basés sur Axway Transfer (avant on disait CFT)
qui réprésente 80% du marché de la transmission de données interbancaires (enfin d'après ce que l'on m'a dit)
le protocole PeSit est un protocole sécurisé qui date de l'ère préhistorique PRE INTERNET
à l'époque glorieuse de Tranpac et autre NUMERIS.
Les tuyaux fiables, sécurisé ET surveillé, garantis par Orange/France télécom ayant disparu il a fallu passé via les tuyaux INTERNET
Certain connaissant la robustesse du truc on simplement ouvert un port et font transiter le protocole directement.
D'autres plus méfiants on encapsulé l'échange sécurisé dans un VPN, jusque la on peut trouver cela logique ( ceinture et bretelle )
Et puis est venue une horde de sultant en sécurité qui on absolument voulu rajouter dans l'authentification du cerfificat SSL
Bref on frise le ridicule, par contre il ne tue pas mais des sociétés comme verisign et autre vendeurs de certificats se font des c….. en Diamant
Sans parler des effets de bords et autres problèmes liés à la gestion des Certificats
Avec le summum :
un grosse entité avait même décidé de devenir Autorité de certification, rien que ça et nous a même obligé d'utiliser LEUR certificat … ok pourquoi pas
5 ans plus tard … dialogue de sourd …
Cette même entité nous demande changer de certificat (pour des raisons de sécurité)
Nous : OK pas de de problème, on fait comme la dernière fois envoyez nous le nouveau certif.
réponse de l'entité : non vous en comprenez pas, vous devez CHANGER de certificat, nous ne pouvons pas vous fournir de certificat
Nous : mais la dernière fois c'est ce que vous avez fait … ?!?
Entité : oui mais depuis le service a changé et ce n'est plus le même protocole …
Nous : OK quel type de certificat faut il mettre en oeuvre ? de quel fournisseur ?
Entité : c'est a vous de vous débrouiller, voici deja NOS certificats que vous devez intégrer dans votre base de données…
Résultat : après analyse de leur certificats , et des documents transmis j'ai pu trouvé une société française suffisement compréhensive pour comprendre le problème et finalement j'ai trouvé un certificat compatible avec cette "Entité"
Conclusion : la force d'une chaîne est égale à la valeur de l'élément le plus faible
et la sécurité informatique ne fait pas exception à la règle
Mais toujours est il que RIEN ne remplace le BON SENS
# En informatique comme dans la "vrai" vie
Posté par abriotde (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 04 août 2020 à 13:12.
Le sécurité en informatique c'est comme dans la vrai vie. On est jamais totalement protégé d'un voleur. Tout dépends du rapport risque/coût. La première chose est de juger la valeur de ce que l'on a. De là en découle le prix que l'on est prêt à en payer. Un bon principe est d'être plus sécurisé que le voisin. Dans ce cas le voleur ira d'abord voir le voisin.
Adapté a l'informatique c'est plus tu met de sécurité mieux c'est, mais plus ça coûte en productivité mais aussi en utilisabilité pour les utilisateurs finaux. Rien ne sert de mettre un super mot de passe différent pour chaque compte si a chaque fois tu fais mot de passe oublié. Si tu est prêt a te mettre a l'informatique un PC sous BSD sera mieux encore que Linux car étant moins commun tu gagne en sécurité (mais c'est moins pratique ne serais-ce que pour les tutoriel). Sinon tu est obligé de passer par la case anti-virus.
Pareil pour le code, il vaux mieux respecter les "best-practice" car sinon tu sera le maillon faible que le hacker attaquera. Ajouter des couches de sécurité c'est bien mais tu perd en productivité, tout dépends donc du rapport risque/coût.
Ce qui est aussi vrai c'est que plus la sécurité en prise en compte tôt moins elle coûte et plus elle est efficace. C'est la raison du succès du langage Rust.
Surtout ne pas mettre une sécurité excessive car alors la tentation est trop grande pour les utilisateurs de la contourner et ainsi d'ouvrir des failles aux hacker.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: En informatique comme dans la "vrai" vie
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
C’est une variante de sécurité par l’obscurité, c’est très efficace contre les bots et autre kiddies, ça ne marche pas vraiment si tu es la cible de 0.1% qui t’en veut directement. Et dans ce cas avoir un truc moins connu et potentiellement moins éprouvé pourrait être plus risqué.
Avoir plein de bugs mais pas connus ça n’aide pas du tout les bots mais ça aide beaucoup celui qui t’en veut vraiment. Et toi-même tu ne sais pas comment t’en protéger.
Note: je ne dis pas que BSD est moins bien que Linux par principe, mais que le principe de « moins commun donc plus sécurisé » a des limites.
La sécurité par l’obscurité n’est pas à jeter complètement, changer le port par défaut de SSH bloquera 99.99% des bots même si ton mot de passe est
123abc, et puis ça soulagera tes logs, mais ça ne doit pas être un prétexte pour utiliser123abccomme mot de passe et se passer des bonnes pratiques que tu utiliserais si tu avais une vitrine sur la grand-place : pas d’accès root à distance, passphrase, etc. Le port-knocking est aussi une forme de sécurité par l’obscurité c’est pas à jeter non-plus.Dans tous les cas je préfère un peu de diversité dans les systèmes et les configurations. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: En informatique comme dans la "vrai" vie
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 06 août 2020 à 12:15.
Dans le cas de BSD (et encore plus Open-BSD) on ne parle pas d'une passoir niveau sécurité c'est tout de même un serveur ultra répandu dans les entreprises pour des serveurs dédié (Box internet, serveur proxy, NAS) et dans des très grosses entreprise. D'ailleurs plus que Linux BSD est très orienté sécurité dans son implémentation comme dans sa configuration (c'est d'ailleurs en partie pourquoi c'est lus compliquer à installer/bidouiller).
Sinon oui, l'originalité n'est pas un critère de sécurité, il ajoute à la sécurité.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: En informatique comme dans la "vrai" vie
Posté par barmic 🦦 . Évalué à 4.
Ça peut être un critère de sécurité mais dans un approche différente. Tu peux vouloir avoir 2 implémentations différentes séquentielles (si elles sont en parallèle ça n'a pas de sens) pour éviter qu'une faille traverse tout.
Ça peut vouloir dire utiliser un système différent dans la DMZ qu'ailleurs. Si quelqu'un arrive à entrer dans la DMZ il faudra qu'il abuse d'une autre faille pour entre dans le reste du réseau.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En informatique comme dans la "vrai" vie
Posté par Kerro . Évalué à 10.
Deux trekkeurs vont se promener dans la savane africaine.
L'un d'eux a un équipement tape à l'œil : chaussures ultra-légères, vêtements techniques fins et moulants, et sac à dos « One Clic » qui se détache d'une simple pression sur la poitrine.
- ahah, tu crois vraiment que ton équipement te permettra de distancer un lion ?!
- ce n'est pas pour courir plus vite qu'un lion. C'est juste pour courir plus vite que toi.
[^] # Re: En informatique comme dans la "vrai" vie
Posté par KiKouN . Évalué à 4.
C'est très bien d'être plus sécurisé que le voisin. Mais en lisant le début de cette histoire, j'aurai penser que le deuxième trekkeur aurait volé le premier car il était plus "tape à l'oeil".
Une autre protection contre les voleurs c'est de n'avoir rien à voler ou du moins de ne pas le montrer.
[^] # Re: En informatique comme dans la "vrai" vie
Posté par fearan . Évalué à 2.
bof, un bon croche pied et c'est réglé ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# une question de cout
Posté par eric gerbier (site web personnel) . Évalué à 2.
Pour moi, la bonne question n'est pas de savoir si je vais me faire pirater, mais qu'est ce que ça va me couter :
[^] # Re: une question de cout
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Indépendamment de la valeur de tes données elle-mêmes, ce que ça peut te coûter de les voir exposées.
Cf. protection des données, les diverses sanctions prévues par le RGPD, etc. Il se peut qu’un intrus se retrouve au contact de données qui ne l’intéresse pas, mais techniquement elles sont exposées.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: une question de cout
Posté par Christophe B. (site web personnel) . Évalué à 3.
C'est assez compliqué car il faut aussi ajouter l'image de ta société :
Combien de clients / Chiffre d'affaire peut tu perdre dans ce cas
Et les sauvegardes : il fut un temps au l'on préconisais les choses suivantes :
1 sauvegarde quotidienne dont une cartouche (ok c'était il y a longtemps) externalisée
1 sauvegarde tout les mois a stocker en dehors de la société (coffre)
1 sauvegarde par an idem
Si je devais faire un virus, je ne le déclencherais que 31 jours après infection, histoire de bien être présent sur la majorité des sauvegardes …
Comme je le dis souvent : une assurance coute toujours trop chere tant que l'on en a pas besoin …
[^] # Re: une question de cout
Posté par barmic 🦦 . Évalué à 4.
Puis des fois, t'a beau en avoir besoin, elle reste trop chère
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: une question de cout
Posté par Christophe B. (site web personnel) . Évalué à 4.
Apparemment c'est pas un assureur mais un escroc …
Tout comme AXA qui refuse d'indemniser les commerçants pour les pertes du a COVID …
A ton avis il sont tous en train de revoir les contrats …
Et pour abonder dans ton sens je suis presque sur que l'on changera VRAIMENT d'optique sur le réchauffement climatique le jour ou les assureurs ne voudront plus indemniser leurs assurés sur les catastrophe climatiques a répétition.
Ou que les cotisations seront tellement élevées que nous serons OBLIGES de faire avec ou de combattre le réchauffement climatique au niveau national/européen/mondial
[^] # Re: une question de cout
Posté par claudex . Évalué à 5.
Donc que ce sera trop tard pour lutter contre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: une question de cout
Posté par Christophe B. (site web personnel) . Évalué à 5.
Et c'est bien ça le problème … le manque de bon sens
Cela fait peut être trop longtemps que je suis ingénieur système
mais ce n'est pas quand le disque est plein qu'il faut réagir … c'est avant
Pour moi un "système" qui tourne bien évolue entre 40 et 70 % d'utilisation
à 80% tu réfléchis à la "suite"
à 90% tu dois planifier la "suite"
Cette régle est valable aussi pour plein de choses …
humour (issue de fortune des années 1990) :
[^] # Re: une question de cout
Posté par barmic 🦦 . Évalué à 3.
T'inquiète on a planifié un shred (c'est juste pour la blague je suis loin d'être pessimiste).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: une question de cout
Posté par Christophe B. (site web personnel) . Évalué à 2.
Eh moi qui pensais être violent …
Non un shred cela va "supprimer" tout le monde
Bon ok, les sysadmin ne sont pas sur la même partition que tout le monde … mais quand même …
Blague à part : je l'ai jamais utilisé sous Linux,
Par contre une fois j'ai du lancer une équivalence sur la machine IBM AIX d'un client qui partais chez un broker
Et cela avait duré très longtemps … c'est pareil sous Linux ?
[^] # Re: une question de cout
Posté par barmic 🦦 . Évalué à 3.
Ça dépend des paramètres que tu lui donne. Par défaut il ne fait que 3 itération et je crois qu'il utilise
/dev/urandom. Donc ça va. Mais tu peux lui demander d'en faire 5435 et de partir de/dev/random. Ça doit laisser le temps d'aller se promener.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Super journal
Posté par stopspam . Évalué à 4. Dernière modification le 04 août 2020 à 14:21.
des liens intéressants, un blog que je ne connaissais pas et une réflexion sur un sujet sérieux dans un ton décalé. Au top !
# but de l'outil
Posté par Adrien . Évalué à -5.
Faire un outil informatique sécurisé, je pense qu'on devrait y arriver, il n'y a pas que des branques dans le milieu… Mais est-ce vraiment le but ? à mon avis le problème est là : ceux qui font et administrent les outils informatique n'ont pas pour but d'avoir un système propre, fiable, qui produit des effets attendus.
Au contraire, plus le système est incompréhensible, obscurs, avec un comportement imprévisible, mieux ça sera pour beaucoup. Typiquement, c'est plus facile pour récolter des données perso si personne ne comprend rien à son smartphone. C'est plus facile de vendre de la maintenance sur un bouzin infâme que sur un logiciel très fiable, très stable… C'est tellement facile de faire chanter les gens qui ne maîtrise pas la complexité informatique… ou de les manipuler à grande échelle.
Après 15 ans d'informatique, je ne compare plus l'info à un couteau suisse, mais plutôt une Kalachnikov malheureusement. L'outil info a des bons côtés, mais c'est tellement insignifiant par rapport aux dangers derrière.
Certes, avec un PC je peux poster sur linuxfr, mais d'un autre côté avec une Kalach je peux aussi chasser le sanglier…
# La technique passe après l'humain
Posté par Zatalyz (site web personnel) . Évalué à 7.
La technique et les bonnes pratiques sont suffisantes pour faire face aux attaques non ciblées (les 99% évoquées plus haut) mais dans le cas d'attaque ciblé, un attaquant motivé trouvera toujours comment passer. Ceci dit, les commentaires semblent évoquer principalement l'angle d'attaque technique, alors que c'est franchement le plus "con" à explorer : exploiter des failles dans les logiciels demande de jouer aux échecs avec les sysadmins et concepteurs de logiciel et ça peut demander masse d'effort pour des résultats faibles. À côté, l'ingénierie sociale permet d'exploiter le plus gros bug, celui qu'on n'arrive jamais complètement à patcher, et qui est assis devant le clavier.
C'est un truc qu'on a tendance à perdre de vue quand on s'amuse à sécuriser ses machines et ses logiciels. Et c'est bien de s'occuper des machines, puisque que la majorité des attaques seront menées par des bots stupides. Mais si l'entreprise/projet/personne a affaire à un vrai modèle de menace, la "protection" va se baser sur de la diplomatie (ne pas apparaître comme une cible malgré l'activité, attirer la sympathie des potentiels attaquants tout en veillant à ce que cette sympathie n'amène pas à confier des secrets, etc) et… ben c'est vraiment super compliqué de patcher les humains. Cloisonner les activités et les responsabilités peut aussi bien servir que desservir ; les formations peuvent aider, un peu, mais il y aura toujours des gens qui se feront avoir par un escroc sympathique.
Il m'arrive régulièrement d'accéder à des données confidentielles, au mépris de toute règle de sécurité, parce que la personne en face juge qu'elle peut me "faire confiance", parce qu'elle a laissé traîner un cahier ou un ordi à portée de mes yeux, et autres petits détails faciles. Jusqu'ici, leur confiance semble bien placée mais j'ai un mal fou à leur expliquer que non, même à moi, il ne faut pas faire confiance, que je n'ai pas à savoir le mot de passe de ceci ou le fonctionnement de cela… Peu importe à quel point j'ai l'air sympathique, car c'est le propre des escrocs et d'un certain nombre de personnes malveillantes : avoir l'air digne de confiance, savoir devenir des "proches".
Je trouve cela effrayant, la rapidité avec laquelle on peut récupérer des informations, y compris auprès de gens très doués techniquement (mais trop confiant humainement !). Si je fais le point dans les projets où je suis un peu active, je vois facilement des angles d'attaques psychologiques ou matériels, permettant de récupérer toutes les infos nécessaires avec un minimum de risque et sans grandes connaissances techniques. Mettre une caméra espion au bon endroit, faire parler la bonne personne, c'est facile. Mais c'est difficile de prévoir et donc de protéger ces innombrables angles d'attaques, d'autant que cela demande de développer une surveillance et une paranoïa qui sont difficilement compatibles avec des relations sociales normales.
# Les techniques de sécurités
Posté par vitanix . Évalué à 0.
Il y a des outils qui permettent de supprimer des classes complètes de façon fiable. J'en connais un peu, mais elles ne sont pas mises en avant, je ne sais pas pourquoi. Il est possible que pour chaque problème de sécurité, quelqu'un a trouvé un moyen à la fois efficace, et facile de le contrer, mais j'ai l'impression qu'il y a peu de publicité sur ces outils.
Il y a quelques année, j'ai cherché comment gérer de façon sécurisé les mots de passe des utilisateurs dans une application. Il n'y a pas un site qui l'explique clairement, même l'OSWAP n'est pas claire la dessus. J'ai fini à force de prendre des info par ci par la de trouver un certain niveau de sécurité. Peut être qu'il y a mieux, mais je n'en sais rien.
[^] # Re: Les techniques de sécurités
Posté par Kerro . Évalué à 0.
Peux-tu citer des exemples ?
Le principe pour « gérer de façon sécurisé les mots de passe des utilisateurs dans une application » est connu depuis plus de 40 ans. Si tu n'as pas trouvé l'information de base en moins de 5 minutes alors tu n'as pas choisi le bon métier.
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . Évalué à 5.
Sympathique… Généralement je me méfie de ceux qui considèrent qu'un problème de sécurité est facile. D'une part à cause de l'effet Dunning-Kruger. D'autre par comme pour beaucoup de domaine, il est toujours bon de remettre en cause les bases et de les revoir. Have I Been Pwned n'aurait pas tant de succès, si le sujet était aussi simple que ça. Les HSM ne seraient pas non plus si chères si c'était si simple.
Enfin… Il y a ce document de l'OWASP : Password Storage Cheat Sheet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les techniques de sécurités
Posté par Kerro . Évalué à 3.
J'ai moinssé ton post par erreur (je voulais cliquer sur « répondre »).
[^] # Re: Les techniques de sécurités
Posté par Kerro . Évalué à 3. Dernière modification le 12 août 2020 à 16:16.
Peux-tu copier/coller mon texte où je prétends que c'est facile
à faire?J'ai
clairementécrit que c'est facile àtrouver.Le post parle de « gérer de façon sécurisé les mots de passe des utilisateurs dans une application », ce qui se fait depuis longtemps via un hachage + sel et est considéré comme étant la bonne méthode. On ajoute à cela une limitation du nombre de tentatives pour limiter le forçage tant que la base de données n'est pas exposée.
Estimes-tu que j'ai mal compris le besoin ? Si oui, quel était le besoin de l'auteur du post ?
As-tu des arguments contre la facilité à trouver que la méthode validée depuis longtemps est du hachage, et qu'il est sain de limiter le nombre de tentatives ?
As-tu des arguments sérieux contre le hachage + sel ?
As-tu des arguments sérieux contre la limitation du nombre de tentatives ?
Depuis quelques temps il est également commun d'ajouter une authentification à plusieurs facteurs. Ce n'est ni reconnu comme étant top, ni pratique, ni etc. Et surtout ce n'était probablement pas facile à trouver il y a plusieurs années.
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 12 août 2020 à 16:55.
(Je te trouve bien magnanime après un premier message aussi condescendant…)
Je ne sais pas à quoi tu fais référence. Limiter le nombre de tentatives n'est pas un sujet simple. Tu te base sur quoi ? L'IP ? Et tu fais quoi pour limiter le nombre de tentative (une fois que tu as déclenché ton indicateur de trop de requêtes) ? Tu blacklist l'IP ? Tu verrouille le compte ?
Tu as les techniques anti-DDOS qui peuvent t'aider mais elles ne vont pas faire le café.
Perso j'aime pas mal OAuth. Tu laisse un service gérer ça pour toi. Il choisira lui-même la méthode d'authentification avec du double facteurs ou non. En terme de praticité, un truc comme le fait google où il tu a juste à pointer une notif' de ton téléphone, ça me paraît plutôt pratique. Je sais pas ce que vaut des trucs comme FranceConnect que je n'ai pas encore essayé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par vitanix . Évalué à 1.
Oui, moi aussi, je trouve OAuth bien, mais je n'ai pas encore pu le mettre en place.
[^] # Re: Les techniques de sécurités
Posté par Kerro . Évalué à -1.
Je ne te trouve pas magnanime de ne répondre qu'à 1 question sur 5…
Je t'ai prémâché le travail en détaillant une marche à suivre pour argumenter.
Tu n'as pas donné d'argument qui pourrait te permettre de montrer que j'ai été condescendant, que mes messages sont peu sympatiques, qu'il est sain de se méfier de moi, que je ne me remets pas en cause, etc.
Jusqu'à présent c'est toi qui distribue les qualificatifs péjoratifs à mon encontre. Chose que tu ne ferais probablement pas en présence physique.
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . Évalué à 0.
Tu aurais envoyé :
À quelqu'un que tu ne connais pas s'il était devant toi ?
Personnellement oui il m'est arrivé de dire devant quelqu'un qu'il ne devrait pas tenir de tel propos et pas forcément aussi tranquillement que là.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par Kerro . Évalué à 1. Dernière modification le 13 août 2020 à 17:38.
Tu utilises la technique du millefeuille argumentatif : au lieu de répondre aux questions d'origine, tu avances d'autres propos.
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . Évalué à 0.
Pour te simplifier la vie. J'ai répondu dans un autre commentaire à tes 6 questions. En espérant que ça fasse un peu moins mille-feuilles.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par Kerro . Évalué à 1. Dernière modification le 13 août 2020 à 18:01.
Avec tes incessantes piques, j'ai du mal à comprendre si tu me prends pour un être inférieur, ou si tu te prends pour une être supérieur.
Le « ou » n'étant pas exclusif.
[^] # Re: Les techniques de sécurités
Posté par vitanix . Évalué à 2.
Les techniques que tu cites sont bien, mais pas suffisantes.
J'ai mis en place ces mécanismes en 2011. J'ai fait des amélioration en 2013/2014 en suivant certains conseils de l'OWASP. Voici une page web qui date de 2019 qui donne les explications sur comment hasher le mot de passe : Hash du mot de passe . Ça explique beaucoup de choses, et parles des problèmes sur la façon d'implémenter le tout.
Ça ne parle que du hash, et pas de tout ce qui va autour :
- création d'un nouveau compte avec mot de passe temporaire,
- réinitialisation du mot de passe au bout d'un certain temps,
- réinitialisation du mot de passe d'un utilisateur par un administrateur sans que l'administrateur connaisse le mot de passe et sans que le mot de passe circule en clair par mail,
- gestion des logs pour savoir qui se connecte et se déconnecte et à quelle heure, et sans jamais loguer le mot de passe, ni loguer trop d'information sur l'utilisateur,
- stockage du mot de passe en base en faisant attention que la taille des champs soit suffisamment grand pour stoker le hash,
- blocage d'un compte de façon temporaire, s'il y a eu trop de tentatives par exemple
- blocage d'un compte de façon permanente
- l'envoie du mot de passe entre le navigateur et le serveur
- etc…
Ce que je trouverais bien c'est qu'il y a une librairie qui gère tout cela, et qui rendrait facile le respect de ces principes. Comme cela, c'est maintenu par des spécialistes et tout le monde ferais des sites mieux sécurisé. J'ai regardé récemment du coté de Spring Security, mais c'est une librairie difficile à utiliser je trouve.
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . Évalué à 1.
Oui clairement et tu as préférer juger ton interlocuteur que de te poser la question.
Il l'a explicité.
C'est tellement facile à trouver que je ne vois rien de sain dans le fais de limiter le nombre de tentatives (hors cas très particulier).
Non.
Oui pleins (facilement contournable, ça gène plus l'utilisateur que l'attaquant, ça permet de bloquer des comptes aussi, ça n'est pas fiable,…). Ça ne fonctionne globalement pas c'est bien pour ça que personne ne s'en sert.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . Évalué à 3.
Si comme tu le dis c'est facile à expliquer et difficile à implémenter, c'est que ça ne doit pas être aussi facile à expliquer. Le reste de ton commentaire le montre bien. On connais tous les 3~4 principes de bases (et encore on est pas tout à fait d'accord). C'est bien, mais ça pose un certains nombre de questions qui n'ont rien de triviales.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par vitanix . Évalué à 0.
Oui comme exemple, il y a dans spring data les requetes :
@Query(
value = "SELECT * FROM USERS u WHERE u.status = ?1",
nativeQuery = true)
Collection<User> findAllActiveUsersNative(int parametre);
Autre exemple, avec Google Cloud Platform, le systeme de fichier est en lecture seule. ça signifie que si un virus s'injecte dans le processus du programme, il ne pourra pas s'écrire sur le disque dur, et donc un simple redemarrage supprimera le virus, sauf bien sur s'il accède au noyau de l'OS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.