アカウント名:
パスワード:
税務署の過失は免れないだろう
どう確認したとしてもパスワードは教えちゃいかんでしょ
教えるどころか復号可能な時点でセキュリティ上は大問題ですよ・・(Salt値付きでハッシュ化して格納、が最低ライン)
セキュリティ関係の情報はググると古い情報ばっかりでてきますが、知識をアップデートした方がいいですよ。
何故「Salt値付きでハッシュ化して格納」する必要があるんですか?パスワードの使いまわしが常識だった頃は漏洩したら他のサービスも悪用されるのでその必要がありましたけど、自動生成したパスワードをパスワードマネージャーに保存するのが今の正しいパスワードの管理法ですので、そんな必要ありませんよ。高木浩光先生(https://twitter.com/HiromitsuTakagi/status/1503936415582752768)もそういってますね。Cookieのログイントークンをデータベースにハッシュ化して保存なんて普通しないでしょ? それと同じです今時、ライトユーザーですら(パスワードを入力するのが面倒などの理由で)、Googleのパスワード管理機能とかiCloud キーチェーン使って自動生成・自動入力してますよ。
それと、セキュリティ対策は二極化しており、パスワードを使いまわししている層の人は氏名+生年月日のような非常に弱いパスワード(例: taro0203)を使ってますんで、Salt値付きでハッシュ化して格納してようが短時間で解析されるので無意味です。本質的な対策じゃないのでどうでもいいですね。未だに「ログインサーバーで処理に1秒間かかるぐらいのストレッチング(数万回など)をすべきだ」なんて時代遅れな主張をしているコンサルも居て笑っちゃいますが、銀行も、証券会社も、公的機関も、それどころか場末の個人サイトでさえ「DDoSされたくなければ暗号資産送れ」のように脅迫され、実際にログインフォームにDDoSするような攻撃が頻繁に行われますんで、ストレッチングなど過負荷な処理はやらないほうがいいです。CloudFlareなどのDDoSプロテクション入れてても有る程度は普通のアクセスは通しちゃいますから、少なくともバックエンドは1000回/秒のログイン試行には耐えられないと駄目ですね。となると昔推奨されたストレッチングに関しても、CDNをbypassせざるを得ないログイン画面はすぐにDDoS攻撃に晒されますので可用性リスクを考えるとできないというのが現実的です。
パスワードを平文で保存しておくメリットは色々ありまして、特にお金が絡んでいるサービスですと、「自分の氏名ローマ字と生年月日数字のみで構成された弱いパスワードを設定していた」としてユーザー側の過失を主張して不正アクセス時のユーザー責任割合を増やす主張ができるので企業側には平文でパスワード保存メリットがあるんです。今はどうか知りませんがちょっと前はマネックス証券なんかも平文保存で、忘れたときには書留郵便で郵送する形でしたね。
万が一パスワードが漏洩したら~とはいっても、税務署とか金融機関は漏洩しちゃいけない情報を山のように扱ってます。使いまわしが約款で禁止されている今ではパスワードだけ特別扱いする理由なんてないのです。
長いパスワードしか受け付けなければいいやん
お前は使ってるネットサービスで生パスワードが漏洩して、身内や知り合いにそのパスワードを使われて他人に知られたくないお前のプライバシーを覗きみられてても平気なのか?
パスワードの使いまわしをしていなかったら、生パスワードが漏洩したところで、そのサービスに登録している情報しか覗き見られない。そして、データベース上のパスワードが漏洩する状況というのは、多くの場合そのデータベースに保存されている全てのデータが漏洩する状況なんだけど。
あとね。最近の多層化されたシステムでバックエンドデータベースの情報が直接抜かれるケースって稀だよ。今時はパスワード漏洩もフロントに近い側のアクセス解析・広告・外部APIなどのJavaScriptに悪意のあるコードが仕込まれて漏洩するケースが多く、ハッシュ化では防げない。
> そのサービスに登録している情報しか覗き見られない。
だからそのサービスにある恥ずかしい情報を知り合いに覗き見られる状況を言ってんだろwあるサービスの生パスワードがぶっこぬかれてネットに公開される→それを見つけた知り合いがお前のアカウントにログインして覗き見るっていう至極単純なシナリオも理解できない?
無駄に長文でいろいろ言い訳並べてるけど、単に正常性バイアスに陥って都合の悪い情報を無視したり過小評価してるだけだな。
そのサービスにある恥ずかしい情報はパスワードだけ守れてもぶっこぬかれてるんだよなあ。
いまどき、ログイン処理やパスワード等の記録はフレームワークが提供する機能で実現し、その機能を使えば、ハッシュ化やsaltは自動的に行われます。にもかかわらず、復元可能であるという情報が得られたという事は
という疑念を生み、セキュリティ的に安全ではないサービスを提供していると思われるリスクがあります。
システムが古く、平文で保存するのが当たり前だったころに作られたものかもしれません。しかし、その場合はハッシュ化が当然という時代にも平文保存を続けていたということになり「セキュリティ関係の情報アップデートができていない」という疑念を生みます。そしてパスワードを漏洩したという事実はその疑念が確信に変わる理由としてもっともらしいでしょう。
>自動生成したパスワードをパスワードマネージャーに保存するのが今の正しいパスワードの管理法
勝手にその手法が当たり前だと思わないで下さい。未だに40〜50辺りの「PC苦手なおじさん」はPWを使い回しています。様々な媒体で「PWは使い回さないで!」と発信してもそういう層には届いてないですし、仮に届いていても理解が甘いので・hogeというサイトでは「ニックネーム+誕生日」・fugaというサイトでは前後を入れ替えて「誕生日+ニックネーム」にするような人々ですよ。
バカの尻拭いなんて必要ない!とエリート意識を持つのは勝手ですが、大半の人間がバカである事は理解すべきです。
ストレッチはやめたほうがええというのはわかるが、これ聞いてもハッシュしない方がいいとまでは思えんなハッシュ化するコストは知れてるからハッシュ化はしたほうがええと思うね
普通はハッシュ化はするんだよ。「ハッシュ化するコストは知れてるからハッシュ化はしたほうがええと思うね」は正しい。でも理論的に必須では無くて、目的によりハッシュ化をしないオプションも十分あり得る。ハッシュ化は情報保護の戦略のひとつに過ぎないにもかかわらず、それをやっていれば善、そうでなければ悪みたいな単純な考え方をしている人がダメなのよ。
申し訳ないが十分あり得るとまでは思えないなぁ…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
せめて基本4情報くらいは確認しないと (スコア:-1)
税務署の過失は免れないだろう
Re: (スコア:0)
どう確認したとしてもパスワードは教えちゃいかんでしょ
Re: (スコア:0)
教えるどころか復号可能な時点でセキュリティ上は大問題ですよ・・
(Salt値付きでハッシュ化して格納、が最低ライン)
いい加減時代遅れの知識をまき散らすの止めたら? (スコア:1)
セキュリティ関係の情報はググると古い情報ばっかりでてきますが、知識をアップデートした方がいいですよ。
何故「Salt値付きでハッシュ化して格納」する必要があるんですか?
パスワードの使いまわしが常識だった頃は漏洩したら他のサービスも悪用されるのでその必要がありましたけど、自動生成したパスワードをパスワードマネージャーに保存するのが今の正しいパスワードの管理法ですので、そんな必要ありませんよ。
高木浩光先生(https://twitter.com/HiromitsuTakagi/status/1503936415582752768)もそういってますね。
Cookieのログイントークンをデータベースにハッシュ化して保存なんて普通しないでしょ? それと同じです
今時、ライトユーザーですら(パスワードを入力するのが面倒などの理由で)、Googleのパスワード管理機能とかiCloud キーチェーン使って自動生成・自動入力してますよ。
それと、セキュリティ対策は二極化しており、パスワードを使いまわししている層の人は氏名+生年月日のような非常に弱いパスワード(例: taro0203)を使ってますんで、Salt値付きでハッシュ化して格納してようが短時間で解析されるので無意味です。
本質的な対策じゃないのでどうでもいいですね。
未だに「ログインサーバーで処理に1秒間かかるぐらいのストレッチング(数万回など)をすべきだ」なんて時代遅れな主張をしているコンサルも居て笑っちゃいますが、
銀行も、証券会社も、公的機関も、それどころか場末の個人サイトでさえ「DDoSされたくなければ暗号資産送れ」のように脅迫され、実際にログインフォームにDDoSするような攻撃が頻繁に行われますんで、ストレッチングなど過負荷な処理はやらないほうがいいです。
CloudFlareなどのDDoSプロテクション入れてても有る程度は普通のアクセスは通しちゃいますから、少なくともバックエンドは1000回/秒のログイン試行には耐えられないと駄目ですね。
となると昔推奨されたストレッチングに関しても、CDNをbypassせざるを得ないログイン画面はすぐにDDoS攻撃に晒されますので可用性リスクを考えるとできないというのが現実的です。
パスワードを平文で保存しておくメリットは色々ありまして、特にお金が絡んでいるサービスですと、
「自分の氏名ローマ字と生年月日数字のみで構成された弱いパスワードを設定していた」としてユーザー側の過失を主張して不正アクセス時のユーザー責任割合を増やす主張ができるので企業側には平文でパスワード保存メリットがあるんです。
今はどうか知りませんがちょっと前はマネックス証券なんかも平文保存で、忘れたときには書留郵便で郵送する形でしたね。
万が一パスワードが漏洩したら~とはいっても、税務署とか金融機関は漏洩しちゃいけない情報を山のように扱ってます。
使いまわしが約款で禁止されている今ではパスワードだけ特別扱いする理由なんてないのです。
Re: (スコア:0)
長いパスワードしか受け付けなければいいやん
Re: (スコア:0)
お前は使ってるネットサービスで生パスワードが漏洩して、身内や知り合いにそのパスワードを使われて他人に知られたくないお前のプライバシーを覗きみられてても平気なのか?
Re: (スコア:0)
パスワードの使いまわしをしていなかったら、生パスワードが漏洩したところで、そのサービスに登録している情報しか覗き見られない。
そして、データベース上のパスワードが漏洩する状況というのは、多くの場合そのデータベースに保存されている全てのデータが漏洩する状況なんだけど。
あとね。
最近の多層化されたシステムでバックエンドデータベースの情報が直接抜かれるケースって稀だよ。
今時はパスワード漏洩もフロントに近い側のアクセス解析・広告・外部APIなどのJavaScriptに悪意のあるコードが仕込まれて漏洩するケースが多く、ハッシュ化では防げない。
Re: (スコア:0)
> そのサービスに登録している情報しか覗き見られない。
だからそのサービスにある恥ずかしい情報を知り合いに覗き見られる状況を言ってんだろw
あるサービスの生パスワードがぶっこぬかれてネットに公開される→それを見つけた知り合いがお前のアカウントにログインして覗き見るっていう至極単純なシナリオも理解できない?
無駄に長文でいろいろ言い訳並べてるけど、単に正常性バイアスに陥って都合の悪い情報を無視したり過小評価してるだけだな。
Re: (スコア:0)
そのサービスにある恥ずかしい情報はパスワードだけ守れてもぶっこぬかれてるんだよなあ。
Re: (スコア:0)
いまどき、ログイン処理やパスワード等の記録はフレームワークが提供する機能で実現し、その機能を使えば、ハッシュ化やsaltは自動的に行われます。
にもかかわらず、復元可能であるという情報が得られたという事は
という疑念を生み、セキュリティ的に安全ではないサービスを提供していると思われるリスクがあります。
システムが古く、平文で保存するのが当たり前だったころに作られたものかもしれません。
しかし、その場合はハッシュ化が当然という時代にも平文保存を続けていたということになり
「セキュリティ関係の情報アップデートができていない」という疑念を生みます。
そしてパスワードを漏洩したという事実はその疑念が確信に変わる理由としてもっともらしいでしょう。
Re: (スコア:0)
>自動生成したパスワードをパスワードマネージャーに保存するのが今の正しいパスワードの管理法
勝手にその手法が当たり前だと思わないで下さい。未だに40〜50辺りの「PC苦手なおじさん」はPWを使い回しています。
様々な媒体で「PWは使い回さないで!」と発信してもそういう層には届いてないですし、仮に届いていても理解が甘いので
・hogeというサイトでは「ニックネーム+誕生日」
・fugaというサイトでは前後を入れ替えて「誕生日+ニックネーム」
にするような人々ですよ。
バカの尻拭いなんて必要ない!とエリート意識を持つのは勝手ですが、大半の人間がバカである事は理解すべきです。
Re: (スコア:0)
ストレッチはやめたほうがええというのはわかるが、
これ聞いてもハッシュしない方がいいとまでは思えんな
ハッシュ化するコストは知れてるからハッシュ化はしたほうがええと思うね
Re: (スコア:0)
普通はハッシュ化はするんだよ。「ハッシュ化するコストは知れてるからハッシュ化はしたほうがええと思うね」は正しい。
でも理論的に必須では無くて、目的によりハッシュ化をしないオプションも十分あり得る。
ハッシュ化は情報保護の戦略のひとつに過ぎないにもかかわらず、
それをやっていれば善、そうでなければ悪みたいな単純な考え方をしている人がダメなのよ。
Re: (スコア:0)
申し訳ないが十分あり得るとまでは思えないなぁ…