Twitterでハッカーに優しい銀行が話題に 80
ストーリー by nagazou
親切 部門より
親切 部門より
Twitterで一部の銀行がハッカーに優しい仕様だとして話題になっていたようだ。イオン銀行やローソン銀行では、ユーザーの誕生月別に支店名が振り分けられる仕様であることから、支店名から名義人の誕生月が特定可能となる（発端となったriron博士のツイート、INTERNET Watch、イオン銀行、ローソン）。
先日のリバースブルートフォース攻撃で狙われやすい暗証番号の話でもあったように、生年月日を暗証番号を例にしているユーザーはとても多く1～31日の日付、いや月によってはもっと少ない数字だけの調査で「当たり」暗証番号を引く可能性はとても高い。つまり攻撃者にとって、攻めやすいとても親切な銀行というなる。
なお誕生月別よりは安全だと思われるが、セブン銀行も支店名から口座開設月の特定が可能となっているとのこと（セブン銀行）。
先日のリバースブルートフォース攻撃で狙われやすい暗証番号の話でもあったように、生年月日を暗証番号を例にしているユーザーはとても多く1～31日の日付、いや月によってはもっと少ない数字だけの調査で「当たり」暗証番号を引く可能性はとても高い。つまり攻撃者にとって、攻めやすいとても親切な銀行というなる。
なお誕生月別よりは安全だと思われるが、セブン銀行も支店名から口座開設月の特定が可能となっているとのこと（セブン銀行）。
ハッカーに優しいってそっちかよ (スコア:4, すばらしい洞察)
もうおっさんしかクラッカーって用語使わんのね。
Re:ハッカーに優しいってそっちかよ (スコア:2, おもしろおかしい)
おっさんなので、API公開して遊ばせてくれるとかそういった意味で「優しい」のかと思ってしまいますね。
Re: (スコア:0)
あたり前田のクラッカーもおっさんしか使わんね
Re: (スコア:0)
セキュリティが優れているとか、自由ソフトウェアとか思って本文読んだら違った。
Re: (スコア:0)
ハッカーに優しい→発火に優しい→炎上しやすい
パスワードは破られるものって前提 (スコア:2, すばらしい洞察)
キャッシュカード暗証番号の4桁数字って仕様は変えられないし、大半の銀行では常識の
「ネットバンキングは別のユーザIDとパスワードを使う」って方法は安全ではあるけど
「覚えられない」って問題があるし、どんなにIDとパスワードに辿り着きにくい仕組み（複雑なもの）
にしたところでユーザ操作をマルウェアやフィッシングで盗まれたら終わり。
結局のところ同時に盗まれる可能性がある「要素」だけで完結する認証を許してはならない。
現時点で考えられるセキュリティ対策はそれに尽きる。
Re:パスワードは破られるものって前提 (スコア:1)
ぎっちぎちのセキュリティは金もかかるだろうしユーザの利便性も落ちるから、補償がしっかりしてれば少々ザルでもええわ。
クレカはまさにその路線だしな。
犯罪者に金が流れるのがちょっと困りものだが。
Re:パスワードは破られるものって前提 (スコア:1)
ユーザに面倒を強いるだけがセキュリティじゃないと思うんだけどね。
たとえば、登録されている電話番号に電話掛けて
「ただいまの口座連携処理がお客様による操作でしたら１を押してください」
って自動音声を流すだけでもいい。
# 誤操作を恐れなければ９を押せば口座がロックされるとか。
利便性を損ねるセキュリティって基本的には逆効果だと思う。
パスワード要件を複雑にしたら付箋にメモって貼られるのと同じような話。
Re: (スコア:0)
銀行口座で金を盗まれると会社や自営業ではタイミングによっては倒産するからね。
補償が追いつくのか知らんけど。
Re: (スコア:0)
セキュリティも度が過ぎると振込みや引き出しができなくて同じことになるかもよ。
Re: (スコア:0)
クレカは
・限度額って保険設計する上での現実的な上限がある
・高額決済は本人に確認の電話を入れる(多要素認証)
・引き出し側(加盟店)の責任を問うこともできる
って補償しやすい環境だけど、銀行預金の場合は億単位のカネを一瞬で動かすことも
日常的なので引き受ける保険条件が厳しくなると思う。
利便性を考えたらIDとパスワードは口座番号と4桁暗証番号みたいなザルでもよかったんだよ。
SMSとかパスワードトークンとかの他の要素が入っていれば問題なかった。
(実際にそれらが導入された銀行では不正利用されていない)
Re: (スコア:0)
インターネットショッピングなら3Dセキュアもありますからね。
「入力項目が（カード番号と有効期限とセキュリティコードより）多いと客が逃げる」というのがショッピングサイト側の言い分で、
一向に導入されないのが問題なんですが……。
Re: (スコア:0)
自分の口座でも、入金手数料、出金手数料を取るようにすればいいわな。
銀行を、金庫代わりに使っているようなものだから、安心料だ。
暗証番号6桁には簡単にできますが (スコア:1)
キャッシュカード暗証番号の4桁数字って仕様は変えられないし
技術的には難しくないでしょう。
海外では6桁が一般的な国が多い（中国や香港もそう）し、私は海外の銀行（HSBC）のATMカードを持ってますが、日本の銀行で普通に6桁入力できます。
遅れているとされるゆうちょ銀行や、コンビニATM（セブン銀行）でも普通に6桁のPINに対応していてきちんと入力を受け付けます。
ATMカードの暗証番号はICクレジットカードと違ってサーバ管理です。ICキャッシュカードであってもATMカードには記録されてません。6桁にするのはそこまで難しくないでしょう。
ただ、4桁と6桁の暗証番号が混在することにより、暗証番号入力後に「確定」ボタンを押す使用がでてくるので、そこでサポートコストが多少かかるかもしれませんが。
Re: (スコア:0)
6桁でもさほど変わらん気がするが。その程度なら口座数から考えてリバースブルートフォースは効く。
Re: (スコア:0)
カードはセキュアエレメントを利用したICカードで、暗証番号の代わりにワンタイムパスワードを
利用する方向にしてほしいなぁ。
ユーザの記憶力に頼らない&漏れた時も変更が容易になる方向に向かってほしいなと思いつつ。
ハッシュ関数つかえばいい (スコア:1)
契約者の口座開設時の名前・住所・電話番号・誕生日をSHA-256ハッシュに通して、
下位4bitで支店名を振り分ければいい
支店は16つ用意で
Re:ハッシュ関数つかえばいい (スコア:1)
支店名を40億くらい用意して、ランダム（または契約者の情報をもとにHMAC-SHA256して下位ビットをとって）に割り当てるようにしたら、支店名も知識認証の一部になってより強固になるのでは、
Re: (スコア:0)
ソニー銀行みたいに本店１つしかありません、で十分。999万9999口座までは。
Re: (スコア:0)
銀行口座の認証情報とは直接結び付かないけどユーザにとってなじみのある情報にできればいいけどね。
例えば支店名を都道府県にしておいて届け出住所と紐づけるのはどうだろう？
海外ユーザ向けには専用支店を用意する？
Re: (スコア:0)
ってか、そもそも口座番号って公開情報だよ。
「振込先」として第三者に開示することもあるので、ここにセキュリティ要素を含めてはいけない。
何のためにオンラインバンキングは口座番号ではログインできないようにしてると思ってるんだと。
(一部のセキュリティ意識の低すぎる例外は除く)
Re:ハッシュ関数つかえばいい (スコア:1)
「16つ」って「じゅうむっつ」と読むのかな?
Re:ハッシュ関数つかえばいい (スコア:1)
生年月日が推測されやすい……ってことはないか。いやあった (スコア:1)
タレコめばよかった。 [srad.jp]
-- う～ん、バッドノウハウ？
今となっては過去の話 (スコア:0)
さすがにもうリバースブルートフォース攻撃なんか通用しないでしょう。
磁気タイプのキャッシュカード偽造の可能性が残ってるぐらい？
Re:今となっては過去の話 (スコア:4, 興味深い)
・接続IPを毎回変える
・アタック間隔をランダムにして十分にとる。
・正規ユーザーの利用が多い時間帯を狙う。
・いろんな銀行口座を混ぜる(一つの銀行のアタック回数が減る)
・連番攻撃せず、口座番号をシャッフルする。
・PINも毎回変える(下手な鉄砲も数撃ちゃ当たる方式なので別に固定じゃなくて良い)
・あからさまなPIN(日付とか)はあえて使わない。
さて正規ユーザに対するサービスを止めずにどうやって防ぐ？
Re: (スコア:0)
ログインごとにワンタイムパスワードの入力を要求する
Re: (スコア:0)
それは根本的解決すぎる。
今のダメダメな方式を変更せずに対策は不可能って話の流れなのでは？
Re: (スコア:0)
ログイン後のクリティカルな作業にのみ、ワンタイムパスワードを要求すればいいのよ。
取引履歴参照ぐらいのことで、乱数表を入力させるのも。
Re:今となっては過去の話 (スコア:1)
// 違法ではないので地下ではない的
Re:今となっては過去の話 (スコア:1)
単純に一定期間内の暗証番号間違いをカウント
送信元アドレスが一定、ということであれば、カウントできるけど、そうでなければカウント困難では?
たとえば、botnetを使うとか。
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)
自動ログイン系のアドインは全滅だな
真面目に対策コードを作ろうとしたら大変そう (スコア:0)
アカウントに対しての認証ミスを起こした回数を記録
一定回数を失敗したら対象アカウントをロック
でも簡単にロックしちゃうと悪戯ロックが流行るので、その対応も実装しようとすると面倒かも
Re: (スコア:0)
＞ アカウントに対しての認証ミスを起こした回数を記録
＞ 一定回数を失敗したら対象アカウントをロック
それはみんなが当然やってる普通のブルートフォース攻撃の対策な。
今問題になっているのはリバースブルートフォース攻撃。
こっちは毎回違う接続元から毎回違うアカウントに対して攻撃を掛けるから、接続元やアカウントでロックアウトはできない。
Re: (スコア:0)
IP変えながらアタックした場合、リバースブルートフォースは後から検知できるかも知れんが、拒否する方策があるなら知りたいね。各口座ごとに1回しかアタックしてこないのに、「認証前に」正規のリクエストとどうやって区別する？ 「認証後」に検知できたって、それはすでに盗まれた後だからな。
暗証番号に使えない数字 (スコア:0)
今時の銀行口座なら、自分の生年月日や電話番号は暗証番号にできないはずだけど
Re: (スコア:0)
新規登録できないだけで、既存の口座はそのままじゃないですかね？
自分も残高はほぼゼロの口座にそういうのがありますし。
既存のものを銀行側の都合で勝手に変えるのはハードル高いんだと思います。
Re: (スコア:0)
家族の誕生日、引っ越す前の電話番号なんかは結構使われるらしい。
2月生まれ以外はむしろ安心 (スコア:0)
攻撃者は2月生まれの支店のみを選ぶので、29日を除く2月生まれ以外は安心。
やっぱ統計を見て一番出生者数が多い日を重点的に攻撃したりするのかな。
Re:2月生まれ以外はむしろ安心 (スコア:2)
一番出生者数が多い日を選ぶなら、2月に限定しないと思うよ。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re: (スコア:0)
月の出生者数に対する一日の出生者数の割合の最大値が問題だから2月じゃないかな？
分母の1割はかなり魅力。
年を跨ぐ上、妊娠期間には数日の誤差があるし曜日も毎年変わるし。
と思ったけど、結構偏りがあるみたい(ランキング [televi.tokyo]・Excel [ashisuto.co.jp])。
普通に5割以上違うみたい。
サンプルが増えれば偏りはかなり減りそうだが、確かに2月じゃなくてもよさそう。
Re: (スコア:0)
> 月の出生者数に対する一日の出生者数の割合の最大値が問題だから2月じゃないかな？
月の出生者は均等で、２月は日数が少ないから１日当たりの出生者数が
多くなるって前提に読み取れるんですがそれは。
単に月が確定している口座に誕生日パスワードアタックするなら２月を
ターゲットにした方が試行回数が少なくて済む（から攻撃される）ってだけの話かと
※元コメがなんで断定調かは分かりませんが、
Re: (スコア:0)
一年中一日あたりの出生者数が同じかつあらかじめ誕生月が既知の場合、誕生日が2月1日なのは1/28.5。
口座番号は連番だとか「存在しません」と言われるかで既知なら、出生者数自体は問題ではない。
2月生まれだと分かっている人が2月の何日に産まれたかの問題。