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

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

  • 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
              • Q1 は参考になりますかねぇ。

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

                と危険性を指摘しつつ

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

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

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

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

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

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

                なりませんね。

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

              • > Web アプリが XSS 脆弱性を持っている場合
                はいはいダウトダウト [aist.go.jp]。See Q5.
                # /.のコメントだけに脊髄反射しないで、せめてリンク先全部見てから反論しましょうよ。はっきり言って見苦しいだけですよ。
              • by Stealth (5277) on 2007年03月29日 10時21分 (#1133917)

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

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

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

                親コメント
              • 同一サーバ上にあっても目的が異なるフォームへの誘導などは全く防げない、といった点などが欠落していますよ。
                何の問題もないですね。本物サーバ上にある本物フォームなんだから。
              • by Stealth (5277) on 2007年03月29日 11時54分 (#1133985)

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

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

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

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

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

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

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

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

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

処理中...