0

I'm trying to build a web application that can store passwords of other services like Facebook, Gmail ...etc.

These passwords can be later retrieved and shown to the user. This has to be a web application and has to work with modern browsers. The application cannot have the concept of a master password that can be inputted by the user. It HAS to work without any input from the user. So locally encrypting and decrypting on the device with the master password may not be a option like how the below services do it.

Is there a secure way to do that with encryption like AES. If the server is compromised for example is there a way to protect the keys?

EDIT: In the app the user does have authentication. So the user can login and then input his credentials to other platforms. But that master password cannot be used to encrypt the keys because in the system the user can share the password with other users of this choice. In that case the other user can see the password without the master password. Hope it makes the requirement clear

  • I'm not sure how you expect to accomplish this with no input from the user. If there's no way of authenticating the user (the user will always have to input something), then anyone with access to the machine could use the passwords. – Chris Murray Aug 28 '15 at 16:15
  • The user does have authentication like any regular web app. But with the app I expect the user to share the passwords of other services with some of his/her friends. Please see my edit in the question. – Prasanth Aug 28 '15 at 16:36
  • Here's an idea for utilizing the user's login as a master password and while still accommodating the password sharing feature. Make it so that normally, passwords are encrypted with the user's login (master password). When the user wants to share the password, decrypt it until the next time the recipient logs in. Then, encrypt another copy using the recipient's login, and delete the unencrypted version. That way, you'll have two separate encrypted versions of the password - one decryptable by the owner, and one decryptable by the recipient. – tlng05 Aug 28 '15 at 16:57
  • It's not perfect since the password will be stored unencrypted for a short while before the recipient logs in, so you'll have to think of some ways to mitigate the risks there. Perhaps you can use a different server for holding unencrypted passwords, or encrypt them with a hardcoded password, etc. – tlng05 Aug 28 '15 at 17:02
  • Nope that does not work. I cannot explain why because that gives out the requirements of the app. I would like a solution that odes not use the master password at all if possible – Prasanth Aug 28 '15 at 17:04
1

In general, storing passwords in a reversible format is a bad idea.

That said, you could use AES, with the user's password as key (enforce a strong password policy). That way, users wouldn't be able to view each other's encrypted data, and a compromise of the server won't reveal the key to everyone's data without cracking the user password hashes first.

EDIT: This only applies if your app has some sort of user authentication. If you just have an app that someone can upload data to, then it won't be secure. A SQLi attack won't get the key if you keep it outside of the DB schema, but a full compromise of the box will allow an attacker to find and use the key.

0

You could generate a cryptographically secure 128-bit key and store it in HTML5 storage on the browser.

This would encrypt data without any input from the user.

However, the user would have to use the same browser and computer all the time. You could add the option to export the value - e.g. a browser extension that extracts the key in HTML5 storage and writes it to a local location of the user's choice (e.g. USB stick). You could prompt the user for a password to encrypt the extracted key with, to protect it in transit to another browser. It is recommended to strengthen this key with bcrypt/pbdkdf2.

As for sending certain credentials to others, you could use public key cryptography implemented in JavaScript to encrypt the data with the target users public key and then send it to them using your system.

0

How about using parent and child encryption keys? Encrypted passwords is definitely the solution, what needs to be achieved is securing the encryption keys such that only the legitimate user can decrypt and use the data (password here). You may need something like Bring Your Own Keys (BYOK) model of encryption key management. Try an encryption as a service solution like SecureDB.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.