パスワードを忘れた？ アカウント作成
Close
14985 story

ヤフーと産総研、フィッシングを防止するパスワード相互認証技術を開発 43

ストーリー by kazekiri
ドラフト見ないとな 部門より

ee1000mt 曰く、

Internet Watchによれば、ヤフーと産業総合技術研究所の情報セキュリティ開発センターが、フィッシング詐欺を防止するパスワード相互認証技術を開発したとのこと。この技術は、PAKE (Password Authenticated Key Exchange)を改良したもの。通常はサーバ側だけでパスワードの正当性を検証するが、PAKE方式ではユーザー側でもそのサーバーが自分のパスワードを過去に 登録したサーバーであるかを検証することになる。

今回の技術は、2007年度中にYahoo!オークション上で実証実験され、 RFC化に向けたインターネットドラフト起草、さらにオープンソース化されるということだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ヤフーと産総研、フィッシングを防止するパスワード相互認証技術を開発 More

    • Re:その他の記事 (スコア:0)

      by Anonymous Coward
      ひろみちゅ先生のところですね。

    • Re:その他の記事 (スコア:0)

      by Anonymous Coward
      ソフトバンクが虚業とか技術なしとか言われて久しかったと
      思いますがようやくヤフーからなんですかね。
      「から」と言うより、「しか」なのかな？
    • ヤフーと産総研、釣り記事を防止するプロトコルを開発

      (ここらへんに釣られるクマーのAA)

  • パスワード (スコア:2, 興味深い)

    by STT (32350) on 2007年03月26日 19時40分 (#1132456)
    このPAKEは、パスワードの文字列をサーバに保存する？

    一定の法則でパスワードを決めているのですが、法則が
    バレると芋づる式に、パスワードがバレそうです。
    パスワードの漏洩が無いか個人情報が漏洩と同じぐらい
    ビクビクしています。

    途中の経路は、SSLの証明書でよいとして、、、
    ここに来るようなWebアプリの開発者の人は、ユーザ認証用
    にデータベースに、そのままパスワードを保存しないでmd5
    とかsh1をしてから保存していますか？
    それとも、パスワードをデータベースに保存しなくて他の
    認証手段を使う？

    • オフトピ Re:パスワード (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2007年03月26日 22時42分 (#1132541)
      ここに来るようなWebアプリの開発者の人は、ユーザ認証用 にデータベースに、そのままパスワードを保存しないでmd5 とかsh1をしてから保存していますか？

      仮にそれがされてたとしても、サーバには毎回生のパスワードが送信されている（SSKの復号もされている）わけですが。知ってました？

      • それでも、データベースにはそのままパスワードを保存しない方がよいのでは？

        よく聞く、パスワード流出の原因は
        SQLインジェクションだったり
        内部犯行によるデーターベースの持ち出しや
        外部にPCのログインアカウントとパスワードが流失し
        PC侵入されデータベースの流出と
        パスワードを暗号化してれば防げた (流出したとしても無意味なデータ)
        もしくは被害をかなり小さくできた物が多く感じます。
    • パスワードリストが漏れたら、被害者多数になる可能性が高いのでは？
      何かの後払いの注文とかでも、キャンセルを認めないなんて事はしてこないと思う。してきたとしても、被害者多数と言う状況から何処から漏れたかは証明出来るのだから強気で行けるでしょ。
      住所やクレカ番号などの個人情報は、パスワードリストが見れるくらいなんだから、当然漏れる。

      >それとも、パスワードをデータベースに保存しなくて他の
      >認証手段を使う？

      俺は、パスワードは保存しない。
      今開発している奴は、SHA1とかのハッシュ関数などを利用してパスワードを自動生成して、メールで平文で送る。パスは一定時間で無効に。パスも複数利用して、メールアドレスも複数使ってもらう。
      フィッシングの基本は、メールで届いた偽URLをクリックするからだろうけど、メール仕分け用のハッシュ値をメールヘッダーに入れて送る。
      クライアントのIPのヒストリーをRC5とかで暗合化してクッキーに保存。
      逆に、SSLの暗号化通信には疑問を感じている。経路で盗まれる場合とSSLのセキュリティーホール突かれる場合で、俺は後者の方が危険と考えているから。
      経路で盗まれる可能性があるという前提で、罠を張ったり、解析をしたり、ユーザーと緊密に連絡を取ることで、盗まれた原因を潰す方向。
  • と、思ったりもする。

  • 面白そうなのでプレスリリースに目を通しました。僕は PAKE とかいう言葉も初めて聞いたくらいで、全然前提知識がないので、いろいろ間違ったことを書く可能性が高いです。

    悪く言えば、ウェブブラウザーから専用クライアントへの逆行とも言えるユーザーインターフェース、 password authenticated key exchange (PAKE) 認証方式、 HTTP 認証の小さい拡張など、既存あるいは小規模な要素技術を組み合わせた「だけ」とも言えそうです。でも、これらを組み合わせて実用に耐える新しいフレームワークを作ったという点が売りなのでしょうし、それが事実なら素晴らしいと思います。この技術には期待できそうです。誰でも安心してネットが使えるようになるといいですね。

    なるべくオープンな仕様にして、ウェブサーバー側が簡単に導入できるようにするとともに、マイナーなブラウザーでも開発者が頑張れば実装できるようにしてほしいです。

    ところで、今回発表された技術の全体には名前が付いていないんですね。少し意外でした。

    • Re:プレスリリース雑感 (スコア:1)

      by nisiguti (1286) on 2007年03月28日 11時12分 (#1133212)
      Mutual認証と呼んでいるようですね。

      >具体的には、HTTPアクセス認証(RFC 2617) の自然な拡張として設計し、
      >Basic認証、Digest認証と同じフレームワークを利用した“Mutual”認証を
      >新たに開発しました。
      http://pr.yahoo.co.jp/release/2007/0323a.html [yahoo.co.jp]

      • 今更ですが、 #1133089 [slashdot.jp] で

        ところで、今回発表された技術の全体には名前が付いていないんですね。少し意外でした。

        と書いた部分の意図が伝わっていないと思うので一応お返事します。

        nisiguti さんの書き込み #1133212 [slashdot.jp] より:

        Mutual認証と呼んでいるようですね。

        Mutual というのは今回の技術で新たに制定した HTTP の認証スキームの名前だと思いますが、その名前のことが言いたかったのではありません。

        今回の提案は、 (A) ISO/IEC 11770-4 という既存の PAKE プロトコルを基にして中間者攻撃にやられないようなパスワード相互認証方式を設計し、 (B) そのパスワード相互認証方式を HTTP アクセス認証と融合し、 (C) ブラウザーの機能拡張によって安全に認証を行う仕組み全体です。 Mutual という名前は (B) の部分にしか出てきません。「全体」に名前を付けていないのが不思議だと思うのです。

        例えば、今後この方式が広く使われるようになったとして、ウェブサイトに「このサイトは Mutual 認証を用いているので安全です」と表示するのは変に一部だけ取り出していておかしいと感じます。「パスワード相互認証を用いているので安全です」なら間違っていません。でも、パスワード相互認証方式の中でも今回 Yahoo! と産総研が提案した方式を指す名前がありません。これは提案者である Yahoo! と産総研にとって不利だと思うので、不思議です。

    • 悪く言えば、ウェブブラウザーから専用クライアントへの逆行とも言えるユーザーインターフェース、
      そうですかね？「専用クライアント」というのがよくわからないですが、専用クライアントとウェブブラウザの違いって何だろ。

  • SSLの証明書 (スコア:0, すばらしい洞察)

    by Anonymous Coward on 2007年03月26日 18時41分 (#1132433)
    >Webで利用可能な従来の認証技術としては、パスワードを暗号化して送受信する
    >SSLのクライアント認証方式が挙げられるが、「この方式では、フィッシングに
    >よるパスワード詐取の対策は可能だが、事前にユーザーに電子証明書を配布する
    >必要があり導入コストが高いなどの問題があった」

    SSLの証明書買うのに躊躇するような企業のサイトに、ログインして
    個人情報を預けるほうが不安なんだがなあ。

    # とりあえず、個人情報は500円換算で債権化しときますね

    • Re:SSLの証明書 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2007年03月26日 18時55分 (#1132438)
      その指摘の仕方はサーバー認証方式の話であって、SSLクライアント認証ではまた違うのでは。

      #間違ってるかもしれんので臆病者のAC

      • Re:SSLの証明書 (スコア:1)

        by arkas (10211) on 2007年03月26日 21時38分 (#1132509) 日記
        たぶんあってます。クライアント証明書管理するのも大変だし、安全かつ安価に大量配布する手段もないし、インストールするのは(少なくとも今の仕組みじゃ)素人にはちょっと無理っぽいし。

        クライアント証明書ほどの安全性でなくても、とりあえずユーザパスワードを事前に知らない限り認証が成立しない方式だとしたら、一見の価値はあると思いますよ。技術的に新しいかよりも、利便性と安全性のバランスの実装が肝かもね。

        • Re:SSLの証明書 (スコア:0)

          by Anonymous Coward
          > 安全かつ安価に大量配布する手段もない

          いっそ発想を転換してみるとどうだろう、と最近思います。SSL クライアント証明書の鍵配布問題を厳格に考えるのをやめにして、いっそメールで配ってしまえばどうでしょう。確かにそのメールをスニッフィングされれば（パスフレーズで保護するとしても）安全とは言えませんが、１回かぎりです。共通鍵認証で毎セッション、パスワードがやりとりされるよりはずっとマシだという考え方はありではないでしょうか。

          SSL クライアント証明書を厳格に扱いすぎるあまり、使えない状況になっているのはもったいない気がします。

          • Re:SSLの証明書 (スコア:1)

            by nisiguti (1286) on 2007年03月28日 11時50分 (#1133260)
            >いっそメールで配ってしまえばどうでしょう。

            クライアント証明書はWebブラウザに導入して初めて使えますので、
            メールで配布するというだけでは使い物にならないように思います。
            また一度導入すれば終わりではなく、定期的に証明書を更新する必要も生じます。

            それらクライアント証明書の運用に掛かる様々な費用を考慮すると、
            現時点ではクライアント証明書は安価なサービスには見合わないように思います。

    • SSLはSSLで (スコア:0)

      by Anonymous Coward
      正しい運用方法をサイト運営者とユーザーの双方に啓蒙しないと、
      現状多くのユーザーにとってはただのお飾りにも近いものがあるからなぁ・・・
      肝腎のパスワード入力画面に鍵マークが無いサイトとか。

      • オフトピ: https → http (スコア:1)

        by arkas (10211) on 2007年03月26日 21時35分 (#1132508) 日記
        GETがhttpsでformのPOST先がhttpなサイトを絶滅させてほしいのですが、誰かいい手ありませんかね。
        IE7.1ぐらいで使えなくすれば一発だと思うのだが。

        • Re:オフトピ: https → http (スコア:1, 興味深い)

          by Anonymous Coward on 2007年03月26日 21時59分 (#1132524)
          ＞httpsでformのPOST先がhttpなサイトを絶滅させてほしいのですが、

          それはモロ脆弱性だから、IPAに届け出まくればよいのでは？
          • その逆、ページが http で post が https なサイトは？

            • Re:オフトピ: https → http (スコア:1)

              by Stealth (5277) on 2007年03月27日 16時00分 (#1132884)

              何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。

              送信内容に問題があってフォームが再表示される場合でもPOST 後ですから、https でしょう?

              フォームのページの段階から https にするのは、ユーザにフォームの画面でも鍵のアイコンがブラウザに表示されることで安心感を漂わせるという気休め以外、何のメリットもありません。

              • >>その逆、ページが http で post が https なサイトは？
                >何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。
                ダウト [aist.go.jp]．see Q2

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月27日 18時52分 (#1132927)

                その場合、そもそもフォーム画面に遷移する時点で疑ってない時点でアウトなのですが。

                そこまで気にしているならサイト全体が https でなければダメでしょう。

              • そうか、やっぱりダメなのか。
                具体的には KDDI の契約内容閲覧・変更とかのページだけどね。
                勉強になった。
              • > その場合、そもそもフォーム画面に遷移する時点で疑ってない時点でアウトなのですが。
                > そこまで気にしているならサイト全体が https でなければダメでしょう。

                ダウト [aist.go.jp]. see Q1

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月28日 14時19分 (#1133367)

                Q1 は参考になりますかねぇ。

                ぜなら、リンクを辿っている途中のページに https:/// [https] ではない http:/// [http] のページが1つでもあったなら、そのページが通信路上で改竄されていた可能性を否定できません。いつのまにか違うサイトへジャンプさせられている可能性があります。

                と危険性を指摘しつつ

                ページを移動するたびに見ている画面が https:/// [https] であることを確認するというのは、利用者にとって煩雑すぎる作業です。入力欄のあるページで利用者が重要な情報を入力をしようとしたそのときに、アドレスのドメイン名を確認し、https:// であることを確認するという手順が、シンプルかつ合理的です。

                と、コストと合理性の面から言っていますね。

                しかし、その入力フォーム画面が本当に目的に合致したフォームであるのかは、フォームへのリンクがある画面が https でなければ不安が残るように思いますが、どうでしょうか。

                また、フォーム画面へのリンクは http であってもいいというのは、そのリンクが改竄されてスクリプトが埋め込まれていたりしている可能性も否定できないかと。

                で、そのリンクがある画面へのリンクの改竄がないか……と辿っていくと、結局サイト全体が https になる必要がある、とかになってしまいませんか。そういう話です。

              • その入力フォーム画面が本当に目的に合致したフォームであるのかは、フォームへのリンクがある画面が https でなければ不安が残るように思いますが、どうでしょうか。

                不安は無いですね。なにしろ https で取得した画面なのですから、そのサーバに実在する画面であることが保証されますからね。

                また、フォーム画面へのリンクは http であってもいいというのは、そのリンクが改竄されてスクリプトが埋め込まれていたりしている可能性も否定できないかと。

                前のページでスクリプトが埋め込まれていて、何か問題でも？

                で、そのリンクがある画面へのリンクの改竄がないか……と辿っていくと、結局サイト全体が https になる必要がある、とかになってしまいませんか。そういう話です。

                なりませんね。

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月29日 5時32分 (#1133814)

                リンクの書き換えが可能となってしまっては、Web アプリが XSS 脆弱性を持っている場合に利用される可能性がありますね。

              • > Web アプリが XSS 脆弱性を持っている場合
                はいはいダウトダウト [aist.go.jp]。See Q5.
                # /.のコメントだけに脊髄反射しないで、せめてリンク先全部見てから反論しましょうよ。はっきり言って見苦しいだけですよ。
              • リンクの書き換えが可能となってしまっては、Web アプリが XSS 脆弱性を持っている場合に利用される可能性がありますね。
                脆弱性があったら元々どうしようもない。何言ってんの?

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月29日 10時16分 (#1133913)

                脆弱性が万が一見つかった場合にでも被害を抑える方向での考慮の話ですよ。

                SSL を利用したらその分負荷は上がる訳ですし、結局どのラインでトレードオフするかという話に過ぎないだけでしょう。

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月29日 10時21分 (#1133917)

                RCIS の記述だけを盲目的に信じてるだけというのもどうかと思いますが。

                そもそも DNS ポイゾニングはどうだとかいうところまで Q5 は押さえている話だと解釈していますが、単に SSL をかけるのはフォームからで十分というのは、リーズナブルな解として出しているだけの話でしょう。

                同一サーバ上にあっても目的が異なるフォームへの誘導などは全く防げない、といった点などが欠落していますよ。

              • 同一サーバ上にあっても目的が異なるフォームへの誘導などは全く防げない、といった点などが欠落していますよ。
                何の問題もないですね。本物サーバ上にある本物フォームなんだから。
              • > 脆弱性が万が一見つかった場合にでも被害を抑える方向での考慮の話ですよ。

                嘘はいけないな。君がここでやっていることは、君の最初の失言 #1132884 [slashdot.jp]

                何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。フォームのページの段階から https にするのは、ユーザにフォームの画面でも鍵のアイコンがブラウザに表示されることで安心感を漂わせるという気休め以外、何のメリットもありません。

                が間違いだと指摘されたことに対する釈明なはずで、「脆弱性が万が一見つかった場合にでも被害を抑える方向での考慮の話ですよ」なんて支離滅裂もいいとこ。

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月29日 11時54分 (#1133985)

                たとえばアマゾンのようなオンラインショップにおいて、購入しようとした商品とは別の商品しか購入できないとか、購入ステップに入ろうとしても飛べない、知らない間に第三者のアフィリエイトプログラム経由で購入しようとしている事になっている、といった点が一切クリアできません。

                アマゾンの場合は退会処理のためのフォームがないのでアマゾンではできませんが、購入しようとしたら退会フォームに飛ばされて購入できない、ということも考えられます。

                ですから、何の問題もないと考えるのはお気楽過ぎとしか思えません。ユーザが求めているのはデータの安全性ではなく、そのフォームが含まれている一連のアプリケーションで達成される目的です。

                安全が大事ではないというつもりはありませんが、安全でも目的が達成できないのであれば何の意味もありません。

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月29日 12時01分 (#1133990)

                確かに最初のは失言ですね。その事について書いていないのは私の落ち度です。

                #1132927 [slashdot.jp] 以降は #1132923 [slashdot.jp] へのリンク先を読んだ上で、その内容に対しての納得できない部分について書いています。

                なぜなら、リンクを辿っている途中のページに https:/// [https] ではない http:/// [http] のページが1つでもあったなら、そのページが通信路上で改竄されていた可能性を否定できません。いつのまにか違うサイトへジャンプさせられている可能性があります。

                と、通信経路上での改竄まで視野に入れて話しているのであれば、送受信内容全てを疑っていなければ視点としては足りていません。

                フォーム画面へのリンクが信頼できないにも関わらずフォーム画面が https であることだけを見て信じていいというのはそのフォームの安全性のみの議論でしかなく、#1132933 [slashdot.jp] で書いたように、求めていることが正しく行えている整合性を考慮した場合には不足していと思います。

                #1132927 以降をその流れで読み直していただけたら、と思います。

              • たとえばアマゾンのようなオンラインショップにおいて、購入しようとした商品とは別の商品しか購入できないとか、購入ステップに入ろうとしても飛べない、知らない間に第三者のアフィリエイトプログラム経由で購入しようとしている事になっている、といった点が一切クリアできません。
                それはフィッシング対策の話とは全然別ですね。物事を論理的に整理して考える力を持ちましょう。

              • Re:オフトピ: https → http (スコア:1)

                by Stealth (5277) on 2007年03月29日 12時23分 (#1134008)

                この一連のコメント自体オフトピですからフィッシング対策に限った話だけする必要もないかと。

              • じゃあ、全部SSLにすれば？
                終了。

                文脈コロコロ変える馬鹿に相手してしてらんね。
typodupeerror

ソースを見ろ -- ある4桁UID