アカウント名:
パスワード:
こういう事件を見るたびになぜパスワードを平文保存するのか理解できないのだが。ハッシュ化するのが常識じゃないのか?
こういうコメントを見るたび、結構複雑な気分になる。常識なのは確かなのだが。個人的にはパスワードよりもその他の個人情報の方が流出の害があるので、パスワードが平文保存されていてもあまり問題はない。(パスワードの使い回しは、ユーザーの方が悪いと思っている)どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。
パスワードを平文保存していると、管理者レベルの人に(意識しなくてもうっかり)パスワードを見られてしまうリスクもあるが、メアドの類も同様に他人には見られたくない情報なので、取り立ててパスワードばかりを厳重に取り扱ってもらう事が良いとも言えない。
まあ、パスワードを平文保存しておくメリットは特にないから、ハッシュ化ぐらいやっておけという事なのだろうが・・。
どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。
エンドユーザの立場としては確かにそうかもしれないけど、元々、特殊な事情がない限り、平文のパスワード(可逆な暗号化処理を処理をしている場合を含む)をシステム側で保持する理由がないのに、それを平文で取得できた時点で、住所、氏名に関するまっとうな保護手段が容易できるわけがない、と思っちゃうなぁ。
可逆な形でユーザのパスワードを保持するって、サーバサイドにとっては、かなりリスクの高い行為なんだけど。
個人情報もユーザーパスワードで暗号化すればいいのに、ということでは。それならパスワードをハッシュ化しておけば、パスワードが判明しない限り個人情報が漏洩することもない。
とはいえ、運用側としては、請求書送るとか運用上の目的があって個人情報を持っていると思うので、復号できないと困ってしまうのは確か。そうするとバックドアを用意するか、パスワードを復号可能な状態で保存するか、になってしまう……
そこで考えた。個人情報を暗号化したキーを所有するのは管理者のみとする。ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。登録済みの個人情報を修正するには、単純に再登録する。(修正不可。上書きのみ。項目単位での部分的な再登録は許可)かつて、パスワードの確認機能を廃して再設定機能のみとしたように、個人情報も確認機能を取っ払って再設定のみ可能としてしまう。これならどうだろう。
個人情報を暗号化したキーを所有するのは管理者のみとする。ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。
「のみとする」なんて言葉だけで対策になってないです。何らかの問題で両者が漏れて、漏洩するだけでしょう。
大抵の情報漏洩は、「閲覧できるのは権限のあるユーザーのみとする」システムで起きていますよ。
普通は、
とするかな。確か、Windows で暗号化フォルダを使った時の挙動なんかが、こんな感じだったはず。
郵便局が住所と氏名をハッシュ化するサービスを提供すれば、IT屋が住所と氏名を管理する必要は全くないですよね。
いや、運用のためならそういう情報を外部公開しているサーバや同じサーバセグメントに置いておく必要は無いわけで。ユーザーが変更する度にトリガーでもかませ、外部から一方通行で参照できない管理セグメントのどっかへ変更を飛ばしてそちらで管理するとか、やり様はいろいろとある。
問題は本人がパスワード忘れて復号化も出来なくなってしまった時だけど、そのときは別途サービス側で用意した仮パスワードで暗号化したデータで上書きしてしまうとかさ。
>問題は本人がパスワード忘れて復号化も出来なくなってしまった時
このときに、そのIDの持ち主は連絡してきた本人とどうやって確認するか?が問題では?
普通、個人情報をある程度比較して一致してたら本人とみ見なすと思うのですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
パスワードを平文保存 (スコア:0)
こういう事件を見るたびになぜパスワードを平文保存するのか理解できないのだが。
ハッシュ化するのが常識じゃないのか?
Re: (スコア:0)
こういうコメントを見るたび、結構複雑な気分になる。常識なのは確かなのだが。
個人的にはパスワードよりもその他の個人情報の方が流出の害があるので、パスワードが平文保存されていてもあまり問題はない。
(パスワードの使い回しは、ユーザーの方が悪いと思っている)
どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。
パスワードを平文保存していると、管理者レベルの人に(意識しなくてもうっかり)パスワードを見られてしまうリスクもあるが、
メアドの類も同様に他人には見られたくない情報なので、取り立ててパスワードばかりを厳重に取り扱ってもらう事が良いとも言えない。
まあ、パスワードを平文保存しておくメリットは特にないから、ハッシュ化ぐらいやっておけという事なのだろうが・・。
Re:パスワードを平文保存 (スコア:2)
どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。
エンドユーザの立場としては確かにそうかもしれないけど、元々、特殊な事情がない限り、平文のパスワード(可逆な暗号化処理を処理をしている場合を含む)をシステム側で保持する理由がないのに、それを平文で取得できた時点で、住所、氏名に関するまっとうな保護手段が容易できるわけがない、と思っちゃうなぁ。
可逆な形でユーザのパスワードを保持するって、サーバサイドにとっては、かなりリスクの高い行為なんだけど。
Re:パスワードを平文保存 (スコア:1)
個人情報もユーザーパスワードで暗号化すればいいのに、ということでは。
それならパスワードをハッシュ化しておけば、パスワードが判明しない限り個人情報が漏洩することもない。
とはいえ、運用側としては、請求書送るとか運用上の目的があって個人情報を持っていると思うので、復号できないと困ってしまうのは確か。そうするとバックドアを用意するか、パスワードを復号可能な状態で保存するか、になってしまう……
そこで考えた。
個人情報を暗号化したキーを所有するのは管理者のみとする。
ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。
登録済みの個人情報を修正するには、単純に再登録する。(修正不可。上書きのみ。項目単位での部分的な再登録は許可)
かつて、パスワードの確認機能を廃して再設定機能のみとしたように、個人情報も確認機能を取っ払って再設定のみ可能としてしまう。
これならどうだろう。
Re:パスワードを平文保存 (スコア:1)
個人情報を暗号化したキーを所有するのは管理者のみとする。
ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。
「のみとする」なんて言葉だけで対策になってないです。
何らかの問題で両者が漏れて、漏洩するだけでしょう。
大抵の情報漏洩は、「閲覧できるのは権限のあるユーザーのみとする」システムで起きていますよ。
Re:パスワードを平文保存 (スコア:1)
とはいえ、運用側としては、請求書送るとか運用上の目的があって個人情報を持っていると思うので、復号できないと困ってしまうのは確か。そうするとバックドアを用意するか、パスワードを復号可能な状態で保存するか、になってしまう……
普通は、
とするかな。確か、Windows で暗号化フォルダを使った時の挙動なんかが、こんな感じだったはず。
Re: (スコア:0)
郵便局が住所と氏名をハッシュ化するサービスを提供すれば、IT屋が住所と氏名を管理する必要は全くないですよね。
Re: (スコア:0)
いや、運用のためならそういう情報を外部公開しているサーバや同じサーバセグメントに置いておく必要は無いわけで。
ユーザーが変更する度にトリガーでもかませ、外部から一方通行で参照できない管理セグメントのどっかへ変更を飛ばして
そちらで管理するとか、やり様はいろいろとある。
問題は本人がパスワード忘れて復号化も出来なくなってしまった時だけど、そのときは別途サービス側で用意した
仮パスワードで暗号化したデータで上書きしてしまうとかさ。
Re: (スコア:0)
>問題は本人がパスワード忘れて復号化も出来なくなってしまった時
このときに、そのIDの持ち主は連絡してきた本人とどうやって確認するか?
が問題では?
普通、個人情報をある程度比較して一致してたら本人とみ見なすと思うのですが。