Geoff Griswald
Geoff Griswald

Reputation: 1093

How best to store a password in SQL Server so that the password can be retrieved

So I'm creating an application that logs into a long list of FTP sites, checks for new files and downloads any new files it finds.

I'm using SQL Server 2016 SP1 to store my table of files that I've already downloaded, so when I connect to the FTP and check against that table, I can tell if a file is "new" or not.

I'm also using SQL Server to store my list of FTP sites, usernames and... PASSWORDS! My application loops through every FTP site in my FTP table one by one and uses the credentials in the table to connect to them.

Right now I have the passwords stored as plan varchars, since I need to pass them into the FTP application I'm using.

What I'd like to do is store them as encrypted data, so that I only ever decrypt the password when I'm about to use it. Ideally I'll pass the decrypted password to my FTP client in memory only and never actually write it to disk as a varchar.

Every guide or webpage I come across talks about encrypting passwords so you only get the hash, effectively giving me a way to check if I have the correct password, which is useful for running a website with a password, or checking if a user has entered a password correctly, or whatever.

What I need is a way to store the password encrypted, so that it can be DE-crypted, by me, so I can use it. Whatever I search for along these lines, I always keep coming back to answers that give me a hash check, not a way to decrypt it.

Is what I want to do possible? Is there even any point? Since if I can decrypt the passwords, then surely anyone with access to the database could? Or is there some way of effectively locking them down to only be decrypted by certain UserIDs?

Advice welcomed.

Upvotes: 4

Views: 3233

Answers (3)

Geoff Griswald
Geoff Griswald

Reputation: 1093

It turns out this was a massive waste of time. I can't encrypt and decrypt on the fly easily enough for it to be worth my while. It's possible, but not worth the effort imo.

In the end I just installed a password manager and scripted password requests to it. By far the simpler and safer solution than creating my own encryption and decryption routines.

Upvotes: 0

Wilco
Wilco

Reputation: 384

Not sure what language you are using for your app, but in PHP you could use the openssl and base64 methods to encrypt and decrypt server side. Here's a quick PoC:

<?php

$plaintext = 'plain text string to encrypt';
$password = 'Ir43234Ldsase445wsd4f'; 

$method = 'aes-256-cbc';

echo "Password:" . $password . "\n";

$key = openssl_random_pseudo_bytes(openssl_cipher_iv_length($method));

$ivlen = openssl_cipher_iv_length($method);
$iv = openssl_random_pseudo_bytes($ivlen);

$encrypted = base64_encode(openssl_encrypt($plaintext, $method, $key, OPENSSL_RAW_DATA, $iv));

$decrypted = openssl_decrypt(base64_decode($encrypted), $method, $key, OPENSSL_RAW_DATA, $iv);

echo "plaintext=" . $plaintext . "\n";
echo "cipher=" . $method . "\n";
echo "encrypted to: " . $encrypted . "\n";
echo "decrypted to: " . $decrypted . "\n";

Upvotes: 2

Andrew Simon
Andrew Simon

Reputation: 158

You can store your passwords encrypted and be able to decrypt them by using many different public/private or private key encryption methods out there (asymmetrical or symmetric) such as RSA, AES, and 3DES. However, as you stated at the end of your post this creates a security risk as you will need to protect the ability to decrypt the passwords using either strong database permission access to the data and private key. Ideally you should only ever use one-way hashes when storing passwords, and I'd suggest you search for an alternative solution that avoids storing them otherwise (do you need to log in to every FTP site, for example? It depends on what you're trying to achieve with the application).

If you need to be able to decrypt the passwords with an automatic application, be absolutely sure that the decrypted password is never written anywhere and only exists in temporary memory, and make it such that the private key required to decrypt is protected with only the least necessary permissions. For example, YOU shouldn't have access to the production private key, only the application that runs it which should probably run under its own Active Directory account.

Upvotes: 1

Related Questions