9

I need to store a 3rd-party password in our configuration database, so the user can save their login information for a web service that can be accessed through our server.

I need to pass the password to the web service, so I can't just hash the password and store the hash. I need to be able to get to the actual password for sending to the service.

For security reasons, I'd like to encrypt the password that we're storing in the database. Everything I look up regarding encrypting passwords seems to say "hash it, don't encrypt it!" but I don't think that applies in this case.

I am wondering if it's better to handle the encryption/decryption in the VB.NET code or use SQL Server to accomplish it (from what I see here, it's at least possible to do it in SQL, but I'm not sure if that makes sense. I need to research that more to find out what the deployment issues would be like).

George Stocker
  • 57,289
  • 29
  • 176
  • 237
fussmonkey
  • 606
  • 5
  • 19
  • Please describe in more detail why you cannot hash your password. How does the requirement of passing it to a web service change anything? – Justin Skiles Aug 28 '12 at 13:57
  • 3
    You are right - hashing is not a solution for this problem. Not sure what "best practices" you are looking for - as such the term is simply too wide and vague. – Oded Aug 28 '12 at 13:57
  • 3
    @JustinSkiles - More detail? The password needs to be recoverable, meaning that hashing is out of the picture. The OP description is more than enough to determine this. – Oded Aug 28 '12 at 13:58
  • Do you own both services? If so, you can use OAuth and store a token instead of the user credentials. Is the web service owned by another party? If so, you can ask them to implement an OAuth endpoint. it reduces your liability, and it reduces their liability. – George Stocker Aug 28 '12 at 14:21
  • 2
    You may also want to check into what Mint does, suffice it to say there's a lot involved with what you're asking, and it's almost better to not do it or to use OAuth than it is to do it: http://money.stackexchange.com/questions/15392/are-there-any-risks-from-using-mint-com – George Stocker Aug 28 '12 at 14:23

2 Answers2

1

I agree with George Stocker. If you can use existent protocol - go with it (it will reduce amount of possible issues and security vulnerabilities tenfold).

Just in the case, if you are out of options (can't use any protocol). If you need to access 3rd party webserver only when a user does something on your server, I would recommend following:

  • Don't store passwords in your DB

  • Create a cookie with a password to 3rd party service and encrypt with some secret key. Send this cookie back to a user.

  • As soon as the user returns to your website, you will get cookies, decrypt it, get a password from cookie and use it to access 3rd party webservice.

So, in the case, if somebody will hack your server and will copy the database, they won't have passwords to 3rd party webservices. In the case, if somebody will hack users computers, all cookies are encrypted, so they won't be able to do anything with them.

The only security weakness of this, if somebody will be able to inject some code into your server and will capture passwords from active users sessions.

Victor Ronin
  • 22,758
  • 18
  • 92
  • 184
1

Generally speaking it is better to hash passwords that's true, but in your case that seems to not be possible. I would definitely not recommend encrypting with a symmetric key on the SQL server itself, the reason being is that if your SQL server is compromised then your encryption is also compromised (because the key will be on that same server).

One thing I would recommend is that you use a temporary store somewhere, this could be something like in the session. However be careful of both using sessions and cookies because you can become vulnerable to CSRF attacks and session/cookie hijacking attacks. One thing you can do is have the user enter the password, then encrypt and store it in their cookie, attaching their client IP in the cookie and then adding a timestamp for expiration at the beginning (this will also make the avalanche effect more effective as you are changing the bits in the beginning of your plaintext). Require that for a request to the web service to be made that they attach some CSRF token that is rendered on the client side and that it is a POST not a get, finally validate the client IP and that the timestamp is not older than x minutes/hrs (depending on how paranoid you want to be).

If the users cookie is stolen then they will not be able to make the request because it is specific to their client IP (unless they spoof the users IP but at that point you realize this attacker is not that smart since I'm sure there are other easier attack vectors that will give them a bigger payload). If the user is able to somehow spoof the IP they will not be able to use it for long because the timeout will make the cookie void. And If the user is smart enough to break your encryption algorithm well... then you pretty much had no chance in the first place.

nerdybeardo
  • 4,655
  • 23
  • 32