[JAVA] Java è decompilabile, rischio tutto?

[kuarl]

Originariamente inviato da netarrow
E' aggirabile solo con un bruteforce, ma tramite i salt e le interazioni è un algoritmo molto sicuro e usato, come concorrente ha SHA-1, ma c'è una leggenda che dice che per lui ci sia un algoritmo di ritorno... bhà....

riguardo questa leggenda:
sia per md5 che per sha1 esistono delle tecniche, sviluppate da dei matematici, che permettono di "accorciare" il brute forcing, questo non significa che forzare una di queste chiavi sia alla portata di tutti, anche xke più lunga è la stringa sorgente, più lungo sarà il brute forcing, e per stringhe almeno di 10 caratteri, anche con queste tecniche particolari, ci vogliono anni di elaborazione per un computer comune

[netarrow]

Originariamente inviato da kuarl
riguardo questa leggenda:
sia per md5 che per sha1 esistono delle tecniche, sviluppate da dei matematici, che permettono di "accorciare" il brute forcing, questo non significa che forzare una di queste chiavi sia alla portata di tutti, anche xke più lunga è la stringa sorgente, più lungo sarà il brute forcing, e per stringhe almeno di 10 caratteri, anche con queste tecniche particolari, ci vogliono anni di elaborazione per un computer comune

verissimo era scontato , il fatto che sia teoricamente possibile non indica che sia praticamente possibile, a meno che non si usino migliaia di super computer in contemporanea, ma penso che i tuoi dati d'accesso all'ftp non siano così interessanti da forzarli a tutti i costi

Riguardo l'ofuscatore, se il tuo programma è di piccole dimensioni sarà cmq facilmente comprensibile, gli ofuscatori non fanno altro che sostituire i nome auto-esplicitativi in nomi insignificanti tipo a, a1, kkTrW_D, class2, class3, metoto ecc... Inoltre alcuni aggiungono qua e la dei dicli iterativi che fanno operazioni assurde mai chiamate, altri spostano anche le dichiarazioni senza seguire ordini logici, infine ce ne sono alcuni che, non so come, fanno in modo che quando viene decomnpilato il programma vengano aggiunti dei continue etichetta, dei break etichetta mai messi nel sorgente originale e pure dei goto, che Java riconosce come parola chiave ma non te la fa usare(quindi non compila), poi ho visto che certi valori vengono convertiti in altre basi, ottale, hex ecc..., in alcuni programmi anche le stringhe diventano incomprensibili.
Ti assicuro che funziona MOLTO bene per programmi di medie/grandi dimensioni, se vuoi un assaggio scaricati qualche applet della anfy teem(www.anfyteam.com/) che ha tutte le modifiche sopra indicate, non si capisce NIENTE.


Visto che anche'io non conosco ofuscatori free(solo persone conosco che scrivono codice incomprensibile per mano loro :maLOL: )potresti limitare la protezione solo ai tuoi dati se il tuo scopo è: ricevere in input password, utente e host e confrontare con i dati giusti

1) prendi la password giusta e ci attacchi 12 byte casuali all'inizio (salt)
2) calcoli l'hash di tutto(compreso il salt)
3) all'hash risultate ci riattacchi gli stessi 12 byte del salt
4) se vuoi complicare di più le cose usi delle iterazioni, ovvero calcoli l'hash dell'hash dell'hash per tot volte.

Fatto questo salvi il valore ritornato(s vuoi che la stringa corrisponda allo standars ASCI usa BASE64).

Per controllare che sia giusto il valore inserito a run-time prendi il salt salvato dell'hash precedente, lo attacchi alla stringa inserita e rifai gli stessi procedimenti di prima, se l'hash sarà uguale a quello vecchio il dato è giusto.

Se invece il tuo programma usa i tuoi dati automaticamente(si connette senza che vengano inseriti a run-time) potresti usare i "saled-object", sulla 1.2 funziona solo con le stringhe, ma nel tuo caso non dovrebbe dare problemi inoltre non credo abbia un jdk così vecchio.
Praticamente serializzi i dati crittandoli, ora ho il dubbio se funziona solo con il bouncycastle o anche con quell'oscenità di provider si Sun. In questo caso però si aprirebbe un altro problema, dover salvare la chiave, inoltre dati delicati come password utenti ecc... non dovrebbero andare messi in String visto che essenco final non potresi pulire per bene la memoria e qualche programmino a basso livello potrebbe scrutare grandi spazi di memoria trovando tracce di password in chiaro, quindi usa un char[] e quando finisci di usarlo resettalo per bene con 0x0.