Securely storing passwords in cloud

Question

I'd like to develop a password manager. I am unsure about the safest way to store the data in the cloud.

Credentials (usernames, passwords, login links) will be stored in a MySQL server. I'm planning to store credentials for each site in its own row. This data will be encrypted using the built in methods in Laravel: https://laravel.com/docs/5.5/encryption (AES-256-CBC)

The data needs to be synced between devices, and should not be accessable without decryption from the client (just like a LastPass vault is not decrypt-able by LastPass themselves).

The data needs to be decrypted when it is delivered to the device.

Before I go too far down this path, I'd like to know if someone could give me some feedback of this method, and if using the native encrypt/decrypt methods (https://laravel.com/docs/5.5/encryption) is safe enough compared to e.g. PBKDF2 SHA-256

Answer 1

This is not going to work. According to the docs you have to set the key in the php config. That means all users will have the same key and that key would also be stored on the server. That is not what you want.

Answer 2

I understand you want to put something safely stored into a database. You also do not want it to be decryptable by someone getting ahold of the database.

This first and foremost means: You cannot store the key on the same server as the database. But it has other implications. If you are using the inbuilt laravel helper function encrypt() it actually means that the server uses the same password (secret) to encrypt all of the data you feed it. So if you have two customers they will have the same secret key and thus someone who got ahold of the key will be able to decrypt the whole database.

Second: Laravel stored the key typically in the /.env file in laravels root dir on the server. That means: if someone can access the servers files (and even worse if the sql db is on the same server) - the encryption is useless.

What to do? There are multiple ways around it. My preferred option is to use asymetric encryption using OpenPGP. There already is some proper implementation you can use and even a very good reference project wich i encourage you to have a look at: Pass

The data needs to be synced between devices, and should not be accessable without decryption from the client (just like a LastPass vault is not decrypt-able by LastPass themselves).

That is something you can achieve in several ways. But afaik there is no way around storing (at least) the decryption keys on the client (and on the client only) and thus only transfer encrypted from the client to whatever server or "cloud" you will eventually decide on using. The encryption and decryption must be done on the client then.

If you decide on having a webapplication there probably is some way in doing this using JavaScript and storing a secret in the browser but I don't really have a good working example atm.

If you stick to Public/Private keypairs you might as well use the public key to encrypt information from everywhere but only decrypt it on the client (where the private key is stored). Remember though: If some plaintext information is processed on the server it can be caught by someone who as access to it before encryption.

I hope that answers your question at least roughly.

Answer 3

Why the need to use laravel's encryption? As Elias says (+1 Elias) if you rtfm the key is stored in a file on the server, nullifying the benefit of encrypting the data.

Laravel's functions are a thin wrapper around the openssl extension in php. There's lots of docs on the internet on how to use it.

It is really important to decide whether passwords will be shared between users. If that will ever be the case, then you need to look at asymmetric encryption (with users public keys on the server).

Ideally you would decrypt at the client. Unless you use a thick client (rather than a browser) with the decryption keys held in a file, then, if your server is compromised it can serve up javascript to read back the decrypted data / keys. To some extent this could be mitigated by packaging and deploying an html5 application to the local filesystem (not loading it from the server) and making [a|s]jax calls out for the data, but I for one would want to test such a configuration extensively.