Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

david19's avatar

Laravel Encrypt is not safe

Hello Team. I will create my own password manager with laravel. For store passwords, you can use the laravel encrypt cast in the model.

protected $casts = [
'password' => 'encrypt',
];

The problem with this is, this will use your APP_KEY in the .env file. But the Hosting Provider can see your .env file. I think this is not safe.

I found some posts, there show you can use:

php artisan env:encrypt

But i had not tested yet.

I think the best way for store passwords in the database, is use the login password. But i can not save the login passwort in the session. Have you more ideas for this problem? Yes, the APP_KEY is very long and secure, but the Hosting Provider can read your .env file.

0 likes
7 replies
LaryAI's avatar
Level 58

Hello,

You're correct in noting that Laravel's encryption uses the APP_KEY from the .env file, and if your hosting provider or anyone with access to your server environment can read this file, they could potentially decrypt your data.

The php artisan env:encrypt command you mentioned is not a native Laravel command, so it might be from a package or a custom command someone created. It's not a standard solution for encrypting environment files.

For a password manager, you would ideally want to use a user-specific key to encrypt passwords so that even if someone has access to your APP_KEY, they still can't decrypt the passwords without the user's key. Here's a strategy you could consider:

  1. User-Specific Encryption Key: When a user creates an account, generate a strong encryption key for that user. This key should be unique to the user and used to encrypt and decrypt their passwords.

  2. Secure Key Storage: Store this key in a way that even you, as the application owner, cannot access it. One common approach is to encrypt this key with the user's login password. Since the login password is not stored on the server (only a hashed version is), this means that the key can only be decrypted when the user enters their password.

  3. Encrypt/Decrypt on Login: When the user logs in, decrypt their user-specific key using their login password, and store it in the session securely. Use this key to encrypt and decrypt their passwords during their session. When the session ends, the decrypted key is gone from memory.

Here's a simplified example of how you might implement this:

// When creating a new user
$userKey = generateUserKey(); // Implement this function to generate a secure key
$encryptedUserKey = encryptWithUserPassword($userKey, $userPassword); // Implement this function
$user->encrypted_key = $encryptedUserKey;
$user->save();

// When the user logs in
$decryptedUserKey = decryptWithUserPassword($user->encrypted_key, $inputPassword); // Implement this function
session(['user_key' => $decryptedUserKey]);

// When encrypting a password for storage
$encryptedPassword = encryptWithUserKey($password, session('user_key')); // Implement this function
// Store $encryptedPassword in the database

// When decrypting a password to show to the user
$decryptedPassword = decryptWithUserKey($encryptedPassword, session('user_key')); // Implement this function
// Use $decryptedPassword as needed

Remember, this approach means that if a user forgets their password, their encrypted data cannot be recovered because their user-specific key cannot be decrypted. You'll need to have a clear policy and user understanding of this.

Also, be aware that storing sensitive information like user keys in the session has its own security implications. You should ensure that your session storage is secure and that you're using HTTPS to prevent session hijacking.

Lastly, always keep your application and its dependencies up to date to protect against known vulnerabilities, and consider additional security measures such as two-factor authentication (2FA) for user accounts.

Please note that building a secure password manager is a complex task that involves a deep understanding of cryptography and security practices. If you're not experienced in these areas, it's highly recommended to use existing, well-tested solutions or consult with a security expert.

martinbean's avatar

I think the best way for store passwords in the database, is use the login password.

@david19 And what happens when someone changes their password?

1 like
david19's avatar

@martinbean Change password should disabled. I know this is not the best idea, but the app_key is not hidden for the hosting provider. AWS, Or Hetzner or digitalocean can see your app_key.

martinbean's avatar

@david19 So you’re worried about security, but then you’re then going to create a password manager where the passwords are encrypted with the users’ passwords and those users can’t change their passwords…?

Security is not something to play around with. If you’re not an expert, don’t try and re-invent the wheel. You will make mistakes, and those mistakes can be costly when dealing with something as sensitive as passwords and credentials on behalf of users. Use an established solution such as LastPay or iCloud Keychain.

Why should someone trust your password manager hosted on some shared hosting account, instead of one of the solutions mentioned above that does let you change your password, and also employs full-time experts in cryptography?

3 likes
jlrdw's avatar

@david19 you should be at least using bcrypt. And following the laravel documentation.

I agree that security should not be played around with but be done correctly is my suggestion and opinion.

nexxai's avatar

Ok, instead of the FUD that's being spread here, yes, if your encryption key is in your .env file, anyone (including your hosting provider) can read it and decrypt anything that's been encrypted with it.

This is the security tradeoff you accept for not having full ownership over your computing environment. If you don't have full control over it, someone else does. By using these services, you are explicitly agreeing to that fact.

That said, there are PLENTY of solutions out there that allow you to safely store secret material inside an HSM (hardware security module; aka "TPM") and simply load it into memory as needed (which again, can be read by your hosting provider).

A few options (not exhaustive):

  • Azure Key Vault
  • AWS Secrets Manager
  • Hashicorp Vault
wpnathan's avatar

If you're concerned about a hosting company having access to the key, it would suggest that this is something you're planning to deploy rather than a fun experiment.

I'd urge you to reconsider.

Take a look at 1Password's security whitepaper if you're curious about the complexity involved in building a secure password manager.

This isn't a simple project. I'm not intending to be condescending, I've been a developer for 13 years and I wouldn't feel remotely comfortable working on a project like this. It requires highly specialised expertise which the overwhelming majority of us simply don't have.

1 like

Please or to participate in this conversation.