Le password sono in memoria?

18

Ho un disco fisso crittografato (dm_crypt). Ecco perché memorizzo le mie password in un semplice file di testo. Di solito copio / incollo le password da esso. Ok!
Q: Se apro questo file di testo, questo va in memoria. Quindi tutte le mie password in formato testo chiaro vanno "lì" ... le password verranno cancellate dalla memoria se chiudo il file di testo? Potrebbe la memoria che sto usando accessibile da altri in tempo reale? Esistono modi migliori / più sicuri per copiare / incollare le mie password? Per esempio. per impostare che se premo Ctrl + V, allora dovrebbe cancellare gli appunti? Esecuzione di Fedora 14 ..
O come posso "criptare la mia RAM"? Ci sono modi per farlo?
Grazie!

    
posta LanceBaynes 26.04.2011 - 11:47
fonte

3 risposte

30

Senza mezzi termini, sì, potevano. Questa è la risposta enormemente semplificata.

La risposta più complicata è che devi capire come il tuo sistema operativo gestisce la memoria. Potresti sentire parlare di anelli, livelli di privilegi, ecc. Lasciatemi spiegare brevemente:

  • Quando il tuo sistema operativo inizia (superando l'intera cosa a 16-bit del BIOS) ha fondamentalmente un'intera pila di memoria (tutta la tua RAM) con cui lavorare e lo fa in una modalità privilegiata, il che significa che può fare qualunque cosa piace a qualsiasi parte della memoria.
  • Tuttavia, architetture x86 dal 1980 - qualcosa prima che io nascessi hanno supportato il concetto di modalità protetta, in cui l'hardware della CPU fornisce meccanismi per consentire al sistema operativo di avviare le applicazioni in modo tale da separare gli indirizzi di memoria.
  • Così questa modalità protetta consente al sistema operativo di creare uno spazio di indirizzi virtuali per ogni applicazione. Ciò significa che il concetto di memoria di un'applicazione non è lo stesso degli effettivi indirizzi di memoria fisica e che l'applicazione non ha accesso privilegiato alla memoria. Infatti, alle applicazioni viene direttamente impedito di modificare gli indirizzi di memoria l'uno dell'altro perché non possono vederlo, tranne tramite richieste ben definite al sistema operativo (syscalls) per richieste di cose come la memoria condivisa, dove due i processi condividono uno spazio indirizzo.

(questa è una semplificazione e sto saltando pezzi enormi per brevità, ma questo è il succo - le applicazioni hanno le loro richieste per accedere alla memoria gestita dal sistema operativo e dall'hardware).

Quindi, in teoria, stai bene, giusto? Non tecnicamente vero. Come ho detto, i sistemi operativi forniscono modi ben definiti per accedere alla memoria di altri processi. In termini di possibilità, ecco come potrebbero presentarsi alcuni:

  • Se I scarica la memoria dell'applicazione , posso risolvere abbastanza facilmente la password memorizzata.
  • Un debugger o un rootkit in stile userland progettato in modo appropriato potrebbe essere in grado di fornirmi l'accesso a tale memoria. Non sono un esperto di tali tecniche, ma so che può essere fatto in determinate circostanze.
  • Infine, il sistema operativo potrebbe essere controproducente qui. La memoria virtuale a cui hai accesso ha alcune altre conseguenze. I sistemi operativi lo presentano come virtuale perché scambiano spesso la memoria per garantire che ci sia sufficiente RAM disponibile per le app attualmente in esecuzione. Quindi un attacco interessante potrebbe essere quello di fare in modo che il sistema si scambia, quindi si blocca ed esamina la partizione di swap. Anche il tuo swap è crittografato?

Infine, dovrei sottolineare che se il tuo attaccante sta eseguendo il codice nel kernel tramite un modulo del kernel, il gioco è finito comunque, poiché non c'è nulla che impedisca loro di cercare spazio nella tua memoria per le stringhe ascii.

Tuttavia, per essere realistico:

  • Se il tuo kernel è compromesso tramite un rootkit, un keylogger è probabilmente più facile da implementare di qualcosa progettato per analizzare la memoria in termini di acquisizione delle tue password.
  • I rootkit in stile userland che coinvolgono i debugger per la valutazione di programmi non progettati per il debug (cioè senza debug di simboli, ecc.) non saranno una cosa facile da implementare, anche se sono teoricamente possibili. Inoltre, non è facile sfruttarlo: tu, l'utente, dovresti essere ingannato nell'eseguire il suddetto editor sotto il debugger che probabilmente implica l'ingegneria sociale o l'accesso fisico.

La mia raccomandazione, tuttavia, è che non si memorizzano mai password in chiaro ovunque. Se hai bisogno di un promemoria, ti suggerisco di utilizzare un prompt incompleto parziale che guidi la tua memoria e ti permetta di dedurre le password, ma ragionevolmente impedisce ad altre persone di farlo, anche se ti conoscono. Questo è molto lontano dall'ideale, ma meglio delle password in chiaro.

    
risposta data 26.04.2011 - 13:19
fonte
9

Utilizzerei KeepassX, che utilizza file crittografato tramite la password e facoltativamente tramite file di chiavi e non si preoccuperebbe di questi problemi teorici.

    
risposta data 26.04.2011 - 20:45
fonte
1
  • Usando Keepass, puoi anche bloccare i gestori degli appunti, in modo che non ricevano la notifica quando gli appunti cambiano (questo impedisce al testo incollato attraverso il tipo automatico di essere salvato nel software di gestione degli appunti per esempio. questo tipo di auto è abilitato)

  • C'è anche una funzione per dividere il segreto che protegge dalle applicazioni che potrebbero controllare regolarmente gli appunti contenuti.

risposta data 20.04.2012 - 10:29
fonte