Sécurité vs simplicité

Depuis au moins aussi longtemps que le monteur du présent site est en dévloppement, j'ai le projet de faire une partie privée à mon weblog, où je mettrais toutes les nouvelles que, pour une raison ou pour une autre, je ne souhaite pas afficher publiquement.

Je suis (enfin) pas loin du stade où je pourrai coder ça, et donc c'est à peu près la bonne période pour se poser la question du choix technologique : quel procédé vais-je utiliser pour restreindre l'accès à cette future section seulement aux personnes de mon choix ?

Je vois trois procédés à ma portée (si j'en oublie, n'hésitez pas à me le signaler) :

• un système d'identification perso', à base de cookie ;
• utiliser l'identification HTTP (RFC 2617) ;
• utiliser des certificats SSL.

Par le passé j'ai déjà codé les deux premières solutions, et les deux sont à peu près aussi pénibles l'une que l'autre : avec les cookies il faut réinventer la roue, la chambre à air et le manomètre, et l'identification HTTP n'a l'air plus facile que de prime abord, parce qu'il manque cruellement un standard pour demander au navigateur d'oublier l'identification, du coup il faut coder un tas de solutions ad hoc douteuses.

Mais en fait les questions de code ne regardent que moi, il me semble plus pertinent de s'occuper de prendre la question par le côté utilisteurs : qu'est-ce qui est le plus pratique ? Qu'est-ce qui est le plus sécurisé ?

Il y a habituellement un compromis entre sécurité et simplicité : les mesures les plus efficaces sont souvent les plus contraignantes à mettre en œuvre.

D'un point de vue sécurité, les systèmes à mot de passe, c'est-à-dire en l'occurence les deux premiers, sont connus pour être particulièrement mauvais. Utiliser le SSL, qui présente en plus l'avantage de crypter le flux, au cas où, permet une identification plus fiable.

Et de manière similaire, les systèmes à mot de passe sont plus facile d'accès, tous les gens qui sont un minimum présents sur le 'ternet ont l'habitude de ce genre de systèmes ; alors que gérer des certificats est beaucoup plus geek, et moins accessible aux gens « normaux ».

Mais est-ce réellement si clair ?

Un système d'identification par certificat demande une manipulation, certes plus complexe qu'entrer un login et un mot de passe, mais cette manipulation n'est à faire qu'une seule fois. Une fois le certificat entré dans le navigateur, il n'y a plus rien à faire. Il suffit qu'un(e) geek de bonne volonté, par exemple moi, s'occupe de cette manipulation à un moment opportun, et ce qu'il reste à faire pour l'utilisateur (c'est-à-dire rien) est beaucoup plus simple et plus pratique que devoir entrer régulièrement un mot de passe, sans le compter le fait de devoir le mémoriser en plus. Donc dans ce sens là, l'identification par certificat SSL est plus facile que les systèmes à mot de passe.

Malheureusement, niveau sécurité tout n'est pas clair non plus. Je veux permettre l'accès à certaines personnes, et non pas à certains navigateurs, ce qui fait une différence significative dans les situations où un ordinateur est utilisé par plusieurs personnes, ce qui est finalement assez courant comme situation. Je ne sais pas dans quelle mesure on peut attacher un mot de passe à un certificat particulier, mais dans ce cas le certificat ne serait pas plus pratique que les systèmes à mot de passe (mais pas moins non plus, c'est toujours ça).

D'un autre côté, pour peu que l'utilisateur soit un peu mobile, l'avantage (ou le non-désavantage) des certificats ne pèse pas très lourd : sans la procédure pour importer un certificat, l'utilisateur ne pourrait pas s'identifier ailleurs que depuis son navigateur pré-configuré. Il suffit d'un formatage de disque dur, de vacances, ou de lieu de travail où on ne peut pas jouer librement avec les certificats, pour que l'utilisateur se retrouve « enfermé dehors », ce qui a de quoi légitimement provoquer une frustration à faire préférer les systèmes à mot de passe.

Comme je n'arrive pas à résoudre cette question toute seul, je fais appel à vous, chers lecteurs, et plus particulièrement ceux qui auraient accès à cette section protégée : que pensez vous des différents aspects de la simplicité (ou non) des certificats, par rapport aux systèmes à mot de passe que vous connaissez sûrement ? Avez-vous un avis sur la question de la sécurité ? Quel compromis entre les deux vous sembe être le meilleur ?

Merci d'avance pour votre aide.

Commentaires

1. Le vendredi 11 septembre 2009 à 21:03, par Schmurtz :

Certificats :
Les certificats, c'est overkill comme fonctionnalité pour une page perso. En plus, c'est difficile à mettre en oeuvre aussi bien pour l'admin du serveur que les utilisateurs.

Authentification HTTP :
L'authentification HTTP en mode Digest (mais pas Basic !) est bonne, et ça se configure avec des fichiers .htaccess pas trop difficilement. Il faut juste faire attention que le fichier contenant les comptes ne soit pas accessible via le navigateur. Ça permet de protéger tout ce qu'il y a dans https://instinctive.eu/private/, par exemple.

Tu peux aussi avoir de l'authentification type HTTP avec du HTTPS, ce qui permet d'utiliser le mode Basic (qui sur du non-SSL laisse les mots de passe circuler en clair).

Dans les deux cas, tu crées toi même les comptes et transmet les mots de passe par mail aux gens. (éditer le fichier de mot de passe via une interface web est un peu scabreux, et risque de pénaliser la sécurité).

Authentification par formulaire (+cookies pour maintenir la session) :
Après, si t'es motivée pour rentrer dans le code, tu peux gérer des sessions authentifiées comme font généralement les sites. Attention à ne pas envoyer les mots de passe en clair sur le réseau ;), quand même.
Tu peux aussi utiliser une authentification

Après, ça dépend aussi du niveau d'intégration des parties privées dans le site actuel.

2. Le lundi 14 septembre 2009 à 10:38, par Natacha :

Ce commentaire est très intéressant, malheureusement une bonne partie de ces considérations passent à côté du fait que j'utilise un moteur personnel, et non pas un serveur web classique. Ainsi :
- il faudra « rentrer dans le code » quelque soit la solution choisie, il n'y a donc pas de .htaccess et gérer des certificats n'est plus compliqué que gérer des paires login/mot de passe ;
- « ne pas envoyer les mots de passe en clair sur le réseau », ça veut dire du SSL, donc intégrer à mon code OpenSSL ou GnuTLS, et après ça les certificats ne coûtent pratiquement plus rien à coder ;
- utiliser du SSL, c'est de toute façon se heurter à un souci de certificat, parce que je ne vais pas me payer la signature d'un CA, et je trouve firefox très désagréable dans ces cas là.

Cela dit, j'avoue qu'en plus des commentaires généraux comme le tiens, j'attendais aussi l'avis personnel des gens concernés, dont la plupart sont censés lire ce billet…

3. Le lundi 14 septembre 2009 à 18:40, par florimond :

Les certificats sont la vie !

4. Le samedi 19 septembre 2009 à 19:50, par un anonyme :

Le SSL c'est super d'un point de vue utilisateur, et la solution du ministère des finances (impôts) est facile pour l'utilisateur; on peut protéger les certificats personnels par mot de passe (demandé par Firefox au moment idoine). Il peut même y avoir plusieurs certificats pour le même site, et Firefox demande de choisir.

Bien entendu, je parle ici des certificats côté utilisateur, permettant d'authentifier l'utilisateur. Je doute que ce soit dissociable d'un cryptage/authentification SSL et donc d'un certificat côté serveur. Les certificats auto-signés, c'est pas considéré sûr par Firefox, un certif vérifié coute cher; c'est un problème récurrent mais je me demande si Firefox n'inclut pas depuis quelques temps le certif racine d'une autorité qui fournit des certifs gratuits à but non commercial (mais pas des certificats avec authentification de l'entité derrière, donc sécurisé "bleu", pas sécurisé "vert")

Un truc que certains sites font c'est passer en argument URL un identifiant de session, mais ça fait des liens dégueu que personne ne nettoie, et mettre du javascript partout pour passer l'identifiant en POST c'est pas plus propre.

Les cookies c'est pas si mal, finalement, la méthode HTTP je ne connais pas donc je ne peux pas dire. La plupart des sites que j'ai utilisés c'est par cookie, même les sites en https.

D'ailleurs, seul https te protège du eavesdropping.

Un autre truc: tu veux probablement mettre une directive HTTP interdisant le cache dans le navigateur, si tu en es à te demander qui a accès à l'ordinateur.

5. Le dimanche 20 septembre 2009 à 10:35, par FrnchFrgg :

Tiens, j'étais pourtant sur d'avoir mis mon pseudo dans le message précédent. Boarf.

6. Le dimanche 20 septembre 2009 à 12:40, par FrnchFrgg :

J'avais posté un commentaire pour dire que c'était StartSSL qui proposait des certificats gratuits acceptés par Firefox 3 et + (vérifié) et (selon eux) les autres navigateurs courants, mais le commentaire n'a pas pris.

En parlant de problème avec ton site, le flux RSS ne marche plus ou a changé d'adresse ?

7. Le lundi 21 septembre 2009 à 8:28, par Natacha :

J'avoue que ça fait longtemps que je n'ai pas regardé comment ça marche du côté des impôts, mais j'avais dans l'idée d'être mon propre CA, avec un certificat racine adapté à ajouter par les utilisateurs (ce qui est, d'après le lien que tu as donné, exactement aussi sécurisé que leur faire ajouter mon certificat auto-signé). J'imaginais qu'avec une jolie page pleine de screenshots qui explique comment on fait avec les navigateurs les plus populaires, ça irait.

La méthode HTTP, en gros du point de vue de l'utilisateur c'est à peu près identique aux cookies, mais ça a l'avantage (quand c'est bien fait) de ne pas faire passer le mot de passe en clair sur la connexion (ce qui n'est pas un problème quand c'est une connexion sur SSL, mais ce n'est pas toujours le cas avec les sites à cookie) mais seulement un hash (md5 pour l'instant, mais AFAIK il n'est pas encore assez troué pour que ce soit un problème).

Pour ce qui est de StartSSL, ce serait envisageable si Firefox 3 était le navigateur majoritairement utilisé par mes utilisateurs, mais c'est loin d'être le cas. Donc autant faire son propre CA.

Le flux RSS fonctionnait très bien, il y avait juste un petit problème dans le template de mon dernier dessin, qui aboutissait à quelque chose comme :
<img src= (uri) ".png alt="texte correct" title="texte correct" />
Si ça suffit à vautrer ton parseur XML, le souci est peut-être plus à son niveau qu'au mien…

Par contre pour ton commentaire, le site a fonctionné exactement comme prévu : tu t'es comporté comme un spammeur, en jetant un lien sans suivre la mise en forme officielle, donc ton commentaire a été modéré (c'est pour ça que tu ne vois pas le numéro 6, alors qu'il existe bien). En théorie à ce stade je le validerais, mais je ne suis pas sûre que tu aies été assez sage.

Cela dit, je concède que la modération ou la suppression par le filtre anti-spam manque un peu de retour à l'utilisateur, en cas de faux positif (tu es le premier dans ce cas). Coder ça est dans ma todo-list depuis quelques mois, ça finira bien par être fait un jour.

8. Le mardi 22 septembre 2009 à 21:39, par FrnchFrgg :

Ah... En fait je pensais que ne pas mettre de crochets me privait juste du statut de lien, avec <a> et tout le tintouin. Je n'avais pas imaginé que tu utilisais ce genre de règle pour filtrer. Peut-être que ça devrait être indiqué quelque part (et en particulier indiqué en gros au moment de la prévisualisation si il y a un lien problématique, déjà ça fait un bon feedback).

Et pour le problème du flux ATOM, ça fait partie de la spec qu'un fichier XML doit être refusé en bloc s'il y a une erreur dedans, donc mon parser XML se porte très bien, merci :)

9. Le mardi 22 septembre 2009 à 23:32, par Frnchfrgg :

Ah, et en fait, ce qui fait merder mon parser XML, c'est qu'il y a un <p> fermé par un </P> dans l'article sur VIM (à la fin de "vim vaut mieux que ça")

10. Le mercredi 23 septembre 2009 à 10:20, par Natacha :

« En fait je pensais que ne pas mettre de crochets me privait juste du statut de lien, avec <a> et tout le tintouin. » Mais c'est le cas. J'avoue que je suis assez déçue de te voir amalgamer comme ça sans honte règles de mise en forme et politique éditoriale. Je m'attendais à mieux venant de toi.

La plupart des gens qui postent des liens ici ne le font pas pour mon bien. On peut avoir un a priori positif envers ceux qui se donnent la peine de lire et d'utiliser les règles de mise en forme qui existent ici. On peut avoir un a priori négatif envers ceux qui tentent de mettre en forme n'importe comment, ainsi « <a href » et « [url » suffisent à envoyer le commentaire directement à la poubelle. Et lorsqu'on a pas d'a priori on laisse l'humain décider. Tu te permets de faire l'asocial en refusant de rendre le lien cliquable, et moi je n'aurais pas le droit de laisser le commentaire en attente quelques heures !? Ça me donnerait presque envie de passer le site en modération systématique, tiens.

« ça fait partie de la spec qu'un fichier XML doit être refusé en bloc s'il y a une erreur dedans » Le XML serait donc encore plus pourri que ce que je croyais… Je suis impressionnée, je ne pensais pas que c'était possible. Désolée, je vis encore à l'époque des dinosaures, cette époque glorieuse où on code C à partir des RFC, et où on est laxiste sur les entrées mais strict sur les sorties. Je vais donc prochainement remplacer les flux ATOM par un format moins débile, de toute façon c'est pas avec la quantité de gens qui s'en servent que ça changera grand chose.

11. Le jeudi 24 septembre 2009 à 16:56, par FrnchFrgg :

Ah, j'ai confondu "en attente de modération" avec "modéré (négativement)". Désolé.

Sinon, oui, XML, c'est la grande époque de partage en couille du W3C, suivi d'une brouette de standards en tous genres commençant par X (Xforms, Xhtml, Xtuvasvoircesttropcool, Xjenpasseetdesmeilleures). Cette grande époque s'est finie quand le W3C a enfin arrêté le projet XHTML2 et réintégré HTML5 qui avait été commencé par le WHATWG voyant que le W3C yoyotait.

D'ailleurs, faire du XHTML c'est bien (genre fermer correctement ses balises), mais déclarer ses documents en XHTML, il ne faut pas (avec le mimetype). D'abord parce IE refuse de l'afficher (il propose un téléchargement, iirc), mais aussi parce que Firefox se comporte alors comme avec ton flux ATOM: la moindre erreur et il n'affiche plus la page, juste un "Telle erreur à telle ligne telle colonne", comme le veut la spec.

HTML5 sera complètement compatible avec la syntaxe XHTML (et la rendra valide), aura même sans doute un mode XHTML5 qui rendra invalide les <p> sans </p> etc, mais qui exigera un parser laxiste (et, oui, iirc, HTML5 va jusqu'à définir comment doit se comporter le parser, indépendamment de ce qui est accepté ou pas).

Le parser Firefox est déjà HTML5 (entièrement réécrit pour l'occasion, d'ailleurs c'est un portage de l'implémentation de référence) mais seulement pour un doctype HTML 5 (et pour le firefox de developpement, pas le 3.5)

D'ailleurs, le doctype HTML5, c'est juste

<!DOCTYPE HTML>

Génial, non ?

Nota: XML est certes le début d'un méga partage en couille, et plein d'absurdités, mais par contre c'est nettement plus utilisable que la base précédente d'HTML qui était SGML (les <!DOCTYPE> et autres entités et DTD, c'est du SGML). C'est pour ça que de nombreux standards sont basés sur XML. Ce qui n'empêche pas que mandater un comportement de parser dans la définition de XML au lieu de proposer un comportement par défaut mais changeable dans chaque standard, c'est nullissime. Surtout pour un standard destiné aux échanges par réseau relativement bruité et enclin aux petites erreurs.

12. Le jeudi 24 septembre 2009 à 17:32, par Natacha :

À part ça, comme remplaçant aux flux ATOM, j'étais en train de regarder du côté de NNTP, ou IMAP s'il arrive à être contorsionné pour faire ça (d'après wikipedia, IMAP peut être utilisé pour lire des newsgroups [http://en.wikipedia.org/wiki/Network_News_Transfer_Protocol], reste à voir si c'est possible en anonyme read-only). J'imagine que poller une boîte IMAP n'est pas plus compliqué ni plus geek qu'utiliser un flux ATOM ou RSS.

13. Le dimanche 27 septembre 2009 à 13:18, par FrnchFrgg :

L'avantage le l'IMAP c'est que je crois qu'il existe un mode push où les clients connectés sont automatiquement notifiés des nouveaux messages sans avoir à poller. Par contre je pense que ça bousille mon workflow parce que je doute que Firefox soit un client IMAP. Bah, je changerait de manière de regarder ton site (pour le moment j'ai juste un menu dynamique de marque pages)

14. Le dimanche 4 octobre 2009 à 11:24, par Schmurtz :

Le site des impôts n'utilise plus l'authentification via certificats SSL (il ne l'impose plus, du moins, et propose une seconde solution). Ils ont du avoir trop de problèmes avec les "gens", qui n'ont pas toujours bien compris comment le faire marcher.

15. Le dimanche 4 octobre 2009 à 11:33, par Schmurtz :

Pour l'IMAP, c'est vraiment pas fait pour ça. Et quand on a un lecteur de flux RSS pour pleins d'autres sites, ça obligerai à ne plus voir les flux du tiens dans le même outil, ce qui n'est pas pratique :(.

16. Le lundi 5 octobre 2009 à 11:38, par Natacha :

Au sujet d'SSL, j'avoue que parfois je me demande si je ne surestime pas mes lecteurs par rapport aux « gens ». J'avoue ne pas arriver à imaginer comment on peut ne pas réussir à s'en sortir avec les certificats SSL quand il y a un tutoriel plein d'images comme je l'imaginais. Heureusement la difficulté de coder avec une bibliothèque SSL va problablement achever cette idée, et me faire revenir sur des cookies basiques.

Ah bon, IMAP n'est pas fait pour transmettre des éléments parmi une liste, chacun étant composé d'un corps en texte brut et/ou en HTML, avec des méta-informations comme l'auteur, la date, le titre, etc ? Bon quelque part, ça tombe bien, parce que la spécification d'IMAP est une horreur (et je ne suis pas la seule à penser ça [http://www.courier-mta.org/fud/]), donc je comptais plutôt faire du POP ou du NNTP.

Pour le problème des lecteurs, c'est vrai que ça va être révolutionnairement traumatisant pour les utilisateurs de vérifier dans Google Mail à la place de Google Reader, voire encore plus terrible, vérifier dans Thunderbird au lieu de Thunderbird. Et je ne parle même pas des utilisateurs de rss2email. Ce serait au moins aussi désastreux que si l'HTML ici devenait incompatible avec Opera.

17. Le mardi 6 octobre 2009 à 12:07, par Frnchfrgg :

<< Si l'HTML ici devenait incompatible avec Opera. >>

Parce qu'il l'est en ce moment ? Avec assurance et tout ? :)

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.