[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

認証に関するmistakeのブックマーク (7)

  • http://www.machu.jp/posts/20060521/p01/

  • まちがった自動ログイン処理

    (Last Updated On: )問題:まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考:自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保存されている ユーザ

    まちがった自動ログイン処理
  • 2006-05-07

    あなたが10の理由を示すべき10の理由。 「7の理由」ではパターン化しすぎているから。 9では少なすぎ、11では切りが悪いから。 体系的に広い視野で考えているように見てもらえるから。 なんだかんだいって10個くらいの理由は思いつくから。 10個も示せば一つくらいは「なるほど」と言ってもらえるから。 10個も示せば一度には読みにくいためブックマークしてもらえるから。 10個も示せば時間経過とともにランキング変動も調査できるから。 10位から発表していけば「1位は何だろう」と盛り上げられるから。 タイトルで「10の理由」と書いておいても、実際に10個も示す必要なんてないから。 ※流行ものらしいので、書いてみました。 はてな認証APIに関連して、kazuhoさんが以下のエントリを書いておられます。(via まちゅダイアリー) Re: はてな認証 API Hash ≠ MAC これは「秘密鍵をメッ

    2006-05-07
  • Google Calendar に見る RSS 認証の今後の方向性 : 管理人@Yoski

    先日リリースした toread.cc (あとで読むの英語版) がすごいことになっていて少々バタバタしつつも(「あとで」レポート書きます)、ひとまず落ち着いたエントリを。 さて、各所で話題になっている Google Calendar について。 (レビューは 秋元さんのブログ などで簡潔にまとめられていますので、そちらを参照して頂くとしてここでは割愛します。) さて、私が注目したのは Google Calendar の Atom フィードの配信方法です。 以前から「認証が必要なパーソナルデータをフィードで配信する方法」についてはいろいろな議論がなされていました。 少し前に一番基的で確実といわれていたのが HTTPS + 基認証 を用いる方法で、実際 GMail のフィードではこの方式が用いられています。 ※ GMail Atom フィード: https://gmail.google.co

  • Web の認証

    10.2. Web の認証Web の世界では Web サーバは通常ユーザ認証をするのに SSL もしくは TLS を使い、 サーバ側が認証しています。しかしユーザが誰なのかの認証は、簡単なことではあり ません。 SSL や TLS はクライアント側の認証ですが、実際に使用するに当たって、問題を たくさん抱えています(たとえば、Web ブラウザは共通のユーザ認証形式をサポート しておらず、ユーザがインストールするのは面倒です)。 JavaJavascript を使うと、それ自身に問題があります。それは、ユーザの多くが 無効にしていたり、ファイアーウォールにフィルタをかけていたりするからです。 そして、どちらかというと遅くなります。 たいていの場合、ユーザ毎にプラグインをインストールするのは非現実的でもあり ます。しかし、システムが比較的ユーザが少ないイントラネット向けなら、この 方法は

  • Flickr の認証API - naoyaのはてなダイアリー

    認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ

    Flickr の認証API - naoyaのはてなダイアリー
  • naoyaのはてなダイアリー - 認証API

    でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前になりつつある。Flickr APIの認証はアプリ作成がちょっと面倒になる場合がある(僕のMTプラグインとか)が、とりあえずそれでもいいし、TypekeyでもOpenIDでも試してみる価値はあるだろう。はてなやmixiは、そのサービスでのアイデンティティがそのまま他のサービス上でも通用することもあるわけで、認証APIがあればサービスの価値が大いに高まると思う。 ちょうど今朝認証APIをそろそろ作ろうかという話をして、プロジェクトを立ち上げました。ラボも作ったことだし、そろそろはてなIDを使ってアプリケーションが作れるようにしたいなという意志がありまして。 過去にもはてなのサービスを Hack した

    naoyaのはてなダイアリー - 認証API
  • 1