アカウント名:
パスワード:
あとは、利用者にとって「証明書の内容を逐一確認するよりも、別APIを起動しておいて返信を送るほうが楽」と思えるだけのシステムを構築できるかどうかですね。
そりゃあ、情報が漏れないに越したことはないですが、どんなにがんばっても巧妙な成りすましにだまされてしまう人が出てくるわけで、だったら別方向からの防御手段も講じないと。
今思いついたんですが、別経路の通信手段として、携帯電話とか使えませんかね? 出金直前に銀行から支払い内容の詳細を確認電話がかかってきて、「*」を押して承認しないと出金がキャンセルされる、とか。
あと、銀行側にメリットが出ないなら、なぜ「英銀行のインターネットバンキングが停止」なんて自体になってるんでしょう? デメリットを回避できるってのは、立派なメリットですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
銀行→利用者ルートの認証 (スコア:3, 参考になる)
マル
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:2, 参考になる)
証明書発行会社が、確かにその会社で有ることを確認して発行すると
ただし、認証された証明書だと、もし別の会社が取得した証明書だとしても警告なくアクセスできますからねぇ~
SSLの通信を開始しますメッセージではなく、XXXの会社にアクセスしますみたいな表示が必要なのかもしれません
アクセスしてからSSLの証明書を表示する操作をすれば取得会社を確認できますが、そこまでする人はフィッシング詐欺なんかにはかからないわけで...
Re:銀行→利用者ルートの認証 (スコア:1)
例えばですが、インスタントメッセンジャーで銀行から利用者にメッセージを送って、それに対する返事がなければ出金しないようにすれば、防げるのでは?と
成りすまして利用者にメッセージを送っても、銀行からのメッセージに返信されるわけではないですからね。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
むろん、別ルートで返信されればクラックされたときに、送金操作等をされたタイミングで判明すると言う事もありますが
その場合も送信元が必ず銀行であると言う証明が必要になります
つまりその手のメッセージも送信元を保証する法が無いと、今度はその銀行からのメッセージもなりすまされたら...と言う懸念が出てくるわけです。
正常に銀行に接続されている事を保証する方法と共に、正常に銀行に接続されているかをユーザーが確認する事を容易にする方のがこの手の詐欺の防止には役に立つと思います。
Re:銀行→利用者ルートの認証 (スコア:2, 興味深い)
成りすまして利用者に偽の銀行のメッセージを送っても、そのメッセージに対する返信は成りすました連中に返されるわけで、銀行に送られるわけではないですから、メッセージに対する返答を要求するようにすればいいわけですよ。
インスタントメッセンジャーをもうちょっとセキュアにすれば、リアルタイムで銀行からの問い合わせに利用者が返答できるシステムが作れるのではないかなぁ、と。
あとは、利用者にとって「証明書の内容を逐一確認するよりも、別APIを起動しておいて返信を送るほうが楽」と思えるだけのシステムを構築できるかどうかですね。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:2, すばらしい洞察)
ユーザーが銀行だと思って入力してしまった場合、それらの情報が詐欺団体に流れてしまいませんか?
銀行に対して情報を提示したつもりが、成りすました相手にその手の情報が流れてしまうと..フィッシング詐欺ってそう言うものですし
Re:銀行→利用者ルートの認証 (スコア:1)
そりゃあ、情報が漏れないに越したことはないですが、どんなにがんばっても巧妙な成りすましにだまされてしまう人が出てくるわけで、だったら別方向からの防御手段も講じないと。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
すでに既存で、PKI/IC カード [google.com]による相互確認とかがありますよ
これだと、パスワードと異なり通信データーが漏れても大丈夫という安心があります
また事前に双方で所持している秘密キーが無いと通信できません
PKIカードとPKIにアクセスするためのパスワード等を併せて盗難したらアウトですが、フィッシング詐欺の結果として銀行のサイトにはアクセス出来ないでしょう。
通信経路を別にしても、前に記載した通り発信元の保証、発信先の保証という問題はついてまわります。
銀行とユーザーの間でやりとりされている事が保証されなければ、通信経路を別にしても意味がありません
その別経路が詐称出来ない保証された通信経路(専用線を使ったホットラインとか)なら別ですが、インターネット等を使用するのであれば、そのどちらかが成りすまされてしまう可能性を秘めているからです
無論コストがかかる話なので、なかなか導入はされてないのが現状ですが...
Re:銀行→利用者ルートの認証 (スコア:1)
今思いついたんですが、別経路の通信手段として、携帯電話とか使えませんかね?
出金直前に銀行から支払い内容の詳細を確認電話がかかってきて、「*」を押して承認しないと出金がキャンセルされる、とか。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:0)
できるならこれだけオレオレ詐欺の被害が出ている現状でそのくらいしてますよ。
犯罪の被害額を銀行が保障するようになればいきなり発展しそうですが。
Re:銀行→利用者ルートの認証 (スコア:1)
通信費が手数料に加算されそうですが(苦笑)
電話での承認となると発信者番号詐称 [mainichi-msn.co.jp]も考慮しないとなので、それ以上の使用は注意が必要ですが..
あれは個人的に衝撃でした..
Re:銀行→利用者ルートの認証 (スコア:1)
あれって、(だましてはいますが)本人合意の上で振り込んでるので、銀行側のシステムが何をしようと防ぐのは無理では?
あと、銀行側にメリットが出ないなら、なぜ「英銀行のインターネットバンキングが停止」なんて自体になってるんでしょう? デメリットを回避できるってのは、立派なメリットですよ。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:0, オフトピック)
あわてているお客様を見かけたら、問いかけて防ぐというシステムで何件も阻止できていますよ。
# 人もシステムだということをお忘れか?
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:銀行→利用者ルートの認証 (スコア:1)
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
たぶん見ないだろうけど...
えと、オレオレ詐欺は別にどうでもよくて、発信番号偽造の方に注目してください
電話を確認に使用すると言うことは、加入者は銀行からの電話である事を確認した上で承認すると言うことになります
フィッシング詐欺側で、発信番号を偽造できると言うことは、銀行からの確認電話自体を偽造可能と言うことです。
なので、この認証の場合、発信番号の詐称を考慮しなければないと言うことになるのです.
#いやーしっぱいした(苦笑
Re:銀行→利用者ルートの認証 (スコア:1)
銀行のサイトがXXXだとして、釣師のサイトがXXxだとする。
釣師はメールでXXxをXXXのサイトの様に見せて誤認させアクセスさせるが、誤認するような奴はXXxと表示されてもXXXのサイトだと思うだろうから、効果はそれ程期待出来ないと思う。