Passwords: store encrypted, view in plain text

Question

I've already asked that question at stackoverflow but i was informed it is a bit too broad and relies more in here instead. So let me just copy and paste what i asked there:

I have a security related dilemma which i'm unable to figure out by myself from my knowledge about web applications security.

Let's say i want to create a service where user can store and VIEW in plain text its passwords for multiple services. In such case we have few things to consider: basic security measures by encrypting stored passwords with hash, how to protect passwords in case if they would have been stolen from database by, for example, dumping the database by attacker.

This means passwords would need to be stored encrypted but being possible to display to a user in plain text. Standard way to store passwords for authentication is to hash them for example with bcrypt or other method with salt added to it and such encryption doesn't let you to decrypt passwords easily.

Is what i want even possible to achieve? Or is there any other approach i should take instead of hashing but still secure to store multiple passwords to multiple services by a single user?

I will just add to it that let's assume single password or set of passwords is a blog post to view in a plain text only by author of such post and under specific circumstances by admin and moderator.

Technology itself probably is not the most important thing here but i'm going to make this application using php and laravel framework.

To store and to view is one thing, other thing is how to secure such application from various kinds of encrypted posts hijacks, database dumps and similar attacks?

Answer 1

In general:

• A one-way hash is non-reversible (hence the term one-way)
• Encryption is reversible (provided you have the decryption key)

For regular authentication, we use store password-hashes in the database. Then we hash a user-entered password and compare that to the hash in the database. This way we can authenticate a user without ever storing the password. If the user chose a 'strong' password, it'll be impossible (or at least immensely difficult) to obtained the users clear-text password even if the entire system was compromised.

However, what you're asking for is to retrieve the cleartext password -- which isn't required under most circumstances. The user already knows their password (otherwise they wouldn't have been able to log on) -- and if the user forgot, we'd generally reset the password, by first authenticating an email address or phone number first, and then re-writing the hash for the new password.

If instead you're asking to store 'data' on the account that isn't accessible to anyone without the password -- then the general solution most password-managers utilize is by encrypting the data with key derived from the user password (because user passwords can be quite weak). The data can be a encrypted blob, that would be decrypted on the user-end using their derived key.

The drawback (sort of) is that if the user loses their password, there is no recovering this data, but for most password managers this is actually a 'feature' because nobody wants this data stored in the clear on any server.

Again, the solution would be quite useless if the user chose 'Password1234' as their master password, but there are other solutions for that.

Answer 2

From my understanding you're trying to build a password manager/vault. You can't use hashing for data storage in that case.

You'd definitely be better off using one already out there as it's very easy to get wrong.

You'd have to use symmetric key crypto to encrypt the passwords, and derive the key from a user's password.

I wouldn't recommend you do this yourself really, there's a lot of ways to go wrong. I.e. weak keys/crypto function, storing/transmitting the secret key incorrectly, data integrity, database breaches etc...

As has been mentioned refer to OWASP for app security guidelines, I believe there's a cheat sheet on there to help developers build better software too.

Answer 3

A secure set-up

I recommend encrypting users' passwords using a derived key from the user's normal password. I would use bcrypt for storing their password, PBKDF2 for generating a key and AES for encryption. A set-up could be:

• Store the normal password of the user with bcrypt;
• When the user logs in successfully, use PBKDF2 in Javascript to generate the user's derived key in the browser;
• Send the user their (AES) encrypted blob;
• Decrypt the blob in Javascript, in the memory of the browser;
• When the user is done doing their thing, have them send back an (AES) encrypted blob.

This way the server will never see a user's password or their encryption key. Breaking the encryption would mean brute-forcing the user's password, in which case you can access the user's data anyway.

Other ideas

I would like to add that it might not be necessary for users to actually view their passwords. For example, most password managers don't display passwords but copy them to the clipboard directly. You could have their decrypted blob in memory and have something like a [copy] button that copies the password to their clipboard. This would not just be more secure, but also more convenient for your users.