アカウント名:
パスワード:
平文で保存しておいて表示なんてせずに、単に身元確認の上で再発行するものだけど。顧客に手間のかかる手段は提供できないとかそんな理由で妥協案を採用したんだろうな。スラドでもリスクと天秤でノーガードもありとか言う人は絶えないし、いつになったらセキュリティ意識が浸透するのやら…
この論議では原理で言えば最もセキュリティ原則を知らなければならないのは顧客なんだけどな。「パスワードは使い回ししない」
顧客視点での問題は「平文で保持している事」ではなく「漏洩する事」。「漏洩しない事」さえ満たされればそれは問題ではない。企業に送信した情報はいかなる状況でも確実に保護されるとは限らない。第三者の攻撃、企業の悪意、企業内部の個人の悪意、企業の過失、企業の無知、様々な過程で漏洩は起こり得る。顧客は企業への信頼と得られる価値とリスクを秤にかけて、その企業に与えるべき情報を顧客個人が判断しなければならない。与える情報のいくつかはやむを得ないものだが、共用のパスワードを複数の企業に渡す意味は無い。
こういう事を言うと企業の擁護だと言う人が出てくるが、そもそも論の話だ。データストアに平文で保持されていなければパスワード漏洩が起こらないというものではないし、顧客個人が情報保護の行動を取っていなければ、企業の与り知らぬ場面で容易に情報を窃取されてしまう事も起こる。
すべてのパスワードがユニークなら漏洩しても被害は小さい。これは確かにそう。ただ、異なるすべてのパスワードを人間が記憶する。この運用が不可能なのよ。管理ソフトを使えば可能だけど、利便性が著しく下がる。
問題の本質は、堅牢性と運用可能であるかの隔たりが大きすぎることだから、漏洩リスクの担保は顧客が負うべきというあなたの主張は、現実に則してないと思う。
ユーザーがパスワードを使い回さないのは当然として、企業側も多段認証やトークンなどより堅牢なシステムを用意すべきで、パスワードの平文保持なんてクソ仕様はやっぱり論外。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
セキュリティ原則を知らない現場と経営の悪魔合体だな (スコア:0)
平文で保存しておいて表示なんてせずに、単に身元確認の上で再発行するものだけど。
顧客に手間のかかる手段は提供できないとかそんな理由で妥協案を採用したんだろうな。
スラドでもリスクと天秤でノーガードもありとか言う人は絶えないし、いつになったらセキュリティ意識が浸透するのやら…
Re:セキュリティ原則を知らない現場と経営の悪魔合体だな (スコア:0)
この論議では原理で言えば最もセキュリティ原則を知らなければならないのは顧客なんだけどな。「パスワードは使い回ししない」
顧客視点での問題は「平文で保持している事」ではなく「漏洩する事」。「漏洩しない事」さえ満たされればそれは問題ではない。
企業に送信した情報はいかなる状況でも確実に保護されるとは限らない。
第三者の攻撃、企業の悪意、企業内部の個人の悪意、企業の過失、企業の無知、様々な過程で漏洩は起こり得る。
顧客は企業への信頼と得られる価値とリスクを秤にかけて、その企業に与えるべき情報を顧客個人が判断しなければならない。
与える情報のいくつかはやむを得ないものだが、共用のパスワードを複数の企業に渡す意味は無い。
こういう事を言うと企業の擁護だと言う人が出てくるが、そもそも論の話だ。
データストアに平文で保持されていなければパスワード漏洩が起こらないというものではないし、
顧客個人が情報保護の行動を取っていなければ、企業の与り知らぬ場面で容易に情報を窃取されてしまう事も起こる。
Re: (スコア:0)
すべてのパスワードがユニークなら漏洩しても被害は小さい。これは確かにそう。
ただ、異なるすべてのパスワードを人間が記憶する。この運用が不可能なのよ。
管理ソフトを使えば可能だけど、利便性が著しく下がる。
問題の本質は、堅牢性と運用可能であるかの隔たりが大きすぎることだから、
漏洩リスクの担保は顧客が負うべきというあなたの主張は、現実に則してないと思う。
ユーザーがパスワードを使い回さないのは当然として、
企業側も多段認証やトークンなどより堅牢なシステムを用意すべきで、
パスワードの平文保持なんてクソ仕様はやっぱり論外。