2009-10-02 7 views
6

Supponiamo che ci sia una variabile String che contiene una password in testo semplice.Qualcuno può rubare una password da un'applicazione Java?

Esiste la possibilità di leggere questa password utilizzando un dump della memoria. (Supponiamo di usare un cheat engine.) Sono confuso da questa cosa della JVM. JVM fornisce una sorta di protezione contro questo. Se no, quali sono le pratiche che ho bisogno di usare per evitare tale "furto".

Una minaccia pratica sarebbe un trojan; che invia i segmenti del dump della memoria a una parte esterna.

+2

Vorrei solo notare che tutte le risposte fino ad oggi sono ugualmente applicabili a praticamente tutte le lingue, non solo Java. Il problema è esattamente lo stesso. Alcune lingue potrebbero renderlo leggermente più facile o più difficile di altre, ma hanno tutte la stessa "vulnerabilità" di base. –

+0

Se quel "qualcuno" ha accesso alla JVM senza una ragione ovvia, si ha a che fare con cose peggiori degli attacchi di heap di cui preoccuparsi. La maggior parte delle persone direbbe "Game Over". Domanda SO simile a http://stackoverflow.com/questions/646224/how-does-one-store-password-hashes-securely-in-memory-when-creating-accounts –

+0

memorizza la password in un server e controllala quando necessario –

risposta

11

come già notato, sì, chiunque può estrarre la password, in vari modi. Crittografare la password non sarà di grande aiuto: se decrittografata dall'applicazione, a qualche punto sarà presente anche il modulo decrittografato, più la chiave di decrittazione (o il codice) stesso diventerà una vulnerabilità. Se viene inviato da qualche altra parte in forma crittografata, solo la conoscenza del modulo crittografato è sufficiente per falsificare la transazione, quindi non aiuta molto.

Fondamentalmente, fino a quando "l'autore dell'attacco" è anche il "mittente", alla fine vi farete scoppiare: ecco perché i settori della musica e del video non possono far funzionare il DRM.

Suggerisco di prendere una copia di e di leggere la prima sezione, "Protocolli crittografici". Anche senza entrare nella matematica dell'effettiva crittografia, questo ti darà una buona panoramica di tutti i tipi di schemi di progettazione in quest'area.

7

Se si mantiene la password in testo normale nella propria applicazione, qualcuno può leggerla giocando con i dump della memoria indipendentemente dalla lingua o dal tempo di esecuzione utilizzati.

Per ridurre la possibilità che questo accada mantenga la password in testo normale solo quando è veramente necessario, quindi esegui il dump o la crittografia. Una cosa da notare qui è che JPasswordField restituisce un char [] piuttosto che una stringa. Questo perché non hai il controllo su quando la Stringa sparirà. Anche se non hai alcun controllo su quando un carattere [] svanirà, puoi riempirlo di ciarpame quando hai finito con la password.

Dico riduci perché questo non fermerà nessuno. Finché la password è in memoria, può essere recuperata, e dato che la decrittografia deve anche essere parte del deliverable, anche questa potrebbe essere violata lasciando la tua password spalancata.

+0

Yup, per (char nextChar: pw) nextChar = 0; // Quale potrebbe non funzionare, si noti anche: il carattere finale [] non è definitivo –

+0

Sarà necessario utilizzare un ciclo for normale piuttosto che un foreach. E sì, vale la pena affermare che la finale si applica al riferimento di un array e non ai valori. –

2

Se il programma conosce la password, chiunque utilizzi il programma può estrarre la password.

+3

chiunque sia tecnicamente competente ... –

2

In teoria si potrebbe semplicemente collegarlo al debugger ... impostare un punto di interruzione ... e leggere il contenuto della stringa

4

Questo non ha nulla a che fare con Java - lo stesso identico problema (se è davvero uno) esiste per le applicazioni scritte in tutte le lingue:

  • Se l'eseguibile contiene una password, non importa quanto offuscato o criptato , chiunque abbia accesso all'eseguibile può trovare la password.
  • Se un'applicazione conosce temporaneamente una password o una chiave (ad esempio come parte di un protocollo di autenticazione di rete), chiunque possa osservare la memoria in cui l'applicazione è in esecuzione può trovare la password.

Quest'ultimo è di solito non è considerato un problema, dal momento che un moderno sistema operativo non consente applicazioni arbitrarie di osservare la memoria di ciascuno, e privilege escalation attacchi di solito si basano su diversi vettori di attacco.

+0

È un problema se non si conosce e si sviluppa il sistema come se la chiave "crittografata" fosse effettivamente sicura. –

Problemi correlati