memorizzando le credenziali di terze parti nel database / in qualche luogo sicuro

Question

memorizzando le credenziali di terze parti nel database / in qualche luogo sicuro

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

5

Questa domanda riguarda l'archiviazione delle credenziali di terze parti nel database / in un posto sicuro in modo che non sia possibile accedervi solo dall'utente autorizzato.

Il nostro sistema si collega al sistema di terze parti utilizzando nome utente e password specifici. Stanno usando l'autenticazione di base che richiede il valore nonce e la password in testo semplice per l'autenticazione. Disponiamo di credenziali separate per i diversi utenti che si connettono a questo sistema di terze parti.

Capisco che l'autenticazione di un utente contro la nostra applicazione sia possibile con hash salato e altra crittografia a 1 via.

Forniscimi un approccio migliore in modo da poter memorizzare queste credenziali di terze parti. il nostro sistema richiede che queste credenziali vengano memorizzate localmente, quindi sto cercando alcuni approcci migliori.

authentication risk-management databases confidentiality

posta this.josh 26.09.2011 - 08:36

fonte

3 risposte

Leggi altre domande sui tag authentication risk-management databases confidentiality

Vettori di modellazione di un exploit sconosciuto Problemi nell'evitare il dirottamento di JSON con la convalida AntiForgeryToken di MVC3 o con un token simile

score 3 · Answer 1

Bene, la sfida è che le credenziali in questione devono essere archiviate in un modo che consenta loro di essere letti come testo in chiaro. Ciò significa che alcune delle conoscenze convenzionali sull'archiviazione delle password ( use bcrypt ) non sono applicabili.

Il tuo obiettivo, quindi, è quello di mitigare i rischi e compartimentare i dati. Se possibile, si desidera avere un processo diverso che autentica il sito estraneo e passa l'applicazione Web indietro a un handle di file al socket autenticato attivo. Ciò significa che il tuo sito web compromesso non perderà le effettive credenziali in uso poiché l'applicazione web non avrà le autorizzazioni per leggere quella parte del database.

La crittografia dei valori del database è un concetto comune, ma potrebbe avere un'utilità limitata a seconda di come si progetta l'applicazione di autenticazione se viene eseguita sullo stesso server del database. Se si dispone del tempo e delle risorse, progettarlo in modo tale che la crittografia e la decifrazione avvengano nell'applicazione di autenticazione e il database memorizza i valori crittografati. Il posizionamento di ciascuno di questi ruoli su macchine diverse e l'isolamento del database e del sistema di autenticazione esterno forniscono la maggior parte della segmentazione.

score 1 · Answer 2

La Best Practice per il tuo requisito è l'utilizzo di OAUTH . Quindi, se la Terza Parte (per essere autenticata) fornisce il supporto OAUTH ..... allora questo è il miglior modo preferito in quanto in tal caso non si dovrà archiviare l'accordo con le credenziali, ma proteggere la chiave OAUTH fornita all'utente da Terza parte che è molto meno responsabile.

Anche se per entrambi, Chiave o Credenziali, puoi crittografare i dati sensibili con la password dell'utente per il tuo portale e utilizzare anche Salt con esso.

score 0 · Answer 3

0

Non ho familiarità con Perl. Ma la crittografia SHA è quella che viene in mente dopo aver letto la tua domanda per la crittografia / decrittografia a 2 vie. Quindi l'unica cosa che devi proteggere sarà key invece di tutte le password.

risposta data 26.09.2011 - 08:42

fonte