C'è un strong motivo per salare e cancellare le password quando il riutilizzo della password non è un problema?

Question

C'è un strong motivo per salare e cancellare le password quando il riutilizzo della password non è un problema?

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

5

Ho a che fare con un sistema (in fase di sviluppo) che utilizza stringhe univoche generate dall'utente (non fornite dall'utente) per autenticare i servizi che utilizzeranno un'API. In questo momento, queste stringhe sono memorizzate nel database in testo semplice.

Vorrei capire se c'è un motivo valido per riprogettare questo sistema, in modo che queste stringhe siano salate e con hash.

La mia comprensione dei motivi per cui memorizzare le password solo come hash salati è la seguente:

Un utente malintenzionato può accedere al tuo database.
A questo punto non ti rimane molto da perdere, l'utente malintenzionato può già accedere ai dati dei tuoi clienti e fare praticamente quello che vuole. Le password degli utenti sono un punto controverso. TUTTAVIA ...
I tuoi utenti potrebbero utilizzare la stessa password per altre cose. Se non esegui il sale e l'hash correttamente, l'utente malintenzionato può utilizzare le credenziali rubate per ottenere il controllo di altre risorse, che non hanno nulla a che fare con il tuo sistema (oltre a condividere gli stessi utenti, con cattive abitudini di password).

In altre parole, il punto delle password saling e hashing è quello di proteggere gli utenti dalle conseguenze del riutilizzo della password. Nel mio caso, tuttavia, il riutilizzo della password non dovrebbe essere un fattore.

C'è ancora un motivo valido per modificare il sistema in modo che salti e cancellino anche queste "password"?

Modifica

Almeno alcuni di queste chiavi API finiranno comunque per essere incorporate in applicazioni ampiamente distribuite. La sola chiave API non sarà sufficiente per accedere a tutte le informazioni sensibili. Nella maggior parte dei casi sarà richiesto anche un nome utente e una password regolari. Alcuni utenti API con privilegi speciali saranno limitati dall'indirizzo IP.

passwords hash salt web-service

posta lzam 18.09.2014 - 17:05

fonte

2 risposte

Leggi altre domande sui tag passwords hash salt web-service

XSS riflesso attraverso il valore del cookie? Gestire i certificati SSL per un sito web multi-tenant

score 2 · Answer 1

È una domanda giusta ci sono considerazioni a cui potresti non aver pensato:

Ci sono modi in cui gli attaccanti possono accedere a parti del tuo database senza accedervi, quindi il tuo punto 2 non è del tutto corretto. Gli errori di codifica possono causare perdite di dati, così come le vulnerabilità di SQL. Un utente malintenzionato potrebbe ottenere un dump delle tue password e nient'altro
Se non si memorizza l'hash del proprio passcode, probabilmente lo si sta trasmettendo in chiaro, nel qual caso potrebbero essere annusati se non si utilizza correttamente SSL. L'uso di questi elementi fornirebbe una difesa approfondita contro gli attacchi contro la trasmissione
L'hashing delle password memorizzate mostra la dovuta diligenza e l'impegno per la sicurezza. Se ti è venuta una breccia e si è saputo che non stavi tagliando le tue password, sarebbe un aspetto negativo, anche se il tuo ragionamento era corretto. Se tu fossi audito sarebbe anche un cattivo

Il mio consiglio sarebbe quello di cancellare le password, è abbastanza facile da fare e il vantaggio è lì.

score 0 · Answer 2

In realtà ho già riflettuto su questo problema. Se la tua chiave API è fondamentalmente utilizzata solo per l'inserimento, il vero problema è la perdita di dati chiave e i dati non validi che entrano nell'account di un utente. Sembra che tu abbia adeguati controlli di sicurezza per ciò che è veramente importante: l'accesso degli utenti ai dati. Non vedo alcun bisogno di hash questi necessariamente. Idealmente qualsiasi credenziale di autenticazione può scrivere solo e non leggere) dovrebbe essere sottoposta a hash, ma poiché il sistema è già stato creato, capisco che può essere necessario un grande sforzo per cambiare. Mi limito a verificare che gli utenti siano consapevoli di dover mantenere segrete le proprie chiavi API e non condividerle.