Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Webアプリケーションにおけるパスワードの管理について
Search
mrtc0
September 12, 2016
Programming
10k
28
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Webアプリケーションにおけるパスワードの管理について
#LT駆動 29での発表スライド
mrtc0
September 12, 2016
More Decks by mrtc0
See All by mrtc0
Datadog を使ったプロダクトとクラウドの セキュリティモニタリング
mrtc0
0
3.5k
コードで理解する eBPF セキュリティモニタリング
mrtc0
2
330
Product Security Casual Talk #1 - Datadog を使ったセキュリティモニタリングと 自動化の取り組み
mrtc0
2
740
GMO ペパボ株式会社 23卒・24卒向け セキュリティ勉強会 実践 DevSecOps パイプライン
mrtc0
1
780
実践 DevSecOps パイプライン ~システム開発へのセキュリティの取り入れ方~
mrtc0
2
630
脅威モデリングで考える Kubernetes セキュリティ / CloudNative Days Tokyo 2021 #CNDT2021 #CNDT2021_B
mrtc0
8
3.6k
ProSec-IT 2021 Container Security
mrtc0
2
840
GMO Developer Day 2021 - DevSecOps 推進の取り組みの紹介.pdf
mrtc0
4
1.9k
Web セキュリティ研修 / GMO ペパボ 新卒研修 2021
mrtc0
7
47k
Other Decks in Programming
See All in Programming
『寄り添うラジオ』をAIで作る 体験価値から逆算した、会話しないUXと品質設計
theoriatec2024
3
180
AgentCore CLI で進化した AWS での AI エージェントの作り方 : 必要な機能を必要な時に
icoxfog417
PRO
3
350
Streamlitで実現する自然言語データアプリ開発
ayumu_yamaguchi
1
290
AI活用は、個人から組織へ|マルチプレイヤーエージェントハーネス「QM」の社内活用事例 / AI use is moving from individuals to orgs
rkaga
1
110
巨大モノリシックアプリ モダン化大作戦
ktcryomm
1
1k
XHTMLが残したもの
yosuke_furukawa
PRO
2
810
新卒PdEのリアル
ryu1013
1
500
From 6 People Classroom Meetup to 100 People Regional Conference / FOSS4G Hiroshima 2026
furukawayasuto
0
210
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
120
アクセシビリティから考える情報設計
high_g_engineer
0
380
LoopHub - ローカルで動く GitHub で、AI と共同開発
jugyo
1
560
市販E-Readerを乗っ取れ 〜Embedded Swiftで電子ペーパーガジェットを制御する〜
trickart
0
190
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
6.3k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6.1k
Code Review Best Practice
trishagee
74
20k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
430
Abbi's Birthday
coloredviolet
4
10k
The World Runs on Bad Software
bkeepers
PRO
72
12k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.3k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
sira's awesome portfolio website redesign presentation
elsirapls
0
410
The SEO identity crisis: Don't let AI make you average
varn
0
560
Writing Fast Ruby
sferik
630
63k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
510
Transcript
Webアプリケーションにおける パスワードの管理について 2016-09–04 LT駆動開発 #29 @mrtc0
> whoami • もりたこ(@mrtc0) • ChainerでXSS検知するやつ作った – https://mrtc0.com/lab/php/index.php?q=hello
背景 • パスワードをDBに保存するときに、具体的に どう保存すればいいのか – ハッシュ化 + ソルト – 使用するアルゴリズムはどれにすべきか?
– ちゃんと整理したい • 昨日の深夜にサクッと作ったので気軽にマサカ リ投げてください • Djangoでどういった実装がされているのか
Case 1 • パスワードを平文のまま保存 +------+--------+------------+ | id | name |
password | |------+--------+------------| | 1 | admin | password | +------+--------+------------+
平文での保存 • 推奨されない(当たり前) • 第三者が容易にログインできる • 他人のパスワードの生成パターンを予測できる – Aさんは 文字列+誕生日
とか
Case2 • DB内でパスワードを暗号化 +------+--------+------------------+ | id | name | password
| |------+--------+------------------| | 1 | admin | 402fda0cde783273 | +------+--------+------------------+
暗号化して保存 • Ad be ◦ が過去に採用していたケース • 暗号化されて安全だね!やったー! – とはならない
• 暗号化するプログラムが入手されたら? • 同じパスワードからは同じ文字列が生成される
Case3 • パスワードをハッシュ化して保存 +------+--------+----------------------------------+ | id | name | password
| |------+--------+----------------------------------| | 1 | admin | 5f4dcc3b5aa765d61d8327deb882cf99 | +------+--------+----------------------------------+
ハッシュ化して保存 • 一方向ハッシュ関数を使用して保存 – パスワードの長さに関する情報はなくなった – ユーザーにパスワード長を制限する必要もない – 可逆性がなくなった •
しかし...!
ハッシュ化して保存 • 単にハッシュ化して保存するだけではダメ – 同じパスワードからは同じハッシュ値が生成される • レインボーテーブルを使用したクラック – 事前にパスワード:ハッシュ値のデータを容易して おく(レインボーテーブル)
余談 • MD5 Collision – http://www.mscs.dal.ca/~selinger/md5collisio n/ – 異なるファイルでもMD5ハッシュ値が同じ •
SHA1でもMD5ほどではないが、衝突の危険性 がある
パスワード保存の要件 • DBパスワードを保存する際には以下の要件を 必ず満たす必要がある – 管理者でもユーザーのパスワードを復元できない – 同一パスワードから同一ハッシュ値を生成しない – 十分にストレッチングを行う
Case4 • ハッシュ + ソルトを使用 +------+--------+--------------------------------+ | id | name
| password | |------+--------+--------------------------------| | 1 | admin | $1$salt$qJH7.N4xYta3aEG/dfqo/0 | +------+--------+--------------------------------+
ハッシュ+ソルト • 16byte以上のソルトを使用すること • ランダムなソルトを使用 – random()は使わない – CryptAPIとか/dev/urandomとか •
これで同じパスワードから同じハッシュ値が生 成される問題はなくなった • だいぶ堅牢になったぞ!!!!!
ストレッチング • ハッシュ + ソルトな方式を使用することで かなり堅牢になった • しかし、まだだ!!! • 最新GPUを大量に積めば一瞬で大量のSHA-
256 Hashを計算することも可能 – 最近ではAWSに金をつぎ込むことでも可能! • 現実的に計算できないようにするためにスト レッチングを行う
ストレッチング • ハッシュの計算を何回も繰り返す • PBKDF2, bcryptなどの使用が推奨 – 独自で実装をしてはいけない – 確かNISTが資料を出していたはず(要出典)
PBKDF2 • KDF(Key Derivation Function) – 鍵導出関数 – 固定長で一定のエントロピーを持つより安全な鍵を 得ることが可能
– パラメータに繰り返し回数があり、計算量を調整で きる • PBKDF2はRFC2898に基づたKDF
PBKDF2 • DK = PBKDF2(PRF, Password, Salt, c, dkLen) –
PRF : 疑似乱数生成関数. HMAC – Password : パスワード – Salt : ソルト – C : 繰り返す回数 – DkLen : 出力する導出鍵の長さ
HMAC • MAC(Message Authentication Code)の1つ – 共通鍵を用いて固定長のメッセージを出力する – 改竄検知に使用
MD(Message Digest) • 所謂、一方向ハッシュ関数 – 任意のメッセージから固定長メッセージを生成 – admin → 5f4dcc3b5aa765d61d8327deb882cf99
• 異なるメッセージから同一のハッシュ値を生成 することが困難でなければいけない • ちなみにCRC32のような誤り検出符号は暗号 的ハッシュ関数とは区別される
MDとMAC • MD ... メッセージを容易に計算できる • MAC … 共通鍵がなければ計算できない •
共通鍵なので否認を防止することができない • つまり、メッセージを生成したものが本人であ るという保証はされない
HMAC • ハッシュ関数 + MAC • すべてのハッシュ関数に適用可能 – それぞれHMAC-MD5とかHMAC-SHA1とか •
他にもCBC-MACなどもある – ブロック暗号アルゴリズムと組み合わせる方式 – OMAC/CMAC, PMAC
PBKDF2 • DK = PBKDF2(PRF, Password, Salt, c, dkLen) –
PRF : 疑似乱数生成関数. HMAC – Password : パスワード – Salt : ソルト – C : 繰り返す回数 – DkLen : 出力する導出鍵の長さ • で、何回繰り返せばいい???
Djangoの実装を見てみる • Djangoでは標準で、ユーザーのパスワードを PBKDF2で保存している from django.contrib.auth.models import User user =
User(username="user") user.set_password('password') user.password 'pbkdf2_sha256$24000$NPCTHzvjHgPo$phHqNmNOafrNsxYXZm2HNpPBXzqBVijvakAFVkR HbZs='
Djangoでの実装 user.password.split('$') ['pbkdf2_sha256', '24000', 'NPCTHzvjHgPo', # salt 'phHqNmNOafrNsxYXZm2HNpPBXzqBVijvakAFVkRHbZs='] • PBKDF2
+ HMAC + SHA256で24000回繰り返している
ちなみに • 最新Ver(1.10)では24000回だったが... • マシンの性能の向上に伴って計算回数も増えて いっている Ver 回数 1.9 2015.12
24000 1.8 2015.01 20000 1.7 2014.02 15000 1.6 2013.06 12000 1.5 2013.02 10000
計算速度の問題 • 結構な回数を計算していることがわかったが... • 非常に長いパスワードを計算すると、かなり時 間がかかるのでは?
計測してみた • i5-2520M 2.50GHz – 64文字と10000000文字(10MB)で試す from timeit import timeit
setup = ''' from django.contrib.auth.hashers import PBKDF2PasswordHasher hasher = PBKDF2PasswordHasher() password = "A" * 10000000 salt = "salt" ''' result = timeit(stmt = 'hasher.encode(password = password, salt = salt, iterations = 24000)', setup=setup, number=500) print(result)
計測してみた • 64文字のとき…11.665050101000816 • 10MBのとき… 32.772370806000254 • という感じなので、Djangoでは4098文字制限 がある –
https://www.djangoproject.com/weblog/2013/ sep/15/security/
まとめ • パスワードを保存する際には以下の要件を必ず満たす 必要がある – 管理者でもユーザーのパスワードを復元できない – 同一パスワードから同一ハッシュ値を生成しない • 具体的には
– 疑似乱数発生関数である程度の長さのソルトを使ってハッ シュ値を生成する – KDFで十分な回数繰り返す • WAFでは標準で実装されていたり、ライブラリも充実 しているので積極的に頼っていくべき
感想と疑問 • マシンの性能を考えてストレッチングの回数を 増減したほうが良さそう • マシンやGPUの性能向上に伴って使用するアル ゴリズムやストレッチングの回数を変更してい なければならない • 変更するときにどうすればいいのか
– ログイン時に再生成? – 緊急のときはアカウント停止?