On the Tighten.co blog there's a tutorial posted from Jake Bathman for the Laravel users out there covering the APP_KEY value - what it is and how its used in your application.
A recent Laravel security update fixed an issue with how APP_KEY is used. For someone to exploit this issue, they'd need to have access to the production APP_KEY. The simplest fix for the exploit is to rotate (change) your APP_KEY. That led some of us at Tighten to ask the question: What does the app key do? What is involved in rotating it? What are best practices for managing these keys for our Laravel applications?
In this post, we'll talk about what APP_KEY does and doesn't do, some common misconceptions about its relationship to user password hashing, and the simple steps to changing your APP_KEY safely without losing access to your data.
Before diving in too deep, he reminds the reader about a security release Laravel recently made to correct an issue with
APP_KEY handling (and the recommendation to rotate it). It then moves on to talk about what the setting is, how to generate a new one and its use in cookies. It also tries to dispel myths around:
- its use for password hashing (it's not)
- where it is used for encryption
- rotating the key
- multi-server use
It also makes a recommendation of the process to use for currently encrypted data that was created using the previous
APP_KEY value and how to re-encrypt.