Let's talk about the role of App_KEY in Laravel-Laravel-php.cn

What is the use of App_KEY in Laravel? The following article will introduce to you the role of App_KEY. I hope it will be helpful to you!

Let's talk about the role of App_KEY in Laravel

Every time a Laravel developer creates or clones a Laravel application, generating the application key or APP_KEY is the most important initial step one.

The latest Laravel security update fixes a APP_KEY usage-related vulnerability. In order to exploit this vulnerability, you first need to have access to the production version APP_KEY. The easiest way to resolve this vulnerability is to convert (change) your APP_KEY. This has led some of us to ask the question: What does an application key do? What does the change involve? What are the best practices for managing these keys in a Laravel application?

In this post, we'll discuss the APP_KEY dos and don'ts, some common misconceptions about how it relates to user password hashes, and changing securely APP_KEY without losing access to your data.

Laravel Security Fixes

In early August, Laravel 5.5 and 5.6 received security fixes related to cookie serialization and encryption. On the one hand, the fix is simple and most applications are probably not affected. On the other hand, this is a serious security risk and demonstrates the need for our community to better understand how APP_KEY works.

To exploit this security hole, someone needs to know your APP_KEY, which is why I'm going to walk you through the details of your key, why it matters, and how to change it.

For information about security fixes, see the following resources:

Security Update (5.6.30) Release Notes: https://learnku.com/docs/ laravel/5.6/upgrade#upgra...
Security Update (5.5.42) Release Notes: https://learnku.com/docs/laravel/5.5/upgrade#upgra. ..

What is `APP_KEY`?

The application key is a 32-bit random string stored in the APP_KEY key in the .env file. The Laravel installer automatically generates one for you, so you'll only notice its absence when cloning the ready-made application.

You may have seen this error before:

Lets talk about the role of App_KEY in Laravel

To create a new key, you can generate one yourself and paste it into your .env, or you can run php artisan key:generate to have Laravel create and automatically insert a key for you.

After the application runs, it will use APP_KEY in one place: cookie. Laravel uses the key for all encrypted cookies (including session cookies) before giving it to the user's browser, and uses it to decrypt cookies read from the browser. This prevents clients from changing their cookies and granting them administrator privileges or impersonating other users in the application. Encrypted cookies are an important security feature in Laravel.

All these encryption and decryption operations are handled by Laravel through Encrypter using PHP's built-in security tools, including OpenSSL. We won't take a closer look at how encryption works here, but if you want to learn more, I encourage you to read more about PHP implementation of OpenSSL and openssl_encrypt function.

Common Misconceptions About Password Hashing

In the Laravel Community , including myself until recently, a very common misunderstanding is that task APP_KEY is used for encryption of login passwords. Fortunately, this is not the case! I think this leads many people to believe that APP_KEY is unchangeable unless all user logins are reset.

The password is not encrypted, but hashed.

Laravel password usageHash::make() or bcrypt() for hashing, but neither uses APP_KEY. Let's take a look at encryption and hashing in Laravel.

##Encryption and Hashing

There are two main facades in Laravel:

Crypt (symmetric encryption) andHash (One-way hash encryption). Passwords are hashed, and cookies are (optionally) encrypted. Let's look at the differences.

对称加密

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

$key = "dont-panic";

Copy after login

我想给他发一条短消息，只有该密钥才能解密。我将使用我最喜欢的行业标准的开源加密函数 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

Copy after login

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

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

Copy after login

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

单向哈希

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

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

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

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

您可能已经熟悉许多单向哈希算法：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

Copy after login

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

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

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

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

use Illuminate\Support\Facades\Hash;

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

// 正确

Copy after login

您会注意到，只有在需要对称(可逆)加密时，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.

Copy after login

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

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

Copy after login

要点

更改APP_KEY不会影响用户密码
如果您更改APP_KEY，会导致 session (通过 cookie 实现)无效，所有当前用户被注销
不要害怕您的 APP_KEY
您应该有一个策略来定期轮换 APP_KEY 以及其他凭据和密钥
如果您的代码已手动使用 Laravel 的加密器，则需要制定计划以使用旧密钥解密其加密数据，然后使用新密钥重新加密。

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

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

【相关推荐：laravel视频教程】

The above is the detailed content of Let's talk about the role of App_KEY in Laravel. For more information, please follow other related articles on the PHP Chinese website!