パスワードを忘れた? アカウント作成
14399244 story
お金

Twitterでハッカーに優しい銀行が話題に 80

ストーリー by nagazou
親切 部門より
Twitterで一部の銀行がハッカーに優しい仕様だとして話題になっていたようだ。イオン銀行やローソン銀行では、ユーザーの誕生月別に支店名が振り分けられる仕様であることから、支店名から名義人の誕生月が特定可能となる(発端となったriron博士のツイートINTERNET Watchイオン銀行ローソン)。

先日のリバースブルートフォース攻撃で狙われやすい暗証番号の話でもあったように、生年月日を暗証番号を例にしているユーザーはとても多く1~31日の日付、いや月によってはもっと少ない数字だけの調査で「当たり」暗証番号を引く可能性はとても高い。つまり攻撃者にとって、攻めやすいとても親切な銀行というなる。

なお誕生月別よりは安全だと思われるが、セブン銀行も支店名から口座開設月の特定が可能となっているとのこと(セブン銀行)。
  • by Anonymous Coward on 2020年09月23日 14時59分 (#3893640)

    もうおっさんしかクラッカーって用語使わんのね。

    ここに返信
    • by Anonymous Coward on 2020年09月23日 15時09分 (#3893650)

      おっさんなので、API公開して遊ばせてくれるとかそういった意味で「優しい」のかと思ってしまいますね。

    • by Anonymous Coward

      あたり前田のクラッカーもおっさんしか使わんね

    • by Anonymous Coward

      セキュリティが優れているとか、自由ソフトウェアとか思って本文読んだら違った。

    • by Anonymous Coward

      ハッカーに優しい→発火に優しい→炎上しやすい

  • by Anonymous Coward on 2020年09月23日 14時17分 (#3893599)

    キャッシュカード暗証番号の4桁数字って仕様は変えられないし、大半の銀行では常識の
    「ネットバンキングは別のユーザIDとパスワードを使う」って方法は安全ではあるけど
    「覚えられない」って問題があるし、どんなにIDとパスワードに辿り着きにくい仕組み(複雑なもの)
    にしたところでユーザ操作をマルウェアやフィッシングで盗まれたら終わり。

    結局のところ同時に盗まれる可能性がある「要素」だけで完結する認証を許してはならない。
    現時点で考えられるセキュリティ対策はそれに尽きる。

    ここに返信
    • by Anonymous Coward on 2020年09月23日 14時31分 (#3893616)

      ぎっちぎちのセキュリティは金もかかるだろうしユーザの利便性も落ちるから、補償がしっかりしてれば少々ザルでもええわ。
      クレカはまさにその路線だしな。
      犯罪者に金が流れるのがちょっと困りものだが。

      • by Anonymous Coward on 2020年09月24日 0時24分 (#3893982)

        ユーザに面倒を強いるだけがセキュリティじゃないと思うんだけどね。
        たとえば、登録されている電話番号に電話掛けて
        「ただいまの口座連携処理がお客様による操作でしたら1を押してください」
        って自動音声を流すだけでもいい。
        # 誤操作を恐れなければ9を押せば口座がロックされるとか。

        利便性を損ねるセキュリティって基本的には逆効果だと思う。
        パスワード要件を複雑にしたら付箋にメモって貼られるのと同じような話。

      • by Anonymous Coward

        銀行口座で金を盗まれると会社や自営業ではタイミングによっては倒産するからね。
        補償が追いつくのか知らんけど。

        • by Anonymous Coward

          セキュリティも度が過ぎると振込みや引き出しができなくて同じことになるかもよ。

      • by Anonymous Coward

        クレカは
        ・限度額って保険設計する上での現実的な上限がある
        ・高額決済は本人に確認の電話を入れる(多要素認証)
        ・引き出し側(加盟店)の責任を問うこともできる
        って補償しやすい環境だけど、銀行預金の場合は億単位のカネを一瞬で動かすことも
        日常的なので引き受ける保険条件が厳しくなると思う。

        利便性を考えたらIDとパスワードは口座番号と4桁暗証番号みたいなザルでもよかったんだよ。
        SMSとかパスワードトークンとかの他の要素が入っていれば問題なかった。
        (実際にそれらが導入された銀行では不正利用されていない)

        • by Anonymous Coward

          インターネットショッピングなら3Dセキュアもありますからね。
          「入力項目が(カード番号と有効期限とセキュリティコードより)多いと客が逃げる」というのがショッピングサイト側の言い分で、
          一向に導入されないのが問題なんですが……。

      • by Anonymous Coward

        自分の口座でも、入金手数料、出金手数料を取るようにすればいいわな。
        銀行を、金庫代わりに使っているようなものだから、安心料だ。

    • by Anonymous Coward on 2020年09月23日 16時11分 (#3893695)

      キャッシュカード暗証番号の4桁数字って仕様は変えられないし

      技術的には難しくないでしょう。
      海外では6桁が一般的な国が多い(中国や香港もそう)し、私は海外の銀行(HSBC)のATMカードを持ってますが、日本の銀行で普通に6桁入力できます。
      遅れているとされるゆうちょ銀行や、コンビニATM(セブン銀行)でも普通に6桁のPINに対応していてきちんと入力を受け付けます。

      ATMカードの暗証番号はICクレジットカードと違ってサーバ管理です。ICキャッシュカードであってもATMカードには記録されてません。6桁にするのはそこまで難しくないでしょう。

      ただ、4桁と6桁の暗証番号が混在することにより、暗証番号入力後に「確定」ボタンを押す使用がでてくるので、そこでサポートコストが多少かかるかもしれませんが。

      • by Anonymous Coward

        6桁でもさほど変わらん気がするが。その程度なら口座数から考えてリバースブルートフォースは効く。

    • by Anonymous Coward

      カードはセキュアエレメントを利用したICカードで、暗証番号の代わりにワンタイムパスワードを
      利用する方向にしてほしいなぁ。

      ユーザの記憶力に頼らない&漏れた時も変更が容易になる方向に向かってほしいなと思いつつ。

  • by Anonymous Coward on 2020年09月23日 15時57分 (#3893686)

    契約者の口座開設時の名前・住所・電話番号・誕生日をSHA-256ハッシュに通して、
    下位4bitで支店名を振り分ければいい
    支店は16つ用意で

    ここに返信
    • 支店名を40億くらい用意して、ランダム(または契約者の情報をもとにHMAC-SHA256して下位ビットをとって)に割り当てるようにしたら、支店名も知識認証の一部になってより強固になるのでは、

      • by Anonymous Coward
        自分の口座の支店番号がわかんなくなっちゃいました!ってなるからセキュリティ落としてでも覚えやすくしてるわけで、見た目ランダムになっちゃうハッシュは不適当。
        ソニー銀行みたいに本店1つしかありません、で十分。999万9999口座までは。
        • by Anonymous Coward

          銀行口座の認証情報とは直接結び付かないけどユーザにとってなじみのある情報にできればいいけどね。
          例えば支店名を都道府県にしておいて届け出住所と紐づけるのはどうだろう?
          海外ユーザ向けには専用支店を用意する?

      • by Anonymous Coward

        ってか、そもそも口座番号って公開情報だよ。
        「振込先」として第三者に開示することもあるので、ここにセキュリティ要素を含めてはいけない。

        何のためにオンラインバンキングは口座番号ではログインできないようにしてると思ってるんだと。
        (一部のセキュリティ意識の低すぎる例外は除く)

    • 「16つ」って「じゅうむっつ」と読むのかな?

  • by Anonymous Coward on 2020年09月23日 14時11分 (#3893594)

    さすがにもうリバースブルートフォース攻撃なんか通用しないでしょう。
    磁気タイプのキャッシュカード偽造の可能性が残ってるぐらい?

    ここに返信
    • by Anonymous Coward on 2020年09月23日 16時54分 (#3893743)

      ・接続IPを毎回変える
      ・アタック間隔をランダムにして十分にとる。
      ・正規ユーザーの利用が多い時間帯を狙う。
      ・いろんな銀行口座を混ぜる(一つの銀行のアタック回数が減る)
      ・連番攻撃せず、口座番号をシャッフルする。
      ・PINも毎回変える(下手な鉄砲も数撃ちゃ当たる方式なので別に固定じゃなくて良い)
      ・あからさまなPIN(日付とか)はあえて使わない。

      さて正規ユーザに対するサービスを止めずにどうやって防ぐ?

    • by Anonymous Coward on 2020年09月23日 14時15分 (#3893596)

      (あっちがたぶん)リバースブルートフォース攻撃対策してるから、
      ヨシ!

      • by Anonymous Coward

        とても恐ろしい群衆心理である。
        誰もリバースブルートフォース攻撃対策をしていないのだ。

    • by Anonymous Coward on 2020年09月23日 14時39分 (#3893625)

      > さすがにもうリバースブルートフォース攻撃なんか通用しないでしょう。

      リバースブルートフォース攻撃は原理的にそもそも対策が難しいかと思うのですが、どうやって対策している想定でしょうか?
      せいぜい毎回3秒とかウェイトを入れて遅くするか、それこそ認証を全て二要素認証にするぐらいしか無いと思いますが。

      • by nim (10479) on 2020年09月23日 14時51分 (#3893636)

        元コメとは違う人ですが、ご指摘のようにリバースブルートフォースの完全な対策は困難です。

        単純なものなら、同一接続元からのログイン試行失敗回数でウェイトを置く、というのがありますが、接続元を分散させたり、間隔をおいて試行したりのパスワードスプレー攻撃までいくと、単純なルールでは対応しきれません。

        現実的には、さまざまな手法・条件を組み合わせて(システム全体のログイン失敗回数が急増しているとか、同一IDでのログイン試行時のUAや接続元地域が異なるとか、ログイン画面に仕込んだJavaScriptでマウスの動きが人間ぽいかどうかチェックするとか)確率的に攻撃っぽいものを検出するしかないです。

        その上で、追加の認証を求めたり、反応を遅くしたりという感じですかね。

    • アカウントに対しての認証ミスを起こした回数を記録
      一定回数を失敗したら対象アカウントをロック
      でも簡単にロックしちゃうと悪戯ロックが流行るので、その対応も実装しようとすると面倒かも

      • by Anonymous Coward

        > アカウントに対しての認証ミスを起こした回数を記録
        > 一定回数を失敗したら対象アカウントをロック

        それはみんなが当然やってる普通のブルートフォース攻撃の対策な。
        今問題になっているのはリバースブルートフォース攻撃。
        こっちは毎回違う接続元から毎回違うアカウントに対して攻撃を掛けるから、接続元やアカウントでロックアウトはできない。

    • by Anonymous Coward

      IP変えながらアタックした場合、リバースブルートフォースは後から検知できるかも知れんが、拒否する方策があるなら知りたいね。各口座ごとに1回しかアタックしてこないのに、「認証前に」正規のリクエストとどうやって区別する? 「認証後」に検知できたって、それはすでに盗まれた後だからな。

  • by Anonymous Coward on 2020年09月23日 14時39分 (#3893624)

    今時の銀行口座なら、自分の生年月日や電話番号は暗証番号にできないはずだけど

    ここに返信
    • by Anonymous Coward

      新規登録できないだけで、既存の口座はそのままじゃないですかね?
      自分も残高はほぼゼロの口座にそういうのがありますし。
      既存のものを銀行側の都合で勝手に変えるのはハードル高いんだと思います。

    • by Anonymous Coward

      家族の誕生日、引っ越す前の電話番号なんかは結構使われるらしい。

  • by Anonymous Coward on 2020年09月23日 15時41分 (#3893670)

    攻撃者は2月生まれの支店のみを選ぶので、29日を除く2月生まれ以外は安心。
    やっぱ統計を見て一番出生者数が多い日を重点的に攻撃したりするのかな。

    ここに返信
    • 一番出生者数が多い日を選ぶなら、2月に限定しないと思うよ。

      --
      svn-init() {
        svnadmin create .svnrepo
        svn checkout file://$PWD/.svnrepo .
      }
      • by Anonymous Coward

        月の出生者数に対する一日の出生者数の割合の最大値が問題だから2月じゃないかな?
        分母の1割はかなり魅力。
        年を跨ぐ上、妊娠期間には数日の誤差があるし曜日も毎年変わるし。

        と思ったけど、結構偏りがあるみたい(ランキング [televi.tokyo]・Excel [ashisuto.co.jp])。
        普通に5割以上違うみたい。
        サンプルが増えれば偏りはかなり減りそうだが、確かに2月じゃなくてもよさそう。

        • by Anonymous Coward

          > 月の出生者数に対する一日の出生者数の割合の最大値が問題だから2月じゃないかな?

          月の出生者は均等で、2月は日数が少ないから1日当たりの出生者数が
          多くなるって前提に読み取れるんですがそれは。

          単に月が確定している口座に誕生日パスワードアタックするなら2月を
          ターゲットにした方が試行回数が少なくて済む(から攻撃される)ってだけの話かと
          ※元コメがなんで断定調かは分かりませんが、

          • by Anonymous Coward

            一年中一日あたりの出生者数が同じかつあらかじめ誕生月が既知の場合、誕生日が2月1日なのは1/28.5。
            口座番号は連番だとか「存在しません」と言われるかで既知なら、出生者数自体は問題ではない。
            2月生まれだと分かっている人が2月の何日に産まれたかの問題。

typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...