00:15
はい、8月29日火曜日ですね。 時刻は朝9時半になっていたはずです。
すいません、僕が収録をミスってましてですね。 実はこれは後からこの始めのところだけ、トークスクリプトだけ、後付けで突っ込んでます。
はい、というので、ここから本編をお楽しみください。 どうぞ。
まあ、やっていきたいと思います。
はい、というところで、今日はタイトルを読みます。
パスワードソルトについてですね。
この前、セキュリティといえば徳丸先生でしょう、みたいなのがこの業界にあるんですけど、
その徳丸先生がお話しされていた、そのパスワードソルトについてのお話が、
ちょっと前に、ビクトブランドとビクトスクエアに対する不正アクセスがあったみたいな、
そういう会社さんの情報流出の可能性というところがあって、
そこはパスワードがソルトなしのMD5のハッシュで保存されたというのが話題になっています。
かなり危険というか、脆弱な対応をしてたんだなというところですね。
MD5自体はすでに、Googleでしたっけ?
どっかがアタックして、もう突破できますよみたいな実証実験をやってましたね。
その記事を書いてましたね。
でも、MD5はそもそももう脆弱すぎると。
そのMD5を使っていたし、そのパスワードを作る時もソルトなしで作っていたところで、
知ってる人からするとほぼほぼオープンになってますよと言っても過言ではない。
そんな状況だったらしいですね。
徳丸先生はそこでちょっと思ったところがあって、
実際そのパスワードソルトに対して、
皆さんがどんな理解があるのかなというのが気になったらしい。
何か誤解されてる方も多いんじゃないかなというところで、
ツイートですね。試験問題的に4択クイズをツイートされてましたね。
ソルトかハッシュのところに4択クイズで、
現在知識でこれかなっていうのを見てくださいと。
問題としては、パスワードをハッシュ値で保存する際のソルトは、
どこに保存するのが一般的な実装でしょうかというのを選択肢出されていて、
今回4つ選択肢がありましたね。
皆さん答えられたかもしれないですけど、
1つ目が機密性の高いファイルに保存して、
環境変数で渡すというのが1つ目ですね。
2つ目がハッシュ値とともにデータベースに保存すると。
3つ目がハードウェアセキュリティモジュールに保存をすると。
ラスト4つ目がソルトは保存せずに毎回ランダムに生成しましょうと。
というような4択のクイズでしたと。
このうちどれかが正解なんですけど、
今回は7811票の皆さんがチャレンジされまして、
僕もチャレンジしまして、僕は運良く正解しました。
焦ったというか悩んだんですけど。
ちなみに言うと、これの答えは2つ目ですね。
ハッシュ値とともにデータベースに保存するというのが
愛聴徳丸先生の中では正解だとおっしゃっていて、
今回正答率は33.9%ということで3分の1ぐらいしかいなかったので、
意外と皆さん間違えたところですね。
ちなみに第2位は機密性の高いファイルに保存して、
環境変数で渡すというところが第2位ですね。
03:00
第3位がソルトを保存せずに毎回ランダムに生成すると。
ラスト4つ目、ハードウェアセキュリティモジュールに保存するですけど、
僕はこの4つ目のハードウェアセキュリティモジュール、
HSMというのがよく分からなかったので、
そもそも答えられなかったというのですね。
僕の今までのやってきた経験値で、
データベースに保存するんだろうなというところでした。
これについていろいろ徳丸先生がしゃべられているんですけど、
ハッシュ値で保存する目的というのは、
基本的には漏洩してもパスワードの悪用をなるべく遅らせることがまず1つです。
あとは管理者といっても、
パスワードを知り得ると悪用の可能性が正直あるよねというところですよね。
中の人でもそれはもちろんある。
あとはサーバーに侵入される前提だと、
暗号の鍵とかも搾取される可能性が高いというところで、
それらを回避するためになるべく遅らせたりするところで、
ハッシュ値を使うと。
そのまま単純ハッシュだと、
ぶっちゃけると同じパスワードのユーザー間で、
同一となる危険性も正直に残っていますというので、
パスワードソルトとかを使って一時性を保ち、担保したいところですね。
そんなことをやっていきます。
いろいろハッシュの関数、アルゴリズムもたくさん出てきて、
先ほど言いましたMD5もそれの1つですけど、
MD5はもう危険ですというので、
だいたいシャア256とかシャア512とかその辺を使うんじゃないかということですね。
ソルトはどこに保存するのが一般的かというところのお話もエゴされていて、
基本的には皆さんは多分Linuxのサーバーを使うということが多いと思います。
一旦それを前提なお話をされているんですけど、
そもそもハッシュとか値を使ってましたけど、
システムとかバージョンごとにハッシュの保存形式が結構まちまちだったんですね。
僕はこれ知らなくて。
相互運用上の問題も正直あったんですね。
これを解決するためにモジュラークリップフォーマットみたいなものが考案されたらしいですね。
現在のLinuxにも広く利用されております。
僕はOpenSSLコマンドとかそんな自分で意図的に使ったことなかったので、
こういうふうな使い方あるんだねって結構勉強になりました。
OpenSSLのパスワードオプションで、
ソルトイコールホゲホゲとパスワードこれですみたいので使えるらしいですね。
専門的な話が続いているのであんま詳しく述べられてないんですけど、
いろんなことを加味すると結果パスワードっていうのは
ハッシュと共にデータベースに保存するっていうところが最適解だよっていうのはおっしゃってますね。
この記事についてはみなさん読まれたかわかんないですけど、
後ほどツイートしますので見ていただければというところですね。
問題はソルトとハッシュを両方データベースに保存すると
結局流出後に悪用されるんじゃないかって話は正直あるんですけど、
突破されている時点でどちらにしろ流用される可能性は高いですけど、
簡単に破れるってことなんですけど、とにかく時間をたっぷりかけられれば
破られるっていうのはそりゃそうなんですけど、
それを簡単に破られるわけではないってところが結構ポイントです。
そのスピードってところですよね。
現代のスーパーコンピューターとか使ったらどうなのかって話はもちろんあるかもしれないですけど、
割とですね、アルゴリズムもだいぶ進化してきているのと、
そんなちょっとやそっとスパコン使ったところで、
やっぱ天文学的な確率じゃないとなかなかとらぶりつけないようになっているはずなので、
06:00
そういう意味では、なるべく遅らせるのがまだ今のところの最適解なんだってところですね。
結局、暗号のアルゴリズムって、
なんだっけ、楕円関数論を使って表現みたいなところがあって、
結果的には完璧にブロックできているというよりも、
とにかくたどり着くまでかなりの分母ですから、
ケースが多いので、
それを全部やっていくとかなり時間がかかるっていうところが、
暗号の強度ってところらしいですね。
今、現代では。
これがもしかしたら変わるかもしれないですけど、
今のところは時間がかかるってところがギリギリ担保しているところらしいですね。
ちなみに、先ほど4択のクイズがあって、
残り3つの誤答は何が問題かっていうところを解説されていました。
真っ先に分かりやすいのは、
ソルトを保存せずに毎回ランダムに生成するってところですね。
これパッと見、確かにこれが良さそうな気がしますけど、
致命的で、ランダムに生成することは別にいいんですよ。
それができれば本当はいいんですけど、
生成した後、保存しないとバスターの称号できなくなるので、
奇発性ですよねっていうので、
結局は保存しなきゃいけないよねってことですね。
続いて、次に回答が多かった、
機密性の高いファイルに保存して環境変数を出しましょうねっていうやつですけど、
ソルトの要件である、
ユーザーごとに異なるっていうのを満たせない実装になるっていうところが、
ポイントというか問題だったと。
ペッパーの方に使うならあり得ますけど、
環境変数での受け渡しは、
侵入を前提とすると、
安全じゃ言えないよねってところで、
高いファイルに保存しても良くないよってところでした。
最後ですね、ハードウェアセキュリティモジュールに保存ってやつですけど、
ユーザー数が数十万以上になることを加味すると、
ユーザーごとに異なるっていうのを満たすことが
結構困難な実装だったところですね。
あと一方ですね、ペッパーの保存には適した方法ですと。
ですが、せっかくハードウェアセキュリティモジュールを使うんであれば、
暗号鍵は外に持ち出さずに、
パスワード発注をモジュール内で複合化する方が、
特性化した方法だっていうところもあるような話でしたね。
ちょっとこれは別の話とは議論があるので、
そこに関しては基地では述べませんという話でした。
ソルトの保存方法について、
詳しく解説をされてましたけども、
ペッパーというのはシークレットソルトという場合もあるらしいですね。
これをいかに安全に管理することが課題になってくるというところで、
今後、HSMもそうですし、
クラウドのハードウェアセキュリティモジュールというのもあるらしくて、
それの選択肢としては一応考えられるかもしれないですね。
あとはパスワードとか、攻撃の現状、誤解とか何やらかんやらについて
解説したYouTubeも貼ってるんで見てねっていうことでした。
結構当たり前のように僕らも使ってました、
発注とかソルトの話ですけど、
こうやってしっかり勉強してみると、
やっぱ大事だなっていうのがつくづく感じますね。
運用方法が皆さん間違っている可能性も多いにあり得るし、
僕はたまたま正しい運用をしているプロジェクトに入って勉強させてもらって、
たまたまそれを知識として知ってたから良かったですけど、
こういうちゃんとですね、
なかなか授業とか本とかで述べられづらい、
またパスワードとかセキュリティ周りって勉強するリソースが少ないので、
こうやって教えていただけるのはすごくありがたいなと思いましたね。
何もないから大丈夫ってわけじゃなくて、
今までやっている、今自分たちが組んでいるシステムの設計が
果たして本当に正しいというか、
09:01
これでちゃんと耐えられるのかっていうのを常に見直すとか、
振り返りをするっていうのはすごく大事なことだと思っていて、
でもこれはエンジニアの仕事だと思ってますので、
認定とか分からないかもしれないけど、
それでもしっかり自分たちでも調べたり情報収集したりしなきゃいけないなっていうのをこの記事を読みつつ、
改めて反省をしたという感じがあります。
はい、というところで、以上パスワードソルトのお話でした。
とても勉強になりましたね。
短いですけど、今日は朝方はこの辺で締めていきたいと思います。
パスワードソルトね、ソルト自体に
ハッシュをしておいて、それをソルトとして使うみたいなやり方もあったりしましたね。
昔はMD5しか僕もまだ知らないときは、
MD5を20回くらいかけたものを
ソルトとして、最後に本来の入力された
パスワードと一緒にMD5使って
ハッシュにしましたみたいなこともやってたりしましたね。
なかなか20回という回数自体も
1つのソルトみたいなものですよね。
そういう色々なテクニックというか、無理やりやってたこともありますけどね。
あと、パスワードソルト自体を
プロジェクト名にすることってよくあったりするんですけど、
それも結構僕は安易じゃないの?と思ったりしますね。
プロジェクト名自体が一位な文字列だと思うので、
それはそれで、そうそう知られることはないと思うんですけど、
できればそこもランダムなものをするとか、
機密性の高いものをするとかの方がいいかもしれないなと思いましたけどね。
そんなところで今日は終わっていきたいと思います。
明日は適当な記事を読もうと思ってるんですけど、
最近ですね、僕が、
冗弱で申し訳ないんですけど、最近知った
React Best Practice、バレットプルーフリアクトかっていうのを
僕最近知ったんですよね。今それをザーッと眺めてるんですね。
ディレクトリー眺めたり、色んな人の解説記事を読んでるんですけど、
これがまた面白そうなんで、Reactとか
フロントエンドのいわゆるディレクトリ構成とか
コンポイント設計みたいなところの話を
ダラダラと喋れたらなと思ってますので、興味ある方は来てみてください。
そんな感じで今日は終わっていきたいと思います。
今日も一日頑張っていけたらなと思います。それでは終了します。
お疲れ様でした。
