0

I'll quickly outline the purpose of our application:

The user logs in using his username and password. He will receive a list of servers he can connect to. After choosing a server the connection to this server is established.

Some more details about the application that complicate our requirements:

  • One user can have multiple devices
  • Server lists can be shared amongst multiple users

What's the best way to store the server passwords on our application server?

Ideas that we already played with:

  • Symmetic encryption using the user's password as key
    • Won't work with shared list
    • Would need to store the user's password on the client if don't want him to log in every time he's using the application
  • Symmetic encryption using the user's password hash (bcrypt) as key
    • Won't work with shared list
    • If an attacker has access to the server he will be able to decrypt the server passwords using the user's password hash, that is also stored in the database
  • Using bcrypt to securely store the passwords
    • Won't work as we will need the plain password to connect
  • Storing the passwords in plain text
    • C'mon...

Any ideas are more than welcome.

  • 1
    Please don't store decryptable passwords. – user Jan 17 at 14:19
  • 1
    Have you seen Apache Guacamole? It does all this already. – schroeder Jan 17 at 14:58
  • 2
    Why couple the credentials to the server with the app user's password? Why can't the app manage the credentials separately? You say that the server lists can be shared, but then suggest that the credentials are also shared. Can you clarify that? – schroeder Jan 17 at 15:01
  • Can you clarify who enters the server passwords? The users? Also are the remote servers you connect to under your control? If not, if there are any methods other than username+password to connect to them? I'm not quite sure I understand the use case of multiple users sharing passwords to remote servers they add, though. – jcaron Jan 17 at 17:11
  • @user it's not always quite that straight-forward. You certainly shouldn't store user-provided passwords in de-cryptable formats, but that is simply because of the risk of password re-use, and a desire to protect the user from themselves. System generated passwords are a bit more flexible, since you can have high confidence that the user didn't also use it for their email/banking login. In this case the OP may be referring to system-generated passwords and so relaxing that requirement is reasonable. Moreover since they are for use with a third party, the plain text is required. – Conor Mancone Jan 17 at 19:36
0

Symmetic encryption using the user's password as key

This is the base of a correct solution. If you want to store it securely, you need to encrypt it with a key you don't have. So that leaves the user's password.

To solve the problems, you just need more layers of indirection.

Shared lists are encrypted with a single key, and that key is in turn encrypted with the key of each user that has access to it. That way, multiple users can decrypt the decryption key and access the list.

To avoid logging in each time, use an additional key that the user decrypts with his password. You hold on to this key, so that reauthentication isn't required, without storing the password.

  • Thanks for this idea. Can you clarify a bit on the last part: As I understand this sounds like some sort of a token to keep the login alive (e.g. JSON Web Token). Do we encrypt the server passwords with this key? Then both information would be on server side... I think I misunderstood something here :) – Michael Schmidt Jan 20 at 6:36

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.