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

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

  • 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 脆弱性を持っている場合に利用される可能性がありますね。
                脆弱性があったら元々どうしようもない。何言ってんの?
              • by Stealth (5277) on 2007年03月29日 10時16分 (#1133913)

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

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

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

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

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

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

              • 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 以降をその流れで読み直していただけたら、と思います。

                親コメント

物事のやり方は一つではない -- Perlな人

処理中...