アカウント名:
パスワード:
それよりも、なんで三井住友銀行はワンタイムパスワードをRSA securityのからVascoに変えたんでしょうねぇ?テンキーついているから、画面のチャレンジコードを入力して、結果を入れるのかと思ったらそうじゃないし。
確かに、チャレンジコード入れられれば、防げた話ですね。送金先が違えばチャレンジコードが合わない筈なので。
うわ、意味の通らない文章になってました。すみません。チャレンジコードを送金先+saltみたいな形にすれば、ということが言いたかったです。
送金先12345とsalt678を使ってチャレンジコードを123456とすれば、ユーザが入力するのは123456に対するOTPであって、攻撃者が送金先54321に送金させようとしても、チャレンジコード54321678に対応するOTPを得ることができない。
そのチャレンジコードを処理するフローが、・PC画面にチャレンジコードが表示される・OTP生成器にチャレンジコードを手入力してパスワード生成・出来たパスワードをPCに手入力という流れだとしたら、最初に表示されるチャレンジコードを、「送金先12345に対するチャレンジコードは54321678です」と表示されたらもうダメですね。
ブラウザが乗っ取られたら、ブラウザを通すかぎりはもうどうしようもないので、スマホなどを使った二段階認証で、・利用者はPCに送金先・送金額を入力・銀行側はスマホに送金策・送金額を送出・利用者はスマホに表示された送金先・送金額を確認してから承認といった流れにするぐらいが無難なとこじゃないかな。
そうですね。MITM攻撃に根本的に有効かつ簡単に導入できそうなのは、2経路認証+副経路での内容確認くらいだと思います。
それ、ユーザが手元にもつレスポンス計算機側にその機能を含んでないと無理では?中間者が、送金先54321への送金リクエストをまず銀行サイトに送って、銀行サイトがチャレンジコード54321678を返してきたときに、中間者がユーザに提示する画面に送金先12345とチャレンジコード54321678を表示し、ユーザがそれを信用すれば攻撃が成立するわけで。
レスポンス計算機にそこまで機能を作りこむのは、あまり現実的じゃないような。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
中間者攻撃ですよねぇ (スコア:0)
それよりも、なんで三井住友銀行はワンタイムパスワードをRSA securityのからVascoに変えたんでしょうねぇ?
テンキーついているから、画面のチャレンジコードを入力して、結果を入れるのかと思ったらそうじゃないし。
Re: (スコア:2)
確かに、チャレンジコード入れられれば、防げた話ですね。
送金先が違えばチャレンジコードが合わない筈なので。
Re:中間者攻撃ですよねぇ (スコア:1)
ただの文字列として受け取って、これも本物と同じような見た目の結果画面を出せばいいだけ。
あとはユーザが気づく前にコトを行えばOK。
Re:中間者攻撃ですよねぇ (スコア:2)
うわ、意味の通らない文章になってました。すみません。
チャレンジコードを送金先+saltみたいな形にすれば、ということが言いたかったです。
送金先12345とsalt678を使ってチャレンジコードを123456とすれば、ユーザが入力するのは123456に対するOTPであって、
攻撃者が送金先54321に送金させようとしても、チャレンジコード54321678に対応するOTPを得ることができない。
Re:中間者攻撃ですよねぇ (スコア:1)
そのチャレンジコードを処理するフローが、
・PC画面にチャレンジコードが表示される
・OTP生成器にチャレンジコードを手入力してパスワード生成
・出来たパスワードをPCに手入力
という流れだとしたら、最初に表示されるチャレンジコードを、「送金先12345に対するチャレンジコードは54321678です」と表示されたらもうダメですね。
ブラウザが乗っ取られたら、ブラウザを通すかぎりはもうどうしようもないので、
スマホなどを使った二段階認証で、
・利用者はPCに送金先・送金額を入力
・銀行側はスマホに送金策・送金額を送出
・利用者はスマホに表示された送金先・送金額を確認してから承認
といった流れにするぐらいが無難なとこじゃないかな。
Re:中間者攻撃ですよねぇ (スコア:1)
そうですね。
MITM攻撃に根本的に有効かつ簡単に導入できそうなのは、
2経路認証+副経路での内容確認くらいだと思います。
Re: (スコア:0)
それ、ユーザが手元にもつレスポンス計算機側にその機能を含んでないと無理では?
中間者が、送金先54321への送金リクエストをまず銀行サイトに送って、銀行サイトが
チャレンジコード54321678を返してきたときに、中間者がユーザに提示する画面に
送金先12345とチャレンジコード54321678を表示し、ユーザがそれを信用すれば
攻撃が成立するわけで。
レスポンス計算機にそこまで機能を作りこむのは、あまり現実的じゃないような。