Laravel 中的 App_KEY 到底有什么用?

每次 Laravel 开发人员新建或克隆 Laravel 应用时,生成 application keyAPP_KEY 是最重要的初始步骤之一。

最近的 Laravel 安全更新修复了一个 APP_KEY 用途相关的漏洞。为了利用此漏洞,首先需要有权访问生产版 APP_KEY。解决此漏洞最简单的方法是转换(更改)您的 APP_KEY。这导致我们中的一些人提出了一个问题:应用程序密钥有什么作用?更改涉及什么?管理 Laravel 应用程序中的这些密钥的最佳实践是什么?

在这篇文章中,我们将讨论 APP_KEY 做和不做的事情,关于它与用户密码哈希的关系的一些常见误解,以及安全地更改 APP_KEY 的简单步骤而不会丢失对您数据的访问权限。

Laravel 安全修复

8月初,Laravel 5.5 和 5.6 收到了与 Cookie 序列化和加密有关的安全修复程序。一方面,修复很简单,大多数应用程序可能没有受到影响。另一方面,这是一个严重的安全风险,表明我们的社区需要更好地了解 APP_KEY 的工作方式。

要利用此安全漏洞,需要有人知道您的 APP_KEY,这就是为什么我要带您详细了解您的密钥,为什么重要以及如何更改它的原因。

有关安全修补程序的信息,请参阅以下资源:

什么是 APP_KEY

应用程序密钥是一个32位字符的随机字符串,存储在 .env 文件中的 APP_KEY 密钥中。 Laravel 安装程序会自动为您生成一个,因此您只会在克隆现成应用程序时注意到它的缺失。

您之前可能看到过此错误:

RuntimeException

要创建新密钥,您可以自己生成一个密钥并将其粘贴到您的 .env 中,或者可以运行 php artisan key:generate 让 Laravel 为您创建并自动插入一个密钥。

应用程序运行后,便会在一个地方使用 APP_KEY:cookie。Laravel 将密钥用于所有加密的 cookie (包括会话 cookie),然后再将其交给用户浏览器,并使用它解密从浏览器读取的 cookie。这样可以防止客户端更改其 cookie 并为其授予管理员特权或模拟应用程序中的其他用户。加密的 cookie 是 Laravel 中的重要安全特性。

所有这些加密和解密操作均由Laravel通过 Encrypter 使用 PHP 内置的安全工具处理,包括 OpenSSL。我们不会在这里仔细研究加密的工作原理,但是如果您想了解更多信息,我鼓励您阅读更多关于 PHP implementation of OpenSSLopenssl_encrypt function.

关于密码哈希的常见误解

在 Laravel 社区中,包括我自己直到最近,一个非常普遍的误解是任务 APP_KEY 用于登录密码的加密。幸运的是,事实并非如此!我觉得这导致许多人认为 APP_KEY 是不可更改,除非重置所有用户的登录。

密码并非被加密,而是被 哈希散列.

Laravel 的密码使用 Hash::make()bcrypt() 进行哈希处理,但都不使用 APP_KEY。让我们看一下 Laravel 中的加密和哈希。

加密与散列

Laravel 中有两个主要的 facades:Crypt (对称加密) 和 Hash (单向哈希加密)。密码被 哈希散列,而 cookies 被(可选) 加密。让我们看一下差异。

对称加密

假设我想向我的朋友亚瑟 (Arthur) 发送一个秘密消息。上一次我们在一起时,我们俩一致确定了一个秘钥:

$key = "dont-panic";

我想给他发一条短消息,只有该密钥才能解密。我将使用我最喜欢的行业标准的开源加密函数 openssl_encrypt() (Laravel的 Crypt 使用的就是这个)再加上我俩共同的 $key 进行文本加密的字符串发送给他:

$message = "So long and thanks for all the fish";
$key = "dont-panic";
$cipher = "AES-256-CBC";
echo openssl_encrypt($message, $cipher, $key);

// JJEK8L4G3BCfY0evXDRxUke2zqAzq6i7wL/Px4SjaEHXqt3x7hsj4+PhVQaH4ujX

我可以用任何方式将这个字符串发送给亚瑟;由于我们是仅有的两个拥有私钥的人,因此我不担心其他人会阅读该消息。

fake tweet with encrypted string

当 Arthur 收到时,他将使用我们的私钥解密此过程。这是其中的 对称 部分:我们能够加密和解密而不会丢失信息。

$secret = "JJEK8L4G3BCfY0evXDRxUke2zqAzq6i7wL/Px4SjaEHXqt3x7hsj4+PhVQaH4ujX";
$key = "dont-panic";
$cipher = "AES-256-CBC";
echo openssl_decrypt($secret, $cipher, $key);

// So long and thanks for all the fish

Laravel 使用 APP_KEY 作为加密密钥,对发送者和接收者的 cookie 使用相同的方法。使用相同的应用程序密钥对响应 cookie 进行加密,发送给用户,在接下来的请求中进行读取和解密。

单向哈希

我们的对称加密示例具有很多潜在的用途,但是所有这些都涉及最终需要解密被加密的消息。

但是,当涉及到诸如用户密码之类的东西时,您永远都不应有解密它们的方法。

这意味着我们的 Crypt 方法将无法使用,因此无法基于我们拥有的密钥。相反,我们需要一个 hashing 函数,它应该是:

  1. 快速: 计算机应该能够快速生成哈希
  2. 确定性: 散列相同的输入总是给出相同的输出
  3. 随机性: 更改输入的单个字母应会彻底更改输出
  4. 唯一: 冲突率(将不同的输入散列到相同的输出)应该很小
  5. 难以暴力破解: 应该很难对所有可能的输入进行散列以猜测我们的原始输入

您可能已经熟悉许多单向哈希算法:MD5 和 SHA-1 可以快速计算,但不是最安全的(它们在上述第 4 和第 5 项上较弱)。

Laravel 散列实现了原生 PHP 的 password_hash() 函数,默认为一种称为 bcrypt 的散列算法。对于单向哈希来说,这是一个很好的默认值,您不需要更改它(尽管 Laravel 现在也提供了 一些其他 哈希方法。)

use Illuminate\Support\Facades\Hash;

$password = "dont-panic";
echo Hash::make($password);

// $2y$10$hEEF0lv4spxnvw5O4XyLZ.QjCE1tCu8HjMpWhmCS89J0EcSW0XELu

如果您曾经查看过 users 表,则可能看起来很熟悉。这是什么意思:

  • $2y$ 使用 blowfish 算法进行哈希散列 (bcrypt)
  • 10$ “成本”因素(越高意味着要花更长的时间进行哈希)
  • hEEF0lv4spxnvw5O4XyLZ. 22位字符的 “salt”
  • QjCE1tCu8HjMpWhmCS89J0EcSW0XELu 哈希输出

由于这是单向哈希,因此我们 无法 对其进行解密。我们所能做的就是对它进行测试。

当使用此密码的用户尝试登录时,Laravel 会对其密码输入进行哈希处理,并使用 PHP 的 password_verify() 函数将新哈希与数据库哈希进行比较:

use Illuminate\Support\Facades\Hash;

$input = request()->get('password'); // "dont-panic"
$hash = '$2y$10$hEEF0lv4spxnvw5O4XyLZ.QjCE1tCu8HjMpWhmCS89J0EcSW0XELu';
return Hash::check($input, $hash);

// 正确

您会注意到,只有在需要对称(可逆)加密时,Laravel 才需要一个密钥 (APP_KEY)。用户密码的存储永远不可逆,因此完全不需要 APP_KEY

但这并不意味着您的密钥应该被粗心对待。相反,请像对待其他任何生产凭证一样对待它:使用与 MySQL 密码或 MailChimp API 密钥相同的注意和安全性。

更改密钥

任何良好的凭证管理策略都应包括 轮换: 定期(例如每6个月)或在特定情况下(例如员工离职)更改密钥和密码。

幸运的是,您只需要记住一些事情,就可以轮换你的 APP_KEY

多台服务器

如果您从多台服务器提供相同的应用程序,则需要更新每台服务器上的密钥。

现有用户的 sessions (cookies)

更改 APP_KEY 后,当前登录到您的应用程序的所有用户的会话均将失效。在最佳时间安排您的密钥轮换,以最大程度地减少给用户带来的不便。

您已加密的其他数据

尽管 cookie 的安全性是 Laravel 唯一使用 APP_KEY 作为框架的地方,但是您的应用程序中可能会包含用于加密数据的自定义代码。如果您使用 Laravel 的加密功能,请制定并测试一个计划,以使用旧密钥解密该数据,然后使用新密钥重新加密。

设置新的APP_KEY

首先,将现有的 APP_KEY 复制到其他地方,以防万一更改密钥会产生意外的副作用。

在尝试在生产服务器上轮换 APP_KEY 之前,请尝试在本地计算机上轮换 APP_KEY,以确保一切顺利。准备好后,运行 php artisan key:generate

[jbathman my_app]# php artisan key:generate
**************************************
*     Application In Production!     *
**************************************

Do you really wish to run this command? (yes/no) [no]:
> yes

Application key [base64:x2SHH01+2R+vwv09YcrvXqdFJ+bbqgT9gW4njcYLjDE=] set successfully.

就是这样!如果要生成密钥而不修改您的 .env 文件,请包含 --show 标志:

[jbathman ~/my_app]# php artisan key:generate --show
base64:c3SzeMQZZHPT+eLQH6BnpDhw/uKH2N5zgM2x2a8qpcA=

要点

  • 更改APP_KEY不会影响用户密码
  • 如果您更改APP_KEY,会导致 session (通过 cookie 实现)无效,所有当前用户被注销
  • 不要害怕您的 APP_KEY
  • 您应该有一个策略来定期轮换 APP_KEY 以及其他凭据和密钥
  • 如果您的代码已手动使用 Laravel 的加密器,则需要制定计划以使用旧密钥解密其加密数据,然后使用新密钥重新加密。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://tighten.co/blog/app-key-and-you

译文地址:https://learnku.com/laravel/t/41250

本帖已被设为精华帖!
本文为协同翻译文章,如您发现瑕疵请点击「改进」按钮提交优化建议
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!