loading
L'authentification unifiée et la sécurité...
De nos jours, il est nécessaire, si l'on désire avoir une activité plus ou moins importante sur le web, de participer à l'univers généré par pas mal de sites. Qui dit participation dit nécessité d'authentification et on peut très vite se retrouver submergé de comptes dispersés sur la toile. Ce fut le sujet principal de la conférence d'Eric Daspet (@edasfr).
Plusieurs possibilités s'offrent à nous si l'on décide de se créer un compte. Soit on utilise le même nom d'utilisateur et le même mot de passe partout, pour simuler une authentification centralisée, créant ainsi une énorme faille de sécurité, soit on crée des noms d'utilisateur et/ou surtout des mots de passe différents pour tous les sites, ce qui peut très vite devenir fastidieux et très désagréable (je prend volontairement les deux extrêmes, tout autre cas n'étant qu'un compromis proportionnel de ces deux là).
Il est à noter que Yahoo offre une très bonne alternative à cela pour des connections ponctuelles, grâce à un système de jeton d'authentification valable quelques minutes sans inscription nécessaire à condition d'avoir un ami inscrit au service.
Mais il y a une autre solution bien plus pratique : certains services d'authentification centralisée sont disponibles, comme par exemple openID ou oAuth, pour citer les plus connus pour ce type d'authentification.
Si un service que l'on appellera arbitrairement Yukulele décide d'intégrer pleinement openID (par exemple), il accèpte qu'un utilisateur se connecte grâce à son compte openID s'il en possède déjà un aux services fournis par Yukulele, et/ou qu'il se connecte à d'autres services supportant openID grâce à ses identifiants créés pour Yukulele.
Certains comme Google ou Yahoo ne l'implémentent qu'à moitié, ils fournissent des identifiants openID mais n'acceptent pas des connections à partir d'identifiants externes. Concrètement, vous pouvez vous connecter sur http://identi.ca/ avec votre compte gmail en tant qu'openID, mais gmail refuse que vous vous connectiez avec votre compte openID fourni par launchpad, par exemple.
Intégrer openID permet à l'utilisateur final du service une utilisation plus aisée, moins contraignante, il hésitera donc moins avant de participer, n'ayant pas besoin de se crée un nouvel identifiant.
L'intégrer peut prendre du temps, mais en pesant le pour et le contre, on se rend vite compte que c'est un excellent investissement.
Les notions d'identifications et authentifications nous amènent natuerellement à la conférence de Christian Heilmann @codepo8 sur la sécurité dans le domaine du web.
L'utilisation d'un mot de passe identique sur tous les sites auquel on est inscrit est, comme dit précédemment un réel problème.
Oui les mots de passe peuvent être (et sont heureusement généralement) stockés de façon encryptée en base de données, mais au moment de la création du compte, un script malveillant peut très bien essayer de se connecter à votre compte google que vous aurez bien sûr mis en adresse email grâce à ce mot de passe dans le but de tirer des informations précieuses vous concernant, par exemple, il est donc nécessaire d'utiliser des mots de passe différents (à moins que le service utilisé propose une alternative au mot de passe, tel qu'openID …).
Chris nous a ensuite fait une démonstration d'un hack twitter permettant de contourner la protection des notification d'un utilisateur, comme quoi quelque chose peut paraître sécurisé, et bien qu'étant très employé, ne pas l'être du tout. La popularité n'est pas forcément source de fiabilité.
Après des slides tous plus exotiques et originaux les uns que les autres, il a abordé l'importance des fichiers du type robot.txt qui dévoilent les pages d'administration ou autres données critiques (il est à noter que par défaut apache laisse accès aux dossier .svn contenant tout le code source de votre projet. Si vous gérez votre projet avec subversion, vérifiez vos configurations ! surtout si vous avez des script de donné automatique), et les fichiers htaccess qui permettent d'empêcher celà.
Il coule de source qu'un code non maintenu est voué à être une faille de sécurité un moment ou un autre, vieillissant mal, donc bannissez le vieux code ou maintenez le.
Le web est plein de dangers, il ne faut pas les sous estimer. La conférence qui rend parano...
Les slides de Chris sont beaux, clairs et drôles : http://www.slideshare.net/cheilmann/basic-housekeeping-plugging-obvious-security-holes-in-web-sites-paris-web2009
Conclusion : N'utilisez plus IE6, c'est le mal, tuez le. (coin ! @glazou)
PS : n'hésitez pas à tuer flash aussi, si vous en avez l'occasion.
/me réserve le troll sur microsoft pour un autre jour.
De nos jours, il est nécessaire, si l'on désire avoir une activité plus ou moins importante sur le web, de participer à l'univers généré par pas mal de sites. Qui dit participation dit nécessité d'authentification et on peut très vite se retrouver submergé de comptes dispersés sur la toile. Ce fut le sujet principal de la conférence d'Eric Daspet (@edasfr).
Plusieurs possibilités s'offrent à nous si l'on décide de se créer un compte. Soit on utilise le même nom d'utilisateur et le même mot de passe partout, pour simuler une authentification centralisée, créant ainsi une énorme faille de sécurité, soit on crée des noms d'utilisateur et/ou surtout des mots de passe différents pour tous les sites, ce qui peut très vite devenir fastidieux et très désagréable (je prend volontairement les deux extrêmes, tout autre cas n'étant qu'un compromis proportionnel de ces deux là).
Il est à noter que Yahoo offre une très bonne alternative à cela pour des connections ponctuelles, grâce à un système de jeton d'authentification valable quelques minutes sans inscription nécessaire à condition d'avoir un ami inscrit au service.
Mais il y a une autre solution bien plus pratique : certains services d'authentification centralisée sont disponibles, comme par exemple openID ou oAuth, pour citer les plus connus pour ce type d'authentification.
Si un service que l'on appellera arbitrairement Yukulele décide d'intégrer pleinement openID (par exemple), il accèpte qu'un utilisateur se connecte grâce à son compte openID s'il en possède déjà un aux services fournis par Yukulele, et/ou qu'il se connecte à d'autres services supportant openID grâce à ses identifiants créés pour Yukulele.
Certains comme Google ou Yahoo ne l'implémentent qu'à moitié, ils fournissent des identifiants openID mais n'acceptent pas des connections à partir d'identifiants externes. Concrètement, vous pouvez vous connecter sur http://identi.ca/ avec votre compte gmail en tant qu'openID, mais gmail refuse que vous vous connectiez avec votre compte openID fourni par launchpad, par exemple.
Intégrer openID permet à l'utilisateur final du service une utilisation plus aisée, moins contraignante, il hésitera donc moins avant de participer, n'ayant pas besoin de se crée un nouvel identifiant.
L'intégrer peut prendre du temps, mais en pesant le pour et le contre, on se rend vite compte que c'est un excellent investissement.
Les notions d'identifications et authentifications nous amènent natuerellement à la conférence de Christian Heilmann @codepo8 sur la sécurité dans le domaine du web.
L'utilisation d'un mot de passe identique sur tous les sites auquel on est inscrit est, comme dit précédemment un réel problème.
Oui les mots de passe peuvent être (et sont heureusement généralement) stockés de façon encryptée en base de données, mais au moment de la création du compte, un script malveillant peut très bien essayer de se connecter à votre compte google que vous aurez bien sûr mis en adresse email grâce à ce mot de passe dans le but de tirer des informations précieuses vous concernant, par exemple, il est donc nécessaire d'utiliser des mots de passe différents (à moins que le service utilisé propose une alternative au mot de passe, tel qu'openID …).
Chris nous a ensuite fait une démonstration d'un hack twitter permettant de contourner la protection des notification d'un utilisateur, comme quoi quelque chose peut paraître sécurisé, et bien qu'étant très employé, ne pas l'être du tout. La popularité n'est pas forcément source de fiabilité.
Après des slides tous plus exotiques et originaux les uns que les autres, il a abordé l'importance des fichiers du type robot.txt qui dévoilent les pages d'administration ou autres données critiques (il est à noter que par défaut apache laisse accès aux dossier .svn contenant tout le code source de votre projet. Si vous gérez votre projet avec subversion, vérifiez vos configurations ! surtout si vous avez des script de donné automatique), et les fichiers htaccess qui permettent d'empêcher celà.
Il coule de source qu'un code non maintenu est voué à être une faille de sécurité un moment ou un autre, vieillissant mal, donc bannissez le vieux code ou maintenez le.
Le web est plein de dangers, il ne faut pas les sous estimer. La conférence qui rend parano...
Les slides de Chris sont beaux, clairs et drôles : http://www.slideshare.net/cheilmann/basic-housekeeping-plugging-obvious-security-holes-in-web-sites-paris-web2009
Conclusion : N'utilisez plus IE6, c'est le mal, tuez le. (coin ! @glazou)
PS : n'hésitez pas à tuer flash aussi, si vous en avez l'occasion.
/me réserve le troll sur microsoft pour un autre jour.