How to minimize security risk when having to work with decrypted (plain text) passwords due to 3rd party API design

Question

I'm developing an application (C#) for Microsoft SharePoint platform that uses SQL Server's (2008 R2) Remote BLOB Storage (RBS) technology. To accomplish certain client-side tasks, I must obtain username/password pair from the database and pass it to a constructor that looks like this (MSDN):

public BlobStoreCredentials(string credentialName, byte[] credentialSecret)

Note that credentialSecret here expects a decrypted password; the password is encrypted internally after the constructor call.

Microsoft, for reasons unknown to me, by-design stores RBS passwords that I can feed to the above constructor symmetrically encrypted in the database, with encryption key stored inside the same database (to create/insert passwords, a Microsoft-provided stored procedure that accepts a plain-text password is used). From what little I know about security, this is no-go, correct?

To obtain a valid byte[] credentialSecret, I am apparently supposed to use a query that looks somewhat like this and returns username and decrypted password:

OPEN SYMMETRIC KEY skey
DECRYPTION BY CERTIFICATE cert;

SELECT [username], CONVERT(nvarchar, DecryptByKey(password)) 
FROM [credentials] 
WHERE [id]=@userId;

I can then feed the decrypted password to the constructor (client-side) which encrypts it internally, uses it to perform some tasks and disposes the credentials at the end (see MSDN sample code above).

It seems to me that many things are very wrong with this design. Even if I decided to deploy a custom orthogonal database for storing one-way hashed passwords only, I would at one point need to "decrypt" them to plain-text to feed them to the constructor above.

My question is, are there ways to reasonably minimize security issues with this approach while accepting the premise of the question (i.e. I need to pass decrypted credentials to the constructor), or is this design inherently so insecure that it's beyond improvement? It's not just the technical aspect, but also about how to communicate situations like this to employer and just how to react (as a non-security guy) in general when dealing with a situation that seems to force me to use bad security design? The solution I presented obviously works, but it is - as far as I know - bad security-wise, not to mention it resembles a Rube Goldberg device.

(I apologize if this question is not specific enough for this site, but I don't know where else to evaluate my options.)

Answer 1

I have not used these technologies before but what I can tell you is if you decrypt the password in your SQL query then anyone on your network can sniff and get the passwords as plain text.

If I understand correctly, your C# will get the decrypted passwords? If so I would recommend you have something such as in your C# application:

1. C# generate a random key (used for salt in your encryption) and sends salt to stored procedure in SQL.
2. The stored procedure will encrypt the password based on the salt (from the client)
3. C# will decrypt it based on salt key you provided

The attacker would be able to decrypt it, if he got the random salt and reverse engineer your C# (which is very easy due to been bytecodes) but least it isn't plain text or static encryption and much better than your plain-text.