アカウント名:
パスワード:
> 現代ではパスワードクラック技術が向上しておりそれ技術の向上と関係あるの？
元々、耐性としては・長さが一番・複雑さが2番だったんだが、昔は長いのが入れられないことも多かったし、クラック技術も未熟だったのでそこまで耐性が求められず、長いのは打つのがだるいからか覚えにくいからか、複雑なパスワードが好まれた。# どっちが先か知らないが、昔は「長いパスワード」が入れられるシステムが少なかったし
今は複雑なだけでは対クラック性が足りなくなり、長さが必要になってきた
長いほうがいい、開き直ってしまえばパス「ワード」は諦めてパス「フレーズ」パス「センテンス」にすりゃ少々長くても間違えない忘れないからそんなにコストは上がらないし、はじめっからこっち薦めておけばよかった
って事でしょう
昔はメモリやストレージが高価で節約が美徳だったから、折角同じ7bit ASCIIなら8文字くらいに収めてユーザには記号で複雑さを稼いでもらうというのが当然だった鍵長と考えれば英数大小と記号で8文字なら7*8=56bitに対して、記号を抜いて16文字なら6*16=96bitだからな
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどなハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
ハッシュの長さが短くてパスワードの長さに制限がなければ同じハッシュを再現できる可能性が高まるので、やはりパスワードの入力長は制限があったほうが良いと思う。
> ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
そんなことはまったくない
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立するパスワード(=ハッシュ値が一致する文字列、今回の場合は「1」）を割り出せてしまう
ハッシュにしたとしてもパスワードのデータ長をある程度長くすることは必要
実際に、「パスワードフィールドには長々と文字を入力できるが、実際には過去互換性のためそのうち先頭8文字しか使わない仕様だった。 そのうえで内部への保存はパスワード平文ではなくハッシュ値だった。 結果としてパスワード長8文字を超える強度のパスワードは使えない仕様だった」という仕様だったOS(というかAPI仕様)は存在する
という話の流れで、
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立する
>だったんだが、昔は長いのが入れられないことも多かったし、
銀行ATMは今でも数字4桁ドコモの認証も一緒年寄りはほぼみんな生年月日に設定それ以外は覚えられないから
サーファーは 1173 が多いんだとか
良い波->イイナミ->1173
だそうです。
…ということは、肉好きは 1129になるのか？！なんて連想してしまいました。
銀行ATMにしろ、ドコモの認証にしろ、・一定回数間違えたらアカウントにロックかけることでブルートフォースへの対策にしてる・ATMであればキャッシュカード必須だし、監視カメラのあるATM機にアクセスするので足がつきやすい・ドコモの認証は、ドコモの回線からの接続に限定し、さらにICCID単位でロックをかけられるので、ブルートフォースをで攻撃できるIDが非常に限定的という要素を無視して、単なる数字4桁の脆弱さと同一視するのはいかがなものかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
算数のお時間 (スコア:0)
> 現代ではパスワードクラック技術が向上しており
それ技術の向上と関係あるの？
Re:算数のお時間 (スコア:3)
元々、耐性としては
・長さが一番
・複雑さが2番
だったんだが、昔は長いのが入れられないことも多かったし、
クラック技術も未熟だったのでそこまで耐性が求められず、
長いのは打つのがだるいからか覚えにくいからか、複雑なパスワードが好まれた。
# どっちが先か知らないが、昔は「長いパスワード」が入れられるシステムが少なかったし
今は複雑なだけでは対クラック性が足りなくなり、長さが必要になってきた
長いほうがいい、開き直ってしまえばパス「ワード」は諦めてパス「フレーズ」
パス「センテンス」
にすりゃ少々長くても間違えない忘れないからそんなにコストは上がらないし、
はじめっからこっち薦めておけばよかった
って事でしょう
Re:算数のお時間 (スコア:2)
Re: (スコア:0)
昔はメモリやストレージが高価で節約が美徳だったから、折角同じ7bit ASCIIなら8文字くらいに収めてユーザには記号で複雑さを稼いでもらうというのが当然だった
鍵長と考えれば英数大小と記号で8文字なら7*8=56bitに対して、記号を抜いて16文字なら6*16=96bitだからな
Re: (スコア:0)
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
Re:算数のお時間 (スコア:1)
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
ハッシュの長さが短くてパスワードの長さに制限がなければ
同じハッシュを再現できる可能性が高まるので、
やはりパスワードの入力長は制限があったほうが良いと思う。
Re: (スコア:0)
> ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
そんなことはまったくない
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、
悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立するパスワード
(=ハッシュ値が一致する文字列、今回の場合は「1」）を割り出せてしまう
ハッシュにしたとしてもパスワードのデータ長をある程度長くすることは必要
実際に、
「パスワードフィールドには長々と文字を入力できるが、実際には過去互換性のためそのうち先頭8文字しか使わない仕様だった。
そのうえで内部への保存はパスワード平文ではなくハッシュ値だった。
結果としてパスワード長8文字を超える強度のパスワードは使えない仕様だった」
という仕様だったOS(というかAPI仕様)は存在する
Re: (スコア:0)
昔はメモリやストレージが高価で節約が美徳だったから、折角同じ7bit ASCIIなら8文字くらいに収めてユーザには記号で複雑さを稼いでもらうというのが当然だった
鍵長と考えれば英数大小と記号で8文字なら7*8=56bitに対して、記号を抜いて16文字なら6*16=96bitだからな
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
という話の流れで、
そんなことはまったくない
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、
悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立する
Re: (スコア:0)
>だったんだが、昔は長いのが入れられないことも多かったし、
銀行ATMは今でも数字4桁
ドコモの認証も一緒
年寄りはほぼみんな生年月日に設定
それ以外は覚えられないから
サーファー (スコア:0)
サーファーは 1173 が多いんだとか
良い波->イイナミ->1173
だそうです。
…ということは、
肉好きは 1129
になるのか？！なんて連想してしまいました。
Re: (スコア:0)
Re: (スコア:0)
銀行ATMにしろ、ドコモの認証にしろ、
・一定回数間違えたらアカウントにロックかけることでブルートフォースへの対策にしてる
・ATMであればキャッシュカード必須だし、監視カメラのあるATM機にアクセスするので足がつきやすい
・ドコモの認証は、ドコモの回線からの接続に限定し、さらにICCID単位でロックをかけられるので、ブルートフォースをで攻撃できるIDが非常に限定的
という要素を無視して、単なる数字4桁の脆弱さと同一視するのはいかがなものかと。