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

ヤフーと産総研、フィッシングを防止するパスワード相互認証技術を開発」記事へのコメント

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

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

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

    # とりあえず、個人情報は500円換算で債権化しときますね
    • by Anonymous Coward
      正しい運用方法をサイト運営者とユーザーの双方に啓蒙しないと、
      現状多くのユーザーにとってはただのお飾りにも近いものがあるからなぁ・・・
      肝腎のパスワード入力画面に鍵マークが無いサイトとか。
      • GETがhttpsでformのPOST先がhttpなサイトを絶滅させてほしいのですが、誰かいい手ありませんかね。
        IE7.1ぐらいで使えなくすれば一発だと思うのだが。
        • by Anonymous Coward
          >httpsでformのPOST先がhttpなサイトを絶滅させてほしいのですが、

          それはモロ脆弱性だから、IPAに届け出まくればよいのでは?
          • その逆、ページが http で post が https なサイトは?
            • 何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。

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

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

              • >>その逆、ページが http で post が https なサイトは?
                >何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。
                ダウト [aist.go.jp].see Q2
              • その場合、そもそもフォーム画面に遷移する時点で疑ってない時点でアウトなのですが。

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

              • > その場合、そもそもフォーム画面に遷移する時点で疑ってない時点でアウトなのですが。
                > そこまで気にしているならサイト全体が https でなければダメでしょう。

                ダウト [aist.go.jp]. see Q1
              • 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 になる必要がある、とかになってしまいませんか。そういう話です。

                なりませんね。

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

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

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

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

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

                親コメント
              • by Stealth (5277) on 2007年03月29日 10時21分 (#1133917)

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

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

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

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

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

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

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

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

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

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

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

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

                親コメント
              • by Stealth (5277) on 2007年03月29日 12時01分 (#1133990)

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

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

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

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

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

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

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

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

                親コメント
              • じゃあ、全部SSLにすれば?
                終了。

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

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

処理中...