Sto sviluppando un'applicazione (C #) per la piattaforma Microsoft SharePoint che utilizza la tecnologia RBS (Remote BLOB Storage) di SQL Server (2008 R2). Per eseguire determinate attività lato client, devo ottenere una coppia nome utente / password dal database e passarla a un costruttore che assomiglia a questo ( MSDN ):
public BlobStoreCredentials(string credentialName, byte[] credentialSecret)
Tieni presente che credentialSecret prevede una password decrittografata ; la password viene crittografata internamente dopo la chiamata del costruttore.
Microsoft, per ragioni a me sconosciute, by-design memorizza le password RBS che posso alimentare al costruttore precedente crittografato simmetricamente nel database, con la chiave di crittografia memorizzata nello stesso database (per creare / inserire le password, viene utilizzata una stored procedure fornita da Microsoft che accetta una password in testo semplice). Da quel poco che so sulla sicurezza, questo è no-go, corretto?
Per ottenere un byte[] credentialSecret valido, apparentemente si suppone che utilizzi una query simile a questa e che restituisca nome utente e password decifrata:
OPEN SYMMETRIC KEY skey
DECRYPTION BY CERTIFICATE cert;
SELECT [username], CONVERT(nvarchar, DecryptByKey(password))
FROM [credentials]
WHERE [id]=@userId;
Posso quindi alimentare la password decrittografata al costruttore (lato client) che la crittografa internamente, la utilizza per eseguire alcune attività e dispone le credenziali alla fine (vedere il codice di esempio MSDN sopra).
Mi sembra che molte cose abbiano torto in questo progetto. Anche se avessi deciso di distribuire un database ortogonale personalizzato per archiviare solo le password hash unidirezionali, a un certo punto dovrei "decodificarle" in testo semplice per inviarle al costruttore sopra.
La mia domanda è: ci sono modi per minimizzare ragionevolmente problemi di sicurezza con questo approccio accettando la premessa della domanda (cioè ho bisogno di passare credenziali decifrate al costruttore), o questo disegno è intrinsecamente così insicuro che è al di là del miglioramento? Non è solo l'aspetto tecnico, ma anche come comunicare situazioni come questa al datore di lavoro e come reagire (in quanto non di sicurezza) in generale quando si ha a che fare con una situazione che mi costringe a usare un cattivo design di sicurezza? La soluzione che ho presentato ovviamente funziona, ma è - per quanto ne so - una cattiva sicurezza, per non dire che assomiglia a un dispositivo Rube Goldberg.
(Mi scuso se questa domanda non è abbastanza specifica per questo sito, ma non so dove altro valuti le mie opzioni.)