Come archiviare in modo sicuro le password su un servizio web di terze parti nel mio database?

Question

Ho bisogno di memorizzare una password di terze parti nel nostro database di configurazione, in modo che l'utente possa salvare le informazioni di accesso per un servizio Web a cui è possibile accedere tramite il nostro server.

Ho bisogno di passare la password al servizio web, quindi non posso semplicemente cancellare la password e memorizzare l'hash. Devo essere in grado di ottenere la password effettiva per l'invio al servizio.

Per motivi di sicurezza, desidero crittografare la password che stiamo memorizzando nel database. Tutto quello che guardo riguardo alle password di crittografia sembra dire "hash, non criptarlo!" ma non penso che si applichi in questo caso.

Mi chiedo se è meglio per gestire la cifratura/decifratura nel codice VB.NET o utilizzare SQL Server per realizzarlo (da quello che vedo here, è almeno possibile farlo in SQL, ma io Non sono sicuro che abbia senso. Devo fare ulteriori ricerche per scoprire quali sarebbero i problemi di distribuzione).

Answer 1

Sono d'accordo con George Stocker. Se è possibile utilizzare il protocollo esistente, utilizzarlo (ridurrà la quantità di possibili problemi e le vulnerabilità di sicurezza dieci volte).

Solo nel caso, se non si dispone di opzioni (non è possibile utilizzare alcun protocollo). Se avete bisogno di accedere terze parti server web solo quando un utente fa qualcosa sul server, mi sento di raccomandare seguente:

• Non conservare le password in vostro DB

• creare un cookie con una password per Servizio di terze parti e crittografia con una chiave segreta. Invia questo cookie a un utente.

• Non appena l'utente torna sul tuo sito web, riceverai i cookie, lo decrittografano, ottengono una password dai cookie e la usano per accedere a servizi web di terze parti.

Così, nel caso, se qualcuno vi incidere il vostro server e copierà il database, non avranno le password al 3 webservices parti. Nel caso, se qualcuno hackererà i computer degli utenti, tutti i cookie saranno crittografati, quindi non saranno in grado di fare nulla con loro.

L'unico punto debole di sicurezza di questo, se qualcuno sarà in grado di iniettare del codice nel server e catturerà le password dalle sessioni degli utenti attivi.

Answer 2

In generale è meglio utilizzare le password di hash che è vero, ma nel tuo caso ciò sembra non essere possibile. Non raccomanderei assolutamente la crittografia con una chiave simmetrica sul server SQL stesso, la ragione è che se il server SQL viene compromesso, anche la crittografia viene compromessa (perché la chiave si troverà sullo stesso server).

Una cosa che consiglierei è di usare un negozio temporaneo da qualche parte, questo potrebbe essere qualcosa come nella sessione. Tuttavia, fai attenzione sia all'utilizzo di sessioni che ai cookie perché puoi diventare vulnerabile agli attacchi CSRF e agli attacchi di session/cookie hijacking. Una cosa che puoi fare è che l'utente inserisca la password, quindi la cripta e la memorizzi nel suo cookie, allegando l'IP del client nel cookie e aggiungendo un timestamp per la scadenza all'inizio (questo renderà anche l'effetto valanga più efficace come stai cambiando i bit all'inizio del testo in chiaro).Richiedere che venga effettuata una richiesta al servizio Web di allegare un token CSRF che viene reso sul lato client e che è un POST non un get, infine convalidare l'IP del client e che il timestamp non è precedente a x minuti/hrs (a seconda di come vuoi essere paranoico).

Se il cookie degli utenti viene rubato, non sarà in grado di effettuare la richiesta perché è specifico per il loro IP client (a meno che non falsifichi l'IP degli utenti, ma a quel punto ti rendi conto che questo aggressore non è così intelligente dal momento che io Sono sicuro che ci sono altri vettori di attacco più facili che daranno loro un carico utile maggiore). Se l'utente è in grado di falsificare in qualche modo l'IP, non sarà in grado di usarlo a lungo perché il timeout renderà il cookie nullo. E se l'utente è abbastanza intelligente da rompere bene l'algoritmo di crittografia ... in quel momento non avevi praticamente nessuna possibilità.