Zugangsdaten halbwegs sicher speichern

[cmrudolph]

Hi,

ich bin auf der Suche nach einer Best Practice was die Speicherung von Zugangsdaten angeht.

Zuerst einmal möchte ich darum bitten, dass nicht alle sofort antworten, ich solle erst einmal die SuFu oder Google nutzen. Die Quintessenz ist, dass es nicht möglich ist. Das ist mir klar, denn wann immer eine Applikation Daten im Klartext benötigt, müssen sie irgendwo im Programm lesbar gespeichert werden.

Primär geht es mir um die Speicherung von Zertifikaten und Passwortstrings (wobei die Zertifikate auch auf die Speicherung eines Passwortstrings - einer Passphrase - zurückführbar sind) um Zugang zu Webservices zu bekommen.

Die Lösung das Problem in einen Webservice zu verlagern zählt nicht, denn dort würde ich das Problem auch gerne "lösen".

Der naive Ansatz wäre, die Zugangsdaten in einer Konfigurationsdatei zu speichern und diese mit dem Verfahren meiner Wahl zu verschlüsseln. Der Schlüssel dafür müsste aber auch irgendwo gespeichert werden - das Problem besteht also immer noch.

Ein weiterer Ansatz wäre, die Zugangsdaten mit einem Nutzerpasswort zu verschlüsseln. Dies kommt allerdings nicht infrage, weil man keine weiteren Nutzer anlegen könnte, die das Passwort ebenfalls entschlüsseln könnten. Das ginge nur, wenn ein anderer Nutzer, der das Passwort bereits kennt, das Passwort weitergäbe.

Das einzige was mir jetzt noch einfällt ist die Möglichkeit, das Passwort wie oben beschrieben in eine verschlüsselte Konfigurationsdatei auszulagern und einen Obfuscator zu verwenden, um das Auffinden der Routine zum entschlüsseln etwas unkenntlicher zu machen... Nichtsdestotrotz ließe sich der verschleierte Quellcode aber dennoch zurückgewinnen und man könnte die Anwendung auch noch debuggen...

Nahezu jeder Webservice benötigt doch Zugangsdaten und immer lese ich nur den Hinweis: "Die Zugangsdaten sollten auf keinen Fall im Quellcode gespeichert werden. Das ist hier nur aus Demonstrationszwecken so gemacht."

Gibt es zu diesem Thema eine Best Practice?

 

[bone2]

hash ist das stichwort.

speicher vom passwort und name nur den hash, schon kann man es nicht mehr zurückverwandeln in den eigentlichen string.

bleibt nur noch das problem, das jemand nen hexeditor aufmacht udn einfach den gespeicherten hashwert im programmcode ändert

 

[maki]

Worum geht es denn?
Zugangsdaten auf dem Server oder auf dem Client?
Letzteres ist immer problematisch, weil der Client eben "alles" hat.

 

[cmrudolph]

Mir geht es um Clientanwendungen, da ich Serveranwendungen genauso behandeln möchte, wie Clientanwendungen. Wenn der Server kompromittiert wird, sollten die Zugangsdaten nicht unbedingt gleich auf dem Silbertablett präsentiert werden.

Hash ist leider das falsche Stichwort. Es geht hier nicht um Authentifizierung, sondern um "sichere" Speicherung von Zugangsdaten.

 

[maki]

Mir geht es um Clientanwendungen, da ich Serveranwendungen genauso behandeln möchte, wie Clientanwendungen. Wenn der Server kompromittiert wird, sollten die Zugangsdaten nicht unbedingt gleich auf dem Silbertablett präsentiert werden.

Naja, wenn ein Server kompromitiert wird, ist nix mehr sicher.

Muss denn der Client selber die Zugangsdaten haben/speichern?
Systeme wie LDAP, Kerrberos etc. stellen soz. eine Benutzerdatenbank dar, an ihr kann man sich authentifizieren und muss selber kein Zugansdaten speichern.
Best Practise ist wirklich, dass man es vermeidet selber die Zugangsdaten zu speichern, denn dann hat man selber das Problem am Hals

 

[cmrudolph]

Der Client muss eigentlich keine Zugangsdaten speichern. Eine Infrastruktur wie LDAP zusätzlich aufzusetzen ist glaube ich ein Overkill.
Vor allem, weil ich zeitgesteuerte Abläufe habe, die auch nach einem Serverneustart (Stromausfall) problemlos weiterlaufen sollen, ohne dass sich ein Admin erstmal einloggen muss.

Mir ist auch das Prinzip bekannt, dass man immer mit minimalen Rechten arbeiten sollte. Daran haben aber viele Webservice Entwickler nicht gedacht und geben einem immer Vollzugriff, sobald man gültige Zugangsdaten hat. Von einer Rechteverwaltung kann man meist nur träumen.
Bei der Datenbankanbindung ist das kein Problem, dort habe ich Nutzer, die nur das können, was sie sollen (Rollenverteilt).

 

[maki]

Der Client muss eigentlich keine Zugangsdaten speichern. Eine Infrastruktur wie LDAP zusätzlich aufzusetzen ist glaube ich ein Overkill.
Vor allem, weil ich zeitgesteuerte Abläufe habe, die auch nach einem Serverneustart (Stromausfall) problemlos weiterlaufen sollen, ohne dass sich ein Admin erstmal einloggen muss.

Naja, extra ein LDAP aufsetzen wäre wohl etwas viel.

Dein Argument mit "ohne dass sich ein Admin erstmal einloggen muss" kann ich nciht nachvollziehen, was sollte denn so ein Admin machen wollen?

Was ist den die Umgebung bzw. der Kontext, Intranet (da gibt es eigentlich immer LDAP), Internet, alles mögliche...?

 

[cmrudolph]

Dein Argument mit "ohne dass sich ein Admin erstmal einloggen muss" kann ich nciht nachvollziehen, was sollte denn so ein Admin machen wollen?

Wenn ich deinen Vorschlag mit LDAP / Verzeichnisdienst richtig verstanden habe, dann soll dieser ja erst nach erfolgreicher Authentifizierung die Zugangsdaten rausrücken. Wenn es ohne authentifizierung ginge, oder mit fest eincodierter Authentifizierung, dann hätte man das gleiche Problem wie vorher.

Der Kontext ist Internet, also das denkbar schwierigste Terrain.

 

[maki]

Wenn es ums Internet kann man LDAP gleich vergessen.

Wie gesagt, am besten keine Zugangsdaten selber speichern, den user einen Nutzernamen und Passwort eintippen lassen welche der Server prüft ist sehr verbreitet
Sicherlich, es geht erstmal ein bisschen Komfort für den Benutzer verloren, aber so ist das mit der Sicherheit.
Browser cachen ja Zugangsdaten auf Wunsch und legen sie dann hoffentlich sicher(?) ab, dann wird es wieder komfortabler, und dadurch eben wieder unsicherer.

 

[SlaterB]

Ein weiterer Ansatz wäre, die Zugangsdaten mit einem Nutzerpasswort zu verschlüsseln. Dies kommt allerdings nicht infrage, weil man keine weiteren Nutzer anlegen könnte, die das Passwort ebenfalls entschlüsseln könnten. Das ginge nur, wenn ein anderer Nutzer, der das Passwort bereits kennt, das Passwort weitergäbe.

weiß nicht genau wie du das meinst, welches Passwort etwa soll weitergegeben werden, das Nutzerpasswort von X an Y (was soll Y damit machen?) oder die Zugangsdaten direkt (die X gar nicht kennt?)

jedenfalls als Hinweis dazu:
User X könnte sein Passwort eintippen, so dass das Programm die Zugangsdaten entschlüsseln kann und im Einsatz hat,
in diesem Zustand könnte sich dann ein neuer User anmelden mit eigenem Passwort usw.,
die Zugangsdaten werden dann mit diesem neuen Passwort neu verschlüsselt gespeichert,
falls das die Grundidee hierzu ist,

vielleicht meintest du diesen gesamten Gedankengang schon,
und dass ein alter User X irgendwie beteiligt ist, ist ja immernoch etwas störend,

----

außerdem evtl. gefährlich, wenn ein Angreifer mit beliebig vielen beliebig gewählten eigenen neuen
Passwörtern die Zugangsdaten bearbeiten darf, kann man aus den verschlüsselten Resultaten,
die sicher leicht einlesbar irgendwo liegen, irgendwann vielleicht die Original-Zugangsdaten berechnen

 

[cmrudolph]

Das Problem ist ja nicht, den Service selbst abzusichern. Es geht ja um die Zugangsdaten zu weiteren Services. Und diese Services müssen auch nach einem Serverneustart korrekt konsumiert werden können, damit keine Produktivität verloren geht.

Bei Diensten, deren Nutzung durch einen Endanwender angestoßen wird, kann man die Zugangsdaten mit deren Passwort verschlüsseln.

Eine Möglichkeit fällt mir gerade noch ein: nach einem Serverneustart kann man die Admins (bspw. per Mail) benachrichtigen, dass sie schleunigst die Zugangsdaten freigeben sollen. Dann hätte man die Daten nur im Speicher.

 

[cmrudolph]

jedenfalls als Hinweis dazu:
User X könnte sein Passwort eintippen, so dass das Programm die Zugangsdaten entschlüsseln kann und im Einsatz hat,
in diesem Zustand könnte sich dann ein neuer User anmelden mit eigenem Passwort usw.,
die Zugangsdaten werden dann mit diesem neuen Passwort neu verschlüsselt gespeichert,
falls das die Grundidee hierzu ist,

vielleicht meintest du diesen gesamten Gedankengang schon,
und dass ein alter User X irgendwie beteiligt ist, ist ja immernoch etwas störend,

Diesen Gedankengang meinte ich! Weshalb ich in meinem Szenario einen weiteren Nutzer beteiligt habe, ist weil ich von der Annahme ausging, dass die Zugangsdaten nicht im Speicher liegen. Es wäre aber wahrscheinlich sicherer die Zugangsdaten im Speicher zu halten als andere Nutzer zu involvieren.

 

[vimar]

also ich habe von der primfaktorzerlegung bez. krypologie gehört @ uni. soll wohl nicht möglich sein die zerlegung zu entdecken. müsstest halt irgendwo die zerlegung nur speichern in ner methode die nur aufm server läuft. o00o.


Kryptographie-Grundlagen | Primfaktorzerlegung | TecChannel.de

 

[freez]

Wenn ich dein Problem richtig verstehe, dann ist das ja sowas ähnliches, als wenn ich einen automatischen Job habe, der regelmäßig auf einem FTP Server nach einer Datei schaut. Dazu muss der Job die Zugangsdaten zum FTP Server kennen.

Hier würde ich empfehlen, vom Anbieter des Services (hier in dem Bsp. der FTP Server) einen Account nur für deinen Job zu generieren und diesen Account auf deinen Server zu binden, damit er nicht von jedem beliebigen PC aus genutzt werden kann. Dein Server mit dem Job sollte natürlich einen extrem eingeschränkten Benutzerkreis haben, welche nur auf den Job Zugriff haben, wenn sie es benötigen. Dann kannst du mit einer Verschlüsselung (evtl. asynchron) diese Zugangsdaten in einem File abspeichern. Zugriff auf den Service sollte natürlich verschlüsselt erfolgen (evtl. SSL bei Webservices), damit die Zugangsdaten nicht im Klartext übertragen werden.

Ich denke, dass du es nicht noch besser absichern kannst, wenn du die ZugangsDaten in deiner Anwendung im Klartext benötigst. Aber hier ist die Angriffsfläche sehr stark minimiert. Du kannst nur versuchen die Möglichkeiten für einen Angriff soweit einzuschränken, wie es geht. Maximale Sicherheit ist dabei leider nicht möglich, da diese Information für deinen Job nunmal vorhanden sein muss und somit auch für einen Menschen auslesbar ist.

 

[skummy]

Was spricht denn dagegen die Zugangsdaten in eine Konfigurations-Datei auszulagern und mit entsprechenden Lese-Rechten zu versehen? Dieser Weg wird zum Beispiel bei Linux gegangen und ist durchaus üblich.

 

[maki]

Was spricht denn dagegen die Zugangsdaten in eine Konfigurations-Datei auszulagern und mit entsprechenden Lese-Rechten zu versehen? Dieser Weg wird zum Beispiel bei Linux gegangen und ist durchaus üblich.

Da widerspreche ich mal energisch, ist weder üblich, noch kenne ich das von Linux..

Linux speichert nicht einfach so Zugangsdaten die nur durch Dateisystemrechte geschützt sind, du verwechselst das wohl mit dem Hash

 

[SlaterB]

@skummy
sag das mal der Obfuscator-Industrie, dann braucht man ja auch den Quelltext nicht mehr zu schützen
Windows gibts aber auch noch..

und wie ist das unter Linux eigentlich mit der Installation? wer soll das einrichten, kann der dann nicht die Zugangsdaten sehen?

 

[skummy]

@SlaterB: Klar..."root" kann alles sehen. Aber irgendjemand muss ja auch die Zugangsdaten hinterlegen.

@Maki: Nein, als Beispiel fällt mir gerade die LDAP-Authentifierzung vom Apache ein

AuthLDAPURL "ldap://fs1.kania-lokal.de:389/dc=kania-lokal,dc=de?uid?sub"
AuthLDAPGroupAttribute memberUid
require group cn=phpldapadmin,ou=groups,dc=kania-lokal,dc=de
# AuthLDAPBindDN und AuthLDAPBindPassword wird benoetigt, wenn
# keine anonyme suche im LDAP erlaubt ist.
AuthLDAPBindDN "cn=manager,dc=kania-lokal,dc=de"
AuthLDAPBindPassword "geheim"

So...da muss man auch ein Passwort hinterlegen.
Des weiteren gibt es auch Key-Files und Zertifikate die beispielsweise für HTTPs verwendet werden und auch irgendwo auf dem Server liegen müssen.

Ich mein, wie soll es auch funktionieren? Ich kann einem Webservice nun mal keinen Hash zur Passwort-Authentifizierung mitgeben, wenn sich dieser Beispielsweise wiederum per FTP anmelden soll.

Ein anderes Beispiel: LDAP Super-User-Authentifizierung über einen Web-Service. Diesem Web-Service muss man für die Authentifizierung Zugangsdaten mitgeben. Die Authentifizierung geschieht meinetwegen über eine Java-Methode, die die Zugangsdaten in Klartext benötigt.

Wie soll man sich bei solchen Systemen auch über einen Hash anmelden können?

Grüße

 

[SlaterB]

@SlaterB: Klar..."root" kann alles sehen. Aber irgendjemand muss ja auch die Zugangsdaten hinterlegen.

es geht doch wohl um das typische Beispiel, dass man sich ein Programm inklusive fertiger Zugangsdaten aus dem Netz oder sonstiger Quelle
(PC Spiele kann man auch im Laden kaufen ) besorgt,
und dann nutzen können soll, möglichst ohne die internen Daten einsehen zu können

 

[skummy]

es geht doch wohl um das typische Beispiel, dass man sich ein Programm inklusive fertiger Zugangsdaten aus dem Netz oder sonstiger Quelle
(PC Spiele kann man auch im Laden kaufen ) besorgt,
und dann nutzen können soll, möglichst ohne die internen Daten einsehen zu können

?Wo gibts denn sowas? Sowas ist _im Prinzip_ hochgradig gefährlich! Ich mein, so bekloppt ist doch nur ein vom Staat beauftragtes Unternehmen, das ein Spionageprogramm erstellen soll. Da wurde beispielsweise ein "Private Key" in den Quelltext einkompiliert...das Ergebnis ist bekannt.

 

[cmrudolph]

Windows gibts aber auch noch..

und wie ist das unter Linux eigentlich mit der Installation? wer soll das einrichten, kann der dann nicht die Zugangsdaten sehen?

Bei Windows gibts mittlerweile auch ein Dateisystem, das heißt "New Technology File System". Ist zwar nicht gar so neu, aber Rechteverwaltung kann es.
Naja, wir wollen nicht lächerlich werden.

Das kann so nicht funktionieren. Denn wenn der Server kompromittiert wurde, dann sind die Dateisystem-Leserechte nicht unbedingt die größte Hürde.


Dateisystemrechte oder gar einen ftp Server halte ich für keine Lösung. Zumal man die Zugriffsrechte für die Anwendung bei einem Unix-Server sowieso für nur genau einen Nutzer verteilen würde, sodass niemand anders Zugriff darauf hat. Der Daemon wird anfangs mit dem richtigen Nutzer gestartet, sodass er die benötigten Daten lesen und ausführen kann und das war es dann.

Ich denke, dass die beste Lösung sein wird, die Zugangsdaten mit einem Nutzerpasswort zu verschlüsseln, von diesem Nutzer durch Passworteingabe freigeben zu lassen und dann im Speicher zu halten (dort natürlich auch verschlüsselt, mit einem zufälligen Laufzeitpasswort, damit man nicht einfach Strings aus dem Speicher lesen kann).
Falls man mehreren Nutzern die Möglichkeit geben möchte, die Freigabe zu erteilen, dann müsste man Kopien des Passwortes anlegen und diese dann in den "Tresor" der Nutzer legen, die die Freigabe erteilen dürfen.

Damit dürfte man ein kryptographisch sicheres Verfahren gefunden haben um die Zugangsdaten zu speichern.


Nachteil ist wie gesagt, dass das Passwort dauerhaft im Speicher bleibt. Dieser Nachteil trifft auf Prozesse, die von einem Endanwender angestoßen werden, nicht zu, da man dann an entsprechender Stelle die Passworteingabe fordern kann.

 

[maki]

Hi skummy,

du sprichst da wieder von Servern, der TS sucht eine Lösung für Clients, das spricht dagegen

Aber sicherlich, bei Servern ist das unter Linux üblich, bei Clientmaschinen allerdings nicht mehr so

"Key Files und Zertifikate" können liegen wo sie wollen, steht ja nix drinnen im klartext, sobald eine Passphrase angegeben werden muss, wird der Admin beim Serverstart danach gefragt, macht Apache auch so

 

[SlaterB]

"Key Files und Zertifikate" können liegen wo sie wollen, steht ja nix drinnen im klartext, sobald eine Passphrase angegeben werden muss, wird der Admin beim Serverstart danach gefragt, macht Apache auch so

falls du die Hash-Werte meinst, können die aber auch ruhig geschützt werden, um Auswertungen zu verhindern, Brute force und so

edit:
da die letzten beiden Postings aber gerade anscheinend von Servern statt normalen User-PCs sprechen:
stimmt, da sind die Einzelrechte wohl nicht so richtig, wenn dort überhaupt Dateien gelesen werden können sieht es schon übel aus

Passworteingabe freigeben zu lassen und dann im Speicher zu halten (dort natürlich auch verschlüsselt, mit einem zufälligen Laufzeitpasswort, damit man nicht einfach Strings aus dem Speicher lesen kann).

JPasswordField liefert extra ein char[] zurück, gar nicht erst einen String

 

[maki]

falls du die Hash-Werte meinst, können die aber auch ruhig geschützt werden, um Auswertungen zu verhindern, Brute force und so

Ich meinte SSL Zertifikate

Schützen kann man vieles, läuft aber am Ende wieder auf eine Sache hinaus: vertrauen

Vertraut man den Server/DB Admins?
Vertraut man der Stelle die das Zertifikat ausgestellt hat?
Vertraut man dem Zufallszahlengenerator? (da war ja mal was...)

 

[Dekker]

Hash ist leider das falsche Stichwort. Es geht hier nicht um Authentifizierung, sondern um "sichere" Speicherung von Zugangsdaten.

Du sollst die Passwörter gehasht speichern, nicht authentifizieren. Das ist das was er gemeint hat.

Nutzerdaten mit Userpasswort verschlüsseln und dann den Schlüssel gehasht (hkey) speichern.

 

[skummy]

Hmm...okay. Einigen wir uns darauf, dass ohne eine Nutzereingabe, das Problem des OP nicht zu lösen ist ;-).

Und SSL-Zertifikate sollten schon nicht für jeden lesbar auf dem Server rumliegen lassen. Sonst bringt die Verschlüsslung über HTTPs quasi nix.

 

[cmrudolph]

Schützen kann man vieles, läuft aber am Ende wieder auf eine Sache hinaus: vertrauen

Vertraut man den Server/DB Admins?
Vertraut man der Stelle die das Zertifikat ausgestellt hat?
Vertraut man dem Zufallszahlengenerator? (da war ja mal was...)

Full ACK! Ich vertraue prinzipiell erstmal niemandem. Da sich die Server auch nicht unter meiner physikalischen Kontrolle befinden, kann ich nichtmal sichergehen, dass sich nicht jemand einfach so mal eben die Festplatte schnappt oder das System im Singleuser Mode bootet.

Es ist immer eine Frage der Kosten: was gibt es für einen potenziellen Angreifer zu gewinnen und wie viel kostet es, einen erfolgreichen Angriff durchzuführen. Wenn genügend Gewinn bei einem Angriff übrig bleibt, dann ist das System unsicher.

Die Daten im Speicher zu halten ist bei einem System, dessen Software ich unter Kontrolle habe, kein soo großes Risiko (meine Einschätzung), da sich die Daten (vorausgesetzt, dass niemand in das laufende System eingedrungen ist) nur durch eine Cold Boot Attack extrahiert werden können.

@maki: deine Beispiele sind sehr schön gewählt. Vertraut man der Zertifizierungsstelle und vertraut man den Zufallszahlengeneratoren... da gab es in letzter Zeit ja einige Vorfälle, die zeigen, dass das Vertrauen nicht unbedingt begründet ist.

 

[maki]

Hmm...okay. Einigen wir uns darauf, dass ohne eine Nutzereingabe, das Problem des OP nicht zu lösen ist

Ja

Und SSL-Zertifikate sollten schon nicht für jeden lesbar auf dem Server rumliegen lassen. Sonst bringt die Verschlüsslung über HTTPs quasi nix.

Ja, denn wenn jeder & überall Zugriff auf den Server hat...

 

[cmrudolph]

Du sollst die Passwörter gehasht speichern, nicht authentifizieren. Das ist das was er gemeint hat.

Nein, ein Hash hat wirklich nichts damit zu tun. Den kann ich zum authentifizieren gebrauchen, zu mehr aber nicht. Denn aus dem Hash (vorausgesetzt es ist ein kryptographisch sicherer Hash) kann ich keine Rückschlüsse auf die Ursprungsdaten (das Passwort) ziehen.
Ich muss aber das Passwort kennen, damit ich mich bei einem anderen Service anmelden kann.

 

[Dekker]

Nein, ein Hash hat wirklich nichts damit zu tun. Den kann ich zum authentifizieren gebrauchen, zu mehr aber nicht. Denn aus dem Hash (vorausgesetzt es ist ein kryptographisch sicherer Hash) kann ich keine Rückschlüsse auf die Ursprungsdaten (das Passwort) ziehen.

Darum geht es doch gerade... Passwort sollen nicht im Klartext gespeichert werden sondern als Hash. So wie es auch so gut wie jedes Betriebssystem macht. Dort werden diese allerdings noch zusätzlich gesalzen.

 

[SlaterB]

Nein, ein Hash hat wirklich nichts damit zu tun.

dann ersetze eben
> Du sollst die Passwörter gehasht speichern
durch
> Du sollst die Passwörter verschlüsselt speichern
so dass man sie durch User-Eingabe wieder zurückbekommt,

wobei zumindest mir strenggenommen unklar ist worum es die ganze Zeit geht,
sollen feste Login-Daten an einen WebService gespeichert werden (das dann pro User anders speichern ist schon komisch)
oder viele individuelle Daten, die jeder User erst eingibt, durch ein kurzes Passwort pro User verschlüsselt werden, damit nicht zig Sachen immer neu einzutippen sind oder oder

 

[skummy]

@SlaterB: Und ich dachte ich bin mit meiner Verwirrung allein :-D!

Ich glaube, der OP will feste Zugangsdaten in seinem Client speichern ohne dass jemand Einsicht zu den Zugangsdaten hat.

Da der OP die Zugangsdaten für einen Web-Service wieder im Klartext benötigt, brauchen wir eine Verschlüsslung mit der wir vom Verschlüsslungsstring wieder zum Klartext kommen. Eine symmetrische Verschlüsslung sozusagen. Ein Hash fällt also aus.

Man benötigt zwangsläufig einen Key, der für die Ver- bzw. Entschlüsslung verwendet wird. Da der OP diesen Key auch nirgends speichern will, bleibt nur die manuelle Eingabe vom Benutzer.

Ich hoffe, ich habe das soweit richtig zusammengefasst ;-)!

 

[Dit_]

Nein, ein Hash hat wirklich nichts damit zu tun. Den kann ich zum authentifizieren gebrauchen, zu mehr aber nicht. Denn aus dem Hash (vorausgesetzt es ist ein kryptographisch sicherer Hash) kann ich keine Rückschlüsse auf die Ursprungsdaten (das Passwort) ziehen.

Soweit ich weiss, wird ein Passwort zum Authentifizieren verwendet und liegt immer in HASH-Form dar. Nur der Benutzer kennt den "UrsprungsString". Das was du willst ist wohl was ganz anderes.

Ich muss aber das Passwort kennen, damit ich mich bei einem anderen Service anmelden kann.

Und wo ist das Problem? Melde dich an einem anderen Service mit diesem Hash-String an.

Oder hast du vor die Zugangsdaten im Klartext an Service zu senden :noe:


Entweder liegt hier ein Designfehler vor oder du versuchst zu erklären was genau du machen möchtest.

 

[cmrudolph]

wobei zumindest mir strenggenommen unklar ist worum es die ganze Zeit geht,
sollen feste Login-Daten an einen WebService gespeichert werden (das dann pro User anders speichern ist schon komisch)
oder viele individuelle Daten, die jeder User erst eingibt, durch ein kurzes Passwort pro User verschlüsselt werden, damit nicht zig Sachen immer neu einzutippen sind oder oder

1. werden Zugangsdaten zur Datenbank benötigt
2. werden mehrere Webservices genutzt, die regelmäßig ohne Nutzerinteraktion konsumiert werden sollen
3. werden gewisse Webservices konsumiert, nachdem der Endanwender gesagt hat, dass das passieren soll (Bsp.: rufe meine Emails ab)

Hierfür werden überall Zugangsdaten benötigt. Teilweise Zertifikate, teilweise eine Client ID und ein Passwort. Teilweise sind die Zugangsdaten pro Endanwender (Bsp.: Email Postfach), teilweise sind sie pro Anwendungsinstallation (die regelmäßig konsumierten Webservices).
Es ist also eigentlich alles dabei.

Es ging mir jetzt darum in Erfahrung zu bringen, wie man derartige Zugangsdaten am besten absichert. Dabei wollte ich ein Sicherheitsniveau anstreben, als wenn es sich um eine Clientanwendung handeln würde, um im Falle einer Kompromittierung noch ein möglichst sicheres System zu haben.

Ist das präzise genug formuliert?

 

[skummy]

Und wo ist das Problem? Melde dich an einem anderen Service mit diesem Hash-String an.

Oder hast du vor die Zugangsdaten im Klartext an Service zu senden :noe:


Entweder liegt hier ein Designfehler vor oder du versuchst zu erklären was genau du machen möchtest.

Er benötigt die Zugangsdaten im Web-Service im Klartext! Deswegen muss er sie auch an den Web-Service im Klartext übergeben.
Anderes Beispiel: Ein Web-Service verwendet SVNKit. Dort kann man sich nur über Klartext-Zugangsdaten mit einer Methode am SVN anmelden. Da bringt dir ein Hash nichts.

 

[cmrudolph]

Und wo ist das Problem? Melde dich an einem anderen Service mit diesem Hash-String an.

Dann wäre ja der Hash ein Passwort und man hätte damit nichts gewonnen. Das funktioniert so nicht!

 

[SlaterB]

Es ging mir jetzt darum in Erfahrung zu bringen, wie man derartige Zugangsdaten am besten absichert. Dabei wollte ich ein Sicherheitsniveau anstreben, als wenn es sich um eine Clientanwendung handeln würde, um im Falle einer Kompromittierung noch ein möglichst sicheres System zu haben.

Ist das präzise genug formuliert?

'als wenn es sich um eine Clientanwendung handeln würde'.. ist es denn keine Client-Anwendung?
ist es ein Server im Internet?
denn Server auf die man nicht vollen Zugriff hat, nur über ein definitiertes Web-Interface kontrolliert besuchen kann,
ist nunmal das Sicherste was es gibt (bis auf die Kompromittierung, die du ansprichst?), abgesehen von kompletter Trennung und Tresor-Wand vor der Außenwelt

und vor wem soll geschützt werden? vor dem einen User der an seinem Client sitzt, falls es eine Client-Anwendung ist?
denn wenn der ein Passwort eingibt und damit verschlüsselte Daten auf der Client-Festplatte entschlüsselt werden,
ist derjenige, der dieses Passwort eingibt, ja quasi im Besitz der unentschlüsselten Daten,

geht es um mehrere User X + Y, um Schutz der Daten von Y vor User X, der das Passwort von Y nicht kennt?

edit:
wenn es allgemeine Zugangsdaten gibt, die eh jeder User hat, spätestens nach Eingabe seines Passworts, wozu diese dann schützen, vor wem?
vor Leuten die nicht als User registriert sind? oder gehts darum dass sie nur im Programm genutzt werden können, aber nicht ausgelesen für andere Programme?

bisschen Wiederholung aktuell, ich stelle mich nochmal ganz dumm, das wurde bestimmt schon genannt

 

[cmrudolph]

'als wenn es sich um eine Clientanwendung handeln würde'.. ist es denn keine Client-Anwendung?

Nein.

ist es ein Server im Internet?

Ja.

denn Server auf die man nicht vollen Zugriff hat, nur über ein definitiertes Web-Interface kontrolliert besuchen kann,
ist nunmal das Sicherste was es gibt (bis auf Exploits), abgesehen von kompletter Trennung und Tresor-Wand vor der Außenwelt

Und ebendort liegt der Hund begraben. Wenn man davon ausgeht, dass der Server sicher sei, dann müsste man ja auch Passworte nicht hashen.

In meiner Annahme ist der Server eben nicht sicher, auch wenn ich mein möglichstes dafür tue.

und vor wem soll geschützt werden? vor dem einen User der an seinem Client sitz, falls es eine Client-Anwendung ist?
denn wenn der ein Passwort eingibt und damit verschlüsselte Daten auf der Client-Festplatte entschlüsselt werden,
ist derjenige, der dieses Passwort eingibt, ja quasi im Besitz der unentschlüsselten Daten,

geht es um mehrere User X + Y, um Schutz der Daten von Y vor User X, der das Passwort von Y nicht kennt?

Es geht darum, dass ein User X nicht die Daten von User Y bekommt und umgekehrt. Und dass Mallory gar keine Zugangsdaten bekommt. Und ich möchte, dass er sich auf den Kopf stellen kann um die Daten zu bekommen, sie aber trotzdem nicht bekommt.

 

[SlaterB]

ich habe noch bisschen editiert, aber dass es ein Server ist, ist glaube ich bereits ein Fortschritt hier im Thread,
auch wenn es strenggenommen schon im ersten Posting steht

"Die Lösung das Problem in einen Webservice zu verlagern zählt nicht, denn dort würde ich das Problem auch gerne "lösen"."
wobei das auch andeutete, dass NICHT in einen Webservice verlagert wird, was eher nach Client-Anwendungen klingt

 

[cmrudolph]

wobei das auch andeutete, dass NICHT in einen Webservice verlagert wird, was eher nach Client-Anwendungen klingt

Da hast du recht, denn mir ging es ja quasi um die Eierlegendewollmilchsau. Zugangsdaten in einer Anwendung speichern, ohne dass sie jemand bekommt. Ich möchte ja die Serveranwendung wie eine Clientanwendung behandeln. Das hat wohl zu Verwirrung geführt.

Wobei ich mir noch nicht so ganz sicher bin, ob die Lösung den Nutzer nach den Zugangsdaten zu fragen diejenige ist, die sich die Entwickler von Webservices vorstellen, die dann in die Doku schreiben, dass man die Zugangsdaten bitte nicht im Quellcode hinterlegen möge.

 

[SlaterB]

da ich gerade so redselig bin, noch bisschen ohne genaue Kenntnis:
also ein Server, der sich beim Start oder spätestens beim ersten User so einrichten soll, dass er (ich beschränke mich aktuell auf: ) allgemeine Zugangsdaten X zu einem zweiten Server kennt,

den User ein Passwort eintippen zu lassen, naja,
strenggenommen könnten alle User dasselbe Passwort Y bekommen, allein auf die Daten X bezogen,
wer Y kennt hat dann auch X, ist es gar allgemein bekannt, kann sich z.B. jeder anonym anmelden, kann man
das Passwort gleich dem Server selber geben, dann wäre es gar kein zusätzlicher Schutz mehr,
so zumindest vor allen Menschen die keine User sind, die Y nicht kennen..

abgesehen davon gilt: wenn der Server-Schutz nicht besteht, wenn der Quelltext vollständig verfügbar ist,
kopiert und selbst ausgeführt werden kann, gibt es strenggenommen gar keinen algorithmischen Schutz, nicht mal Speicher zur Laufzeit,
kann in bestimmten Systemen theoretisch notfalls komplett ausgelesen werden,
von Änderung des Quelltext zu Debugger, System.out.println() oder sonstigen 'normaleren' Untersuchungen abgesehen,
Obfuscator hilft angeblich wie sonst auch

nur mit Festplattenzugriff hat man vielleicht keine vollständige Kenntnis der Server-Hardware,
und auch nicht auf den Arbeitsspeicher der offiziell laufenden Ausführung,
ob es wohl geheime Kennzahlen wie Nummer des MainBoards gibt, die man im Programm auslesen und als Schlüssel verwenden kann?

dann ist noch der Login auf einen zweiten Server, der hoffentlich nicht komprimitiert ist, weil mit viel einfacheren Zugang,
falls man dafür 'allgemeine Zugangsdaten' braucht, wäre man am Ende des Kreises ,
vielleicht ist der aber über lokales Netzwerk verbunden oder es gibt irgendeinen Mechanismus dass sicher nur der offizielle Server dort Zugang enthält?
mit so einer Lösung könnte die Festplatte des 1. Rechners weitgehend leer sein, man kann alle Daten direkt vom zweiten Rechner holen, statt nur ein Passwort für die Daten auf dem 1. Rechner

das Problem wäre dann nur (wieder einmal) auf einen anderen verschoben, wird dich nicht überzeugen,
aber wenn der wie gesagt etwas sicherer durch eingeschränkten Zugriff/ keine direkte Internet-Verbindung läuft?
zudem könnte der vielleicht eher ohne nötigen automatischen Neustart auskommen, nur mit Arbeitsspeicher-Daten arbeiten,
gestartet von DVD, die vor Netzwerk-Anschluss wieder entfernt wird
mit Laptop-Akkus, um bei Stromausfall nicht auszugehen, mehrere Zweit-Rechner gegen Schutz vor CPU-Abrauchen alle Schaltjahre usw.

dass man über den 1. Server nicht irgendwie auf den 2. rankommt, ist nie ausgeschlossen
bzw. braucht man gar nicht wenn der 1. Server die Daten sowieso bald im Arbeitsspeicher hat,
aber nur mit der Festplatte des 1. Servers kommt man nicht weit, darum geht es doch aktuell oder?

wenn die Komprimitierung des 1. Servers auch beliebige Teile der laufenden Software betrifft.., neues Thema..

 

[freez]

Die Frage wäre doch erst mal, was darf die Sicherheit kosten? Und wie stark beschränkt sie den normalen Betrieb. Ich kann natürlich 3 Personen meines Vertrauens damit beauftragen, gleichzeitig und jede Stunde einen Knopf zu drücken und persönliche Zugangsdaten (100 stellig mit Sonderzeichen und Groß- Kleinschreibung) einzugeben, damit die Zugangsdaten im Arbeitsspeicher mit einem neuen Algorithmus erneuert werden.

Was passiert, wenn einer Magen- Darm kriegt ......

Das war jetzt etwas gesponnen und bitte nicht auf Sicherheitslücken kontrollieren ABER:
Die Daten müssen nun mal für die Anwendung im Klartext vorliegen. Es läuft alles auf Vertrauen raus ... auch in obigen Beispiel. Hier sollte sich der TS mal überlegen, wem oder welchem Gerät er am meisten und mit einem vernünftigen Kosten / Nutzenverhältniss vertrauen möchte. Und dort die Daten verschlüsselt ablegen (wie auch immer in nem File, oder per Admineingabe ....) . Und vor allem dann noch mal das Gesamtkonzept überdenken, ob er noch an anderer Stelle Schwächen hat, die seine gewählte Sicherheit wieder auffressen.

 

[cmrudolph]

Die Frage wäre doch erst mal, was darf die Sicherheit kosten? Und wie stark beschränkt sie den normalen Betrieb. Ich kann natürlich 3 Personen meines Vertrauens damit beauftragen, gleichzeitig und jede Stunde einen Knopf zu drücken und persönliche Zugangsdaten (100 stellig mit Sonderzeichen und Groß- Kleinschreibung) einzugeben, damit die Zugangsdaten im Arbeitsspeicher mit einem neuen Algorithmus erneuert werden.

Was passiert, wenn einer Magen- Darm kriegt ......

Das ist sehr wohl richtig und ich glaube, dass es sehr schwierig ist, genau das richtige Maß an Sicherheit zu finden.

Es läuft alles auf Vertrauen raus ... auch in obigen Beispiel. Hier sollte sich der TS mal überlegen, wem oder welchem Gerät er am meisten und mit einem vernünftigen Kosten / Nutzenverhältniss vertrauen möchte. Und dort die Daten verschlüsselt ablegen (wie auch immer in nem File, oder per Admineingabe ....) .

Ich hatte eigentlich in Beitrag #21 mehr oder minder das Maß gefunden, welches meiner Meinung nach praktikabel ist.
Vielleicht ist es untergegangen oder ich war nicht ganz deutlich:

• es sollte pro Endanwender einen Keystore geben und einen für das Gesamtsystem. In dem für das Gesamtsystem sind die Zugangsdaten für die Datenbank, Webservices die ohne Nutzerinteraktion laufen müssen und was man sonst noch im Hintergrund für Zugangsdaten braucht.
  In den Keystores für die Endanwender sind die Zugangsdaten für Services, die nur auf Nutzerinteraktion benötigt werden (z. B. individuelle externe Emailzugänge).
• der Keystore für das Gesamtsystem wird beim Systemstart einmal durch einen Admin freigegeben, indem dieser ein Passwort eingibt. Die Daten werden verschlüsselt im Speicher gehalten, um ein Auslesen zu erschweren. Der Schlüssel dazu wird zur Laufzeit generiert und liegt auch irgendwo im Speicher (wie gesagt, es soll nur das direkte finden von Strings im Speicher verhindern).
• die Keystores der Endanwender werden mit Login des zugehörigen Endanwenders freigegeben und bei Logout / Sessionablauf wieder geschlossen. Die Daten liegen so lange wie im vorigen Punkt beschrieben im Speicher.

Dass beim Start der Anwendung erst einmal ein Passwort eingegeben werden muss, ist, wie bereits im Thread erwähnt, eine gängige Sache (siehe Start von Apache mit SSL Zertifikaten, die eine Passphrase haben. Aber auch der Start eines Betriebssystemes, das auf einer verschlüsselten Festplatte liegt benötigt Nutzerinteraktion).

Falls es einen unplanmäßigen Neustart des Systems gab, kann ein Monitor den / die Admins informieren, dass das System freigegeben werden muss (per Mail, SMS, Jabber oder was auch immer).

Und vor allem dann noch mal das Gesamtkonzept überdenken, ob er noch an anderer Stelle Schwächen hat, die seine gewählte Sicherheit wieder auffressen.

Die Keystores sind dann natürlich nur so sicher, wie das "Masterpasswort" der Endanwender. Selbiges gilt für den Keystore des Gesamtsystems. Erst recht, wenn der Gesamtstore durch mehrere verschiedene Passworte freigegeben werden kann. Dann ist das schwächste Passwort entscheidend.
Auch dürfen die Passworte nicht im Klartext übertragen werden etc..

 

[freez]

Die Keystores sind dann natürlich nur so sicher, wie das "Masterpasswort" der Endanwender. Selbiges gilt für den Keystore des Gesamtsystems. Erst recht, wenn der Gesamtstore durch mehrere verschiedene Passworte freigegeben werden kann. Dann ist das schwächste Passwort entscheidend.
Auch dürfen die Passworte nicht im Klartext übertragen werden etc..

Auch darf man das drum herum nicht vergessen:

• Der / Die Entwickler des Systems, bzw. die Sourcecodeverwaltung für die Anwendung sollte man nicht außen vor lassen ... Ein Entwickler, der verärgert ist kann erheblichen Schaden verursachen
• Dann sollten die Übertragungswege der Zugangsdaten vom Anfang bis Ende sicher sein (Siehe DE-Mail, die die Mails auf dem Server entschlüsseln wollten und dann im Klartext vorliegen haben ... also ENDE - ZU - ENDE Verschlüsselung)
• Muss man die Anwendung auf fremden Rechnern / Servern installieren, wo auch andere Menschen Zugriff haben?
• Wenn der Admin kündigt, ist dann noch der Zugang zu den keystores durch andere Admins sichergestellt?

Vielleicht gibt es noch mehr Dinge die man bewerten muss, mir fällt aber auf die schnelle nix ein. Aber ich glaube du bist auf einem sehr guten Weg :toll:.

 

[cmrudolph]

Auch darf man das drum herum nicht vergessen:

Es stimmt, eine gute Sicherheitsinfrastruktur aufzusetzen ist eine Wissenschaft für sich, bei der schon viel gepatzt wurde.

• Der / Die Entwickler des Systems, bzw. die Sourcecodeverwaltung für die Anwendung sollte man nicht außen vor lassen ... Ein Entwickler, der verärgert ist kann erheblichen Schaden verursachen

Ich erinnere mich an einen Fall, bei dem im Linux Kernel eine Zeile eingeschleust wurde, in der in einer if Bedingung statt [c]== 0[/c] [c]= 0[/c] gesetzt wurde, wodurch jeder in einem bestimmten Fall Rootzugriff bekommen konnte. Auch wenn es in diesem Fall rechtzeitig entdeckt wurde und es iirc auch nicht derjenige war, dem der CVS Zugang gehörte, gibt es bestimmt viele Fälle, in denen sich ein Entwickler aus Wut oder gegen Bezahlung dazu hinreißen lässt, irgendwo ein kleines Loch hineinzubohren.

• Wenn der Admin kündigt, ist dann noch der Zugang zu den keystores durch andere Admins sichergestellt?

Auch ein guter Punkt, an den ich bisher noch nicht gedacht hatte. Er könnte ja auch einen Unfall haben oder aus einem anderen Grunde nicht verfügbar sein. Um solche Fälle abzufangen könnte man den Masterkey ausdrucken und in einem Tresor verwahren.

 

[GUI-Programmer]

[OT]Ich lese den Thread von anfang an mit. Ich kenne mich auf diesen Gebiet bisjetzt noch überhaupt nicht aus. Aber mit "halbwegs sicher speichern" hat das hier glaub ich nicht mehr viel zu tun, ... und ist auch gut so. Ihr baut hier ja fast ein ganzes Sicherheitssytem auf. Weiter so!!! :toll:[/OT]

 

[puls]

Ich würde vorschlagen Honeywords zu benutzen und möglichst viel zu kombinieren.

1. Quellcode verschleiern + Chaoscode
2. Passwörter und Honeywords verschleiern
3. Zeit und Ortinformationen ins Passwort einfließen lassen
4. Konfigurationsdatei verstecken

Mit Java hast du natürlich das Problem das Quellcode relative leicht decompiliert werden kann.

1. Obfuscator benutzen und evetuell den Code an dieser Stelle verkomplizieren obwohl dasm ehr Schaden als nutzen könnte.
2. Neben dem echten Passwort noch weitere Passwörter abspeichern. Sollten diese Honeywords für diesen bestimmten Account genutzt werden kann das System den Account sperren oder besser ein Pseudosystem aktiveren um herauszufinden worauf der Angriff abzielt und wer ihn verursacht. Der Algorithmus der das richtige Passwort auswählt kann natürlich auch extrahiert werden. Aber das hilft schonmal gegen Brude Force Attacken.
3. Du kannst die Uhrzeit einfließen lassen damit ein abgefangener Code bei unverschlüsselte Übertragung nur z.b 1 Minute gültige ist. Ebenso könnte die MAC-Adresse mit dem Passwort verschlüsselt werden damit diese an den Rechner gebunden ist.
4. Verstecke die Datei im JAR File und Splitte die Informationen am besten in mehrer Dateien auf.

Alles hilft nicht wenn man den Quellcode decompiliert. Signiert sollte dieser auch sein damit er nicht so leicht manipuliert werden kann.
Nicht davon in sicher nur der Aufwand wird größer.