Sécuriser le bookmarklet

[ldleman]

Pour l'auto connexion dans le bookmarklet, faire passer le hash dans l'entete http de manière a ce qu'il soit crypté sur le réseau :

http://login:hash@nomduserveur/flux/, le navigateur met dans l'en-tête HTTP Authorization: Basic base64(login:mdp)

C'est chiffré en SSL ,côté serveur,on lis cet en-tête, on decode64, on coupes ":" et c'est bon.

[ldleman]

Voir pour la v2.0

[Sbgodin]

Tu pourrais faire un "milestone" pour la v2.

[ldleman]

Tu t'en tirera pas comment ça :p, vas d'abord falloir m'expliquer ce que c'est et comment on s'en sert :D ! (ça faisait trop longtemps que je ne t'avais pas saoulé avec mon gitincultisme (oui j'invente des mots, mais c'est classe)

[Sbgodin]

C'est spécifique à la gestion des tickets de Github. Dans cette page, à droite du "Ldleman is assigned" il y a un "No milestone" (pas de borne/étape). Si tu cliques sur la roue cranté, tu verras qu'il y en a déjà un "importExport refondu". J'y ai déposé tous les bug à résoudre avant la prochaîne (proposition de) fusion de la branche importExport. On peut filtrer selon la borne.

Donc, tu peux créer les bornes dans l'onglet "Milestones", à côté de "Browse issues".

[ldleman]

Donc le but serait de créer un milestone v2.0 et d'y mettre toutes les suggestions qui correspondent à ce qu'on doit faire en v2.0 ? :)

[Sbgodin]

Le Tue, 26 Mar 2013 13:06:30 -0700 Idleman notifications@github.com a écrit :

Donc le but serait de créer un milestone v2.0 et d'y mettre toutes les suggestions qui correspondent à ce qu'on doit faire en v2.0 ? :)

C'est l'idée. Tu y places ce que tu approuves, et on sait tous le bout de chemin qu'il reste à faire.

Christophe HENRY FR EO EN - http://www.sbgodin.fr

[ldleman]

Mais ça inclus que je sache ce que je veux faire plus de 10 minutes avant que ça germe dans mon cerveau ça !? :D

[Sbgodin]

C'est la rançon du succès. Si ça continue, tu vas passer ton temps à gérer/diriger et moins coder. Il y a 42 tickets ouverts, des messages et tout...

[ldleman]

Le soucis étant que gérer c'est déjà ce que je fais au boulot, et la raison pour laquelle je code pour le plaisir à la maison :p, si au moins l'argent venait en même temps que le succès soupir

Bon ben jvais voir pour ce milestone mais faut que je réfléchisse a ce que je vais y mettre, je voudrait pas non plus me mettre la pression, leed doit rester un plaisir et pas une machine à pression sinon je n'aurais plus le cœur à m'y mettre :)

[Phyks]

Un gros +1 pour cette feature. Le bookmarklet est un peu critique là avec la connexion faite automatiquement.

Pourquoi ne pas utiliser le même système que dans shaarli ? Un bookmark qui renvoie sur la page de connexion (puis redirige vers l'action demandée). Si l'utilisateur est logué, c'est transparent, sinon, il doit se connecter d'abord. Plus de problèmes de mots de passe / hashs qui se baladent comme ça.

[ldleman]

Le but est plus de faciliter la vie à l'utilisateur que d'hover-securiser une application qui à la base n'est pas vraiment sensible (leed n'étant pas non plus un logiciel de gestion bancaire), faire passer le mdp dans l'entete permettra d'allier la sécurité et le coté pratique, c'est rare d'avoir des solutions de compromis entre l'accessibilité et la sécurité alors autant en profiter ^^

[Phyks]

En fait, je ne vois pas le vrai intérêt de passer le mot de passe en en-tête.

Si on a du SSL, ok le mot de passe est chiffré. Mais sinon, il se balade en clair dans l'en-tête, ce qui est certes déjà le cas avec le formulaire de connexion, mais reste moins bien qu'un token (au pire, si le token est intercepté, ce n'est pas un mot de passe potentiellement multi-sites qui tombe).

Dans tous les cas, en-tête, POST et GET sont protégés en SSL il me semble. Donc que ce soit un token qui passe en GET ou un mot de passe en en-tête, c'est pareil. La seule différence étant que l'en-tête HTTP (contrairement au token en GET) ne risque pas de ressortir dans une variable REFERRER.

Après, je suis d'accord que c'est pas la peine d'oversécuriser Leed, mais un système comme sur Shaarli, ça marche pas mal -> si l'utilisateur a encore une session en cours, c'est transparent. Sinon, il se connecte via le formulaire.

[ldleman]

Le but étant de passer le token en entête plutôt qu'en paramètre de manière à le camoufler un peu plus et non de remplacer le token par un password en clair (ce qui serait pire j'en conviens).

Perso je trouve pas top le système de shaarli, je suis souvent amené à vider ma session lors de mes devs, et je dois sans arrêt me reco à shaarli, le but d'un bookmarklet pour moi et d'effectuer une action très rapidement et en toute simplicité, si l'on doit passer les 3/4 du temps à se reconnecter je trouve que ça perd de son utilité et qu'il vaut mieux l'enlever.

Comme je le disais l’application leed n'est pas sensible, et comme on utilise un token plutôt qu'un mot de passe seul les données de l'application sont en danger dans le cas d'une attaque, je pense que ça vaut bien le confort d'avoir un bookmarklet rapide et sans prise de tête :).

[Sbgodin]

J'ai vérifié à l'instant avec Wireshark. Soit j'ai fait une grosse boulette, soit il se passe vraiment ce qui suit.

En HTTP, tout se passe en clair. En cas d'interception du flux, tout est récupéré que ce soit GET ou POST.

En HTTPS, presque toute la liaison est sécurisée. Ne transpirent que l'adresse IP du serveur et l'hôte demandé. Les paramètre GET, figurant sur l'url, ne sont pas visibles. En HTTPS, l'accès à Leed est donc autant sécurisé que HTTPS. Il n'y a rien à faire de plus je pense.

L'implémentation actuelle n'utilise pas directement le couple login/passe mais un jeton fabriqué à la base des deux. Ce n'est pas idéal, mais au passage en multi-utilisateurs on aura un jeton aléatoire par utilisateur.

Je pense qu'on peut fermer ce ticket. @ldleman ?

[ldleman]

oki doki