Passwort verwenden ohne dass es im Quelltext steht

[Bogomier]

Hallo,

gibt es eine Lösung, wie ich auf ein Passwort in einer Java-Klasse zugreifen kann, ohne dass es im Klartext, für jedermann lesbar, im Quellcode steht??

Habe schon die Suche strapaziert aber keine befriedigende Lösung gefunden...

Bin für jeden Hinweis dankbar.

 

[Der Müde Joe]

hashe das Passwort und vergleiche den Hashwert des eingegebenen Passwortes mit dem Hashwert des Pw im Quellcode

 

[madboy]

Kommt darauf an, was du machen wilst. Willst du eine Datenübertragung verschlüsseln oder dich authentifizieren, ...
Da gäbe es schon Möglichkeiten.

Als direkte Antort auf deine Frage würde ich aber sagen: nein

Edit: mit einem Hash könnte es auch klappen wie Der Müde Joe geschrieben hat. Kommt wie gesagt drauf an, was du mit dem Passwort machen willst.

 

[Bogomier]

Also,ich schreibe eine Anwendung, bei der eine Mail generiert und verschickt wird.

Um die Mail verschicken zu können, muss ich ja Username und Passwort irgendwo im Quelltext angeben. Nur wäre das nicht so toll, wenn die Mailkonto-Daten im Klartext im Code stehen...

Der User soll also nirgends die Daten eingeben sondern der Mailversand soll automatisch erfolgen.

Im Tutorial von jGuru zur JavaMailAPI steht, man kann die Daten aus einem verschlüsselten Config-File einlesen. Weiss aber nicht wie ich das anstellen soll.

 

[madboy]

Wenn es ein Tutorial ist, frag doch den Ersteller :wink:
Oder poste mal nen Link oder Code. Bin grad n bisschen zu faul zum suchen

 

[Bogomier]

Hier der Link zum Tutorial

http://java.sun.com/developer/onlineTraining/JavaMail/contents.html#JavaMailAuthenticator

steht halt leider nix genaues drin über das verschlüsselte Speichern des Passworts in einer Datei.

Werde mal noch weiter recherchieren, wenn jemand Ideen hat, gerne her damit

 

[Murray]

Aber selbst wenn Benutzername und Password in einer verschlüsselten Datei stehen, dann steht doch der Mechansimus zum Entschlüsseln wieder im Quelltext, so dass jemand, der Zugriff auf den Quelltext und die Datei hat, doch wieder an die Klartexte kommt.

 

[Gast]

habs nur kurz überflogen, aber es sieht so aus, als bräuchte die session das passwort im klartext.

die einfachste variante ist jetzt, dass du in PasswordAuthentication#getPassword ne kleine entschlüsselung einbaust und das passwort entsprechend verschlüsselt in nem string vorhältst. sicher ist das nicht, aber es verhindert zumindest, dass das passwort schon direkt im class file in reintext steht.

die nächste stufe wäre, dass passwort von einem servlet liefern zu lassen, das auf deinem eigenen server rennt. dann müsste nen cracker schon die kommunikation sniffen oder nen memory dump der vm durchforsten, um das passwort zu finden.

und die dritte stufe ist, das mail versenden komplett an nen servlet zu übergeben und den client nur den inhalt senden zu lassen. auslagerung ist die einzig sichere art, inhalte zu schützen.

 

[Bogomier]

Danke für die antworten.

Die Situation ist die, dass andere Leute (in diesem Falle meine Profs.) Zugriff auf alle Quelltexte haben.

Somit bringt die Auslagerung in andere Quelldateien leider nicht viel.

So wie ich das sehe, kann ich es dann auch gleich im Klartext drin stehen lassen...

 

[Guest]

Guck dir mal die Klasse javax.crypto.Cipher.java an. Damit kannst du byte[] ver- und entschlüssel.

Das wird bei uns z. B. genutzt um JAR-Files zu erzeugen, in denen verschlüsselte Dateien liegen. Wenn man den Algorythmus der Verschlüsselung kennt (der dann bei dir ja im Quelltext stehen würde) kann man zwar die Daten trotzdem entschlüsseln, im Ganzen ist das aber immer noch "sicherer" als das Passwort gleich im Quelltext zu schreiben, da man es halt erst vorsätzlich entschlüsseln müsste um den genauen Text zu erfahren.

 

[MasterEvil]

Wie wäre es mit einem anonym zu nutzenden popServer oder so?
Ansonsten, wie der Gast schon sagte, einfach nur den Mailinhalt an den Server per Servlet oder php-Script, ist ja kein großer Aufwand!

 

[Xams]

Oder du verschlüsselst die ganze Klasse und schreibst einen Classloader, der sie bei Verwendung wieder entschlüsselst.
Diesen Loader packst du mit einigen anderen unsinnigen Klassen versteckt in ein package ala my.mail.test. Da packst du dann einige Klassen rein und nennst die Test1, Test2, Test3,... und darunter ist auch dein KLassloader.
Klingt kompliziert, ich weiß.
Das verhindert aber, das jemand deine Klasse einfach decompiled.
MFG

 

[André B.]

Oder er macht den ClassLoader einfach ganz normal in ein Package (z.B. my.loader) und macht das ganze nachher mit nem Obfuscator unkenntlich.
http://de.wikipedia.org/wiki/Obfuscator

 

[L-ectron-X]

Ein Obfuscator macht aber doch nur Namen von Klassen und Variablen unkenntlich. Ein String würde dennoch lesbar bleiben...

 

[André B.]

Das ist klar. Mir ging es mehr um den Klassenlader, den er so nicht unbedingt zwischen 5 Klassen mit dem Namen Testx verstecken muss.
Mfg André

 

[Guest]

hashe das Passwort und vergleiche den Hashwert des eingegebenen Passwortes mit dem Hashwert des Pw im Quellcode

Das ist die Methode der Wahl. Aus dem Hash des Passwortes ist das Passwort NICHT mehr identifizierbar. So macht das z.B. auch UNIX. Da stehen die Hashes der Passwörter in einer Datei.

Wichtig ist dabei nur, dass Du eine kryptografische Hash-Funktion verwendest und nicht etwa die hashCode()-Methode der Klasse String, die hat mit dem ganzen nämlich nix zu tun

Fred

 

[Murray]

hashe das Passwort und vergleiche den Hashwert des eingegebenen Passwortes mit dem Hashwert des Pw im Quellcode

Das ist die Methode der Wahl. Aus dem Hash des Passwortes ist das Passwort NICHT mehr identifizierbar. So macht das z.B. auch UNIX. Da stehen die Hashes der Passwörter in einer Datei.

Natürlich wäre das eine Lösung - allerdings setzt die - ähnlich wie die Idee mit dem Auslagern der Mail-Funktionalität in ein Servlet - voraus, dass auf der Serverseite eine neue Infrastruktur vorgeschaltet wird, die dann wieder das gleiche Problem hat: der Mailserver braucht zur Authentifizeriung nunmal das Passwort im Klartext. Man sichert dann zwar die Übertragungsstrecke; im konkreten Fall ging ja aber wohl darum, dass der TE verhindert wollte, dass sein Prof das Passwort - oder den Algo, wie man das Passwort ermitteln kann - irgendwo im Code sieht.

 

[tuxedo]

Das Problem ist doch fast analog zu dem Problem die Klassen so zu verschlüsseln dass ein decompilieren sogut wie unmöglich ist?!

Solange der Mailserver kein bereits verschlüsseltes Passwort entgegen nimmt muss entweder

a) das Passwort im Klartext verwendet werden
oder
b) das Passwort verschlüsselt im Code stehen, wobei es vor dem senden entschlüsselt werden muss und man somit mittels decompilieren wieder eine Anleitung zum entschlüsseln hat.

Auch das Passwort anderso auslagern macht wenig Sinn. Schließlich muss es von der Anwendung ja anfefordert werden. Und nach dem decompilen hat man auch dazu wieder die Anleitung.

- Alex

 

[moormaster]

Kannst du mal erklären, wo dein Programm läuft und zu welchem Zweck es dient?

Falls das Programm beim Nutzer lokal läuft: Wäre es nicht machbar, dass jeder Nutzer seine eigenen Zugangsdaten von seinem Mailprovider eingeben muss, damit die Mails verschickt werden können? Dann würden die Zugangsdaten lokal bei jedem Nutzer in irgendeiner Config-Datei auf der Festplatte schlummern und niemand muss deine Zugangsdaten erfahren.

 

[Murray]

Kannst du mal erklären, wo dein Programm läuft und zu welchem Zweck es dient?

Falls das Programm beim Nutzer lokal läuft: Wäre es nicht machbar, dass jeder Nutzer seine eigenen Zugangsdaten von seinem Mailprovider eingeben muss, damit die Mails verschickt werden können? Dann würden die Zugangsdaten lokal bei jedem Nutzer in irgendeiner Config-Datei auf der Festplatte schlummern und niemand muss deine Zugangsdaten erfahren.

Der User soll also nirgends die Daten eingeben sondern der Mailversand soll automatisch erfolgen.

 

[tuxedo]

Muss denn die Mail zwingend über einen fest definierten Mailserver erfolgen? Geht's nicht dass der User einmal konfiguriert über welchen Mailserver mit welchem Benutzer und Passwort die Email gesendet werden soll?

- Alex

 

[moormaster]

Ok

Also wie gesagt wenn sich jeder die Anwendung lokal installiert, dann sollte man vielleicht drüber nachdenken, ob nicht jeder seine eigenen Zugangsdaten für Mailversand nutzen können sollte.

Falls das Programm eine Art Online-Service darstellt, dann würde ich mich dem Anschliessen, dass man sich einen Server im Internet einrichtet, welcher die zu versendenen Mails entgegennimmt und absendet, ohne dass Passwörter zu diesem Server hin übertragen werden müssen.

Falls du unbedingt in deinem Programm Zugangsdaten unterbringen musst: Kann man sich dafür nicht einen extra FreeMail Account machen, der nur dafür angemeldet wurde? So dass man sozusagen keinen Nutzen von dem Passwort hat? (Ausser jemand nutzt das Passwort, um in den Einstellungen beim Free-Mail-Account herumzufuschen )

 

[Bogomier]

War ja einiges los hier

Also das Programm ist Teil einer Public-Key-Infrastruktur.

Der User gibt Daten in ein Web-Formular ein, im Hintergrund wird ein Zertifikat (aus den User-Daten) für einen öffentlichen Schlüssel für Public-Key-Kryptographie erstellt und das Zertifikat wird anschließend per Mail verschickt.

Die Quellen liegen also auf dem Server. Der juser hat gar nix mit Konfiguration zu tun, sondern gibt nur seine Mailadresse als Empfänger ein.

Problem ist nur dass meine Profs zur Beurteilung Einsicht in den Quellcode haben. Daher habe ich mich gefragt wie man das lösen kann, ohne dass die Profs in irgendeiner Form Zugang zu den Klartext-Account-Daten haben (Nicht dass ich meinen Profs böse Absichten unterstellen würde )

Falls du unbedingt in deinem Programm Zugangsdaten unterbringen musst: Kann man sich dafür nicht einen extra FreeMail Account machen, der nur dafür angemeldet wurde? So dass man sozusagen keinen Nutzen von dem Passwort hat? (Ausser jemand nutzt das Passwort, um in den Einstellungen beim Free-Mail-Account herumzufuschen )

Das ist momentan mein Stand der Dinge. So werde ich es wohl handhaben. Alles andere ist irgendwie eine Verlagerung des Problems, wie ich das sehe.

Danke für eure Vorschläge, wenn jetzt nicht noch die ultimative Lösung kommt, belasse ich es dabei, wie eben geschildert.

 

[moormaster]

Mal ne andere Frage: Kann man nicht auf dem gleichen Server, wo das Programm läuft, einfach einen SMTP Server installieren und dann diesen nutzen, um die Mails zu versenden?

 

[Bogomier]

ja wäre sicher möglich und ne gute lösung. Allerdings müsste ich mich da erst in Mailserver-Geschichten einarbeiten, wofür mir die Zeit fehlt.