Make a more secure six-digit pin system on the back

I'm developing a password manager which has two forms of authentication.

First the user logs in using their password. I have this working securely using bcrypt.

The next part is far more tricky. The user's saved services are stored in a JSON format like so:

{ "name":"facebook", "login":"<a href="/cdn-cgi/l/email-protection" data-cfemail="513c28343c30383d11343c30383d7f323e3c">[email protected]</a>", "signup-email":"<a href="/cdn-cgi/l/email-protection" data-cfemail="076a7e626a666e6b47626a666e6b2964686a">[email protected]</a>", "password":"121654754321", "notes":"my security questions answer is \"blah blah blah\"" }

I plan to store this in a DB table with two fields: id, and data(the AES256 encrypted JSON).

So far my design is using a 6 digit pin with a 32 char salt (unique to each user) to encrypt this. the pin is never stored. the salt is stored in the user table.

What are the possible flaws in doing it this way? Can anyone recommend a better way to implement this?

The risk

Your systems poses a great security challenge, since it acts as a central password repository, thus making it a choice target. Your best defence is ignorance: if you can't decode it, an attacker would have a hard time doing it too. Also, you don't need access to the data stored, but the user (and only the user) does.

What you've done/intend to do is on the right track since you don't have access to the full key. But why do you use a 6-digit pin instead of a "standard" password/phrase? You're responsible for the security of over 80% of the encryption key, and you've got all of them in one single place! An attacker just needs to figure out the (quite weak) pin to add to the salt in order to read the data. Plus, if your system gets compromized, one could manage to retrieve user requests in order to extract the pins and gain access to your user's accounts.

(some) Tips

What could you do then? I'm no expert in security, but I know some tricks. I'll try to answer to the best of my abilities.

Delegate decryption to the end-user

If the decryption key never gets close to your system, the data would be way safer. In order to retrieve a user's passlist, one would need to break into this user's computer and somehow retrieve the decrypted data off the page. That's totally doable, maybe easier than breaking into your server in some case, but this would only grant access to only one account. That's quite good for your other users :D

There's a growing number of applications using this approach to acheive similar results. You often see client-side AES decryption done with javascript for instance. The zerobin project describes such a mechanism.

Use strong encryption keys

As said earlier, leaving the user only 6 bytes in the encryption key isn't really robust. They need to be able to add as much entropy they like. Passwords with an upper size limit are often a bad idea (I personally hate those who tell me how short my password has to be).

Have a look at key stretching

(This point is related to the previous)

Key stretching describes an operation taking a standard "human" password and transforms it into a stronger encryption key. It has many applications, and is in use in several password managers of the kind you're building.

RSA's PBKDF2 is a well-known key stretching algorithm used in many security applications.

Side notes

Of course there are several other points you need to address in order to build a secure system:

Obviously, you NEED to enforce SSL (HTTPS) communications between your server and your clients ; Access to your server needs to be well protected in order to protect the secrets used for encryption. Client-side decryption greatly reduces the threats posed by break-ins, but that doesn't mean they shouldn't be protected. This implies fine tuned firewalls, up-to-date applications, reactivity to security fixes, etc. ; You need to teach a thing or two to your users about security. It's well known that both ends of a channel have to be secured in order for the channel itself to be secure too. There are probably many other concerns, but hey, this isn't a lecture on security ;-)