【要約】古の時代、我々はどうやってセッション ID を生成していたのか [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
Web黎明期の開発者が、ステートレスなHTTPにおいてセッション管理を実現しようとした際に直面した課題である。
- ・Cookie導入に伴い、一意かつ予測不可能なセッションIDが必要となった。
- ・当時は
/dev/urandomや CSPRNG が未実装で、信頼できる乱数生成手段が欠如していた。 - ・メモリ制約が厳しく、エントロピー確保のためのデータ保持が困難であった。
// Approach
開発者は、実行のたびに値が変化する外部情報を「種（seed）」として利用する手法を採用した。
- ・
uptime、ps、netstatなどのコマンド実行結果を取得した。 - ・Webサーバのアクセスログのファイルサイズや更新日時をエントロピー源とした。
- ・得られた文字列を
md5でハッシュ化し、それらを連結して再度md5を計算した。 - ・MD5の128ビットという短さを補うため、末尾に
unix timeを付与した。
// Result
当時の開発者は、擬似的な予測不可能性を確保することに成功したが、現代の基準では極めて脆弱である。
- ・MD5の衝突耐性の欠如により、セッションハイジャックのリスクが残る。
- ・Unix timeの付与は予測が容易であり、セキュリティ強化として機能していない。
- ・現代では、OSのCSPRNGを利用したWebフレームワーク標準の機能を使うことが正解である。
Senior Engineer Insight
> 現代のエンジニアが学ぶべきは、技術の「進化」ではなく「負債の回避」である。この記事の手法は、リソース制約下での苦肉の策だが、セキュリティとパフォーマンスの両面で致命的だ。外部コマンドの呼び出しはシステムコールを多用し、高トラフィック環境ではボトルネックとなる。また、
shell=True を用いた実装はコマンドインジェクションの温床だ。常に「標準ライブラリやフレームワークの枯れた実装」を選択し、独自の暗号学的実装を避けるべきである。