アカウント名:
パスワード:
さすがにもうリバースブルートフォース攻撃なんか通用しないでしょう。磁気タイプのキャッシュカード偽造の可能性が残ってるぐらい?
・接続IPを毎回変える・アタック間隔をランダムにして十分にとる。・正規ユーザーの利用が多い時間帯を狙う。・いろんな銀行口座を混ぜる(一つの銀行のアタック回数が減る)・連番攻撃せず、口座番号をシャッフルする。・PINも毎回変える(下手な鉄砲も数撃ちゃ当たる方式なので別に固定じゃなくて良い)・あからさまなPIN(日付とか)はあえて使わない。
さて正規ユーザに対するサービスを止めずにどうやって防ぐ?
ログインごとにワンタイムパスワードの入力を要求する
それは根本的解決すぎる。今のダメダメな方式を変更せずに対策は不可能って話の流れなのでは?
ログイン後のクリティカルな作業にのみ、ワンタイムパスワードを要求すればいいのよ。取引履歴参照ぐらいのことで、乱数表を入力させるのも。
そういう銀行あるけど逆効果なんだよな。乱数表って20~40個程度しかパターンがないんだけど、ロガー仕掛けられて情報蓄積された時を考えると不必要に乱数表の値を入れさせるのは結構危険。
というか乱数表自体がもう時代遅れも甚だしい。(はずなんだけど未だに新規開設でも使ってるじ○ん銀行とか大丈夫か?)
乱数表はSBIが使ってますな。もしくは独自認証アプリを入れるしかなく。独自アプリなんていけてないから、Microsoft Authenticatorにしてもらえないだろうか。。
>じ○ん銀行
じおん銀行?
#宇宙世紀に一般向け情報通信ネットワークの存在が表現されるようになったのはいつからだろう?#正直TV作品では見覚えが無い。
暗証番号を確認されるだけでもだいぶやばい。磁気カードな人間及び、カード現物を確保するルート用意した上での知人犯行に脆弱。
単純に一定期間内の暗証番号間違いをカウント一定数のエラー数だったらハニーポットアカウントにご招待この瞬間に人的行動監視対象&本人への確認適当な残金表示なのに確認行動をしない&送金を連続するような行動だったらブラック認定して取引停止
これで大抵の不正は防げそう
単純に一定期間内の暗証番号間違いをカウント
送信元アドレスが一定、ということであれば、カウントできるけど、そうでなければカウント困難では?たとえば、botnetを使うとか。
別にアドレスが不定であってもログイン失敗はカウントできるでしょ
無理でしょ。ログインに失敗するのは、毎回違うアカウントですよ。
コンシューマ向けのサービスじゃなかったら「一定回数の連続ログイン失敗」でサービス自体を止めてしまうことも出来るんだけど、それってDoS攻撃が成立したって意味になるので出来ないんだよね。パスワードスプレーは対処困難な攻撃の1つ。
(あっちがたぶん)リバースブルートフォース攻撃対策してるから、ヨシ!
とても恐ろしい群衆心理である。誰もリバースブルートフォース攻撃対策をしていないのだ。
> さすがにもうリバースブルートフォース攻撃なんか通用しないでしょう。
リバースブルートフォース攻撃は原理的にそもそも対策が難しいかと思うのですが、どうやって対策している想定でしょうか?せいぜい毎回3秒とかウェイトを入れて遅くするか、それこそ認証を全て二要素認証にするぐらいしか無いと思いますが。
元コメとは違う人ですが、ご指摘のようにリバースブルートフォースの完全な対策は困難です。
単純なものなら、同一接続元からのログイン試行失敗回数でウェイトを置く、というのがありますが、接続元を分散させたり、間隔をおいて試行したりのパスワードスプレー攻撃までいくと、単純なルールでは対応しきれません。
現実的には、さまざまな手法・条件を組み合わせて(システム全体のログイン失敗回数が急増しているとか、同一IDでのログイン試行時のUAや接続元地域が異なるとか、ログイン画面に仕込んだJavaScriptでマウスの動きが人間ぽいかどうかチェックするとか)確率的に攻撃っぽいものを検出するしかないです。
その上で、追加の認証を求めたり、反応を遅くしたりという感じですかね。
> ログイン画面に仕込んだJavaScriptでマウスの動きが人間ぽいか
これ銀行がやったら非難囂々なのでは?
こういう製品があります。
https://www.akamai.com/jp/ja/multimedia/documents/presentation/web-sec... [akamai.com]
具体的には知らないけど、金融機関で導入しているところがあってもおかしくないんじゃないかな。
銀行のサイトのログイン画面でマウスの動きを読み取ってどういう問題があるんだ?なんでもセキュリティとかプライバシーとか言えばいいってもんじゃないと思うんだが
自動ログイン系のアドインは全滅だな
キーボード操作でのログインやスマホ・タブレットからのログインはどうするんでしょう?マウス使わないよ?
そういうケースは警告の閾値下げるだけでしょ。それ単体で警告の材料としてるわけがない。マウス操作が人間っぽかったら、アタックされてるとの判定が甘くなる、って考えればわかるかな?
アカウントに対しての認証ミスを起こした回数を記録一定回数を失敗したら対象アカウントをロックでも簡単にロックしちゃうと悪戯ロックが流行るので、その対応も実装しようとすると面倒かも
> アカウントに対しての認証ミスを起こした回数を記録> 一定回数を失敗したら対象アカウントをロック
それはみんなが当然やってる普通のブルートフォース攻撃の対策な。今問題になっているのはリバースブルートフォース攻撃。こっちは毎回違う接続元から毎回違うアカウントに対して攻撃を掛けるから、接続元やアカウントでロックアウトはできない。
ロックしてしまえばいいじゃない。アカウントではなく接続元を。毎回違うって言ってもボットネットのリソースも無限ではないし。
銀行側にどんな権限があって接続元をロックできるんだよ。
IP変えながらアタックした場合、リバースブルートフォースは後から検知できるかも知れんが、拒否する方策があるなら知りたいね。各口座ごとに1回しかアタックしてこないのに、「認証前に」正規のリクエストとどうやって区別する? 「認証後」に検知できたって、それはすでに盗まれた後だからな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
今となっては過去の話 (スコア:0)
さすがにもうリバースブルートフォース攻撃なんか通用しないでしょう。
磁気タイプのキャッシュカード偽造の可能性が残ってるぐらい?
Re:今となっては過去の話 (スコア:4, 興味深い)
・接続IPを毎回変える
・アタック間隔をランダムにして十分にとる。
・正規ユーザーの利用が多い時間帯を狙う。
・いろんな銀行口座を混ぜる(一つの銀行のアタック回数が減る)
・連番攻撃せず、口座番号をシャッフルする。
・PINも毎回変える(下手な鉄砲も数撃ちゃ当たる方式なので別に固定じゃなくて良い)
・あからさまなPIN(日付とか)はあえて使わない。
さて正規ユーザに対するサービスを止めずにどうやって防ぐ?
Re: (スコア:0)
ログインごとにワンタイムパスワードの入力を要求する
Re: (スコア:0)
それは根本的解決すぎる。
今のダメダメな方式を変更せずに対策は不可能って話の流れなのでは?
Re: (スコア:0)
ログイン後のクリティカルな作業にのみ、ワンタイムパスワードを要求すればいいのよ。
取引履歴参照ぐらいのことで、乱数表を入力させるのも。
Re: (スコア:0)
そういう銀行あるけど逆効果なんだよな。
乱数表って20~40個程度しかパターンがないんだけど、ロガー仕掛けられて情報蓄積された時を
考えると不必要に乱数表の値を入れさせるのは結構危険。
というか乱数表自体がもう時代遅れも甚だしい。
(はずなんだけど未だに新規開設でも使ってるじ○ん銀行とか大丈夫か?)
Re: (スコア:0)
乱数表はSBIが使ってますな。もしくは独自認証アプリを入れるしかなく。
独自アプリなんていけてないから、Microsoft Authenticatorにしてもらえないだろうか。。
Re: (スコア:0)
>じ○ん銀行
じおん銀行?
#宇宙世紀に一般向け情報通信ネットワークの存在が表現されるようになったのはいつからだろう?
#正直TV作品では見覚えが無い。
Re:今となっては過去の話 (スコア:1)
// 違法ではないので地下ではない的
Re: (スコア:0)
暗証番号を確認されるだけでもだいぶやばい。
磁気カードな人間及び、カード現物を確保するルート用意した上での知人犯行に脆弱。
Re: (スコア:0)
単純に一定期間内の暗証番号間違いをカウント
一定数のエラー数だったらハニーポットアカウントにご招待
この瞬間に人的行動監視対象&本人への確認
適当な残金表示なのに確認行動をしない&送金を連続するような行動だったらブラック認定して取引停止
これで大抵の不正は防げそう
Re:今となっては過去の話 (スコア:1)
単純に一定期間内の暗証番号間違いをカウント
送信元アドレスが一定、ということであれば、カウントできるけど、そうでなければカウント困難では?
たとえば、botnetを使うとか。
Re: (スコア:0)
別にアドレスが不定であってもログイン失敗はカウントできるでしょ
Re: (スコア:0)
無理でしょ。
ログインに失敗するのは、毎回違うアカウントですよ。
Re: (スコア:0)
コンシューマ向けのサービスじゃなかったら「一定回数の連続ログイン失敗」で
サービス自体を止めてしまうことも出来るんだけど、それってDoS攻撃が成立した
って意味になるので出来ないんだよね。
パスワードスプレーは対処困難な攻撃の1つ。
Re:今となっては過去の話 (スコア:1)
(あっちがたぶん)リバースブルートフォース攻撃対策してるから、
ヨシ!
Re: (スコア:0)
とても恐ろしい群衆心理である。
誰もリバースブルートフォース攻撃対策をしていないのだ。
Re:今となっては過去の話 (スコア:1)
> さすがにもうリバースブルートフォース攻撃なんか通用しないでしょう。
リバースブルートフォース攻撃は原理的にそもそも対策が難しいかと思うのですが、どうやって対策している想定でしょうか?
せいぜい毎回3秒とかウェイトを入れて遅くするか、それこそ認証を全て二要素認証にするぐらいしか無いと思いますが。
Re:今となっては過去の話 (スコア:4, 興味深い)
元コメとは違う人ですが、ご指摘のようにリバースブルートフォースの完全な対策は困難です。
単純なものなら、同一接続元からのログイン試行失敗回数でウェイトを置く、というのがありますが、接続元を分散させたり、間隔をおいて試行したりのパスワードスプレー攻撃までいくと、単純なルールでは対応しきれません。
現実的には、さまざまな手法・条件を組み合わせて(システム全体のログイン失敗回数が急増しているとか、同一IDでのログイン試行時のUAや接続元地域が異なるとか、ログイン画面に仕込んだJavaScriptでマウスの動きが人間ぽいかどうかチェックするとか)確率的に攻撃っぽいものを検出するしかないです。
その上で、追加の認証を求めたり、反応を遅くしたりという感じですかね。
Re: (スコア:0)
> ログイン画面に仕込んだJavaScriptでマウスの動きが人間ぽいか
これ銀行がやったら非難囂々なのでは?
Re:今となっては過去の話 (スコア:1)
こういう製品があります。
https://www.akamai.com/jp/ja/multimedia/documents/presentation/web-sec... [akamai.com]
具体的には知らないけど、金融機関で導入しているところがあってもおかしくないんじゃないかな。
Re: (スコア:0)
銀行のサイトのログイン画面でマウスの動きを読み取ってどういう問題があるんだ?
なんでもセキュリティとかプライバシーとか言えばいいってもんじゃないと思うんだが
Re: (スコア:0)
自動ログイン系のアドインは全滅だな
Re: (スコア:0)
キーボード操作でのログインやスマホ・タブレットからのログインはどうするんでしょう?
マウス使わないよ?
Re: (スコア:0)
そういうケースは警告の閾値下げるだけでしょ。
それ単体で警告の材料としてるわけがない。
マウス操作が人間っぽかったら、アタックされてるとの判定が甘くなる、って考えればわかるかな?
真面目に対策コードを作ろうとしたら大変そう (スコア:0)
アカウントに対しての認証ミスを起こした回数を記録
一定回数を失敗したら対象アカウントをロック
でも簡単にロックしちゃうと悪戯ロックが流行るので、その対応も実装しようとすると面倒かも
Re: (スコア:0)
> アカウントに対しての認証ミスを起こした回数を記録
> 一定回数を失敗したら対象アカウントをロック
それはみんなが当然やってる普通のブルートフォース攻撃の対策な。
今問題になっているのはリバースブルートフォース攻撃。
こっちは毎回違う接続元から毎回違うアカウントに対して攻撃を掛けるから、接続元やアカウントでロックアウトはできない。
Re: (スコア:0)
ロックしてしまえばいいじゃない。アカウントではなく接続元を。
毎回違うって言ってもボットネットのリソースも無限ではないし。
Re: (スコア:0)
銀行側にどんな権限があって接続元をロックできるんだよ。
Re: (スコア:0)
IP変えながらアタックした場合、リバースブルートフォースは後から検知できるかも知れんが、拒否する方策があるなら知りたいね。各口座ごとに1回しかアタックしてこないのに、「認証前に」正規のリクエストとどうやって区別する? 「認証後」に検知できたって、それはすでに盗まれた後だからな。