【要約】Railsで学ぶ 暗号化とハッシュ 〜master.keyやDeviseは内部で何をしている？〜 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
Rails開発者が、暗号化とハッシュの概念を混同することで、重大なセキュリティ事故を招くリスクがある。適切なアルゴリズムを選択できない場合、以下のような問題が発生する。
- ・パスワードを高速なSHAで保存し、総当たり攻撃を許す。
- ・復号が必要なデータに対し、復号不可能なハッシュを使用する。
- ・対称鍵のみの運用により、鍵の安全な配送（鍵配送問題）に失敗する。
// Approach
データの可逆性と用途に基づき、暗号化とハッシュを明確に使い分ける手法を提示する。用途に応じて以下の技術を適切に選択する。
- ・暗号化（AES/RSA）: 秘密の保持と復号を目的とする。大量データには高速なAESを用い、鍵の受け渡しには非対称鍵のRSAを用いるハイブリッド方式が定石である。
- ・ハッシュ（SHA/bcrypt）: 同一性確認やパスワード保存を目的とする。改ざん検知には高速なSHAを用い、パスワードには攻撃耐性の高いbcryptを用いる。
- ・bcryptの活用: 計算コスト（コストファクタ）を意図的に上げ、ソルトを付与することで、総当たり攻撃やレインボーテーブル攻撃を防ぐ。
// Result
開発者がRailsの標準機能の内部挙動を正しく理解し、適切な設計を選択できるようになる。具体的には以下の対応関係が明確化される。
- ・credentials.yml.enc: AES-128-GCMによる暗号化。
- ・Devise: bcryptによるハッシュ化（encrypted_password）。
- ・cookies.signed: HMAC-SHAによる改ざん検知。
- ・cookies.encrypted: AES-256-GCMによる暗号化。
Senior Engineer Insight
> 暗号化とハッシュの混同は、設計ミスから致命的な脆弱性を生む。bcryptのコストファクタ調整は、計算資源の進化に合わせた運用設計として重要だ。Railsの抽象化に依存せず、内部のアルゴリズムを把握せよ。自前実装を避け、OpenSSLやbcryptなどの枯れたライブラリを活用する原則を徹底すべきである。