Java - ent/verschlüsseln

[Julius]

Hallo,
Ich schreiben im Moment für ein Programm die Passwort verschlüsselung, diese werden mit AES verschlüsselt und in verschiedenen Dateien geschrieben.
So weit so gut, aber ich muss dafür immer die selben Schlüssel benutzen, wenn jetzt aber jemand meine *.jar einfach decompiliert kann er diese ja sehen.
Wie kann ich das verhindern?
Kennt irgendwer einen sicheren freeware anti-decompiler?

Danke,
Julius

 

[madboy]

So weit so gut, aber ich muss dafür immer die selben Schlüssel benutzen, wenn jetzt aber jemand meine *.jar einfach decompiliert kann er diese ja sehen.

Lass den Benutzer den Schlüssel eingeben.

Wie kann ich das verhindern?

Siehe oben, sonst gar nicht.

Kennt irgendwer einen sicheren freeware anti-decompiler?

Es gibt nur Obfuscatoren, die es für den Menschen schwieriger machen, den dekompilierten Code zu lesen. Unmöglich ist das Auslesen des Schlüssels damit nicht, nur ein wenig schwieriger.

Siehe auch
http://www.java-forum.org/de/viewtopic.php?t=62076
und
http://www.java-forum.org/de/viewtopic.php?t=61985

 

[HeRaider]

Das kann man leider nicht verhindern. Man kann es den Leuten jedoch schwerer machen den Code nach dem decompilieren zu verstehen indem man Obfuscatoren einsetzt.
Ich würde da ProGuard empfehlen. Ist sehr zuverlässig und hat bei mir noch nie Probleme verursacht: http://proguard.sourceforge.net/

 

[Wildcard]

Bitte keine weiteren Obfuscatoren empfehlen. Aus offensichtlichen Gründen sind die hier nicht zu gebrauchen und ich möchte vermeiden das Julius die Sache missversteht, sich einen Obfuscator besorgt und dann später angibt die Passwörter seien in seinem Programm XY sicher aufgehoben.

 

[HeRaider]

Ich hab doch nie behauptet, dass die Passwörter dann sicher sind. Dazu hab ich ja nicht mal was geschrieben.
Die Passwörter werden denke ich mal als Strings im Code vorhanden sein. Das heißt also nur, dass der Code um die Passwörter herum schwer zu lesen ist. Der String an sich bleibt natürlich vollständig erhalten (und das muss er ja auch). Mein Kommentar bezog sich nur auf den "anti-decompiler".

 

[Wildcard]

Ich sage auch nicht das du das behauptet hast, ich will bei soetwas sensiblem wie Passwörtern einfach nur Missverständnisse vermeiden. Der Obfuscator wird ja aus genau dem Grund gesucht ein PW zu schützen. Das funktioniert nicht, daher wird wohl auch kein Obfuscator mehr benötigt.

 

[maki]

diese werden mit AES verschlüsselt und in verschiedenen Dateien geschrieben.

Das ist das Problem.

Sobald du diese "Dateien" welche die Passwörter beinhalten auslieferst, kann so ziemlich jeder Javaentwickler darauf zugreifen.

 

[tincup]

Sobald du diese "Dateien" welche die Passwörter beinhalten auslieferst, kann so ziemlich jeder Javaentwickler darauf zugreifen.

Ich denke er meinte, dass nicht die Passwörter selbst in Dateien geschrieben werden, sondern die verschlüsselten Daten. Das Passwort sitzt hard-coded im Code und das ist das Problem. Das ist schon rein von der Logik her nicht lösbar. Wenn die Java VM das Passwort rauskriegt (durch Laufenlassen des Codes), kann das theoretisch jeder. Sicher wäre wirklich nur die Eingabe durch einen Benutzer.

Eventuell könnte man versuchen, den String im Code auf komplizierteste Art und Weise zusammenzubauen, aber sicher wäre das natürlich immer noch nicht. Hängt dann von der Sensibilität der Daten ab.

 

[HeRaider]

Eventuell könnte man versuchen, den String im Code auf komplizierteste Art und Weise zusammenzubauen, aber sicher wäre das natürlich immer noch nicht. Hängt dann von der Sensibilität der Daten ab.

Die Verschlüsselung ist dann immer noch genauso unsicher wie vorher da der Code der dieses Zusammenbauen übernimmt ja auch einsehbar ist.
Sicherer wäre es wohl wenn man das Passwort verschlüsselt extern ablegen könnte (z.B. auf nem Server).
Wenn der User dann das Passwort eingeben sollte wird dieses ebenfalls verschlüsselt und dann mit dem gespeicherten Passwort verglichen.
Man kann zwar immer noch nicht behaupten, dass es absolut sicher ist aber es wäre zumindest sicherer als das Passwort im Code zu verstecken.

 

[Xams]

Man könnte auch nur den MD5 speichern und den mit dem eingegebenen Passwort vergleichen

 

[Julius]

Vielen Dank für die vielen Antworten erstmal....

Die Passwörter sind das was in die Dateien geschrieben wird, der Schlüssel für die Datei mit den Passwörtern ist das Problem.

Ich denke es es ist nicht besonders benutzerfreundlich wenn man dem User einen Schlüssel gibt (den er vor dem Passwort eingeben muss), der ungefähr so aus sieht: "8c06da19e61c1497815b56cef46c58b6" .

Ich frag mich bloß wie das andere Programme machen die mit Passwörtern arbeiten, die werden die ja auch nicht als String speichern.

Was ist MD5?

Julius

 

[Wildcard]

Wenn dein Programm Passwörter speichern und verschlüsseln soll, dann ist das Masterpasswort des Users der Schlüssel zu den gespeicherten Passwörtern.

 

[Julius]

Okay, MD5 wäre eine Möglichkeit, aber:

Eine andere Angriffsmethode stellen Rainbowtables dar. Hier wird eine sehr große Liste mit MD5-Einträgen erstellt. Diese Liste wird dann mit dem gesuchten Hash verglichen. So ist es sehr einfach, Passwörter, die als MD5 gespeichert sind, zu entschlüsseln. Ab einer bestimmten Länge des Passwortes ist diese Attacke allerdings nicht mehr möglich, da die Berechnung solcher Listen enorm zeitintensiv ist und sehr viel Speicherplatz benötigt. Es gibt allerdings fertige Listen, die bis zu einer Länge von 8 Zeichen gehen, dabei werden Klein- und Großbuchstaben, sowie Zahlen verwendet.

sieht nicht so sicher aus... aber ich denke die Idee geht in die richtige Richtung

Vielen Dank,
Julius

 

[Julius]

Wenn dein Programm Passwörter speichern und verschlüsseln soll, dann ist das Masterpasswort des Users der Schlüssel zu den gespeicherten Passwörtern.

Es verschlüsselt aber keine Passwörter sondern es bracht ein Passwort um geöffnet zu werden....

Julius

 

[Guest]

Okay, MD5 wäre eine Möglichkeit, aber:

Eine andere Angriffsmethode stellen Rainbowtables dar. Hier wird eine sehr große Liste mit MD5-Einträgen erstellt. Diese Liste wird dann mit dem gesuchten Hash verglichen. So ist es sehr einfach, Passwörter, die als MD5 gespeichert sind, zu entschlüsseln. Ab einer bestimmten Länge des Passwortes ist diese Attacke allerdings nicht mehr möglich, da die Berechnung solcher Listen enorm zeitintensiv ist und sehr viel Speicherplatz benötigt. Es gibt allerdings fertige Listen, die bis zu einer Länge von 8 Zeichen gehen, dabei werden Klein- und Großbuchstaben, sowie Zahlen verwendet.

sieht nicht so sicher aus... aber ich denke die Idee geht in die richtige Richtung

Vielen Dank,
Julius

Benutze einen Salt. Dann ist das mit den Rainbowtables nicht so schlimm

 

[Wildcard]

Es verschlüsselt aber keine Passwörter sondern es bracht ein Passwort um geöffnet zu werden....

Dann lass den User eins eingeben und gut, ich verstehe das Problem nicht. Dein Programm muss das Passwort dazu ja nicht kennen.

 

[Julius]

Und wie funktioniert ein Salt?
Ich muss zugeben das ich den Wikipedia artikel nicht ganz verstehe...

[Okay, wie mein Programm funktioniert:
1. User macht Passwort
2. Passwort wird verschlüsselt und gespeichert
3. User nutzt das Programm....
4. schließt Programm
5. User will Programm wieder öffnen
6. Passwort wird aus Datei eingelesen und decrypted
7. Passwort wird abgefragt
8. User gibt Passwort falsch oder richtig ein
9. Passwörter werdeb verglichen
10. Wenn positiv kann User Programm wieder benutzen]



Vielen Dank,
Julius

 

[Wildcard]

Wenn du mit dem Passwort Daten verschlüsseln willst brauchst du weder einen Hash noch musst du dir das Passwort speichern.
Du kannst die verschlüsselte Datei einfach mit einer Prüfsumme versehen. Wenn die Prüfsumme mit dem angegebenen Passwort zu den entschlüsselten Daten passt, war das Passwort richtig.
Wenn es nur um das Passwort geht, kannst du dir einen salted hash speichern.

 

[Julius]

Wenn du mit dem Passwort Daten verschlüsseln willst ...

Nein will ich nicht...

einen salted hash speichern.

Ja, aber wie mache ich das, bzw. wie vergleiche ich denn mit der einagabe...

....

Vielen Dank,
Julius

 

[Wildcard]

In dem du erneut einen salted hash von der Eingabe generierst und mit dem gespeicherten Wert vergleichst.

 

[Julius]

Gibt es in java eine Klasse mit der ich einen Salted Hash mache? - Ja Message Digest
Wird zu dem Hash das Salz hinzugefügt oder zu dem String(in diesem Fall das Passwort)? - Zu dem Message Digest Object
Ist das "Salz" zufall? - Nein
Ist das "Salz" ein String, oder int oder byte[] oder....? - String
...?????
Vlt. hat ja jemand ein Beispiel (oder eine gute Seite)...? - Hier

Okay alles selbst beantwortet außer... was nehme ich als Salt/Salz am besten, was nicht standart (wie e-mail, name ...) ist??
Und unterstützt Java SHA256?


Vielen Dank
Julius