Archiviazione sicura / recupero dei dati in un database

Question

Archiviazione sicura / recupero dei dati in un database

#1 da (4 voti)
#2 da (1 voti)

4

Sto sviluppando un C # relativamente relativamente amatoriale per un piccolo team di assistenza clienti e lavorando con l'API SalesForce nella mia applicazione. Con SalesForce, l'accesso tramite l'API richiede l'aggiunta di un token di sicurezza alla password. Poiché i miei utenti sono pignoli, sarà necessario (solo) il token di sicurezza per essere memorizzato nel database dell'applicazione in modo che non debbano inserirli ogni volta che usano l'applicazione.

Spero di ricevere qualche consiglio sul modo migliore per mantenere questo ragionevolmente sicuro poiché questa è la mia prima avventura in qualsiasi tipo di serio tipo di sicurezza. Ho letto e preso il metodo di crittografia / decrittografia AESThenHMAC da questo dopo .

I miei pensieri sul processo sono i seguenti:

Al primo accesso all'applicazione, all'utente viene richiesto il nome utente, la password e il token di sicurezza.
Il token di sicurezza viene crittografato usando SimpleEncryptWithPassword da sopra con la loro password come parametro 'password' e memorizzato nel database.
Nei login successivi, all'utente viene richiesto il nome utente e la password, il token di sicurezza viene recuperato e decrittografato, quindi l'utente ha effettuato l'accesso utilizzando l'API Salesforce.

Le mie domande sono:

Questo fornisce un ragionevole livello di sicurezza per l'archiviazione del token di sicurezza?
Se no, perché no e cosa posso / dovrei fare per migliorarlo?
In caso affermativo, quale dei seguenti è il metodo migliore per indicizzare il token di sicurezza con il nome utente nel database?
1. Il nome utente è testo normale
2. Il nome utente è sottoposto a hash
3. Il nome utente è crittografato nello stesso modo del token di sicurezza

Grazie in anticipo per qualsiasi consiglio / aiuto / input.

encryption

posta Jdinklage Morgoone 17.11.2013 - 23:32

fonte

2 risposte

1

Questa proposta non è un buon metodo per archiviare le credenziali di autenticazione. la maggior parte della notabilità è una violazione di CWE-257 . Le password non devono essere archiviate in un formato recuperabile, mai, nessun sistema dovrebbe fare affidamento su questo progetto. Memorizzare le password in questo modo è anche una violazione di CWE-916 , utilizzando bcrypt è un'alternativa migliore .

risposta data 18.11.2013 - 03:58

fonte

Leggi altre domande sui tag encryption

Riferimento per password non sicura tramite e-mail Cos'è Open Resolver Project e come risolve gli attacchi di riflessione DNS?

score 4 · Accepted Answer

Il punto di CWE 257 è di forzare l'app di autenticazione per valutare le password non decodificandole e confrontandole con il testo in chiaro, ma crittografando (o eseguendo effettivamente l'hashing) nuovamente il testo in chiaro e confrontando i testi opachi. Ma la tua non è l'app di autenticazione; è tecnicamente il cliente. Le app devono memorizzare le password sui sistemi back-end in ogni momento, non c'è modo di aggirarle. Diamine, anche il mio browser memorizza le password di volta in volta.

Inoltre, il vettore di attacco dettagliato in CWE 257 non si applica qui. Un amministratore non può in realtà decodificare il token senza la password dell'utente, perché la password è la chiave. Quindi secondo me non ti preoccupare.

Nel complesso, penso che la tua idea sia soddisfacente. Potresti considerare l'associazione al dispositivo (ad es. Impostare un cookie persistente sicuro con molta entropia) e richiedere all'utente di reinserire il token quando cambia dispositivo.

Un punto debole è che l'utente dovrà scavare di nuovo il suo token se cambia la sua password; questo potrebbe scoraggiarlo dal cambiarlo abbastanza spesso. Inoltre, sembra che la tua base di utenti principale non possa essere infastidita da cose del genere comunque.