アカウント名:
パスワード:
心配ならネットバンク使わなきゃいい銀行に行ってATM操作して振り込みやらしたらいいATMでのスキミングが心配なら窓口でやればいい
不便？手数料？しらんがな
このソフト入れたら安全って訳でもない入れないよりは安心できるだけ
ブラウザでの口座アクセスを廃止して専用のアプリケーションを用意すればいいそもそも絶対的なセキュリティが求められる物事にリスクの高いブラウザを採用するのが間違い。
専用アプリケーションの開発を考えるなら、それはつまりコストを度外視しているということで、それなら専用アプリケーションだけでなく専用OSと専用マシンを開発し専用回線に専用プロトコルで接続するのが、一番安全で、他のベンダの都合に左右されない一番安定した手段だろう。
まあそんなの当然コストに見合わないし、専用アプリケーションなんて理想論に過ぎない。コストを考慮して選んだ妥協案に対して、理想論を振りかざして「間違い」などと断じても意味がないよね。
専用アプリケーションの開発を考えるなら、それはつまりコストを度外視しているということで、 それなら専用アプリケーションだけでなく専用OSと専用マシンを開発し専用回線に専用プロトコルで接続するのが、 一番安全で、他のベンダの都合に左右されない一番安定した手段だろう。 まあそんなの当然コストに見合わないし、専用アプリケーションなんて理想論に過ぎない。 コストを考慮して選んだ妥協案に対して、理想論を振りかざして「間違い」などと断じても意味がないよね。
専用アプリケーションの開発を考えるなら、それはつまりコストを度外視しているということで、 それなら専用アプリケーションだけでなく専用OSと専用マシンを開発し専用回線に専用プロトコルで接続するのが、 一番安全で、他のベンダの都合に左右されない一番安定した手段だろう。
まあそんなの当然コストに見合わないし、専用アプリケーションなんて理想論に過ぎない。 コストを考慮して選んだ妥協案に対して、理想論を振りかざして「間違い」などと断じても意味がないよね。
いや、明確に 「間違い」 だと断言できます。
フィッシングやMITBを防ぐための専用プラグインなんていうのは、性質上ブラウザのアップデートや他のセキュリティソフトなどと競合して不具合が発生することは必至です。それに、MITBに対する不正振込に対する完全な対策とはならず、マルウェア製作者とのいたちごっこになるだけです。「専用アプリ」を使ったとしても、マルウェアが Administrator / root 権限を得てしまえば同じことです。
正解は、みずほ銀行のように 「メッセージ認証コード（MAC）」を生成する物理トークンを用いた「トランザクション認証」を導入 [security.srad.jp] することでしょう。
これは、広義に解釈すると、「専用マシン」で「専用アプリケーション」を動かしており、物理トークンとブラウザ間は、振込先口座番号（トークンのテンキーに入力）や、それをもとに生成された暗号学的に安全なメッセージ認証コード（ブラウザにユーザーが入力）を、手動入力でデータをやり取りするという「専用回線に専用プロトコル」で通信をおこなっています。
現実的なコストで、あなたのいうところの「理想論」を実現することができるのです。
このトランザクション認証は、専用トークンに間違って詐欺師の口座番号を入力しない限り、パソコンがどんなマルウェアに感染してMITBされていても、ユーザーフィッシング詐欺サイトにアクセスしていても、不正振込を防ぐことができるので、技術的に完璧に近いやり方です。
三菱東京UFJ銀行はトランザクション認証をやらずに、大切な資産を守る対策（はじめてのセキュリティ） [bk.mufg.jp]によると、
と複数の対策を併用しようとしています。
全部、詐欺師といたちごっこになる不完全な対策で、3つ全部やったとしても安全にはならなりません（例えば、ワンタイムパスワードは中継型フィッシングを防げない）。
また、来年6月12日からはワンタイムパスワードが必須になりますが、トランザクション認証対応のトークンを配布しながら、ワンタイムパスワード機能しか利用しない（脆弱） [bk.mufg.jp] など、理解に苦しむやり方なのです。
顧客に手間をかけさせるだけで、不正送金を完全に防ぐことのできない不完全な対策を複数併用するというのは、どう考えても合理的でない行動です。「コストを考慮して選んだ妥協案」なんていうものではなく、
といった状況にあるのではないでしょうか。
現に、みずほ銀行のトランザクション認証では不正振込は発生していないようですが、三菱東京UFJ銀行は、フィッシング詐欺やらマルウェアなどの不正振込が続出しており、対策が適切でなかったことを証明しています。
このトランザクション認証の端末って、PCを使わず残高の確認とかもできるの？セキュリティリスクと言っても不正な振込だけじゃなくて残高の盗み読むとかもある。そのリンク先でひろみちゅ先生が言っている通り、口座番号をそもそも間違って教えられた場合にリスクがあるし、専用端末だけで相手先の口座番号の確認からのすべての手続きが完結しないのであれば、「理想論」が達成されているようには見えないけど……。
三菱東京UFJ銀行の体制が疑わしいのはわかったけど、それならなおのこと専用アプリを開発すれば改善されるというものではないと思う。
箪笥預金最強！まで読んだ。
そもそも口座番号を間違って教えられたって、ネットに限らんような。銀行間ネットワークの話でもあるわけで、アプリなんて末端部分の話だけで解決するわけでもない。こういう面でもシステム開発に銀の弾丸はない。
因みにみずほのトランザクション認証は振り込み等のトランザクションに対してのみ。
> このトランザクション認証の端末って、PCを使わず残高の確認とかもできるの？技術的には可能だろうけど実装はされてないだろうなぁ…7セグ液晶では微妙すぎる。まぁ「広義に解釈すると」って書かてている通り、送金限定の効果と考えればよろしい。> 口座番号をそもそも間違って教えられた場合にリスクがある鍵交換と同じ種類の脆弱性ですね。そこら辺を掘り下げるのは銀行屋の範疇じゃない。汚染状態のPCで口座番号を掴んでしまう状態なら誤解しやすい口座名で突破されますから、「取引先の正しい名称」が得られなければ振込先が端末に表示されても意味がないです。口座名が専用端末に表示される方が攻撃は難しくなりますが、それだけでは防御できません。
完全じゃないから無意味というとこの世の全てがだいたい無意味になってしまいますし、実行可能性とコストを考えたらトランザクション認証は有効化したほうが良いと思います。
トランザクション認証は通信情報(口座情報)の改ざん保護が目的ですよね。クライアントサイドのプラットフォーム次第で使うかどうかではなく導入すべき物だと思います。
その上で アプリにしてブラウザの変化から隔離する ブラウザにしてブラウザの変化に追従するを条件によって選択ではないでしょうかね。
まあどちらにせよ、プラットフォームの変化を無視するスタイルはダメだよ、と言えますけどね。
正直TPMなりスマートカード使うなり、ハードウエア認証のほうが楽だと思います...
確か半年に1回程度大きな変更があるので、専用アプリを作っても大差ないような気がするまさか、LTSB版を使わないと保証しませんなんてふざけたことは言わねえよな
IEはwindows10で塩漬け状態なのでホットフィックスの検証だけすればよいのでは？IEが死んでEDGEオンリーになった時が怖いけれどきっと大丈夫。
確かにブラウザ環境は変化が激しすぎなところは有りますね。それを思えば専用アプリのほうがテストも楽かも。
あと、Webアプリと違って自前の専用アプリでなら、中途半端に動くのを抑制できる。中途半端に動くってのが一番危ないから。
理想論だってなんだって、こんなところで雑談にマジレスするのと同じ程度には意味あんじゃねーの
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
いっそのこと (スコア:0)
心配ならネットバンク使わなきゃいい
銀行に行ってATM操作して振り込みやらしたらいい
ATMでのスキミングが心配なら窓口でやればいい
不便？手数料？
しらんがな
このソフト入れたら安全って訳でもない
入れないよりは安心できるだけ
Re: (スコア:0)
ブラウザでの口座アクセスを廃止して専用のアプリケーションを用意すればいい
そもそも絶対的なセキュリティが求められる物事にリスクの高いブラウザを採用するのが間違い。
Re:いっそのこと (スコア:0)
専用アプリケーションの開発を考えるなら、それはつまりコストを度外視しているということで、
それなら専用アプリケーションだけでなく専用OSと専用マシンを開発し専用回線に専用プロトコルで接続するのが、
一番安全で、他のベンダの都合に左右されない一番安定した手段だろう。
まあそんなの当然コストに見合わないし、専用アプリケーションなんて理想論に過ぎない。
コストを考慮して選んだ妥協案に対して、理想論を振りかざして「間違い」などと断じても意味がないよね。
明確に 「間違い」 だと断言できます (スコア:5, 興味深い)
いや、明確に 「間違い」 だと断言できます。
フィッシングやMITBを防ぐための専用プラグインなんていうのは、性質上ブラウザのアップデートや他のセキュリティソフトなどと競合して不具合が発生することは必至です。それに、MITBに対する不正振込に対する完全な対策とはならず、マルウェア製作者とのいたちごっこになるだけです。「専用アプリ」を使ったとしても、マルウェアが Administrator / root 権限を得てしまえば同じことです。
正解は、みずほ銀行のように 「メッセージ認証コード（MAC）」を生成する物理トークンを用いた「トランザクション認証」を導入 [security.srad.jp] することでしょう。
これは、広義に解釈すると、「専用マシン」で「専用アプリケーション」を動かしており、物理トークンとブラウザ間は、振込先口座番号（トークンのテンキーに入力）や、それをもとに生成された暗号学的に安全なメッセージ認証コード（ブラウザにユーザーが入力）を、手動入力でデータをやり取りするという「専用回線に専用プロトコル」で通信をおこなっています。
現実的なコストで、あなたのいうところの「理想論」を実現することができるのです。
このトランザクション認証は、専用トークンに間違って詐欺師の口座番号を入力しない限り、パソコンがどんなマルウェアに感染してMITBされていても、ユーザーフィッシング詐欺サイトにアクセスしていても、不正振込を防ぐことができるので、技術的に完璧に近いやり方です。
三菱東京UFJ銀行はトランザクション認証をやらずに、大切な資産を守る対策（はじめてのセキュリティ） [bk.mufg.jp]によると、
と複数の対策を併用しようとしています。
全部、詐欺師といたちごっこになる不完全な対策で、3つ全部やったとしても安全にはならなりません（例えば、ワンタイムパスワードは中継型フィッシングを防げない）。
また、来年6月12日からはワンタイムパスワードが必須になりますが、トランザクション認証対応のトークンを配布しながら、ワンタイムパスワード機能しか利用しない（脆弱） [bk.mufg.jp] など、理解に苦しむやり方なのです。
顧客に手間をかけさせるだけで、不正送金を完全に防ぐことのできない不完全な対策を複数併用するというのは、どう考えても合理的でない行動です。「コストを考慮して選んだ妥協案」なんていうものではなく、
といった状況にあるのではないでしょうか。
現に、みずほ銀行のトランザクション認証では不正振込は発生していないようですが、三菱東京UFJ銀行は、フィッシング詐欺やらマルウェアなどの不正振込が続出しており、対策が適切でなかったことを証明しています。
Re: (スコア:0)
このトランザクション認証の端末って、PCを使わず残高の確認とかもできるの？
セキュリティリスクと言っても不正な振込だけじゃなくて残高の盗み読むとかもある。
そのリンク先でひろみちゅ先生が言っている通り、口座番号をそもそも間違って教えられた場合にリスクがあるし、
専用端末だけで相手先の口座番号の確認からのすべての手続きが完結しないのであれば、
「理想論」が達成されているようには見えないけど……。
三菱東京UFJ銀行の体制が疑わしいのはわかったけど、
それならなおのこと専用アプリを開発すれば改善されるというものではないと思う。
Re: (スコア:0)
箪笥預金最強！まで読んだ。
そもそも口座番号を間違って教えられたって、ネットに限らんような。
銀行間ネットワークの話でもあるわけで、アプリなんて末端部分の話だけで解決するわけでもない。
こういう面でもシステム開発に銀の弾丸はない。
因みにみずほのトランザクション認証は振り込み等のトランザクションに対してのみ。
Re: (スコア:0)
> このトランザクション認証の端末って、PCを使わず残高の確認とかもできるの？
技術的には可能だろうけど実装はされてないだろうなぁ…7セグ液晶では微妙すぎる。
まぁ「広義に解釈すると」って書かてている通り、送金限定の効果と考えればよろしい。
> 口座番号をそもそも間違って教えられた場合にリスクがある
鍵交換と同じ種類の脆弱性ですね。そこら辺を掘り下げるのは銀行屋の範疇じゃない。
汚染状態のPCで口座番号を掴んでしまう状態なら誤解しやすい口座名で突破されますから、
「取引先の正しい名称」が得られなければ振込先が端末に表示されても意味がないです。
口座名が専用端末に表示される方が攻撃は難しくなりますが、それだけでは防御できません。
完全じゃないから無意味というとこの世の全てがだいたい無意味になってしまいますし、
実行可能性とコストを考えたらトランザクション認証は有効化したほうが良いと思います。
Re: (スコア:0)
トランザクション認証は通信情報(口座情報)の改ざん保護が目的ですよね。
クライアントサイドのプラットフォーム次第で使うかどうかではなく導入すべき物だと思います。
その上で
アプリにしてブラウザの変化から隔離する
ブラウザにしてブラウザの変化に追従する
を条件によって選択ではないでしょうかね。
まあどちらにせよ、プラットフォームの変化を無視するスタイルはダメだよ、と言えますけどね。
Re: (スコア:0)
正直TPMなりスマートカード使うなり、ハードウエア認証のほうが楽だと思います...
Re:いっそのこと (スコア:1)
一般向けで、それなりの信頼性が必要になるものを WEBでやると専用アプリと比べて検証コストが10倍や20倍じゃきかないうえに、アプリ提供側の想定に関係なくそれが数ヶ月に一回って頻度でやってくる。
実際に、半年分の検証コストで、専用アプリの開発と検証やれちゃうんだよ。
WEBアプリの維持するか、専用アプリに移行するかって試算出したら、だいたい2年で 1/10 くらいまでコスト下がっちゃうんだよ。
Macをサポート環境に入れるとかいうところでさえ 1/5 ぐらいで維持できる。
今年だけでも、WEBから専用アプリへの移行2つやったし、一方は1年で1/10まで下がってるよ。
windows10・・・ (スコア:0)
確か半年に1回程度大きな変更があるので、専用アプリを作っても大差ないような気がする
まさか、LTSB版を使わないと保証しませんなんてふざけたことは言わねえよな
Re: (スコア:0)
IEはwindows10で塩漬け状態なのでホットフィックスの検証だけすればよいのでは？
IEが死んでEDGEオンリーになった時が怖いけれどきっと大丈夫。
Re: (スコア:0)
確かにブラウザ環境は変化が激しすぎなところは有りますね。
それを思えば専用アプリのほうがテストも楽かも。
Re: (スコア:0)
あと、Webアプリと違って自前の専用アプリでなら、中途半端に動くのを抑制できる。
中途半端に動くってのが一番危ないから。
Re: (スコア:0)
理想論だってなんだって、こんなところで
雑談にマジレスするのと同じ程度には
意味あんじゃねーの