アカウント名:
パスワード:
キャッシュカード暗証番号の4桁数字って仕様は変えられないし、大半の銀行では常識の「ネットバンキングは別のユーザIDとパスワードを使う」って方法は安全ではあるけど「覚えられない」って問題があるし、どんなにIDとパスワードに辿り着きにくい仕組み（複雑なもの）にしたところでユーザ操作をマルウェアやフィッシングで盗まれたら終わり。
結局のところ同時に盗まれる可能性がある「要素」だけで完結する認証を許してはならない。現時点で考えられるセキュリティ対策はそれに尽きる。
ぎっちぎちのセキュリティは金もかかるだろうしユーザの利便性も落ちるから、補償がしっかりしてれば少々ザルでもええわ。クレカはまさにその路線だしな。犯罪者に金が流れるのがちょっと困りものだが。
ユーザに面倒を強いるだけがセキュリティじゃないと思うんだけどね。たとえば、登録されている電話番号に電話掛けて「ただいまの口座連携処理がお客様による操作でしたら１を押してください」って自動音声を流すだけでもいい。# 誤操作を恐れなければ９を押せば口座がロックされるとか。
利便性を損ねるセキュリティって基本的には逆効果だと思う。パスワード要件を複雑にしたら付箋にメモって貼られるのと同じような話。
銀行口座で金を盗まれると会社や自営業ではタイミングによっては倒産するからね。補償が追いつくのか知らんけど。
セキュリティも度が過ぎると振込みや引き出しができなくて同じことになるかもよ。
某信用金庫のインターネットバンキングがパスワードロックされた時の解除も口座がある支店で口座名義人本人+本人確認書類+申請書でしたNumLockがかかってる事に気づかず単身赴任先でロックされた時は難儀しました
クレカは・限度額って保険設計する上での現実的な上限がある・高額決済は本人に確認の電話を入れる(多要素認証)・引き出し側(加盟店)の責任を問うこともできるって補償しやすい環境だけど、銀行預金の場合は億単位のカネを一瞬で動かすことも日常的なので引き受ける保険条件が厳しくなると思う。
利便性を考えたらIDとパスワードは口座番号と4桁暗証番号みたいなザルでもよかったんだよ。SMSとかパスワードトークンとかの他の要素が入っていれば問題なかった。(実際にそれらが導入された銀行では不正利用されていない)
インターネットショッピングなら3Dセキュアもありますからね。「入力項目が（カード番号と有効期限とセキュリティコードより）多いと客が逃げる」というのがショッピングサイト側の言い分で、一向に導入されないのが問題なんですが……。
まぁ、3Dセキュアを導入してない場合は不正利用時にショッピングサイトの負担になるだけ。導入してればカード会社が持ってくれるので「逃げられるリスク」と「不正利用時のリスク」のどちらを取るか判断する権利は加盟店側が持ってる。
>「入力項目が（カード番号と有効期限とセキュリティコードより）多いと客が逃げる」というのがショッピングサイト側の言い分で、取扱商品(というかターゲット客層)にもよりますが、実際に3Dセキュア入れるとコンバージョン率が半端無く下がる上コールセンターへの問い合わせ&クレームも増えるので・・・更に、取扱商品がある程度の利益率があり転売価値が低い商品だと、カード会社に不正利用のチャージバックを支払った方が大体儲かります
別な方も書かれていますが、大半のアクワイアラ(クレジットカードの決済代行会社)のEC用のサービスではセキュリティ
自分の口座でも、入金手数料、出金手数料を取るようにすればいいわな。銀行を、金庫代わりに使っているようなものだから、安心料だ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
パスワードは破られるものって前提 (スコア:2, すばらしい洞察)
キャッシュカード暗証番号の4桁数字って仕様は変えられないし、大半の銀行では常識の
「ネットバンキングは別のユーザIDとパスワードを使う」って方法は安全ではあるけど
「覚えられない」って問題があるし、どんなにIDとパスワードに辿り着きにくい仕組み（複雑なもの）
にしたところでユーザ操作をマルウェアやフィッシングで盗まれたら終わり。
結局のところ同時に盗まれる可能性がある「要素」だけで完結する認証を許してはならない。
現時点で考えられるセキュリティ対策はそれに尽きる。
Re:パスワードは破られるものって前提 (スコア:1)
ぎっちぎちのセキュリティは金もかかるだろうしユーザの利便性も落ちるから、補償がしっかりしてれば少々ザルでもええわ。
クレカはまさにその路線だしな。
犯罪者に金が流れるのがちょっと困りものだが。
Re:パスワードは破られるものって前提 (スコア:1)
ユーザに面倒を強いるだけがセキュリティじゃないと思うんだけどね。
たとえば、登録されている電話番号に電話掛けて
「ただいまの口座連携処理がお客様による操作でしたら１を押してください」
って自動音声を流すだけでもいい。
# 誤操作を恐れなければ９を押せば口座がロックされるとか。
利便性を損ねるセキュリティって基本的には逆効果だと思う。
パスワード要件を複雑にしたら付箋にメモって貼られるのと同じような話。
Re: (スコア:0)
銀行口座で金を盗まれると会社や自営業ではタイミングによっては倒産するからね。
補償が追いつくのか知らんけど。
Re: (スコア:0)
セキュリティも度が過ぎると振込みや引き出しができなくて同じことになるかもよ。
Re: (スコア:0)
某信用金庫のインターネットバンキングがパスワードロックされた時の解除も口座がある支店で口座名義人本人+本人確認書類+申請書でした
NumLockがかかってる事に気づかず単身赴任先でロックされた時は難儀しました
Re: (スコア:0)
クレカは
・限度額って保険設計する上での現実的な上限がある
・高額決済は本人に確認の電話を入れる(多要素認証)
・引き出し側(加盟店)の責任を問うこともできる
って補償しやすい環境だけど、銀行預金の場合は億単位のカネを一瞬で動かすことも
日常的なので引き受ける保険条件が厳しくなると思う。
利便性を考えたらIDとパスワードは口座番号と4桁暗証番号みたいなザルでもよかったんだよ。
SMSとかパスワードトークンとかの他の要素が入っていれば問題なかった。
(実際にそれらが導入された銀行では不正利用されていない)
Re: (スコア:0)
インターネットショッピングなら3Dセキュアもありますからね。
「入力項目が（カード番号と有効期限とセキュリティコードより）多いと客が逃げる」というのがショッピングサイト側の言い分で、
一向に導入されないのが問題なんですが……。
Re: (スコア:0)
まぁ、3Dセキュアを導入してない場合は不正利用時にショッピングサイトの負担になるだけ。
導入してればカード会社が持ってくれるので「逃げられるリスク」と「不正利用時のリスク」の
どちらを取るか判断する権利は加盟店側が持ってる。
Re: (スコア:0)
>「入力項目が（カード番号と有効期限とセキュリティコードより）多いと客が逃げる」というのがショッピングサイト側の言い分で、
取扱商品(というかターゲット客層)にもよりますが、実際に3Dセキュア入れるとコンバージョン率が半端無く下がる上
コールセンターへの問い合わせ&クレームも増えるので・・・
更に、取扱商品がある程度の利益率があり転売価値が低い商品だと、カード会社に不正利用のチャージバックを支払った方が大体儲かります
別な方も書かれていますが、大半のアクワイアラ(クレジットカードの決済代行会社)のEC用のサービスでは
セキュリティ
Re: (スコア:0)
自分の口座でも、入金手数料、出金手数料を取るようにすればいいわな。
銀行を、金庫代わりに使っているようなものだから、安心料だ。