In the case that your
APP_KEY is exposed, you MUST update it.
APP_KEY is NOT used for password hashing for user logins, but it is used for:
- Encrypting cookies (which Snipe-IT uses for sessions)
- Creating the signature for signed URLs and queued closures (which Snipe-IT does not use)
- Encrypting values using the
decrypt()helpers, which Snipe-IT does use in encrypted custom fields (if you use those) and also in storing your LDAP password in your admin settings (if you use LDAP syncing).
If you do not rotate your
APP_KEY after it's been leaked, you can make yourself vulnerable to session replay attacks.
Fortunately, we make rotating your key really easy to do in Snipe-IT:
php artisan snipeit:rotate-key
You can see how straightforward that script is (if you can read any PHP) by visiting the source code here.
It basically just generates a new key, decrypts your old data, updates your
APP_KEY with the newly generated one, and recrypts the previously encrypted data with the new key.
Simply changing your
APP_KEYwithout running the above key rotation script can result in data loss if you have data such as encrypted custom fields or your stored LDAP Bind User password. This data cannot be recovered without the original key.
If you have neither encrypted custom fields nor a stored LDAP password, you can simply run
php artisan key:generateand generate a new key, but we STRONGLY recommend backing up your database and your
.envbefore doing so, just in case there's an encrypted field you weren't aware of.
For more info on how Laravel's
APP_KEY works, see this great piece by Mohamed Said, one of the developers of the Laravel framework.
Updated 4 months ago