Erste Schritte Verschlüsselung / Login-Sicherheit

[muemme]

Hallo,
ich habe ein Datenverwaltungsprogramm im Java-Editor geschrieben. Ich würde für dieses Projekt jetzt anschließend einen Login programmieren. Wie das an sich funktioniert, wüsste ich, aber die Sicherheit ist jetzt hier ein problem. Das Programm liest aus Textdatein Daten aus, was eine Sicherheitslücke wäre, da jeder einfach diese textdateien öffnen könnte und die wert ändern könnte. Auch beim Login das Passwort söllte auf irgendeine Weise verschlüsselt werden.
Wie könnte ich das anstellen zw. könntet ihr mir ein paar Links zum nachlesen geben?

 

[thet1983]

was wird ausgelesen? Programm relevante Daten?

Wo wird das Passwort abgelegt? Datenbank? ConfigFile?

 

[Thallius]

Ich speichere meine Kpnfigurations Daten auch immer in XML Files. Damit diese nicht von jedem geändert werden können erzeuge ich einfach einen sha512 hash aus dem Text kombiniert mit einem salt und speichere ihn als Tag mit in dem file. Beim einladen der Daten überprüfe ich ob der hash noch stimmt. Wenn jetzt jemand auch nur 1 Zeichen in der Datei ändert wird die Datei nicht mehr akzeptiert.

Gruß

Claus

 

[mrBrown]

Ich speichere meine Kpnfigurations Daten auch immer in XML Files. Damit diese nicht von jedem geändert werden können erzeuge ich einfach einen sha512 hash aus dem Text kombiniert mit einem salt und speichere ihn als Tag mit in dem file. Beim einladen der Daten überprüfe ich ob der hash noch stimmt. Wenn jetzt jemand auch nur 1 Zeichen in der Datei ändert wird die Datei nicht mehr akzeptiert.

Außer man ändert einfach ebenso den entsprechenden Tag, und schon bringt es nichts mehr

 

[Thallius]

Außer man ändert einfach ebenso den entsprechenden Tag, und schon bringt es nichts mehr

Und wie bitte willst du den Tag ändern wenn du den Salt nicht hast?

Manchmal glaube ich du hältst mich für komplett bescheuert und schreibst aus Prinzip immer irgendwas gegen mich....

 

[mrBrown]

Und wie bitte willst du den Tag ändern wenn du den Salt nicht hast?

Auf den man Zugriff hat, weil man die jar bei sich aufm Rechner liegen hat^^

Manchmal glaube ich du hältst mich für komplett bescheuert und schreibst aus Prinzip immer irgendwas gegen mich....

Natürlich, aber das ist mit jedem so


Ich halte es einfach nur in den meisten Fällen für ziemlich Sinnfrei, außerhalb der jar liegende config-Daten zu sichern. Die sind schließlich im Normalfall dafür gedacht, geändert zu werden - ob jetzt vom Programm oder vom User macht in den wenigsten Fällen einen Unterschied, invalider Inhalt wird ja sowieso aussortiert...

 

[Thallius]

Auf den man Zugriff hat, weil man die jar bei sich aufm Rechner liegen hat^^


Natürlich, aber das ist mit jedem so


Ich halte es einfach nur in den meisten Fällen für ziemlich Sinnfrei, außerhalb der jar liegende config-Daten zu sichern. Die sind schließlich im Normalfall dafür gedacht, geändert zu werden - ob jetzt vom Programm oder vom User macht in den wenigsten Fällen einen Unterschied, invalider Inhalt wird ja sowieso aussortiert...

Nein das sind sie eben nicht. Eine config Datei ist für mich keine Settings Datei. Ich habe zum Beispiel eine applikation die je nach Land wo sie deployed wird auf ein anderes backend zugreift. Diese Konfiguration findet nun in einer XML Datei statt. Der Admin hat ein Tool mit dem er das File nach einer Änderung wieder validieren kann. Der User kann das nicht. Damit kann der Admin ohne Änderung der applikation die Installationen vornehmen. Und der Salt ist natürlich hart codiert. Und klar wenn der User sich jetzt die Mühe macht und das obfuskierte Jar decompiliert und sucht, dann wird er diesen irgendwo finden aber wir wissen ja wohl beide dass eben immer nur eine vertretbare Sicherheit gibt und keine perfekt.

 

[mrBrown]

Nein das sind sie eben nicht. Eine config Datei ist für mich keine Settings Datei. Ich habe zum Beispiel eine applikation die je nach Land wo sie deployed wird auf ein anderes backend zugreift. Diese Konfiguration findet nun in einer XML Datei statt. Der Admin hat ein Tool mit dem er das File nach einer Änderung wieder validieren kann. Der User kann das nicht. Damit kann der Admin ohne Änderung der applikation die Installationen vornehmen. Und der Salt ist natürlich hart codiert. Und klar wenn der User sich jetzt die Mühe macht und das obfuskierte Jar decompiliert und sucht, dann wird er diesen irgendwo finden aber wir wissen ja wohl beide dass eben immer nur eine vertretbare Sicherheit gibt und keine perfekt.

Die Applikation schluckt also einfach so jegliche Settings, völlig egal ob die überhaupt valide sind?
Das nenn ich mal defensiv programmiert

Wenn der Nutzer keinen Schreibzugriff auf die Setting haben soll, gehören die einfach an einen Ort, wo er keinen Schreibzugriff hat. Das sollte nicht davon abhängen, ob der Admin dran gedacht hat, die Datei zu validieren...

 

[Thallius]

Die Applikation schluckt also einfach so jegliche Settings, völlig egal ob die überhaupt valide sind?
Das nenn ich mal defensiv programmiert

Wenn der Nutzer keinen Schreibzugriff auf die Setting haben soll, gehören die einfach an einen Ort, wo er keinen Schreibzugriff hat. Das sollte nicht davon abhängen, ob der Admin dran gedacht hat, die Datei zu validieren...

Du hast gewonnen. Ich bin einfach ein überbezahlter idiot der nur Schrott programmiert und dummerweise dafür mit einem dreistelligem stundensatz bezahlt wird. Aber weis du was: irgendwie kann ich ziemlich gut damit leben...