Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1
    Utente di HTML.it
    Registrato dal
    Dec 2012
    Messaggi
    15

    Protezione dati personali

    Salve.
    Sto realizzando un software gestionale ad interfaccia grafica in Java, che tra le altre cose deve gestire i dati di diversi clienti: si tratta di dati personali, che vengono salvati su file .txt in locale, quindi devo proteggerli adeguatamente o rischio una violazione della legge sulla privacy e potenzialmente un'accusa penale.
    Al di là di questo, è anche buon senso: come proteggere i preziosi dati dei clienti da eventuali nemici della mia attività che vogliono portarmeli via?
    Per il momento, ho sviluppato due metodi: criptare i file contenenti i dati dei clienti con un algoritmo di mia invenzione, non conosciuto e basato su una chiave inserita ogni volta che si vuole leggere/cancellare/modificare un file; e analogamente proteggere il programma all'avvio con username e password, per evitare che, nel caso in cui qualcuno si introduca nottetempo nell'azienda destinataria del mio software, riesca a passare la notte a cercare di trovare la chiave: avrebbe due protezioni da superare, in questo caso doppia, e quindi farebbe molta più fatica.
    Il problema però è evidente: quando l'utilizzatore dell'sw inserisce username e password, il programma verifica che siano corretti perchè ne ha una copia in memoria; allo stesso modo, il criptaggio e il decriptaggio avvengono con un algoritmo inserito nel mio programma, altrimenti non funzionerebbero, e qualunque malintenzionato un minimo esperto di informatica potrebbe rivoltare come un calzino in 30 secondi i miei file .class o .jar e carpire il tutto, vanificando la mia fatica.
    Come posso ovviare a questi problemi? Possibilmente senza offuscatori di cui mi fido poco, o nel caso se ne avete uno buono e fidato posso pensarci.
    Altra cosa: i file possono sempre essere copiati e crackati altrove; come posso impedirlo?

  2. #2

    Re: Protezione dati personali

    Originariamente inviato da tenik
    Per il momento, ho sviluppato due metodi: criptare i file contenenti i dati dei clienti con un algoritmo di mia invenzione, non conosciuto
    Pessima idea. Un algoritmo "non conosciuto" inventato da chi di crittografia non sa niente (ovvero da chiunque, me e te inclusi, tranne un ridotto numero di matematici) è quanto di meno sicuro ci sia per mettere in sicurezza dei dati, con ogni probabilità è passibile di attacchi "semplici" anche senza conoscere la chiave.
    La "security by obscurity" tende a non funzionare quando è fatta dai professionisti, figurati dai dilettanti.
    e basato su una chiave inserita ogni volta che si vuole leggere/cancellare/modificare un file;
    Non puoi usare questa chiave con un algoritmo di cifratura noto e sicuro, come AES?
    Il problema però è evidente: quando l'utilizzatore dell'sw inserisce username e password, il programma verifica che siano corretti perchè ne ha una copia in memoria;
    Il programma non dovrebbe conservare in memoria la password, è sufficiente memorizzarne solamente un hash.
    allo stesso modo, il criptaggio e il decriptaggio avvengono con un algoritmo inserito nel mio programma, altrimenti non funzionerebbero, e qualunque malintenzionato un minimo esperto di informatica potrebbe rivoltare come un calzino in 30 secondi i miei file .class o .jar e carpire il tutto, vanificando la mia fatica.
    ... motivo per cui la chiave con cui decifrare i file in questione deve stare altrove (=in mano all'utente, possibilmente su una smartcard o altro "token" fisico se i dati da proteggere sono seriamente importanti), al massimo tra i dati del programma potresti tenere giusto del "salt" da aggiungere alla chiave fornita dall'esterno per complicare le cose.
    Altra cosa: i file possono sempre essere copiati e crackati altrove; come posso impedirlo?
    Non puoi.
    Amaro C++, il gusto pieno dell'undefined behavior.

  3. #3
    Utente di HTML.it
    Registrato dal
    Dec 2012
    Messaggi
    15
    Vado con ordine.

    1) Ovviamente userò una versione modificata di un algoritmo noto: non mi lancio minimamente in creazioni da zero; mi sono espresso male, intendevo di mia invenzione nel senso che lo ottimizzo; pensavo anch'io all'AES, oppure all'RSA per farlo comunicare con un server online su cui salvare i file, ma è in alto mare per ora.

    2) Chiariscimi, in merito so poco e niente: come faccio a memorizzarne solo un hash?

    3) Sì, la chiave è in mano all'utente, il fatto è che comunque avendo l'algoritmo e dei file tutti uguali, formattati allo stesso modo, basta concentrarsi magari sulla prima riga, che rappresenta ad esempio il nome di battesimo del cliente, e metterci un buon algoritmo di crack e in un attimo si decodifica, rendendo poi facilissimo procedere riga per riga...

    4) Non è possibile rendere non copiabili/spostabili dei file? In nessun modo?

  4. #4
    Originariamente inviato da tenik
    1) Ovviamente userò una versione modificata di un algoritmo noto: non mi lancio minimamente in creazioni da zero; mi sono espresso male, intendevo di mia invenzione nel senso che lo ottimizzo; pensavo anch'io all'AES, oppure all'RSA per farlo comunicare con un server online su cui salvare i file, ma è in alto mare per ora.
    Consiglio: non toccare minimamente il "core" di un algoritmo crittografico se non sai esattamente cosa stai facendo. Per i non addetti ai lavori gli algoritmi di crittografia devono essere delle black box a cui passi chiave e dati e ti sputa fuori i dati cifrati. Se vuoi fare modifiche limitati alla chiave - eventualmente aggiungendo del salt fissato in testa o in coda o quel che ti pare; lascia stare l'algoritmo vero e proprio.
    Inoltre, occhio che AES e RSA sono due oggetti ben diversi e non intercambiabili, uno è un algoritmo di cifratura simmetrico (una chiave per cifrare e decifrare) e veloce, l'altro asimmetrico (una chiave per cifrare, una differente "complementare" per decifrare) e sensibilmente più lento; hanno usi piuttosto diversi.
    2) Chiariscimi, in merito so poco e niente: come faccio a memorizzarne solo un hash?
    Un hash crittografico è una funzione che trasforma rapidamente dei dati arbitrari in una sequenza di bytes di lunghezza fissata (quasi) univoca. Queste funzioni sono progettate perché
    - piccoli cambiamenti nell'input producano un cambiamento radicale nell'output;
    - dall'output sia praticamente impossibile risalire all'input in maniera;
    - garantiscano una probabilità di collisione (=dati diversi che generano lo stesso hash) estremamente piccola.
    Un uso classico degli hash crittografici è ad esempio per vedere se un file è arrivato intatto o è stato modificato durante il trasferimento; l'altro uso tipico è per (non) memorizzare in maniera sicura delle password.
    Quando l'utente registra la sua password per la prima volta il sistema non la memorizza in chiaro, ma ne memorizza soltanto l'hash. All'accesso il programma effettua l'hash della password fornita e lo confronta con l'hash memorizzato: se coincidono la password è corretta, se no è errata.
    In questa maniera la password non viene mai memorizzata in chiaro, e potrebbe anche essere usata senza particolari rischi come chiave di cifratura per i file di dati, dato che tra i dati del programma ne è memorizzato solo l'hash, e da esso non è possibile risalire alla password originale.
    3) Sì, la chiave è in mano all'utente, il fatto è che comunque avendo l'algoritmo e dei file tutti uguali, formattati allo stesso modo, basta concentrarsi magari sulla prima riga, che rappresenta ad esempio il nome di battesimo del cliente, e metterci un buon algoritmo di crack e in un attimo si decodifica, rendendo poi facilissimo procedere riga per riga...
    Questo è un rischio che si corre se si usano algoritmi di cifratura "amatoriali", algoritmi come AES sono pensati appositamente per non essere vulnerabili a questo genere di attacchi (i cosiddetti "known-plaintext attacks").
    4) Non è possibile rendere non copiabili/spostabili dei file? In nessun modo?
    No. Se il tuo programma ha la possibilità di leggerli, allora qualunque altro programma che viene eseguito sotto le sue stesse credenziali può farlo.
    Amaro C++, il gusto pieno dell'undefined behavior.

  5. #5
    Utente di HTML.it
    Registrato dal
    Dec 2012
    Messaggi
    15
    Capito. Ho cercato in giro mentre mi rispondevi, e ho scoperto che la classe Object ha un metodo hashCode, ma è abbastanza debole a quanto ho visto... esistono in java delle librerie/classi che permettono di hashare con algoritmi più sicuri, ad esempio MD5 o simili?

    Poi: sì, so che sono cose ben diverse AES e RSA, ma come dicevo uno mi serviva in locale, l'altro nell'eventualità di memorizzare i file non in locale ma su server... anche in questo caso, esiste un'implementazione di AES in java? Forse con javax.crypto?

  6. #6
    Originariamente inviato da tenik
    Capito. Ho cercato in giro mentre mi rispondevi, e ho scoperto che la classe Object ha un metodo hashCode, ma è abbastanza debole a quanto ho visto...
    Non c'entra, lì "hash" non è usato in senso crittografico; si tratta di hash usati per memorizzare oggetti in hash table e strutture analoghe, che hanno obiettivi diversi dalla sicurezza crittografica.
    esistono in java delle librerie/classi che permettono di hashare con algoritmi più sicuri, ad esempio MD5 o simili?
    anche in questo caso, esiste un'implementazione di AES in java? Forse con javax.crypto?
    Puoi avere facilmente una risposta cercando su Google...
    In ogni caso, MD5 non è più considerato sicuro come algoritmo di hashing, usa almeno SHA-1 o suoi successori.
    Poi: sì, so che sono cose ben diverse AES e RSA, ma come dicevo uno mi serviva in locale, l'altro nell'eventualità di memorizzare i file non in locale ma su server...
    Perché dovrebbe cambiare qualcosa? Se sul server carichi file cifrati in AES, la cui chiave sta in mano solo all'utente, non c'è bisogno di scomodare la crittografia asimmetrica. La crittografia asimmetrica entra in gioco quando i dati devono essere cifrati da un lato e decifrati dall'altro senza far passare in chiaro la chiave di decifratura (operazione invece necessaria nel caso della crittografia simmetrica).
    Amaro C++, il gusto pieno dell'undefined behavior.

  7. #7
    Utente di HTML.it
    Registrato dal
    Dec 2012
    Messaggi
    15
    Ho dovuto lurkare un bel po', ma alla fine ho trovato un'implementazione dell'SHA (tutti i tipi) in java... tramite la libreria java.security.MessageDigest. L'unico sbattimento è il fatto che non svolge tutto da sola, questa libreria: bisogna prima di tutto convertire la stringa in una sequenza di byte che utilizzi il charset di default (si fa tutto col metodo getBytes() di String), poi applicare la libreria, e in seguito riconvertire il risultato ottenuto in esadecimale dalla sequenza di bytes per ottenere un risultato completo.
    Spiego tutto per altri a cui servisse; linko anche la pagina della documentazione:
    http://docs.oracle.com/javase/6/docs...ageDigest.html
    dove c'è un esempietto di codice nella descrizione iniziale che in pratica fornisce tutto, tranne la ricostruzione dell'esadecimale.

    Quanto al criptaggio con AES, devo lurkare ancora

  8. #8
    Originariamente inviato da tenik
    Ho dovuto lurkare un bel po', ma alla fine ho trovato un'implementazione dell'SHA (tutti i tipi) in java... tramite la libreria java.security.MessageDigest. L'unico sbattimento è il fatto che non svolge tutto da sola, questa libreria: bisogna prima di tutto convertire la stringa in una sequenza di byte che utilizzi il charset di default (si fa tutto col metodo getBytes() di String), poi applicare la libreria, e in seguito riconvertire il risultato ottenuto in esadecimale dalla sequenza di bytes per ottenere un risultato completo.
    Be' nulla di strano, le funzioni di hash lavorano sui bytes, mentre tu hai una stringa (che potresti fornire alla funzione di hashing in un encoding a piacere); comunque, perché ti serve in esadecimale? Memorizza direttamente i bytes...
    Quanto al criptaggio con AES, devo lurkare ancora
    http://www.javamex.com/tutorials/cry...ymmetric.shtml
    Amaro C++, il gusto pieno dell'undefined behavior.

  9. #9
    Utente di HTML.it
    Registrato dal
    Dec 2012
    Messaggi
    15
    Grazie mille, alla fine sono riuscito.
    Mi rimane però un piccolo problema: dato che lascio all'utente il compito di impostare al primo avvio nome utente, password, ecc., sono costretto a memorizzare in un file esterno gli hashcode, e ad ogni avvio del programma verifico la sua esistenza: se c'è, allora procede all'avvio normale chiedendo username e password, se non c'è lo considera un "primo avvio" e quindi lo ricrea richiedendo username, password, ecc. Il mio problema quindi diventa: come impedisco che questo file possa essere cancellato o manomesso, senza dover intervenire sul codice sul pc destinatario salvando gli hash nel sorgente? Se ad esempio il programma finito lo mando per e-mail dall'altra parte d'Italia, spiegando che dal primo avvio pensa poi lui a fare tutto, e non serve il mio intervento, come posso anche rendere non modificabile e/o cancellabile dall'esterno del programma questo file? Può sempre succedere di cancellare la cosa sbagliata, come noto il peggior nemico dei computer è l'utente stesso... idee in merito? Senza dover usare software esterni, intendo, ma dall'interno dell'architettura java.

  10. #10
    A priori non è possibile rendere un file non modificabile - se la tua applicazione può modificarlo, allora anche l'utente può. Puoi rendere la cancellazione un po' più difficile (impostare ACL restrittive, impostare il file come "di sola lettura", ...), ma se l'utente è amministratore può fare quel che gli pare con i file custoditi sulla macchina.

    Tra parentesi, come mai tutti questi file txt? Non fai prima ad usare un qualche DB (anche cose molto semplici e file-based, tipo SQLite)?
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.