Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
您最多选择25个主题 主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符

comments.html 12KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123
  1. <div class="comment" typeof="schema:UserComments">
  2. <p class="comment-meta">
  3. <span class="comment-author" property="schema:creator">Yann</span> le <span class="comment-date" property="schema:commentTime">09/01/2007</span> :
  4. </p>
  5. <div class="comment-content" property="schema:commentText">
  6. <p>Effectivement, avec un peu de recul, on se rend compte que la technologie n'en est encore qu'à ses balbutiements et n'est pas tout à fait prête à être massivement déployée...<br />
  7. <br />
  8. Malgré tout, OpenID paraît évoluer vite et devrait rapidement arriver à maturité... Non ?</p>
  9. </div>
  10. </div>
  11. <div class="comment" typeof="schema:UserComments">
  12. <p class="comment-meta">
  13. <span class="comment-author" property="schema:creator">Eric Daspet</span> le <span class="comment-date" property="schema:commentTime">09/01/2007</span> :
  14. </p>
  15. <div class="comment-content" property="schema:commentText">
  16. <p>Le pishing est extrêment simple : il suffit que vilain-pirate.com se connecte à votre serveur openid (il en connait l'url) et recopie l'interface et le graphisme. C'est simple à faire et peut être fait automatiquement derrière votre dos sans intervention humaine.<br />
  17. <br />
  18. Avoir une question ou une marque personnelle sur votre serveur openid n'est d'aucune aide. Quand vilain-pirate.com se connecte sur votre serveur openid pour recopier l'interface, il peut tout seul proposer votre login et obtenir votre interface et votre graphisme spécifique. C'est quelque chose de public vu que c'est justement quelque chose qui intervient avant que vous tapiez le mot de passe. Aucune difficulté pour le recopier en dynamique. A vrai dire ça sera recopié sans même le faire exprès.<br />
  19. <br />
  20. <br />
  21. <br />
  22. Maintenant ... il est où le problème ? On est dans la même problématique que partout ailleurs sur Internet. OpenId ne résoud pas la problématique du pishing, ça n'est pas son rôle, mais il ne vous y expose pas plus pour autant. Comme partout ailleurs, avant de s'identifier il faut vérifier l'url dans le navigateur, vérifier le joli cadenas SSL (et en cas de doute retapper soi même l'url). <br />
  23. <br />
  24. Il n'y a pas lieu de s'inquiéter plus du pishing avec openid qu'avec quoi que ce soit d'autre. En fait c'est même l'inverse : pour peu que vous vous identifiez au préalable, vous avez un risque qui est assez faible (si on vous redemande un mot de passe, vous savez qu'il a problème vu que vous êtes déjà authentifiés).</p>
  25. </div>
  26. </div>
  27. <div class="comment" typeof="schema:UserComments">
  28. <p class="comment-meta">
  29. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">10/01/2007</span> :
  30. </p>
  31. <div class="comment-content" property="schema:commentText">
  32. <p>@Yann : j'espère ;-)<br />
  33. <br />
  34. @Eric Daspet : <br />
  35. &gt; Quand vilain-pirate.com se connecte sur votre serveur openid pour recopier l'interface, il peut tout seul proposer votre login et obtenir votre interface et votre graphisme spécifique.<br />
  36. <br />
  37. Sauf si l'interface laisse le choix entre plusieurs photos (dont la tienne) et que ces photos changent selon l'ip qui appelle la page (sinon il en faudrait trop pour que le vilain pirate n'arrive pas à identifier laquelle revient toujours).<br />
  38. <br />
  39. Même chose si l'utilisateur doit choisir entre plusieurs questions dont la sienne.<br />
  40. <br />
  41. &gt; Il n'y a pas lieu de s'inquiéter plus du pishing avec openid qu'avec quoi que ce soit d'autre.<br />
  42. <br />
  43. Sauf qu'on est rarement amené à être redirigé pour entrer nos identifiants/mots de passe. C'est là où c'est dangeureux.</p>
  44. </div>
  45. </div>
  46. <div class="comment" typeof="schema:UserComments">
  47. <p class="comment-meta">
  48. <span class="comment-author" property="schema:creator">Eric Daspet</span> le <span class="comment-date" property="schema:commentTime">10/01/2007</span> :
  49. </p>
  50. <div class="comment-content" property="schema:commentText">
  51. <p>@David:<br />
  52. <br />
  53. Pour les photos : pas mieux.<br />
  54. vilain-pirate.com a juste à faire une requête sur ton provider et recopier ce qu'il voit. Si ton provider donne le choix entre plusieurs photos, vilain-pirate.com se contente de tout recopier et te donnera le choix entre les mêmes photos.<br />
  55. Quand tu choisiras ta photo, c'est vilain-pirate.com qui recoit le choix, et qui peut l'utiliser ensuite.<br />
  56. C'est toujours la même IP qui fait ici la demande à ton provider : celle de vilain-pirate.com.<br />
  57. <br />
  58. Quoi que tu demandes à l'utilisateur (photo, question ou simple mot de passe), recopier exactement la page qui compose la question/demande et intercepter la réponse (pour éventuellement la rejouer en interne) c'est simple et ça peut être fait automatiquement en temps réel.</p>
  59. </div>
  60. </div>
  61. <div class="comment" typeof="schema:UserComments">
  62. <p class="comment-meta">
  63. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">10/01/2007</span> :
  64. </p>
  65. <div class="comment-content" property="schema:commentText">
  66. <p>@Eric : dans ce cas il suffit d'inverser l'ordre les identifiants/mots de passe sont demandés dans un premier temps et les images sont affichées ensuite. Au pire, il y a corruption de l'identification mais étant donné que la seconde étape ne peut être franchie, il est toujours possible de changer son mot de passe une fois que l'on se rend compte de la supercherie... </p>
  67. </div>
  68. </div>
  69. <div class="comment" typeof="schema:UserComments">
  70. <p class="comment-meta">
  71. <span class="comment-author" property="schema:creator">near</span> le <span class="comment-date" property="schema:commentTime">10/01/2007</span> :
  72. </p>
  73. <div class="comment-content" property="schema:commentText">
  74. <p>Je vois openid interessant pour sa propre infrastructure et la perennité des comptes utilisateurs... Jamais je n'utiliserais un compte openid, même si c'était sur mon propre serveur ! Ce serait plutôt transparent pour l'utilisateur... <br />
  75. <br />
  76. Pour donner un exemple : tu crées un site qui permet de partager des photos. Tu fais inscrire les utilisateurs sur un serveur openid, mais ils ne le savent pas car le serveur openid est privé, et puis ce n'est pas leur problème de toute manière. Ils se logguent aussi sur ton site grâce à ce même serveur. Plus tard, tu crées une plateforme de blog, et tu souhaites en faire profiter tes utilisiteurs (déjà heureux d'avoir un endroit sympa où échanger leurs photos) : tu veux que ce soit simple pour eux (pourquoi devraient-ils se réinscrire alors que ce nouveau service vient de toi ?) et pour toi (hmm... comment vais-je faire pour gérer les users existants ?) et c'est là qu'openid va être interessant. Certes, il n'a aucun intérêt pour tes utilisateurs &quot;techniquement&quot; (ils s'en foutent, ils veulent juste ne pas avoir à se réinscrire), mais pour toi, c'est une grosse épine en moins.<br />
  77. <br />
  78. L'authentification inter-serveurs (dans le sens, inter-domaines) est relativement chiante à gérer... combien j'ai entendu de gens me demander &quot;comment je peux récupérer un cookie provenant d'un autre domaine&quot;. A première vue, on pourrait se dire &quot;je sais pas où ce gars a appris à faire du developpement web, mais il devrait vite lire les specs http&quot;. Hors, pour les boites qui fournissent des services très variés (comprendre, sur différents sites), c'est créer un pseudo-protocole pour pouvoir authentifier un users à plusieurs endroits indépendants. On peut feinter et faire en sorte de pointer toujours vers la même base de données (c'est légitime, mais...), ou d'utiliser une tronçonneuse (des services d'annuaire, complexité pour pas grand chose), ou autre. Mais avec openid c'est bien, c'est beau, c'est b... propre.<br />
  79. <br />
  80. La solution d'une base de données interne est bonne aussi, la quasi-totalité des sites de services doivent penser comme celà. Mais là où ça se corse, c'est comment faire pour gérer l'interopératibilité : exemple, comment MSN et Yahoo ont-ils fait pour pouvoir taper dans leurs bases respectives lorsqu'un utilisateur de MSN Messenger ajoute son copain sous Yahoo IM (et vice-versa) ? Je suis quasiment certains que les 2 bases n'avaient rien à voir, et qu'ils ont du inventer un protocole à eux pour &quot;inter&quot;-authentifier les utilisateurs. Vous imaginez le travail... Bien sûr, on pourrait croire qu'on aura jamais à &quot;partager&quot; sa base d'utilisateurs avec quelqu'un d'autre, mais le fait qu'openid existe prouve bien le contraire.<br />
  81. <br />
  82. L'autre problème est la perennité. Imaginons que MSN meurt, que faire des x millions d'utilisateurs sous MSN qui se retrouvent orphelins, alors qu'ils sont encore dans les listes de Yahoosiens ? Imaginez sans un serveur type openid... ils pourraient migrer les serveurs, et continuer comme si de rien était en interne bien sûr, mais quel bazar alors qu'il y'a des solutions (presque) toutes prêtes.<br />
  83. <br />
  84. Je n'ai pas lu les spécifications d'openid, je me suis juste interessé au concept de SSO (Single Sign-On). Ce que je verrais bien, c'est un super-sso, qui pourrait gérer les identités. Je ne sais pas si openid fait ça, mais ça serait bien de pouvoir dire &quot;pour ce site je veux être untel avec telles informations&quot;, etc... Il y'a énormément de documents interessants sur le sujet.<br />
  85. <br />
  86. PS : je ne pense pas que MSN et Yahoo aient eu de gros problèmes... vu le nombre d'utilisateurs, leurs architectures ont surement été bien pensées, et la &quot;fusion&quot; faite sans douleur :)</p>
  87. </div>
  88. </div>
  89. <div class="comment" typeof="schema:UserComments">
  90. <p class="comment-meta">
  91. <span class="comment-author" property="schema:creator">RockPepper.com</span> le <span class="comment-date" property="schema:commentTime">24/04/2007</span> :
  92. </p>
  93. <div class="comment-content" property="schema:commentText">
  94. <!-- TB -->
  95. <p><strong>OpenID, c&#8217;est quoi ?</strong></p>
  96. <p>Tu lis partout &#8220;OpenID&#8221; ? Tes potes te parlent tout le temps d&#8217;OpenID ? On te conseille OpenID ? On te dit &#8220;OpenID, c&#8217;est le bien&#8221; ? OpenID, OpenID, OpenID, OpenID&#8230; Tu te sens seul. Oui. Seul. Non, s&#8217;il t...</p>
  97. </div>
  98. </div>
  99. <div class="comment" typeof="schema:UserComments">
  100. <p class="comment-meta">
  101. <span class="comment-author" property="schema:creator">noura</span> le <span class="comment-date" property="schema:commentTime">04/05/2007</span> :
  102. </p>
  103. <div class="comment-content" property="schema:commentText">
  104. <p>je veux savoire c'est quio la corruption?</p>
  105. </div>
  106. </div>
  107. <div class="comment" typeof="schema:UserComments">
  108. <p class="comment-meta">
  109. <span class="comment-author" property="schema:creator">scaf</span> le <span class="comment-date" property="schema:commentTime">08/01/2008</span> :
  110. </p>
  111. <div class="comment-content" property="schema:commentText">
  112. <p>Selon moi le phishing n'est pas une menace pour openID.<br />
  113. <br />
  114. On vous a déjà fait du phising pour pirater votre compte de recette sur marmiton.org ou de partition de guitare ?!<br />
  115. - je suis près à vous passer mes identifiants si ça peut vous être utile -<br />
  116. <br />
  117. Si on part sur le fait que 60% des sites que je consulte ont casiment les même identifiant me concernant, et que les services sécurisé (banque, mails) le restent, cet identifiant unique pourrait bien décharger ma mémoire d'un bon kilo d'identifiant superflu dont je me fiche royalement de leur apport en terme de sécurité.<br />
  118. <br />
  119. J'ai trouvé interessant l'idée de pouvoir choisir par site le niveau d'information à transmettre.<br />
  120. Le must serais d'integrer ce robinet de notre &quot;vie privée&quot; directement depuis le navigateur, ça reglerais l'enventuel problème de phising pour des sites + sensibles.</p>
  121. </div>
  122. </div>