相次ぐ情報漏えいとログイン認証
ITエンジニアの雑談駆動開発部。この番組は、同い年、若手エンジニア2人が技術のこと、 キャリアのことを等身大のまま語り合っていく番組です。
成長中の2人が学んだことをリアルタイムでお届けします。 使用書なし、テストなし、雑談だけで駆動していきます。
ITエンジニアの雑談駆動開発部、始まります!
イェーイ!
イェーイ!
始まりました!よし!噛まずに言えたんじゃないかな?
ですね!滑舌最高!
滑舌の雑談駆動開発部がやばいからね!
雑談や!
ここがやばい!
毎回この緊張感でね。
はい。
漏えいしてますか?
漏えい?
最近漏えいしてますか?
漏れちゃってるかもしれない。
最近漏れてますよね?
漏れちゃってるかも。
漏れすぎじゃないですか?マジで。
毎日ですね。
毎日漏れてるから。個人情報が。
もう朝ニュースだいたいセキュリティの話。
しかもなんかPHPの話あったじゃないですか。
ありましたね。
あれのせいでね。
もう漏れる漏れる。
なんかすごい大事みたいだね。
はい。
漏れないようにしないじゃないですか。
そうですね。
セキュリティって正直
自分あんまり分かってない。
自分も
なんなんだろうな。
なんか総合格闘技のイメージがありますね。
本当にちゃんと勉強してる人が
畑違いって言ったら違うけど
ちょっと別の
系列な感じがするじゃないですか。
そのウェブ開発と。
一緒だけどやる人はやるみたいな。
はい。
感じになってるんで
そこを勉強したいなっていうのが今回のテーマですね。
今の旬ですもんね。
そう旬なんでやるっていう
そういう朝かな。
トレンドに乗っていいと思いますよ。
はい。
じゃあやっていきましょうか。
漏えいしてますと最近。
はい。
焼肉キングとかね。
会員情報が数千万件出てる。
数千万件出ても
今日は1日に2個ぐらい
数千万件出てた感じがしたけど。
そうなの?
タイムズとかね。
これが皮切りで結構
結構タイムズ評価してるけどね。
一番最初にね。
偉いよね最初にやっても
その後もここぞとばかりに
いろんな企業が
いってるじゃないですか。
タイムズから始まったみたいなところがね。
ありますけど。
なんでこんなに漏れてるんだろうと思って。
個人情報とか拾ってきてるから
認証が破られてんじゃねみたいな。
そのログイン
されたら
振られちゃうじゃないですか情報って。
その辺ちょっと怪しいんじゃないかと思って。
その辺を
重点的に今回
見たいなと思って。
見たのがとくまる本ってやつなんですけど。
とくまる本?
この
ぶっといですね。
辞書みたいな。
とんきもんって呼ばれるらしいですよ。
武器になる本。
として
エンジニア系で有名らしいんですけど。
とくまるさんが書いてるんですか?
そう、とくまるさんが書いてる。
とくまるっていうおじさんが書いてて。
これがセキュリティで有名な本らしいんで。
これはとんきもんで勉強してきました。
とくまるおじさんの
とんきもんですか?
そう。
とくまるおじさんのとんきもんで
勉強してきたことをちょっと
やっていこうかなと思います。
そもそも読む前はやっぱり
漏らせちゃダメじゃないですか。
漏らすことが悪じゃないですか。
はい。
だからしっかりと漏らさないための
セキュリティの話をしていきたいなと
思います。
漏えいした時にログイン突破
されたからっていうのは
半分当たってるらしいんですけど。
はい。
半分は本当にログインを
突破されて。
けど
本当に結構あるのは
ソフトウェアの脆弱性が出てるみたいな。
今回のPHPみたいな。
とか
メールとか送られて。
はい。
間違えて開いちゃう。
変なとこ開いちゃって。
普通にシステムの不具合とか。
普通に人が誰かに
売ってるとか。
中の人が外に売っちゃうとか。
ログインだけじゃないけど
今回はログインを見ていきましょう
っていうところで。
入り口や被害拡大の要因としては
認証が絡むことが多いですし。
ウェブアプリケーションとしても
ログインって
よく使うじゃないですか。
絶対サービスだとありますもんね。
知っておくべき内容かな
っていうところ。
今本当に
セキュリティって騒がれて
自分まだあんまり分かってないけど
今誰でも遅くないと。
今こそセキュリティを学んで
市場価値を高めていこうじゃありませんか。
エンジニア以外でも
リテラシー高めていきましょうとね。
基本的なことを
話していくんで
知ってる人から聞いたら
昔話の当たり前かもしれないんですけど
まあいいじゃないの。
ですね。おさらい。
おさらいだね。
ということで
ログイン突破の攻撃手法と二段階認証
ログイン突破の攻撃方法
何がありますかっていうところですね。
基本的にログインって
IDとパスワードを
セットにしてやるじゃないですか。
ログイン突破の時は
このIDを固定して
パスワードをぐるぐる回されて
たくさん攻撃されたり
パスワードを固定されて
IDの方を回されたり
みたいな。
一個固定して
層あたりでやるんですか。
みたいなのがあるんですけど
これが
基本情報みたいな話になるんですけど
ITを固定して
パスワードを変えるのが
辞書攻撃とかプルートフォース攻撃
みたいな。
言われるじゃないですか。
逆にパスワードを固定して
IDを回すのがリバーと
プルートフォース方式って書いてあるじゃないですか。
そうなんだ。かっこいい。
かっこいいじゃないですか。
パスワードスプレーとかもあるらしいですよ。
そうなんだ。
パスワードスプレーっていうのは
よく使われるパスワードの
パスワードを数個だけ用意して
大量のIDを少しずつ
バラまくみたいな。
よくありそうなパスワードに対して
大量のID。
友達のスマホとかに入ろうって
ふざけてるときとか
プルートフォース攻撃したろうか
みたいな。
使い方する。
あとちょっと面白いと思ったのが
上アカウント探索ってのがあるらしいです。
全部名前生かしてますよ。
上アカウントってどういう意味だと思いますか。
上アカウント探索どういうものだと
予想できますか。
上アカウント?
上アカウント探索。
あれ?
危機感持った方がいいのかな。
上じゃなかったっけ?
それは霊話かな。
霊話なアカウント探索だよ。
上?
上、ちなみに人の名前です。
なんだろう。
慈愛上?
なんだろう。
上っていうのは
海外にいるところの
アベレージネーム。
平均的なよくある名前。
アベレージ上
一般的な一般人っていう人が
よくあるような
パスワードに設定してます。
例えば太郎山田とかあるじゃないですか。
太郎山田のパスワード。
パスワードはパスワード。
本当によくあるありきたりな
パスワードで攻撃することを
上アカウント探索っていうらしいです。
あるあるで
リテラシーが高いと絶対
しないようなやつであえて
でもそういう人はやっちゃう人はやっちゃうんで
上アカウント
上で攻撃するみたいなものを
言うらしいです。
これへんの
対策としては
アカウントロックをする。
何回以上やったら
もうそれ以上
ログインできませんみたいな。
iPhoneでも何回もやったら
10分後とか
あれじゃないですか。
二段階認証ですね。
二段階認証
とかをやるんです。
これ二段階認証がすごくいいです。
いいんだ。
パソコンからやってスマホでも
入れなきゃいけないやつ。
パスワード突破されたとしても
その先にメールアドレスとかで届いて
メールアドレスに
その人の特定のメールアドレスで
知らないとわからない情報が流れてきて
それで認証する。
番号が送られてくる。
これ二段階認証をやるのがすごく大事。
ニュースでも言ってますよね。
やっぱ大事なんだ。
パスキーと二段階認証ね。
こんな感じで
パスワードを認証されて突破されちゃいますよ
っていうのが
あるんですけど
SQLインジェクションの仕組みと対策
これは攻撃手法の話で
我々開発者が
作り込んじゃうようなセキュリティバグも
あるわけじゃないですか。
これを私たちは防ぎたいんですよ。
なるほど。
システム開発するときに
穴を自分で作っちゃってますね。
これがドクマル本が掲げる
不正ログインを防ぐ前提は
二つ。
今回は二つあげます。
思いやすい。
ドンキすぎて全部読めなかったんで。
すごい持ってるから。
ドンキすぎて読めなかったから二つあげるんですけど
まず一つは
セキュリティバグをなくすこと。
パスワードを予測困難なものにする
という仕組みを作ること。
まずは一つ目。
攻撃者が賢いわけじゃなくて
作る側のミスの話をしていきます。
例えばセキュリティバグっていうところで
一つあげられるのがSQLインジェクション。
聞いたことある。
なんで起きるのかっていうところなんですけど
定義的に言ったら
入力をSQLの文字列に
そのまま連結しちゃう。
そうするとダメ。
例えば
パスワードとユーザーIDで
認証するって時に
仕組みとして
SQLで
データを見に行って
ユーザー
例えば太郎さん
ユーザー名太郎さん
パスワードは太郎101
っていうのを
SQL文で書いて
DBを見に行って
取得できたら
太郎さん認証完了
みたいな仕組み
にした時に
これ
SQL文を
ペタッとコード上に書いてて
条件のパス
ワードと
ユーザーのところに
ユーザーから受け取った
名前をそのまま
代入しちゃう
と
もっと
良くないんですよ
入力のSQLとして扱っちゃう
そうそう
実行しちゃうんですね
入力をそのままSQL文の中に
入れちゃう
内部のコードの中で
入れちゃうと
これが危ない
じゃあ入力地とSQLを
ごっちゃにして
考える
別々にして考える必要がある
ごっちゃにしちゃったら
例えば入力欄に
SQL丸々書いて
テーブル名とか合ってたら実行されちゃう
みたいな
これちょっと読み上げてみようかな
例えば
セレクトアスタリスク
フロムユーザーズ
ユーザーテーブルからから
where条件でユーザーネーム
シングルコード
アドミンシングルコードを閉じる
&
パスワード
イコール
シングルシングル
1イコール1
にしちゃった場合
アドミンっていうユーザーが存在してたら
パスワードは
通っちゃうんです
ユーザーアドミンで
1イコール1だから絶対トゥルーってこと
1イコール1になって
パスワード認証が通っちゃう
これが内部的に
ユーザーの
入力をそのままコードの中で受け取っちゃって
なるほど
パスワード入れなくてよくなりますね
これで入れなくなってアドミンで入れちゃう
なるほど
入力値に
1イコール1っていうSQL条件入れたら
絶対トゥルーになるから
へー
これで入られちゃうよ
これコメントアウト方式
みたいなやつがあるんですけど
これさっきセレクトフロムユーザーウェア
ユーザーネームで
アドミン入れるじゃないですか
アドミンの後に
これなんだっけ
ハイフンだ
スペースハイフン
でシングルコードで
これもうコメントにしちゃうんですよ
アドミンの後のパスワードの
なるほど
SQL自体を全部コメントアウトしちゃう
なるほど
そうしたらアドミンっていうのが取れちゃって
うんうん
ユーザーが取得できたんで
ログインできちゃう
みたいな
それ以降のがコメントアウトするから
そう
ただのユーザーからアドミン取ったよ
だけになっちゃう
みたいな感じで突破されちゃう
こんな感じで
SQLの特性を
ユーザーからの
入力を
素直に受け取っちゃうことによって
SQLインジェクションっていうのが
発生してしまう
これどうしたらいいのかっていう
分けなきゃいけないですって
ごめんさっき言っちゃった
これプレイスフォルダーっていうのを
使わないといけなくて
何が問題だったかっていうと
ユーザーの
入力を
そのまま
SQL文に当てはめてしまったのが
良くない
だからこれ内部的に
まずSQL文を
読み込む
その後に
ユーザーの入力を
SQL文に追加していく
ステップ1
ステップ2に分けてステップ1で
SQLとしては形は先に
決めておいて
その後にステップ2で
ユーザーの入力を
SQLのところに変数に
入れていく感じ
そうするとさっきの
シングルコードとかでコメントになっちゃった
っていうのは
今回はSQL文の変数の
中に入れてるんで
そもそも
意味わかんない数値になってエラーです
ダメですみたいな感じの
これは入力値でSQLの命令じゃないんだ
っていう
エラーになっちゃって突破できません
対処ができる
っていうのが今回の
プレイスフォルダーでSQLインジェクションを
防ぐっていうのが
あるらしいです
作るときに気をつけることが
そうですね
これ多分今の普通の
言語の使用の
この
DBアクセスとかの
よくあるSDKとかを使えば
これはないんですけど
これ一昔前というか数十年前だったら
普通にあったやつで
そう当てはめてみたいな
平文でやってるじゃんみたいな
分かっちまったぜみたいな
これ多分本当に数十年
見かけたら脳汁ヤバいですよ
家族やるんじゃないですか
これだって普通に
俺しか知らない事実として
言っちゃったらどう思いますか
いやー
嬉しいかもしれない
たぶんPHPの
突破方法を公開しちゃったやつも
たぶんこういう気持ちだったんじゃないかな
見つけた瞬間脳汁ヤバいですよ
ヤバい
俺が神だ
俺しか知らない
みたいなやつ
たぶんヤバいなと思った
こういうの知るの嬉しいというか面白かった
とかとか
セッションID固定化とオープンリダイレクト
あとはセッションIDの固定化っていうのがあるんですけど
これ
例えばユーザーが
認証完了した時に
ユーザーっていうのは
サーバー側から
セッションIDっていう
長い文字列をもらうんですよ
その文字列を持ってて
文字列と一緒に
サーバーに
文字列を持っていることによって
私は認証完了してますの証
セッションIDが
私は認証されてますの証としてあって
これを持っていることが
簡易書みたいな
これを
盗まれるんですよ
盗まれたらヤバい
どうやって盗むんですか
まず
攻撃者が対象のサイトに行くんですよ
アクセスすることによって
その人が
サイトにいるっていうことの
セッションIDをまず受け取るんです
最初に行っただけで
セッションIDがその人に渡される
この人が
このサイトに来てるっていうので
セッションIDが来ちゃうんですよね
自分のまず発行する
攻撃者が発行するんですよ
誰から盗んだものでもないってことですか
そうそうそう
これを
攻撃者に使わせたい
被害者の人
被害者になる人に使わせたいんですよ
これ昔
URLに
URLのケツに
セッションIDっていうのを入れてたんですよ
えーヤバくない
ドメインスラスラの後に
セッションIDなんとかみたいなやつを
入れて管理してた時代があったらしく
これを
悪用してというか
被害者の人に
この使用してるサイトで
個人情報とか書いてくださいね
連絡してログインしてやってくださいね
っていうメールとともに
リンクを
文章かなんかで隠して
文字にリンクを入れるじゃないですか
文字に
裏のリンクを入れて
URL
セッションID
イコールなんとかっていうリンクを文字の裏に
仕込ませて
そのリンクをポンって押して
攻撃者がまず受け取ったセッションで
その人も入る
自分の会員証でアクセスさせる
そこでログインするじゃないですか
そのセッション持って
攻撃者もセッション持ってるじゃないですか
最初自分のセッションをその人に
使わせてるから
だから自分もこのセッションを持って
そのサイトに行くと
認証されてる状態で
入れちゃう
そしたら自分のだから
自分のが入るだけじゃないですか
最初
自分が持ってるじゃないですか
自分のものを被害者の人に
使わせて被害者がそこで自分で
ログインするんです
そっか
そこで入れてるから
入れてるから
突破されて
突破されたの分かったら
攻撃者の人によしじゃあ僕も入ろうって言って
そのセッションIDで入っちゃう
みたいな
相乗りするんですね
手法が
セッションIDの固定化っていうやつで
悪いことしますね
これ
対策としては
ログイン成功時にセッションIDを再発行する
だから
被害者の人は
最初に攻撃者の人に
相乗りされた
相乗りされるけど
ログインしたタイミングで
サイト側がもう一回ちゃんと
セッションIDを変えて再発行して
再発行することによって
最初受け取ったセッションIDと別のものを
被害者の人はもらうから
もう攻撃者の人は
セッションIDが違うので
入れません
っていう対策をして
いるらしいです
これは
フレームワークの標準の認証なら
この機能が入っているらしいです
ただ自前で
セッション管理を作ろうみたいな
ことをしだした時に
これを書き忘れると
今でも普通に作り込めるらしい
危ないですね
自分で作っちゃ絶対ダメですね
自分で作らないもしくは
ちゃんとお勉強しようっていう話
はい
書いたことありますか
自分これ本で読んだことあって
セッション管理を作ってみよう
みたいなやつがあって
でやったんですけど
このセッション管理は
絶対に使わないでください
ってもう再三書いてあった
今わかったってこと
それが
なぜ使っちゃダメなのかっていう
そうなんで絶対に
セッション管理は作ってみようって
本当書いていって
断ることにこれはどんな脆弱性があるか
わからないので
絶対に使わないでください
こういう悪いことする人の
手法があるっていう話ですね
はい
オープンリダイレクトの話もしておきましょう
オープン
リダイレクト
なんですかそれ
これログイン後の
転送先のパラメータを
URLに貼っ付けておいて
それによって転送先に
飛ばさせちゃうっていう
技なんですけど
これも昔の話なんですけど
URLの末尾にまたこれも
リダイレクト先の
URLが書けるようになってるんです
だからドメ
例えばyoutube.com
リダイレクト
私の悪い悪.com
みたいなURL.
abil.comが
貼れちゃうんですよそれ
もさっきと同じように文
字の裏に
URLのリンク仕込ませて
押させて
一見普通のサイトに
飛ばすんですよ最初
そっくりなサイト
偽サイトを作ってるんです
その人
偽サイトを作って
その本当に
なんかのログインと全く同じような
フェイクやつを作って
そこで入れさせるんです
サブアーキュービーとかになりましたね
入れさせて
パスワード違います
出てて
間違えたのかなと思って
でもその時には元のところに
戻されて
最初にフェイクで入って失敗して
間違ったのかな
でもう一回行ったら
そこが正しいところに
飛ばすようになって
じゃあパスワードと
IDだけ取られて
でその後は普通に使える
みたいな
怖い
被害者としてはね
だから一回打ち間違えたのかなと思って
入力して
それごとちゃんと取られちゃってるよ
怖っ
一番怖いかも
これドメイン見ててもちゃんと
パラメーターまで見てますか最近
見てないです
逆にその
リテラシー高い人とかドメイン見るとか
いるじゃないですか
中途半端に高いと
頭のyoutube.comだけ見て
youtube.comだ大丈夫
で後半は見ない
みたいなところになっちゃうと
私はちゃんと見てるけど
実は
これって祭りに
変なの合わせてますか
youtube.comで終わってたら安全なんですか
youtube.comで終わってたら安全です
じゃあお尻を見たらいいんだ
へー
これは今は付けててるのか
わかんないけどそういう時代があったらしい
でもそれも
裏側に隠されたらわかんないじゃないですか
はい
なんで気を付けましょうっていう
話です
これもいろいろあるんですけど
この辺のセキュリティのことって
使用書とかに書かれてこないじゃないですか
そうですね
書き忘れたらもう大変なことになるじゃないですか
はい
これも我々ウェブエンジニアが
しっかりと学んでおかないといけない
セキュリティのお話
はい
結構知らないことが
はい
ハッシュ化・ソルトとパスワード解析
2つ目のパスワードの予測を困難にするって
話があるんですけど
ハッシュ化とかありますよね
これパスワードが
これ漏れてからの話です
パスワードが漏れて
これ暗号化とハッシュ化が
違いがあるのわかりますか
何だったっけな
何だったっけな
ハッシュ化はあれですよね
ただ文字を変える
で何だったっけな
暗号化はぐちゃぐちゃにした後も
うん
同じ道通したら
パスワードにその元のやつに戻るみたいなやつ
でハッシュ化をバラバラにしたら
もう誰も一生わかんないみたいな
素晴らしいさすがです
暗号化は戻せる
ハッシュ化は戻せない
あですね
一方向で変換
ハッシュ化するだけ
ハッシュ化は元の数字には戻せない
っていう感じの
これなんかちょっと前の
どっかの大企業で
パスワードが漏れたときに
本当はパスワードってハッシュ化して
保存しないといけないんですけど
これなんか平文
そのまんまのパスワードで
保存されてたらしくて
これなんか
総務省から問題されたらしいです
えー
やばいですね
2026年でも平文保存があるらしいです
あれですね
ハッシュ化はぐちゃぐちゃになったものと
ぐちゃぐちゃになったものを
発合するんですか
それが現在の
ログイン書でやらないといけないことなんだけど
なんかあったらしいですね
そういうところも
でこれ一個思ったんですけど
ハッシュ化されたとしても結局その
ハッシュ化されたパスワードを
どっかのBBとかに入力させられといて
だったら
検索できるじゃないですか
例えば
パスワードっていうのをハッシュ化されたものを
DBに打ち込まれてた
そしたら
仮に誰かが
パスワードのハッシュ化を
拾ってきて
その
拾ってきちゃったら同じハッシュなんで
これパスワードだ
の文字だってわかるじゃないですか
ハッシュ化ってもう
同じぐちゃぐちゃの文字
たまたまでも当てられたら
ぐちゃぐちゃの文字
同じもの
のリストを最初に作られてたら
パスワードっていう文字列の
ハッシュが作られてたら
もう漏れた瞬間
わかるじゃないですか
ワンモア
パスワードリストみたいな
ハッシュ化された
パスワードリストみたいなの最初に作られてたら
どうですか
あれか
イミテーションゲームじゃん
わかんない
チューリングですよね
あれですよね
例えば
IUEOに対応したのが
01234だったら
それが
その対応表バレちゃったら
逆引きできるみたいな
じゃないですかこれ
たとえハッシュ化したとしても
それが逆引きのものが出ちゃったら
これバレちゃうじゃないですか
はいはい
イミテーションゲームですよね
これ
よくないじゃないですか
でもこれ実は
なんとか多分大丈夫なんですよ
これは桁数に依存するんですけど
基本的に
8桁の場合
これ
A数字の大文字小文字
数字記号で
大体95種類あるって言われてるんですけど
8桁のパスワードっていうのは
8桁の
95種類文字の
通りっていうのは
6634丁通りなんですよ
結構ありますね
これ結構あるじゃないですか
大企業の
クラウド事業者のデータセンター並みの
容量らしいんですよ
8桁だけでそもそも
これが仮に12桁になった場合は
計算しました
5403階
6008桁
8662丁
6369億
6289万
625通りの
合わせが必要なんです
12桁の場合
アクエリオンみたい
だからそもそも
物理的に不可能なんですよ
12桁にした
だったらバレない方
絶対に
本当に完全にランダムなものだったら
バレない
絶対同じやつができないっていうことが
保証されたら大丈夫
ただ
本当によくある
みんながつける
簡単なパスワードにしちゃうと
それから順番に探索されちゃうんで
バレちゃうこともあるよね
っていう話なんですけど
誕生日とか
そういうのから見ていくから
これ
バレないようにする仕組みがあるんですよ
えー
パスワードを
保存するときに8桁でも
パスワードを発祝する前に
ソルトっていうものをつける
えー
ソルトっていうのはすごいランダムな数字
を
パスワードの末尾につけて
それと一緒に発祝しちゃう
ってことによって桁数がすごく多くなってるんで
もう
誰もわからない
人塩ってことですね
そういうこと
で
ソルトをかけることによって
基本的にさっきの
12桁以上の数字になるんで
発祝された
DBとかで
辞書的に当てられることは基本的にはない
はず
等しいをかかってるから違うもの
で、あともう一つ
この探索を難しくしてる
ものがあって
発祝をあえて遅くしてるんです
えー
発祝の速度
1回の発祝に0.1秒かかるようにしてるんで
えー
そしたらどうなるんですか
これこうすることによって
0.1秒って結構早いじゃないですか
でもこれを数億回やるとなると
何分何秒かかってくるじゃないですか
はい
これ発祝が早かったら
その分
たくさん短い時間でできちゃうじゃないですか
あ
でもこれあえて発祝がちょっと長くすること
0.1秒だったらユーザーは気づかないじゃないですか
でも
攻撃した時には毎回0.1秒ずつ
重んでいくんで10個やるのに
1秒かかっちゃう
みたいな感じで大量のものできにくくする
っていう仕組みも
セキュリティのことにあるんです
エネミー側の
視点で
エネミー的にやりにくい
あーなるほど攻撃するにも時間かかるから
早撃ちできない
なるほど
これ
そもそもこれたくさん攻撃したい時に
さっきみたいな
DBに入れて自称的な攻撃はさっきしないらしいんですよ
えー
GPUってあるじゃないですか
はい
ガホッていくらしない
早いっすよね
一気に
GPUのイメージだけど
1000人ぐらいが
パイ投げるみたいな
そうです
そういう攻撃するらしいんで
最近は8桁の
パスワードだったらGPU1枚で
8時間で解けるらしいです全部
さっきの6000兆ぐらいのやつを
8時間でいくらしいです
GPUだったら
GPU1000枚使われたら
30分でいくらしいです
いるのかなそんな
GPU1枚100万円弱ぐらいなんで
あー
やる人はやるんですよ
漏えいを前提にした認証設計
できる
物理的に可能であるみたいな
なんでまあそもそもね
こういう
パスワードっていうのは
これもう漏れてるんですよ
正直
ここまで来たら
パスワードは
漏れてる
もう漏らさないっていうのは
正直
厳しい
漏れる前提で動かないと
そもそもこれ
読んでみて思ったんですけど
最近の技術の進歩GPUの進歩とかがあって
どう考えても
そうあたりでバレちゃう
パスワードが出た時点で
発信されたものだとしたら
パスワードが出た時点で
もうバレちゃう
ので
今回本読んでみて
その漏れるのは
しょうがないとは言わないけど
漏れた前提で考えることが大事
セキュリティの話として
今年に入ってからも数万件以上
数百万件以上の大規模の
漏えいが
何回も起きてるじゃないですか
我々一個人の
エンジニアの
アプリじゃなくて本当に企業の
アプリでどんどんどんどん入られてる
ってことは
厳しいんじゃないかっていうのがあって
これは
我々としてやらないといけないこと
利用者としてやらないといけないこと
はまずあると思っていて
パスワードを使い
回さないことであったりとか
長いパスワードにする
で二段階認証するということが
まず挙げられます
その上で開発者として我々がやらないといけないこと
まずは
漏れにくくするんですよ
さっきのSQLの話とか
SQLの話とかデータベースに
平分で保存しないとか
セッションはちゃんと毎回再発行するとか
そういうのをやることが大事なんですけど
その上で
漏れた被害を小さくする
っていうことが我々に求められることなんですよね
はい
漏れたことに気づける仕組みを
ちゃんと作っておく
あー漏れてるぞーって
そう漏れたら漏れたって分かるようにしないといけない
このログであったりとか
バックアップをしっかりとっておいて
そこらへんが
分かる仕組みを作ってこないと
ダメってことですね
なるほど
漏れたことが分かんないのが一番まずいですからね
そうですね
勝手に出回ってるのも嫌ですね
で、どっかの大企業も
なかなか好評までに時間がかかったみたいな
それ
利用者としては困るじゃないですか
数ヶ月前に出てるのに
実は
数ヶ月後の時に出てたんですよね
って言われたらすごい嫌じゃないですか
信用問題にもかかってくる話で
はい
漏れたなら漏れたで
すぐ分かる仕組み作り
っていうところ
誠実な対応が
信頼に繋がりますから
漏れた時点で信頼は落ちてるかもしれないけど
血まで落ちる信頼を少し
止めるという意味でも
最小限に抑える
最小限に思っている
やばいと思ったら素直にエスカレですよ
我々新人のね
ですね
仕事と一緒ですね
ここまで来たらやばかったらすぐ言う
やばいですやばいです
でもこれ
どっかちょっと前に
セキュリティ事故会見みたいなやつで
はい
パスワード漏れちゃいました
っていうのを見たことあるんですけど
パスワード漏れちゃいました
でも私たちのところは大丈夫で
察知化してるんでみたいな
人がいて
私たちのパスワードは
大文字小文字は含んでいますし
記号と数字の
何桁以上でやってるから
私たちのパスワードは大丈夫です
って会見したところがあったんです
えー
エスカレにもほどほどにね
そういうのもあるんだ
そう
1点良い情報悪い情報をしっかりと
埋めてできることに
こうしたことはない
漏らさないことから漏れた後の対応へ
そこはしっかりと知識を身につけていきましょう
って話です
リテラシーを上げるっていうのが
一番大切かもしれないですね
はい
最近のニュースとかでも
キリンが
日本の取材に応じたみたいなの見ました?
あー見ました
それで日本人に対してのメッセージありますか?
日本は
セキュリティの観点で
最悪な国の一つだから
もうちょっと気をつけた方がいい
心配される
ありがとうございます
漏れちゃってることを前提に
漏れちゃってることを前提に
我々としては
作っていく必要があるよねって話で
今回のまとめに
入るんですけど
もともと最初
セキュリティの本読み始めた時に
漏らさないことが正義だって言ったんですけど
漏らさないことは
無理だよねっていうのが
こういうセキュリティの本とか
色々世間のニュースとか見て
分かったじゃないですか
そうですよね
はい
そもそも自分のシステムじゃなくて
他のところで漏れたところを
自分のところにパスワードを
自分のところに使われるってこともあるんで
予想から漏れたらもう
自分のサービスだけじゃないんで
どうしようもないじゃないですか
だから今回の格言を言います
はい
漏らさないはゴールではなく
スタートライン
漏れた後まで考えて
初めて認証を作ったと言えるんじゃないでしょうか
なるほど
毎回格言を作っていくから
ディスクレッチしてくれるんですね
そうそうそう
だからしっかりと
認証を作っていきましょう
ラインとかで
メッセージとかメールとかで
変なこととか悪口とか言わないとか
そういうことも大事です
そういうことです
ということで今回のセキュリティの話は
終わりにしようと思います
ありがとうございました
ありがとうございました