La data in cui una password è stata modificata per l'ultima volta utile per un utente malintenzionato?

Naviga le tue risposte
2

Ovviamente voglio che gli utenti della mia applicazione cambino le loro password su base semi-regolare (in effetti alcune delle nostre app devono essere approvate UL e richiedono un sistema per imporre la modifica delle password ogni 90 giorni). Il modo più semplice per farlo è quello di memorizzare l'ultima volta che l'utente ha cambiato la propria password nel proprio record. Sto anche implementando un flag che, se impostato, segna fondamentalmente la password come "temporanea", costringendo l'utente a cambiare la password al successivo accesso riuscito.

La domanda è semplice: la memorizzazione di questi dati in testo semplice (il flag e / o la data) espone una vulnerabilità?

Vedo un vettore di attacco principale ed è piuttosto serio; un utente malintenzionato che ha ottenuto diritti di modifica sulla tabella utente potrebbe modificare il campo data o il flag, costringendo l'utente a modificare la password a proprio piacimento, esponendolo eventualmente a un keylogger installato sul computer client. Ciò richiede più "ins", ma se entrano in un modo possono ottenere in altri modi. Le informazioni di sola lettura potrebbero comunque fornire un vettore simile identificando il prossimo utente che deve modificare la propria password, rendendole il prossimo obiettivo per sniffare la nuova password.

Ho già un sistema per la crittografia dei dati utente basata su password che nasconde altri dati sensibili nel sistema; La domanda (che potrei aver risposto io stesso) è se includere questi campi nel blob crittografato. Se lo faccio, obbliga legittimamente gli utenti a cambiare le loro password in modo più difficile (potrei voler forzare ogni utente a cambiare la password e altri dati da avviare, se dovessi scoprire che il DB era stato scaricato), ma anche impedisce a un utente malintenzionato di fare lo stesso.

    
posta KeithS 21.12.2012 - 22:18
fonte

2 risposte

1

Caso per testo semplice:

  1. L'utente malintenzionato potrebbe modificare tutte le date per una volta e ripetere. Non è una vulnerabilità di sicurezza, ma potrebbe infastidire il client fino alla fine.
  2. L'utente malintenzionato potrebbe aumentare il numero di reimpostazioni della password, ottenendo quindi più dati da utilizzare in un attacco.
  3. Se viene utilizzato un attacco di dizionario, l'attaccante sa come resettarlo attacco di dizionario.
  4. Aumentare la data darebbe più tempo all'attaccante per qualunque attacco lui / lei scelga e violerebbe la tua pianificazione della sicurezza
  5. Poiché la maggior parte degli utenti in genere modifica solo un numero o una lettera nella propria password, ciò potrebbe aprire un attacco con alcuni schemi di crittografia. Se l'utente malintenzionato sa quando controllare il testo cifrato, sarebbe più semplice creare un dizionario con password passate.
  6. Se utilizzi campi raggruppati (hai menzionato i blob) ed elenca la data che ha modificato, l'attaccante conosce la differenza esatta tra i due testi cifrati.

Caso per testo crittografato:

  1. In base allo schema di crittografia, una cronologia dei testi cifrati potrebbe esporre una certa conoscenza del testo in chiaro. Se l'utente malintenzionato ha capito che stai usando le date nel tuo BLOB (possibile poiché non sono elencate altrove), allora ha uno spazio-chiave molto limitato di testo normale per quella parte del BLOB. Questo potrebbe aprire alcune vulnerabilità.

Non so se tutto ciò è pratico. Lo sto basando su un corso di 6 settimane sulla crittografia a Coursera, ma sono i miei due centesimi.

    
risposta data 22.12.2012 - 19:50
fonte
1

Penso che sarebbe utile per un aggressore. Supponi che

  1. Sono riuscito a procurarmi una copia di backup datata della tabella delle password.
  2. L'ultima modifica è memorizzata in testo semplice.

Quindi potrei stimare la distribuzione delle età delle password. Questo mi aiuterebbe a determinare se valesse la pena dedicare il mio tempo di calcolo a provare a forzare le password.

Ad esempio, se la tabella delle password ha più di 2 anni e l'età massima della password è quasi un anno, allora immaginerò che imposti una modifica della password ogni anno e che tutte le password siano obsolete.

In alternativa, se la tabella delle password è vecchia di un giorno e l'età minima della password è di un anno (o appartiene ai nuovi utenti), molto probabilmente tutte le password sono ancora attuali.

    
risposta data 18.09.2015 - 15:38
fonte

Leggi altre domande sui tag

Perché la crittografia dei dati comporta una chiamata a un controller di dominio Network Sniffing Java Applet Authentication