app key and laravel

Published on Jun 24, 2024

When starting or cloning a Laravel app, generating the application key (APP_KEY) is a crucial step. A recent Laravel security update addressed an issue with how the APP_KEY is used. To prevent potential exploitation, the easiest solution is to rotate the APP_KEY.

But what exactly does the APP_KEY do, and how can you manage it safely? This post will cover the purpose of the APP_KEY, clarify any misunderstandings about its role in password hashing, and provide simple steps for safely changing it without losing access to your data.

What's APP_KEY?

The application key is a randomly generated 32-character string stored in the APP_KEY key in your .env file. If you clone an existing app, you'll need to generate a new key. You can do this manually or use Laravel's key:generate command.

The APP_KEY is primarily used for encrypting cookies, including the session cookie, to prevent unauthorized access or impersonation. Laravel's Encrypter uses PHP's built-in security tools like OpenSSL for encryption and decryption. While we won't delve into the technical details of encryption, you can learn more about OpenSSL and the openssl_encrypt function in PHP.

Common misconceptions

A common misconception in the Laravel community is that the APP_KEY is used for password hashing, but this is not the case. Passwords are actually hashed using Laravel's Hash::make() or bcrypt() functions, neither of which require the APP_KEY. It's important to understand the difference between encryption and hashing in Laravel.

Encrypting vs. Hashing

In Laravel, there are two primary cryptographic facades: Crypt (used for symmetric encryption) and Hash (used for one-way cryptographic hashing). Passwords are hashed using Laravel's Hash facade, while cookies can be encrypted using Crypt. Let's examine the distinctions between these two cryptographic techniques.

Symmetric Encryption

Symmetric encryption is a cryptographic technique where the same secret key is used to both encrypt and decrypt data. This means that anyone with access to the key can read and write the encrypted information. In Laravel, symmetric encryption can be implemented using the Crypt facade. Here's an example of how to encrypt and decrypt data using the AES-256-CBC algorithm with a randomly generated key: 

        
    use Illuminate\Support\Facades\Crypt;

    // Generate a random key
    $key = base64_decode(env('APP_KEY'));
    
    // Encrypt a message
    $encrypted = Crypt::encryptString('Hello, world!', $key);
    
    // Decrypt the message
    $decrypted = Crypt::decryptString($encrypted, $key);
    
    echo $decrypted; // Output: Hello, world!
In this example, we first decode the Laravel application key stored in the .env file. We then use the encryptString method of the Crypt facade to encrypt the message "Hello, world!" using the generated key. Finally, we use the decryptString method to decrypt the encrypted message using the same key, and output the result.

One-Way Hash

One-way hash is a cryptographic technique where a fixed-length value (the hash) is generated from an arbitrary-length input data. The hash function is designed so that it is easy to compute the hash value from the input, but it is infeasible to generate the original input data from the hash value. In Laravel, one-way hash can be implemented using the Hash facade. Here's an example of how to hash a password using the bcrypt algorithm:

Keep in mind

When rotating the Laravel APP_KEY, there are several precautions and side effects to consider. Here are a few:

  • Data loss: Rotating the APP_KEY could result in data loss if you're not careful. For example, if you have encrypted data that was encrypted using the old APP_KEY, it won't be readable with the new APP_KEY. To avoid data loss, make sure to decrypt any sensitive data before rotating the key.
  • Impacted services: Rotating the APP_KEY could impact any services that use the old key, such as session data, cache data, and encrypted cookies. Make sure to update any services that use the APP_KEY to use the new key.
  • User impact: Rotating the APP_KEY could impact your users if they are logged in or have persistent sessions. If you're not careful, they could be logged out or lose their session data. To avoid this, make sure to gracefully handle any active sessions or logged-in users during the rotation process.
  • Application downtime: Rotating the APP_KEY could result in application downtime if not done correctly. Make sure to plan for this and communicate any expected downtime to your users.
  • To minimize these risks, it's important to have a backup plan in case something goes wrong during the rotation process. This could include taking a backup of your data before the rotation, having a rollback plan in case something goes wrong, and communicating any changes to your users well in advance.
← Go back