アカウント名:
パスワード:
ハッシュ化してDBに保存するなら、16文字なんて中途半端な制限を設けず255文字でも1024文字でも保存容量は変わらないはず。まさか・・・・まさかねえ。
ハッシュ化してDBに保存するなら、16文字なんて中途半端な制限を設けず255文字でも1024文字でも保存容量は変わらないはず。 まさか・・・・まさかねえ。
リスト型攻撃が流行していることもあり、パスワードのハッシュ化を推奨する意見が多くなりましたが、パスワードのハッシュ化にはメリットだけでなくデメリットもあるのです。
「パスワードをハッシュ化しなくて良かった!」というモデルケースを挙げてみます。
【モデルケース1】 ダイレクトメール発送の業務委託先から、全顧客のお客様番号と生年月日を含むリストが漏えいしてしまった。(パスワードはダイレクトメール管理に不要なので漏えいしていない) その後、アカウントに不正アクセスされてマイル交換されたというクレームが多発したので、調べてみたところ、クラックされたアカウントのパスワードは "S43.5.1"や"S531203" といった生年月日を含んだものだった。 緊急対策として、パスワード中に、生年月日に含まれる数字が4文字以上含まれていて、かつそれ以外の英数字が4文字以下のアカウントでのマイル交換を一時できない状態とした。それ以降、不正なマイル交換は殆ど無くなったようだった。 もし、パスワードをハッシュ化していたら、全顧客のマイル交換を停止して、全顧客に対してパスワード変更を要求せざるを得なくなっていただろう。 そうしたら、サポートセンターの電話がパンクし、予約や予約変更の電話もつながらなくなって、会社の損害額がとんでもない金額になっていたかもしれない。(仮に、予約受付の電話番号と、マイル交換に関する問い合わせ電話番号を分けていたとしても、顧客はその番号に繋がらなかったら他の番号に掛けることが多い。特に今回のモデルケースのように、情報の漏えいといった過失があると、怒った顧客は違う窓口の番号にもかけてくる)。 ※これは架空のモデルケースです。実際の事例ではありません。
【モデルケース2】 ある顧客から、「80万円相当のマイルが無くなってしまった」というクレームが。 さっそく、ログイン履歴を調べてみると、当該のアカウントに対して、中国のIPアドレスから、"passw0rd0", "passw0rd1", "passw0rd2" というパスワードでログインを試みる記録があった。 当該顧客のパスワードは "passw0rd2" だったので、3回目のアクセスで不正ログインされてしまったようだ。("password"+数字 や "passwd"+数字 というパスワードは使用できなくしていたが、"passw0rd" はブラックリストから漏れていたようだ) 約款には、顧客に対してパスワードは第三者に推測されにくい文字列にすることを要求しており、それに反する場合には責任を負わない旨を明記していた。顧客にはパスワード管理に関する重大な過失が認められるので、不正利用されたマイルは補てんしないことにした。 もし、パスワードをハッシュ化していたら、顧客の設定したパスワードに問題があることを特定できずに、80万円分の損失が出ただろう。 ※これは架空のモデルケースです。実際の航空会社の約款や、その解釈、対応とは一切関係がありません。
--
なお、単純なWebのみのシステムで、大きな金銭が関わらないものであれば、パスワードはハッシュ化した方が良いと思います。特に、スラッシュドットのアカウントシステムのような、セキュリティ管理がいい加減なシステムの場合には、漏えいして他のサイトにリスト型攻撃などの迷惑がかからないように、絶対にハッシュ化すべきです。(といってもログイン画面にSSLすら使っていないようなので、サーバでハッシュ化したところで通信経路で漏えいしてしまう危険があるが……)
逆に、銀行や証券会社、航空会社のように、システムが大規模でWebだけでなく窓口や電話・その他様々なチャネルと連携していて、多額の金銭が絡む場合には、ハッシュ化しない方が良いと思います。
以前、銀行のスキミングした磁気キャッシュカードのデータと誕生月日で、ATMから不正に預貯金を引き出す犯罪が流行したことがあります。 その時、銀行は誕生月日を暗証番号にしている顧客に対して、電話や書面で暗証番号の変更を要求するといった対応を行ないました。(現在ではそのような暗証番号は設定できず撥ねられますが以前は違いました)
パスワードに関しても、ハッシュ化をしていなければ、特定のパスワードパターンの顧客で不正アクセスが増えた際に、個別にパスワード変更を依頼するという対応がとれるのです。
また、銀行ならば、不正に振込が行われた際に、顧客の過失割合を決める上で生のパスワードが必要になるでしょう。(顧客に、暗証番号やパスワードや、その管理についての過失がある場合、犯罪被害時の銀行による補償額が減額される約款になっている銀行が殆どです。)
銀行が生パスワードを保持している場合、不正アクセスの事案が発生したら、 その銀行は、自身から生パスワードが流出していないことを証明しなくてはならなくなりますよ。 これは、その銀行にとって詰みです。
生パスワードを保持していたからといって、銀行が、自身から生パスワードが流出していないことを証明しなければならない(ほぼ悪魔の証明)、ということにはならないと思いますが。
それを言い出したら、キャッシュカードでの不正引出があったら、銀行が、銀行から暗証番号が流失していないことを証明しないといけないのですか?
また、ハッシュ化していたところで、銀行またはシステム管理者の内部犯を疑いだしたら、ハッシュ化処理の前のパスワードを抜き出すことだって可能だし、ハッシュ化の際にソルトの使用やストレッチング処理を行っていれば、全顧客の生パスワードを解析するといったことは困難になりますが、特定の数人の顧客の生パスワードを、ハッシュ値からブルートフォースアタックで解析するぐらいのことは(よほど強いストレッチングをしていて、かつ顧客が強度の強いパスワードを設定していない限りは)現実的な時間で可能です。だからこそ、パスワードのハッシュ値が漏えいした企業が、顧客にパスワードの変更を依頼するケースが多いのです。(ハッシュ化は漏えいから悪用可能な状態となるまでの時間を稼ぐ役割)
ちなみに、銀行ではなく大手証券会社ですが、家族がマネックス証券のパスワードを忘れたときには、ログインID・口座番号・パスワード・暗証番号照会依頼書 [monex.co.jp]を郵送して照会しましたが、ログインID・口座番号・パスワード・暗証番号の全てが記載された紙が転送不要の簡易書留郵便で届きました。このことから、マネックス証券は平文でパスワードを保存しているようです。
別ACとして、おおむね納得しましたが。
キャッシュカードの不正利用は物理的に足がつきやすいですからねぇ。
> ログインID・口座番号・パスワード・暗証番号の全てが記載された紙が転送不要の簡易書留郵便で届きました。
暗証番号があり、全て同時に送っているのでアレですが、パスワードを「新規発行」したという可能性はゼロなんでしょうか。
# 某古参ISPもパスワード印刷してきたけどあれはどうだったか……
攻撃に使用されたと思われるものを網羅したハッシュリストを作って、それと照合じゃ駄目なんですかね?
攻撃側が有限なんだから(特に、辞書攻撃とかね)、それに対応するハッシュリストを網羅するのも別に無理って程ではないかなー、って思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
なぜ最大16文字? (スコア:0)
ハッシュ化してDBに保存するなら、16文字なんて中途半端な制限を設けず255文字でも1024文字でも保存容量は変わらないはず。
まさか・・・・まさかねえ。
ハッシュ化にはデメリットもある (スコア:3, 興味深い)
リスト型攻撃が流行していることもあり、パスワードのハッシュ化を推奨する意見が多くなりましたが、パスワードのハッシュ化にはメリットだけでなくデメリットもあるのです。
「パスワードをハッシュ化しなくて良かった!」というモデルケースを挙げてみます。
【モデルケース1】
ダイレクトメール発送の業務委託先から、全顧客のお客様番号と生年月日を含むリストが漏えいしてしまった。(パスワードはダイレクトメール管理に不要なので漏えいしていない)
その後、アカウントに不正アクセスされてマイル交換されたというクレームが多発したので、調べてみたところ、クラックされたアカウントのパスワードは "S43.5.1"や"S531203" といった生年月日を含んだものだった。
緊急対策として、パスワード中に、生年月日に含まれる数字が4文字以上含まれていて、かつそれ以外の英数字が4文字以下のアカウントでのマイル交換を一時できない状態とした。それ以降、不正なマイル交換は殆ど無くなったようだった。
もし、パスワードをハッシュ化していたら、全顧客のマイル交換を停止して、全顧客に対してパスワード変更を要求せざるを得なくなっていただろう。
そうしたら、サポートセンターの電話がパンクし、予約や予約変更の電話もつながらなくなって、会社の損害額がとんでもない金額になっていたかもしれない。(仮に、予約受付の電話番号と、マイル交換に関する問い合わせ電話番号を分けていたとしても、顧客はその番号に繋がらなかったら他の番号に掛けることが多い。特に今回のモデルケースのように、情報の漏えいといった過失があると、怒った顧客は違う窓口の番号にもかけてくる)。
※これは架空のモデルケースです。実際の事例ではありません。
【モデルケース2】
ある顧客から、「80万円相当のマイルが無くなってしまった」というクレームが。
さっそく、ログイン履歴を調べてみると、当該のアカウントに対して、中国のIPアドレスから、"passw0rd0", "passw0rd1", "passw0rd2" というパスワードでログインを試みる記録があった。
当該顧客のパスワードは "passw0rd2" だったので、3回目のアクセスで不正ログインされてしまったようだ。("password"+数字 や "passwd"+数字 というパスワードは使用できなくしていたが、"passw0rd" はブラックリストから漏れていたようだ)
約款には、顧客に対してパスワードは第三者に推測されにくい文字列にすることを要求しており、それに反する場合には責任を負わない旨を明記していた。顧客にはパスワード管理に関する重大な過失が認められるので、不正利用されたマイルは補てんしないことにした。
もし、パスワードをハッシュ化していたら、顧客の設定したパスワードに問題があることを特定できずに、80万円分の損失が出ただろう。
※これは架空のモデルケースです。実際の航空会社の約款や、その解釈、対応とは一切関係がありません。
--
なお、単純なWebのみのシステムで、大きな金銭が関わらないものであれば、パスワードはハッシュ化した方が良いと思います。特に、スラッシュドットのアカウントシステムのような、セキュリティ管理がいい加減なシステムの場合には、漏えいして他のサイトにリスト型攻撃などの迷惑がかからないように、絶対にハッシュ化すべきです。(といってもログイン画面にSSLすら使っていないようなので、サーバでハッシュ化したところで通信経路で漏えいしてしまう危険があるが……)
逆に、銀行や証券会社、航空会社のように、システムが大規模でWebだけでなく窓口や電話・その他様々なチャネルと連携していて、多額の金銭が絡む場合には、ハッシュ化しない方が良いと思います。
以前、銀行のスキミングした磁気キャッシュカードのデータと誕生月日で、ATMから不正に預貯金を引き出す犯罪が流行したことがあります。
その時、銀行は誕生月日を暗証番号にしている顧客に対して、電話や書面で暗証番号の変更を要求するといった対応を行ないました。(現在ではそのような暗証番号は設定できず撥ねられますが以前は違いました)
パスワードに関しても、ハッシュ化をしていなければ、特定のパスワードパターンの顧客で不正アクセスが増えた際に、個別にパスワード変更を依頼するという対応がとれるのです。
また、銀行ならば、不正に振込が行われた際に、顧客の過失割合を決める上で生のパスワードが必要になるでしょう。(顧客に、暗証番号やパスワードや、その管理についての過失がある場合、犯罪被害時の銀行による補償額が減額される約款になっている銀行が殆どです。)
Re:ハッシュ化にはデメリットもある (スコア:1)
その銀行は、自身から生パスワードが流出していないことを証明しなくてはならなくなりますよ。
これは、その銀行にとって詰みです。
生パスワードは、持っていること自体が巨大なリスクなのですよ。
Re:ハッシュ化にはデメリットもある (スコア:1)
生パスワードを保持していたからといって、銀行が、自身から生パスワードが流出していないことを証明しなければならない(ほぼ悪魔の証明)、ということにはならないと思いますが。
それを言い出したら、キャッシュカードでの不正引出があったら、銀行が、銀行から暗証番号が流失していないことを証明しないといけないのですか?
また、ハッシュ化していたところで、銀行またはシステム管理者の内部犯を疑いだしたら、ハッシュ化処理の前のパスワードを抜き出すことだって可能だし、ハッシュ化の際にソルトの使用やストレッチング処理を行っていれば、全顧客の生パスワードを解析するといったことは困難になりますが、特定の数人の顧客の生パスワードを、ハッシュ値からブルートフォースアタックで解析するぐらいのことは(よほど強いストレッチングをしていて、かつ顧客が強度の強いパスワードを設定していない限りは)現実的な時間で可能です。だからこそ、パスワードのハッシュ値が漏えいした企業が、顧客にパスワードの変更を依頼するケースが多いのです。(ハッシュ化は漏えいから悪用可能な状態となるまでの時間を稼ぐ役割)
ちなみに、銀行ではなく大手証券会社ですが、家族がマネックス証券のパスワードを忘れたときには、ログインID・口座番号・パスワード・暗証番号照会依頼書 [monex.co.jp]を郵送して照会しましたが、ログインID・口座番号・パスワード・暗証番号の全てが記載された紙が転送不要の簡易書留郵便で届きました。このことから、マネックス証券は平文でパスワードを保存しているようです。
Re: (スコア:0)
別ACとして、おおむね納得しましたが。
キャッシュカードの不正利用は物理的に足がつきやすいですからねぇ。
> ログインID・口座番号・パスワード・暗証番号の全てが記載された紙が転送不要の簡易書留郵便で届きました。
暗証番号があり、全て同時に送っているのでアレですが、パスワードを「新規発行」したという可能性はゼロなんでしょうか。
# 某古参ISPもパスワード印刷してきたけどあれはどうだったか……
Re: (スコア:0)
Re: (スコア:0)
攻撃に使用されたと思われるものを網羅したハッシュリストを作って、それと照合じゃ駄目なんですかね?
攻撃側が有限なんだから(特に、辞書攻撃とかね)、それに対応するハッシュリストを網羅するのも別に無理って程ではないかなー、って思います。
Re: (スコア:0)
それは顧客のデメリットに更にデメリットを重ねさせて企業側のメリットとしただけに過ぎない。