  |
はてなキーワード: パスワードとは
DBを設計する場合、パスワードのカラムを何文字にするか決めなければならない
これを最大2万文字とかにできなくもないが、DB容量を圧迫するといった理由で8文字や10文字に限定していてもおかしくはない
MongoDBのようなオブジェクトDBなら別だがSQL系のDBならこの理由が最もあてはまりそうに思う
同様の理由で文字種にも制限をかけてそう（UTF-8とか送られたら面倒）
境界値テストとしては最大文字数を試さないといけないが無制限だとそれができなくなる
100文字でテストするとなると、仕様としては100文字が限界ということになって文字数制限をかけることになる
ただ、それなら8文字とかで制限している理由として弱い気がする
無制限ということは極端に言うと1GBのパスワードを受け付ける、ということになる
1GBのハッシュ値を計算するのはブラウザ側になるのだが、1GBのハッシュ値計算が重くて使えない、という苦情が来るかも知れない
ただ、これも1000文字とかにしてしまえば良くて、8文字にしている理由にはならない
ウォーターフォールで実装する場合に上位レイヤでの仕様を決めるのはプログラマーでない場合が多く
定型のエクセル仕様書に「パスワードの最大文字数」というセルがあって、そこにデフォルトで8という数字が入っている
上位レイヤで仮にそこに100とか1000とかの数字を入れたとき、下位レイヤで何が起こるかわからない
つまりそこに8と書いた人が現代にいるのではなく、誰も決定していないから文字数制限が起きている
下位レイヤでの実装側は平文保存の危険性を十分に理解しているのでハッシュ値（とソルトなど）を格納する
多分、仮説４だと思うが、仮説１でないことを信じたい。
しかもCCに業務には必要なさそうだけど仕事やってるアピールするためだけに10人ぐらい入ってる
聞いたら「各PCにはセキュリティソフトあるから大丈夫です！」とか謎の回答
暗号化っていうのは
「情報の正しさを照合できる」
っていう技術
なので
っていうのは嘘で
が正しい
平文を暗号化してサーバに保存している場合は、結局は鍵をサーバに預けているので、信頼情報がユーザの手を離れてしまっている
って言われても家の鍵を大家に預けているのと同じ状態で家の中に100億円置いてるような人だと信用に足らない
じゃぁ例えばユーザにその鍵を預けておいて、認証の度に渡すようにしよう！なんていうことをやっても
鍵はデジタル情報だから簡単にコピー可能（追跡不可能）なので一度でも渡したら信用価値はゼロになる
ちなみにこれはハッシュ化でも同じ話で、ハッシュ値をサーバに保存していても平文を送りつけてハッシュ値をサーバで計算していたら意味が無い
ユーザ側でハッシュ値を計算して送りつける方法なら多少は意味があるけれど、結局は鍵がハッシュ値に変わっただけなので通信傍受されたらダメ
なのでダイジェスト認証っていう仕組みを使うので興味がある人は調べて欲しい
ということで、暗号化をしても結局は鍵の扱いに困ることになる
ログインで知りたいのはパスワードそのものではなくて「パスワードを知っているかどうか」だけ
なので、ハッシュ化を使って「パスワードを知っていたらハッシュ値も当然知ってるよね・・・？」っていう感じの認証を行う
ここで大事なのはハッシュ化っていうのは秘匿情報はユーザの側にあってサーバ側に渡していない、ということ
なのでプログラムをこねくり回しても原理的には元のパスワードは分からないしそれが基本
そこに「でも単純なパスワード使ってる人がいるかも？」「使い回している人がいるかも？」っていう悪知恵で攻撃してくる人がいるので
あと、秘匿情報がユーザ側にある、といってもどうせスマホとかPCに保存されているのでそっちをクラックされると漏洩する
なので基本的に鍵は脳内に保存した文字列か生体認証、もしくはデバイス認証を使う
この辺はパスワードマネージャーを使っていてもマスターパスワードが必要になるのと同じ
ここまでがセキュリティ講習の１日目の午前中の話
前提として、サーバ側のDBの中身が漏洩したと同時に、プログラム、設定ファイル、丸ごと全部漏洩したとみなしている。
プログラムがDB上のパスワードをどのように処理してるか丸見えになる。
複合できるということは、プログラムの手の届く場所に鍵があるということ。
その鍵がユーザごとに違っていようが関係ない。そのプログラムを通せば複合できるわけだから。
複合した結果、元のパスワードを「瞬時に」出せる。
その元のパスワードを使って、正規のユーザのフリをして悪いことができる。
さてハッシュの場合、bcryptなどではソルト付きハッシュ値になってる。
ハッシュなので「時間をかければ」、そのハッシュ値になる値を検索できる。
元のパスワードと同一であるかどうかはわからない。（同一でなければバレる可能性が高まる）
ここである程度時間を稼げるので、サーバ管理者側にサービスを停止したり、パスワードを全部向こうにするような時間の余裕ができる
あーーーほ
暗号化しても平分で持ってても、ようはDBにアクセスされてる時点でハッキングされてるわけ。
そんなときに暗号化しておくともしかしたらパスワード悪用される前に時間稼ぎができるかもしれん。
そして強力なハッシュ+ソルト+ストレッチングするっていう、「現代のデファクトスタンダード」な運用なら一番その時間稼ぎができるわけ。
そもそもDBが完全無欠に守れる自身があるなら平分で保存でもいいわけなんだけど、んなわけねーだろ。万が一流出したときのダメージコントロールのためにハッシュカルル訳？ソコンところ理解できてないから、
安全化どうか？みたいなアホな観点でしかものを語れないわけよ。アホたれ
だからパスワードハッシュおもらししたら、直ちにおもらししたことを報告して、その間にハッシュでパスワード解読時間を稼いでる間に、おもらしされたユーザーは万が一他のサービスで同じパスワード使ってるとかいうアホなことしてたら、対応するわけよ。わかる？
まあでも、そもそも他のサービスでもパスワード流用してるタイプのアホは、そんな事しねーよみたいな気持ちもあるな。
そしたらそもそも、平文でほぞんしててもいいような気がしてきたけど、ハッシュで管理してて、アカウントの数が何千万とかあればだよ。
自分のアカウントのパスワードの解読まで一生かかっても作業が回ってこない可能性もあるので、事実上安全っちゃ安全かもしれない。
でもハッキング対象のアカウントが決め打ちでキメられてるなら、スパコンとか使って意地でも特定アカウントのパスワードを割り出すみたいな作業は可能かもれない。
だからってそれは、平文で保存したり、暗号化していい理由には並んと思ってて、
完全に安全にパスワードを管理することは無理だけど、限りなく安全に近い形で取り扱うことのできるハッシュ化(当たり前だけどそこには強力であること+個別のソルと使うこと+ストレッチングが含まれる)をするのは当然であって、
ハッシュが安全かどうかとか言ってる時点で、そもそもの何が問題で、なぜハッシュが良いとされているのか、なぜハッシュがデファクトで使われているのかってのをまるで理解してないと思う
そうやって表面だけの技術情報をなぞっただけでわかったような気持ちで文章書いてる時点で、自分の知識に対する過剰な自信と、慢心が溢れ出してて嫌いです
https://www.itmedia.co.jp/news/articles/2203/15/news172.html
ドコモ・ソフトバンクのパスワード平文提示問題が話題になっていたが、その中のコメントが理解できていないのがで教えてほしい。
「パスワードを暗号化して保持していても、復号できるなら平文保持と同じ」旨のコメントがいくつかあったのだが、これはどういった理由なのだろうか？
暗号化パスワードが流出しても、十分な強度を持った暗号化方式を利用している限り、鍵が分からなければ復号できないはずだ（方式によってはIVも）
この鍵が容易に解析できるといっているのだろうか？
それとも、サーバで保持しているであろう鍵も盗めるからダメと言っているのだろうか？
そうであればそれは鍵の管理方法次第で、プログラム内に保持しているもしくはユーザ情報(ネットワーク認証コード等)をもとに毎回生成している等であれば問題ないはずだ。
メモリ上の鍵や生成方法も盗まれるからダメという話であれば、それはハッシュ化したところで同じ問題が発生するはずだ。
ハッシュ化されたパスワードでも、ソルトやストレッチング回数を盗みさえすればある程度時間をかければデハッシュできてしまう。
＞ たとえ話のこのくだりは、どれに当たるんだ
元コメントだと明示してあるだろ。元記事の次のコメントだよ。引用すると：
＞ 「平文を個別に提供する」からといって、「パスワード全体を平文で保持している」ことにはならない。保持データには暗号化されている。
パスワードのハッシュとか管理者による文字列のソルトとかに加えて
パスワードのファイルは、可逆暗号化するだけでは不足であり、不可逆暗号化であるハッシュ化が必要だ、という見解がある。
可逆暗号化では、暗号化の解読が可能だが、ハッシュ化ならば、暗号の解読はできないからだ、という理屈だ。
→ https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/news/articles/2203/15/news172.html
しかし、それは正しくない。たとえハッシュ化しても、ハッシュ化の解読は可能である。
それには、次の方法を取る。
「文字列の組み合わせ（総当たり）のハッシュ化をしたリストを得る」
たとえば、 8桁以下の英字（大小）の組み合わせのすべてに対して、そのハッシュ化をしたリストを得る。
こうした一覧リストを得れば、ハッシュ化されたデータファイルから、元のパスワードを復元することが可能である。
※ 全員が復元できるわけではないが、8桁以下の英字をパスワードとしているユーザーに限っては、パスワードを復元することができる。
※ 詳しくは下記を参照。
→ https://qiita.com/gakuri/items/89ddc4fd9b39a884a305
――
問題は、それに要する時間だ。一体どのくらいの時間で「総当たりの一覧リスト」を得られるか？
それについては、ネット上で調べたところ、すでに調べた人がいた。下記だ。
→ https://qiita.com/ockeghem/items/5a5e73528eb0ee055428
これによると、かかる時間は、ハッシュ化の方法（レベル）しだいとなる。具体的には下記だ。（高性能の GPU を使った場合）
・ ハッシュ化が簡単な方法ならば、22分で一覧リストを得る。
・ ハッシュ化が複雑な方法ならば、62年で一覧リストを得る。
というわけで、結論としては、こうなる。
「ハッシュ化すれば、パスワードの復元が不可能だ、とは限らない。特に、低レベルのハッシュ化では、パスワードの復元は容易になされる。高レベルのハッシュ化ならば、たぶん大丈夫だが、スパコンを長時間使えば解読されてしまうレベルではある」
というわけで、「ハッシュ化すればパスワードの復元はされない」というのは、早計だとわかったことになる。
※ 英字だけでなく数字を混ぜたり、文字数を長くしたりすれば、強度は格段に強くなる。
※ 余剰な文字（管理者パスワード）を付け加えて、自動的に文字数を長くする手法がある。これを「ソルト」という。
→ https://it-trend.jp/encryption/article/64-0068
※ ソルトがあれば強靱になるが、ソルトがなければ強靱にならない。その意味で、「ハッシュ化をやりさえすれば大丈夫だ」とは一概には言えないわけだ。
