Contournement des droits via l'héritage des permissions sous Linux et UNIX - Christophe Casalegno

Dans cette vidéo j'ai décidé de vous présenter l'un des concepts de sécurité générale concernant les systèmes "Unix like" tel que Gnu / Linux, FreeBSD, OpenBSD, NetBSD, ou encore des Unix commerciaux, que j'utilise depuis plus de 20 ans.
Bien que j'utilise ce concept depuis plus de deux décennies dans le cadre d'audits et de tests d'intrusion, et que je l'ai mainte fois expliqué en cours : au moment où je publie cette vidéo, des millions de serveurs de productions restent vulnérables à cette approche.
Retrouvez-moi sur Telegram : t.me/ChristopheCasalegno
KZbin
-------------------------------------------------
Ma chaîne principale : / @christophecasalegno
Ma chaîne secondaire : / @brainbazar
Musiques, covers, textes & co : / @chrisiker
Réseaux sociaux
-------------------------------------------------
Twitter : / brain0verride
Instagram : / brain0verride
TikTok : / brainoverride
Linkedin : / christophecasalegno
Facebook (Page Pro) : / brain.override
Facebook (Perso) : / christophe.casalegno
Mais également sur
-------------------------------------------------
Twitch : / brain_0verride
Discord : / discord
t.me/Brain_TechnoBar (le Technobar)
t.me/Brain0verride (mon compte Telegram)
Par email : [e-mail]
Sur le web : www.christophe-casalegno.com

[@yvesgalante6682]

Merci Christophe pour ta vidéo ! Cette vulnérabilité était présente chez mon hébergeur web. Je l'ai annoncée via leur programme “bug bounty” et reçu en retour une prime 650 Euro de prime ;-)

[@ChristopheCasalegno]

Bonjour Yves et merci pour ton retour. Je t'envoie mon numéro de compte pour ma commission (joke) xD. Et félicitations aussi à ton hébergeur qui a joué le jeu !

[@BiMathAx]

Mdrrr chanceux :-)

[@59busta]

C'est les 17 minutes les plus rentables d'une carrière :D

[@wakedxy]

Qui met un dislike sans même suivre la vidéo? pff bon je continue la vidéo et je commente

[@ChristopheCasalegno]

J'en ai un qui dislike en moyenne dans les 25 secondes qui suivent les publications lol.

[@wakedxy]

@@ChristopheCasalegno haha j'en ai au moins 5 comme ca aussi , certainement des jaloux

[@MusicandRelaxation]

@@ChristopheCasalegno ont les appels les haters

[@kawansoft]

Merci, très intéressant.

[@LouisSerieusement]

trop bien ! Merci beaucoup !!

[@jcurwen31]

Excellente vidéo, très didactique. Merci.

[@ChristopheCasalegno]

Bonjour Joseph, merci pour le commentaire, n'hésites pas à nous partager des propres expériences.

[@jonathantikafpei1039]

Merci Christophe. Très bien expliquer. J’ai appris pas mal de choses 💪

[@ChristopheCasalegno]

Si au moins une personne en a appris quelque chose, c'est mission accomplie pur moi :)

[@elronn58]

Très intéressant. J'ai découvert ta chaine il y a un peu plus d'un mois (Merci Thomas de Cocadmin ;-) ) et même si je suis un petit admin sys dans l'univers Microsoft, franchement j'y trouve mon compte. Les explications données sont clairs et les thèmes abordés sont bien maîtrisés. Le tout en français le top.Pour finir je suis allé voir ton CV....comment dire....huuummmm je crois que je vais me mettre au tricot ;-) . Vivement la prochaine vidéo

[@ChristopheCasalegno]

Bonjour Elronn et merci pour ton commentaire. En ce qui me concerne je continue d'apprendre et de découvrir de nouvelles choses tous les jours. Je suis sur que tu as des expériences ou des anecdotes à partager susceptibles d'enseigner beaucoup de choses :). A bientôt.

[@eddybash1342]

Supposons que les fichiers soient chiffrés pour Root et un autre user. Est ce que la clef symétrique est la même pour ces 2 comptes ? Est que l'user lambda pourrait interagir comme dans votre démo avec les fichiers de Root ?

[@ChristopheCasalegno]

Non, l'intéraction ne fonctionne ici que parce que l'utilisateur est propriétaire du répertoire parent.

[@eddybash1342]

@@ChristopheCasalegno on devrait conclure que la faille de sécurité c'est de mettre un fichier accessible par Root sur une branche d'un utilisateur lambda. J'en reviens toujours à la même question : Pourquoi n'est ce pas 'interdit' par une règle de gestion ? Heureusement, on ne joue pas à ça avec des processus s'exécutant dans des Sandbox. Chacun à sa VM...

[@eddybash1342]

Est ce que ça existe sur Aix également ?

[@ChristopheCasalegno]

Sauf erreur de ma part : en principe : oui.

[@AdrienLinuxtricks]

Intéressant mais .... Si on laisse les script de root dans /root/scripts Et qu'on laisse les logs des sites dans /var/log/httpd ... On n'est donc pas vulnérable ? Si j'ai bien compris

[@ChristopheCasalegno]

Bonjour Adrien. Il s'agit plutôt d'un concept général que j'ai illustré avec 2 exemples. Donc par exemple pour le second usecase (les logs apache), s'ils sont situés en dehors d'un répertoire qui pourrait avoir comme parent un répertoire utilisateur, ce usecase indiqué ne fonctionnera pas. De même, si root est le propriétaire du /home/utilisateur, cela ne fonctionnera pas non plus. Si (toujours dans ce cas précis, car chaque cas est un peu unique), le répertoire log a été renforcé avec la commande chattr, il ne sera pas non plus concerné, etc. Je ne me suis jamais amusé à lister l'intégralité de toutes les possibilités de fix pour un seul usecase, mais je suis sur qu'il existe une bonne 15aine de méthodes complètement différentes permettant d'éviter cette exposition. Donc oui, des logs apache par défaut dans le /var/log, ne sont pas concernés. Je retrouve principalement ce cas dans le cadre de structures d'hébergements (pour lesquelles les utilisateurs nécessitent un accès temps réel aux logs par exemple) et pour lesquelles on ne souhaite généralement pas désécuriser son /var/log. Cela permet également de comptabiliser les logs dans l'espace consommé par le client, etc. L'exemple que je cite qui concerne notamment plus de 400.000 serveurs, est typiquement un soft utilisé par les webagency ou de petits hébergeurs pour proposer des environnements mutualisés. Mais il y en a des usecase qui ne reposent pas du tout sur ce type de soft (j'ai testé une bonne quinzaine d'offres dans le monde, excluant les structures que j'avais pu auditer contractuellement) pour essayer d'estimer la présence de ce biais. @++

[@AdrienLinuxtricks]

@@ChristopheCasalegno OK, donc dans le cadre d'un autohébergement, avec les emplacements "par défaut" on est sécurisé correctement. . . Sauf si en SSH, on a par défaut un PermitRootLogin à yes :-)

[@ChristopheCasalegno]

@@AdrienLinuxtricks je suppose que ça va dépendre de la solution choisie, il y a beaucoup trop de distributions pour lister tous les cas par défaut, je ne connais que les 15 ou 20 principales. Mais on va dire que pour une "grande" distribution "classique" par défaut je ne pense pas que ce biais existe. (mais comme encore une fois il existe pour une grande solution du marché, je ne vais pas m'avancer sans avoir testé).

[@thibalito]

Merci pour cette vidéo! Ce n'est pas détectable par selinux par contre?

[@ChristopheCasalegno]

Il y a tellement de usecase différents. Des règles selinux peuvent parfaitement empecher ce type d'utilisation mais il s'agit à chaque fois de règles spécifiques à une "configuration" précise.

[@romainald9291]

Sympas et surtout flippant. Si j'ai bien compris c'est uniquement possible si l'utilisateur à les droits sur le dossier parent du coup, sinon il ne peux pas faire le mv ?

[@ChristopheCasalegno]

Tout à fait, si par exemple le /home/user appartient à root, "user" ou tout process tournant avec son id ne pourra faire l'opération à ce niveau là, mais il pourra dans les niveau suivants.

[@eddybash1342]

@@ChristopheCasalegno il manque une règle de gestion si c'est aussi dangereux que cela. ;)

[@romainald9291]

​@@ChristopheCasalegno Ok, j'ai du revoir plusieurs fois la vidéo pour commencer à comprendre avec le lien symbolique :) J'aimerais bien une vidéo avec d'autre exemple que ce cas et surtout des idées de correction ou de "bonne pratique" puisque c'est pas un bug.

[@eddybash1342]

Bonjour, Pourquoi n'implementez vous pas un patch puisque le code source est disponible ?

[@ChristopheCasalegno]

Bonjour Eddy, ce n'est pas un code source à patcher, c'est un problème de mécompréhension du fonctionnement du système de permissions du système de fichiers.

[@eddybash1342]

@@ChristopheCasalegno si c'est un mauvais mécanisme entraînant une faille de sécurité, c'est donc à corriger. Que je sache, il y a du code qui est déroulé et il y a un trou dans les spécifications de sécurité. ;)

[@ChristopheCasalegno]

@@eddybash1342 Ce n'est pas un mauvais mécanisme. C'est davantage une incompréhension du mécanisme. Chaque situation va demander une action corrective spécifique différente. Il y a la solution qu'à choisi Cpanel par exemple (le lien symbolique), celle que j'ai choisi moi (chattr), et bien d'autres encore. De plus chaque usecase sera différents : l'exemple de détournement de l'écriture des logs en est une, celle des scripts de l'admin en est une autre, ce sont des dizaines et des dizaines de situations différentes qui peuvent se produire. Il s'agit davantage d'intégrer cela dans son approche générale de la sécurité pour essayer d'en détecter rapidement puis de les corriger.

[@wakedxy]

@@eddybash1342 Ca n'a pas besoin de patch, juste une meilleure compréhension de la gestion des permissions

[@eddybash1342]

@@wakedxy ce que je veux dire c'est qu'il faut implémenter une règle de gestion permettant d'interdire ce mécanisme. ;) Les bonnes pratiques ne sont pas connues de tous et il sera toujours fait n'importe quoi si il n'y a pas de contrôle en amont.

[@Lk77ful]

sous quel user tourne apache ? il ne devrait pas pouvoir écrire des logs dans /etc/shadow

[@ChristopheCasalegno]

Que ce soit en fonction de la distribution : apachr/apache, nobody/nogrouo ou daemon cela ne change rien, c'est ici, dans rentrer dans les détails, l'écriture des logs spécifiquement qui est en cause.

[@Lk77ful]

@@ChristopheCasalegno ok ça veut dire qu'on peut avoir accès à tout un tas d'infos sensibles, comme le mdp debian-sys-maint etc... c'est plutôt inquiétant.

[@ChristopheCasalegno]

@@Lk77ful c'est en écriture seulement ici, mais ça peut permettre des choses intéressantes.

[@SALTINBANK]

www-data et non sans PRIVESC il ne peut pas écrire dans les sudoers, le group root ou owner root ...

[@Makinou]

Super vidéo ! Je dois avouer que je suis très surpris par une telle faille, comme quoi il reste encore des énormes failles côté Linux et pour le coup celle-ci il faut "bricoler" afin de s'en prémunir. 😅 Je suis super intéressé pour une suite avec chattr ou même avec les liens symboliques ça serait réellement intéressant de savoir se prémunir de ce genre faille et accessoirement apprendre méthodes d'utilisations qui pourraient servir à autre chose que simplement "patché" cette faille, mais pour de l'administration au quotidien. Surtout les liens symboliques qui ne sont pas très utilisés par les admin sys alors que ça peut faire des merveilles en gain de temps parfois 😄

[@ChristopheCasalegno]

Salut Adel et merci pour ton commentaire. Je te rassure, tous les OS ont les leurs ;) Ce n'est pas propre qu'à Linux, mais je n'aime pas parler de Windows xD. Pour se prémunir ça va dépendre de chaque usecase. Par exemple dans le cas que je montre pour le web (il existe plein d'autres situations "similaires"), tu peux au choix ou combiner : changer l'appartenance du répertoire utilisateur à root (et recrée à l'intérieur un répertoire de travail où il aura seulement les droits), utiliser chattr pour rendre impossible d'effacer les logs (par exemple dans l'installation que je montre et que j'ai désécurisé à dessein, à la base j'ai un chattr +a /home/$user/log qui va empêcher l'exploitation en question. On pourrait aussi mettre les logs dans un autre lieu sur le serveur dans /home/log/user, et jouer sur les droits du groupe (ici non car c'est un groupe commun users) mais si on est sur un groupe par user par exemple, ça peut aussi faire l'affaire. En fait les solutions sont comme les sources potentielles de problèmes : innombrables !

[@k4rm664]

Ah oui c'est surprenant comme faille merci pour cette info .

[@ChristopheCasalegno]

Il existe toujours pire ;) J'essaierai d'aborder quelques autres concepts en cours d'année.

[@FabianThomas]

Merci pour cette vidéo très intéressante. Vous pourriez en faire une autre sur la façon de se protéger de ce problème ? Merci d'avance.

[@ChristopheCasalegno]

Bonjour, le problème c'est qu'il existe une tonne de correctifs possibles pour chaque use case, des besoins, etc. : C'est davantage un concept général à assimiler. Pour l'exemple Web que je donne, mettre le propriétaire de la racine utilisateur à root, utiliser chattr sur le répertoire log, stocker les logs ailleurs, etc. Mais chaque option va : 1) potentiellement demander également des modifications à l'utilisation et à l'administration plus ou moins impactantes 2) Potentiellement rendre vulnerable à un autre concept en sécurité.

[@FabianThomas]

@@ChristopheCasalegno Merci pour votre réponse. Ce serait super intéressant que vous développiez certaines de ces méthodes.

[@michaukoDOTorg]

Intéressant. Ma petite contrib : je me demande à quel moment on dit à son virtualhost / server nginx / etc d'aller coller les logs (détenus donc par root ou www-data ou autre chose un peu sensible) dans le home du user qu'on héberge. J'ai jamais vu ça. Lorsque j'héberge plusieurs sites (plusieurs clients) sur une machine, la personne peut éventuellement manipuler le contenu de son site - son code wordpress etc - via un compte ssh limité à du sftp mais pas accéder directement à ses logs - sinon oui on leur met un cpanel ou autre truc du genre ; c'est le root et uniquement lui qui exploite éventuellement les logs d'un serveur (si c'est à des fins de stats, l'utilisateur proprio du site utilisera de toute manière plutôt un google analytics ou truc du genre). Ainsi le code du site / de l'outil est propriété du user (pour du web avec des pool fpm) et l'administration reste hors /home Si on parle d'autre chose que de site web, même topo, les logs, c'est /var/log, c'est root et point. Et si l'outil nécessite pour son fonctionnement des scripts root etc, c'est pas un outil pour un utilisateur tout bête ou tout au moins l'outil doit installer hors du /home tout ce qui est root. C'est un peu à ça que sert le système de paquets d'une distrib. Le cas par contre où on laisse trainer un petit script owner=root dans un ~user par inattention ou parce-qu'on a besoin d'une petite manip régulièrement qui nécessite des droits plus élevés - au lieu de le mettre dans /root - me parait bien plus probable - et pire (quoique défoncer un fichier de conf /etc c'est déjà pas mal :)) Pour ceux qui flippent d'être affectés, tentez un "find /home -user root" et voyez ce qui sort et posez vous les bonnes questions

[@ChristopheCasalegno]

Bonjour Jack et merci pour ton message. En préambule : il y a très longtemps les logs web restaient quelque chose d'invisible aux yeux des clients. Aujourd'hui ces paradigmes ont bien changé. 90% des clients réclament un accès direct à ces logs, et c'est devenu un standard accessible dans bien des solutions. Ils ne sont quasiment jamais utilisés à des fins statistiques, ils sont utilisés notamment dans le cadre du debugging des applications. De même, il est devenu incontournable, de disposer d'un accès SSH, de git, etc. Ce n'est pas une opinion, c'est une constatation du marché, ayant la "chance" de gérer des activités dans ce domaine au travers de plusieurs sociétés et impliquant plusieurs milliers d'infrastructures. Concernant les logs web d'ailleurs cette tendance n'est pas si récente : il y a bien 10 ou 15 ans que ces demandes ont commencer à affluer. Dans un premier temps on ne mettait à disposition que des archives au moment de la rotation des logs. Dans un second temps, les gens ont commencé à vouloir pouvoir tail -f les logs pendant qu'ils travaillent. "sinon on leur met un cpanel ou autre" : ben non justement, j'ai cité cpanel comme étant non vulnérable à *ce* biais (ce qui ne signifie pas qu'il ne l'est pas à d'autres) mais c'est justement celui souvent considéré comme le numéro 1 du domaine qui y est totalement vulnérable... Tu peux chercher et tester, ça ne te prendra pas beaucoup de temps. Je ne parle pas de millions de serveurs vulnérables par hasard. Donc non il ne suffit plus de donner un accès ftp, ftps ou sftp pour "manipuler le contenu du site", aujourd'hui les gens ont besoin d'utiliser git, de mettre en place des processus et des scripts de déploiement automatiques, peuvent utiliser ansible pour se faire. De nombreux framework demande de pouvoir lancer une multitude de commandes en mode cli, et j'en passe. Bref cette époque est révolue, même pour moi qui suis un "vieux" du domaine, les paradigmes ont changés, et il faut s'y adapter... ou mourir. ""find /home -user root" : en fait *pas du tout*, ce n'est pas le concept que j'explique, ce n'est qu'un exemple. D'ailleurs pour les 2 exemples que j'ai cité, si à contrario le répertoire "racine" de l'utilisateur appartient lui même à root, l'exploitation ne fonctionnera pas (mais bien entendu cela induis d'autres possibilités complètements différentes). Excellente journée.

[@michaukoDOTorg]

​@@ChristopheCasalegno pour cpanel on est d'accord je le citais pour dire que s'il fait ça bien, très bien allons-y. En effet avec un tas de demandes d'outillages (débuggage live via les logs, git, ansible etc), on multiplie les besoins et donc les risques. A un moment, j'aurais tendance à dire au client que ce qu'il lui faut n'est pas un serveur mutualisé avec un vague accès ssh et plein d'outils, mais un OS complet où il installera ce qu'il veut, donc lui vendre une VM et il se démerde complètement. Sinon rapidement tu vas avoir un type à qui tu donnes un bout d'espace et d'outils sur une debian stable, tout est beau et merveilleux et puis rapidement il te demande je ne quel framework monstrueux qui manque de bol demande un php en version ultra récente only => tu commences à mixer tes versions php, installer des bouts de backports ou autre repo alternatif plus ou moins foireux ou mis à jour les jours de pleine lune seulement. Et tout ça "profite" (= fout la merde) aux autres clients hébergés. Il te demande l'accès aux logs etc. Bref à un moment on est dans la situation à risque que tu exposes. Mais c'est, je trouve, parce-qu'on aurait pas du lui vendre un bout de mutualisé alors qu'il a besoin d'une environnement complet. Autant isoler le bonhomme pour éviter de faire prendre un risque à tous les clients de la même machine qui n'ont pas besoin de tout ça. Et si le gars n'est "que" développeur et veut pas "gérer le système" ben alors lui aussi doit évoluer ou mourir : il fait devops ou je ne sais quel terme à la mode et bref, se met un peu à l'admin pour être conscient de ses actes et pas pondre une solution comme on voit trop souvent : un joli dev avec les aspects sécu, performances etc totalement ignorés. Pour le find user root : je disais ça car dans ton explication, je retenais surtout que si j'avais des scripts ou simple fichiers appartenant au root, dans un ~user, pour une raison ou une autre, ce user (volontairement ou suite à piratage) pouvait en gros en profiter pour faire n'importe quoi avec juste un mv ou un ln -s. D'où l'idée déjà de vérifier que j'ai pas laissé de fichiers avec un owner root dans le ~user avec lesquels il pourra me berner. Et le coup des fichiers de logs me faisait halluciner dès le départ. Si je constate que j'ai par exemple des fichiers de logs comme tu montres, je dois rapidement prendre conscience que c'est pas la solution pour mettre à dispo les logs au client, si tant est qu'il en ait besoin.

[@jyjyc9150]

Merci Christophe pour cette vidéo. J ai un serveur avec VIRTUALMIN, qu’en penses tu? Je débute dans l info gérance.

[@ChristopheCasalegno]

Hello JY, virtualmin n'est qu'une interface, c'est surtout l'installation et la configuration de toute la stack en amont (apache, php, mysql, etc.) qui va faire la différence. Bon dimanche :)

[@jyjyc9150]

@@ChristopheCasalegno d accord, j avais choisi centos8…. Merci pour ta réponse.

[@NRichard]

Très intéressant. Comment s'en prémunir du coup (●.◉ ? (parce que franchement c'est assez grave oui) P.S : ça m'a vraiment stressé ces notifications derrière 😮

[@ChristopheCasalegno]

Le problème c'est que s'agissant de défauts de configuration / implémentations qui sont la conséquences de concepts généraux, il n'y a pas de solution unique. Il faut l'intégrer de manière générale et après c'est au cas par cas que tu vas trouver une solution.

[@NRichard]

@@ChristopheCasalegno En gros, on considère ici que ce qui permet la compromission du système est le fait qu'un script avec des privilèges root (plus élevé que l'utilisateur de départ) aille taper dans le répertoire d'un utilisateur aux privilèges moins élevé ? Que chacun reste chez soi par exemple peut aider, non (pas de logs, de rép. admin chez un utilisateur lambda) ? (stay @ 127.0.0.1 ?)

[@nicolasp.7457]

Merci pour ces infos, je me rends compte qu'un de mes serveurs était vulnérable... J'ai honte 😱

[@ChristopheCasalegno]

Il n'y a pas de quoi à avoir honte. Il y en a qui diront / ecrirons qu'il faut être nul pour que ça arrive et qui y sont vulnérables en fait... Sur un use case différent. J ai vu des serveurs passer 3 audits de boîte de sécurité différents et ne pas relever le point.

[@mickaelmickael2218]

Salut Christophe je te met au defi de rentrer dans mon serveur 😁

[@ChristopheCasalegno]

T'en a pas, c'est ça ? xD

[@mickaelmickael2218]

@@ChristopheCasalegno han j aime les défis je fais une sauvegarde et on voit ça 😁

[@ChristopheCasalegno]

@@mickaelmickael2218 je prends 400 euros HT de l'heure en HO, 600 en HNO, 800 en férié / week-end HNO xD

[@mickaelmickael2218]

@@ChristopheCasalegno ah oui quand même lol xD tin si orange me payer comme ça.... Loool

[@ChristopheCasalegno]

@@mickaelmickael2218 quand tu travailles pour toi tu décides de ton tarif. Apres bien sur il faut que les clients acceptent ce prix. Pour l'instant j'ai de la chance je dois refuser des contrats toutes les semaines, ça ne sera peut être pas le cas toute ma vie mais en attendant, j'en profite :)

[@eccoyo]

Question d'un noob, a quel moment la faille commence ? Un utilisateur avec un mot de passe ? Le ssh ouvert ?

[@ChristopheCasalegno]

Hello, Ici c'est un concept de contournement des permissions via l'héritage. Le démarrage peut être via un shell, un site hacké, etc.

[@eddybash1342]

Ca n'existe pas sur Android grâce à sa surcouche de sécurité ?

[@ChristopheCasalegno]

Je ne connais pas assez Android mais je suppose que c'est surtout que les use cases correspondants vont être beaucoup plus rare. Android étant surtout pour du mobile ou éventuellement de l'embarqué.

[@eddybash1342]

@@ChristopheCasalegno ça explique que pour des serveurs web de qualité ( bancaire, finance ) que tout se passe spécifiquement dans une machine virtuelle ex : JVM Toutes les autres implémentations que java, me font rigoler ! ;) Qd je vois un ' CGI' dans le listing du ls, ça m'inquiète pour la sécurité de votre site web que je n'ai jamais vu pour l'instant... ;)

[@eddybash1342]

@@ChristopheCasalegno linux est une passoire comparé à la surcouche Android. Lol developer.android.com/topic/security/best-practices Ca fait vraiment mal au cœur de voir ça... Sorry linux !

[@ChristopheCasalegno]

@@eddybash1342 "Linux" est juste un noyau, pas un OS, mais dans tous les cas c'est inexact. Ce n'est pas un problème de l'OS mais bien un soucis chaise/clavier ici qui est à l'origine du problème. En ce qui me concerne, mes données les plus sensibles, sont stockées sur des machines Gnu/Linux (des fichiers chiffrés en 4096 bits eux même stockées sur une partition chiffrées que je ne monte que manuellement et à la volée). Il faut donc à la fois la passphrase pour la partition, la clef privée GPG et la passphrase de la clef privée. J'ai en plus ajouté une petite surprise à la première étape : une passphrase particulière déclenche la corruption des données. Bon courage :)

[@eddybash1342]

@@ChristopheCasalegno la faille est dans le PRNG que l'on vous fait croire de qualité cryptographique. ;) Vous pourriez nous montrer votre processus d'authentification puisse la sécurité réside dans le secret des clefs et non dans l'algorithme. ;)

[@HiPh0Plover1]

c'est dommage que tu explique pas pourquoi c'est le cas

[@ChristopheCasalegno]

Hello, Happy Turtle et merci pour ton message. En fait il me semblait que je l'expliquais : il s'agit tout simplement du fonctionnement "normal". La plupart ne l'ont juste souvent pas/mal compris, ou oubliés.

[@kalilinux1504]

Comme j'aimerais taper au clavier aussi vite que toi 😂

[@ChristopheCasalegno]

Salut Kali Linux, malheureusement il n'y a pas de lien entre compétence technique et vitesse de frappe, sinon toutes les dactylos seraient les meilleurs ingénieurs ;) En flow, je peux aller encore beaucoup plus vite, pourtant je ne respecte pas les règles de Dactylo (j'utilise assez peu le petit doigt que j'ai tendance à remplacer par l'annulaire)

[@kalilinux1504]

@@ChristopheCasalegno c'est vrai que ça n'a aucun rapport mais la a ce niveau là tu pourrais traduire les discours de Macron 😂 en tout cas super t'es videos 👍👌

[@ChristopheCasalegno]

@@kalilinux1504 xD Au plaisir d'échanger.

[@eddybash1342]

Ca vous fait quoi de savoir que l'on peut déterminer votre password en analysant la signature acoustique des touches de votre clavier ? Lol

[@ChristopheCasalegno]

Que c'est useless, car dans la pratique je n'utilise que des authentifications par clef associées à des restrictions (compte, bastion, etc. )

[@eddybash1342]

@@ChristopheCasalegno vous utilisez des ' clefs ' connectées à un port USB par exemple ? Vous ne saisissez pas de pin code ?

[@ChristopheCasalegno]

@@eddybash1342 Je parlais de clefs SSH pour me connecter sur le serveur. Pour le web et sauf exception (je vis en autarcie mise à part une sortie à l’hôpital toutes les 8 semaines)je passe par un proxy limité à mes seules adresses IP à laquelle se rajoute une authentification par login/pass. Mais l'un sans l'autre est useless. Cela dit : aucun système au monde n'est invulnérable, et le mien ne déroge pas à la règle : celui qui prétend le contraire, est, au mieux un ignorant, au pire un escroc, éventuellement les deux.

[@eddybash1342]

@@ChristopheCasalegno méfiez vous du sérum de vérité que l'on vous injecte toutes les 8 weeks à l'hôpital. Sans le savoir, vous avez déjà tout dit chez eux et vous crachez au bassinet régulièrement sous hypnose. ;) Vous allez certainement recevoir des claviers douteux pour Noël... Je me mefierais à votre place. Vous avez un copain radiologue à l'hosto ? Lol

[@delco2035]

@@eddybash1342 euh. Je crois que c'est la vie privée là.

[@bakkanoor]

Vulnérable de quoi ? De la mauvaise gestion de conf. d'un utilisateur, oui! La vidéo reste instructive pour des personnes voulant en découvrir des chose sur la gestion de droits mais rien de plus.

[@ChristopheCasalegno]

Pas d'un simple utilisateur mais de centaines de milliers de serveurs d'hébergement, tous les serveurs plesk, ainsi que des centaines d'hébergeurs mutualisés pour commencer.