アカウント名:
パスワード:
ハッシュ化して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もパスワード印刷してきたけどあれはどうだったか……
攻撃に使用されたと思われるものを網羅したハッシュリストを作って、それと照合じゃ駄目なんですかね？
攻撃側が有限なんだから(特に、辞書攻撃とかね)、それに対応するハッシュリストを網羅するのも別に無理って程ではないかなー、って思います。
表示した際の外観の都合上、その程度の制限が適切だと判断したとか、ありそうな無さそうな。
いや、普通にやるでしょ。世の中そういうものです。
世の中のサービスの多くはパスワードの文字数に制限あるけど、それが何か？文字数制限あり→生パスワードを保存してる！はさすがに短絡的かと
この際、生パス管理してるからという理由があるのならまだ許せる。無意味に16文字の制限を加えているのなら…その方がむしろ腹立たしい。
まあ生パスの話は置いといて、なぜ16までにしようと思うのだろう。ちょっと足りない感がある人が多いと思うのだが。
無意味に16文字の制限を加えているのなら…その方がむしろ腹立たしい。 まあ生パスの話は置いといて、なぜ16までにしようと思うのだろう。 ちょっと足りない感がある人が多いと思うのだが。
小規模なシステムを管理していた際に、パスワードの文字数制限を255文字までとしていたことがありましたが、次のようなパスワードを登録する人が、あまりにも多かったです。
パスワードの文字数制限を12文字以下に制限するとこんな感じのが増えだしました。（"password"や単純な辞書に載っているものは登録段階で機械的にはじいているのでこれに含まれていません）
このように、文字数や文字種の制限が緩いと、メールアドレス（自分のものや友達・恋人の？）やURL（そのサイトや有名サイトなど）をパスワードに設定する人が出てくるのです。
理由は、たぶん、「英数字と記号を含めること」を推奨していたため、記号を含み、かつ記憶しやすい（コピペしやすい？）文字列としてメールアドレスやURLが思いつき、それをパスワードとしたのだと思います。
文字数の制限すると、きちんとしたパスワードっぽい文字列を登録してくれるユーザーが多くなるので、ある程度制限しているシステムが多いんだと思います。URLはスキーム名があるので良いですが、メールアドレスというのは自由度がかなり高いので、正規表現でメールアドレスのみを弾くのはなかなか大変です。従って、メールアドレスをパスワードとするのを弾きたい管理者は、文字数制限や、パスワードに"@"や"."の使用を禁止するという簡単な対策をとるのだと思います。（実在するドメインかどうかを検証する方法もありますが、面倒です）
余談ですが、パスワードをハッシュ化しているシステムだと、ユーザーが登録しているパスワードが見れないので、システム管理者がこういった傾向に気が付きません。
URLをパスワードにするのか！なかなか良い案だ。正直、ここまでの多様性があるのであれば、別に長いパスワードでも良いんじゃないでしょうか。制限する理由にはならない気がします。
日本限定で仮名文字で17文字か31文字にして1q(季節)ごとに変更させるようにしたらいいかも。#字余りには対応せず
みじかびのき(ゃ)ぷりきとればすぎち(ょ)びれすぎかきつらねは(っ)ぱふみふみ
画像等の共有サービスで、パスワード認証はないけどURLが複雑怪奇なアドレスで、そのURLを共有したい人に教えてね、っというやつは事実上そのURLが共通の認証パスワードという扱いですよね。
どっかからリンクを貼ったりしたら検索エンジンのクローラに晒されてしまいますが、それはこの”パスワード”をWEBに公開しているってことですからね。
そこまで考えて制限を設定したとは思えないけどなぁ。それに、そんなバカなパスワードを設定するのも結局は自己責任だし。文字数を制限することで、本当にセキュリティ目的に長いパスワードを設定したい人が設定出来なくなるのが問題だ。バカにあわせるか、セキュリティ気にしぃにあわせるか。
パスワードは８〜１６桁もしくは３０桁以上にしてください。とかかなぁ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
なぜ最大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)
それは顧客のデメリットに更にデメリットを重ねさせて企業側のメリットとしただけに過ぎない。
Re:なぜ最大16文字？ (スコア:2)
表示した際の外観の都合上、その程度の制限が適切だと判断したとか、ありそうな無さそうな。
Re: (スコア:0)
いや、普通にやるでしょ。世の中そういうものです。
Re: (スコア:0)
世の中のサービスの多くはパスワードの文字数に制限あるけど、それが何か？
文字数制限あり→生パスワードを保存してる！はさすがに短絡的かと
Re:なぜ最大16文字？ (スコア:1)
この際、生パス管理してるからという理由があるのならまだ許せる。
無意味に16文字の制限を加えているのなら…その方がむしろ腹立たしい。
まあ生パスの話は置いといて、なぜ16までにしようと思うのだろう。
ちょっと足りない感がある人が多いと思うのだが。
Re:なぜ最大16文字？ (スコア:4, 興味深い)
小規模なシステムを管理していた際に、パスワードの文字数制限を255文字までとしていたことがありましたが、次のようなパスワードを登録する人が、あまりにも多かったです。
パスワードの文字数制限を12文字以下に制限するとこんな感じのが増えだしました。（"password"や単純な辞書に載っているものは登録段階で機械的にはじいているのでこれに含まれていません）
このように、文字数や文字種の制限が緩いと、メールアドレス（自分のものや友達・恋人の？）やURL（そのサイトや有名サイトなど）をパスワードに設定する人が出てくるのです。
理由は、たぶん、「英数字と記号を含めること」を推奨していたため、記号を含み、かつ記憶しやすい（コピペしやすい？）文字列としてメールアドレスやURLが思いつき、それをパスワードとしたのだと思います。
文字数の制限すると、きちんとしたパスワードっぽい文字列を登録してくれるユーザーが多くなるので、ある程度制限しているシステムが多いんだと思います。URLはスキーム名があるので良いですが、メールアドレスというのは自由度がかなり高いので、正規表現でメールアドレスのみを弾くのはなかなか大変です。従って、メールアドレスをパスワードとするのを弾きたい管理者は、文字数制限や、パスワードに"@"や"."の使用を禁止するという簡単な対策をとるのだと思います。（実在するドメインかどうかを検証する方法もありますが、面倒です）
余談ですが、パスワードをハッシュ化しているシステムだと、ユーザーが登録しているパスワードが見れないので、システム管理者がこういった傾向に気が付きません。
Re: (スコア:0)
URLをパスワードにするのか！なかなか良い案だ。
正直、ここまでの多様性があるのであれば、別に長いパスワードでも良いんじゃないでしょうか。
制限する理由にはならない気がします。
Re:なぜ最大16文字？ (スコア:1)
日本限定で仮名文字で17文字か31文字にして1q(季節)ごとに変更させるようにしたらいいかも。
#字余りには対応せず
みじかびのき(ゃ)ぷりきとればすぎち(ょ)びれすぎかきつらねは(っ)ぱふみふみ
Re: (スコア:0)
画像等の共有サービスで、パスワード認証はないけどURLが複雑怪奇なアドレスで、そのURLを共有したい人に教えてね、
っというやつは事実上そのURLが共通の認証パスワードという扱いですよね。
どっかからリンクを貼ったりしたら検索エンジンのクローラに晒されてしまいますが、
それはこの”パスワード”をWEBに公開しているってことですからね。
Re: (スコア:0)
そこまで考えて制限を設定したとは思えないけどなぁ。
それに、そんなバカなパスワードを設定するのも結局は自己責任だし。
文字数を制限することで、本当にセキュリティ目的に長いパスワードを設定したい人が設定出来なくなるのが問題だ。
バカにあわせるか、セキュリティ気にしぃにあわせるか。
パスワードは８〜１６桁もしくは３０桁以上にしてください。とかかなぁ。