Meine Kennworte bei fremden Systemen verschlüsselt ablegen
-
Hallo Miteinander,
bin auf der Suche nach Best-Practices, wie man mit Kennworten für Schnittstellen umgeht.
Trivial ist die Speicherung von Kennworten, wenn man selbst das System ist, das die Benutzerkonten vergibt und verwaltet. Ich will aber eine vernünftige Lösung dafür, wenn mein System sich an einer Schnittstelle über Zugangsdaten authentifizieren muss, die der Schnittstellenpartner verwaltet.
(Und ich habe keinen Einfluss, dass der Schnittstellenpartner sein Verfahren ändert.)Mein logischer Schluss: Ich brauche Benutzerkennung und Kennwort am Ende im Klartext. Aber eine Liste der Schnittstellen-Benutzer in einer flachen Textdatei als Konfiguration abzulegen, ist ein gefundenes Fressen für jeden Hacker.
Meine aktuelle Idee wäre, die Zugangsdaten symmetrisch oder asymmetrisch verschlüsselt abzulegen und den entsprechenden Key im Programmcode unterzubringen und zur Laufzeit entschlüsseln.
Dann braucht die Analyse viel mehr Aufwand oder Zugriff zur Laufzeit, während man sonst die Zugangsdaten schon bereits auf dem Backupband nachlesen kann.Gibt es da bessere Ideen?
Ciao, Allesquatsch
-
1. Keine Unbefugten an den Server lassen.
2. Keine Unbefugten Zugriff auf die Backups gewähren.
3. Falls du aus irgendeinem Grund nicht kontrollieren kannst, wer Zugriff auf die Backups hat (??), den Key ausschließlich im RAM vorhalten und den Administrator beim Starten des Dienstes eintippen lassen.Den Key im Programmcode vorzuhalten ist sinnfrei. Wer sich bereits strafbar gemacht hat, indem er sich Zugriff auf die Daten des Servers verschafft hat, der scheut dann auch nicht die 20 Minuten, die er braucht, um den Key aus der Executable zu extrahieren.
-
[quote="Allesquatsch"] Ich will aber eine vernünftige Lösung dafür, wenn mein System sich an eine Schnittstelle über Zugangsdaten authentifizieren muss, die der Schnittstellenpartner verwaltet.
[quote]das:
(Und ich habe keinen Einfluss, dass der Schnittstellenpartner sein Verfahren ändert.)
und das:
Gibt es da bessere Ideen?
Beißt sich.
Normalerweise würde man hier einen Hash aus PW und Accountname bilden und den dann an den Schnittstellenpartner übermitteln, der müsste dafür natürlich eine Möglichkeit anbieten anstatt dem PW + Accountname nur einen Hash anzunehmen.
Muss das PW und der Accountname zwingend vom Rechner gespeichert werden?
Sitzt der Benutzer davor und könnte es bei Bedarf eingeben?Bezüglich dem Verschlüssen:
Im Programmcode würde ich den Key auf keinen Fall ablegen, denn den kann im Normalfall ja jeder Benutzer lesen der auch das Programm ausführen, also den Progammcode laden kann.
Wenn, dann gehört der Key in einen sicheren Benutzeraccount bei dessen Benuzterdaten gespeichert, wo nur dieser Zugriff hat. Bspw. der Admin.Benötigt das Programm, das dann bspw. mit normaler Benutzerechten ausgeführt wird sein PW, dann müsste er das vom Adminkonto anfordern. Hier könntest du einen Dienst lokal auf dem Rechner laufen lassen, der mit Adminrechten läuft und diese Rolle übernimmt.
-
normalerweise macht man das glaube ich so, dass man die kennwörter bei erzeugung asymmetrisch verschlüsselt bzw. nen hash-algorithmus drüber laufen lässt und das ergebnis davon in die datei legt, weil sich das ja nicht so einfach umkehren lässt und man dann nur über "brute force" an die klartexte kommt.
wenn du das kennwort überprüfen willst, musst du es ja auch wieder nur verschlüsseln und wenn das kennwort korrekt ist, muss es ja mit dem chiffrat / hash übereinstimmen.
-
Wenn ich dich richitg verstehe, willst du ein Client haben, der sich automatisch an einer Schnittstelle anmeldet, kannst aber dem Client System nicht vertrauen.
Damit könntest du, selbst wenn die Schnittstelle auch Hashes annimmt, auch diese nicht einfach auf deinem System speichern. Denn der potentielle Angreifer könnte dann ja auch den Hash an die Schnittstelle übermitteln.Das heißt du brauchst die mithilfe von einem Anwender. Entweder indem er mithilfe eines Passwortes das gespeicherte Schnittstellen Passwort entschlüsselt oder dieser direkt das Passwort eingibt.
Wenn jetzt tatsächliche Sicherheit nicht ganz so wichtig ist, könntest du auch überlegen das Passwort mit irgendeinem obskuren Verfahren zu ver bzw. entschlüsseln... aber das ist definitiv nicht best practice
-
sollte man nicht sowieso alles, inklusive benutzerauthentifizierung, pauschal mit sitzungsschlüsseln verschlüsselt übertragen? damit kann das passwort quasi "im klartext" zum server geschickt werden und mallory versteht immer nur bahnhof.
-
Hallo Sergey,
;sergey schrieb:
1. Keine Unbefugten an den Server lassen.
2. Keine Unbefugten Zugriff auf die Backups gewähren.
3. Falls du aus irgendeinem Grund nicht kontrollieren kannst, wer Zugriff auf die Backups hat (??),Genau darauf hatten wir uns verlassen. Bloß ist der Teufel ein Eichhörnchen...
den Key ausschließlich im RAM vorhalten
Jepp, das ist auch meine Idee.
und den Administrator beim Starten des Dienstes eintippen lassen.
Ungut, wenn alles von alleine restarten können soll.
Den Key im Programmcode vorzuhalten ist sinnfrei. Wer sich bereits strafbar gemacht hat, indem er sich Zugriff auf die Daten des Servers verschafft hat, der scheut dann auch nicht die 20 Minuten, die er braucht, um den Key aus der Executable zu extrahieren.
Ich denke, dass es deutlich besser ist als gar nichts zu tun. Stehen Benutzerkennung und Kennwort in Klartext in der Konfigurationsdatei, stolpert jeder sofort drüber. Sind die Einträge aber gecryptet, weiß der Angreifer nicht, wieso die Anmeldung nicht gelingt. (Kann ja auch an Deaktivierung, IP-Adresse, Uhrzeit usw. liegen)
Und er muss das Executable analysieren oder die Schnittstelle sniffen.Danke aber für die Anregungen, Allesquatsch
-
computertrolls schrieb:
Normalerweise würde man hier einen Hash aus PW und Accountname bilden und den dann an den Schnittstellenpartner übermitteln, der müsste dafür natürlich eine Möglichkeit anbieten anstatt dem PW + Accountname nur einen Hash anzunehmen.
Im allersten Moment hatte ich auch daran gedacht, aber der Schuss geht nach hinten los: Die Sicherheit bei Hash-Lösungen basiert einzige darauf, dass nur das nicht ermittelbare Kennwort akzeptiert wird.
Würde eine Authentifizierung mit dem Hashwert selbst akzeptiert, hat man nichts anderes als wieder Zugangsdaten.
Schlimmer noch: Man könnte auch die Hashes anderer Benutzer an der Schnittstelle zur Anmeldung nutzen.Muss das PW und der Accountname zwingend vom Rechner gespeichert werden?
Ja, denn der Schnittstellenpartner authentifiziert alle Benutzer, ob online oder Schnittstelle über ein User-Management.
Sitzt der Benutzer davor und könnte es bei Bedarf eingeben?
Nein, der Benutzer hat ein Konto auf meinem System. Aber bei bestimmten Transaktionen muss im Hintergrund eine Transaktion auf einem Remote-System ausgeführt werden. Hier gibt es dann einen technischen User für meine Anwendung.
Danke für Deine Ideen
Ciao, Allesquatsch
-
Wade1234 schrieb:
normalerweise macht man das glaube ich so, dass man die kennwörter bei erzeugung asymmetrisch verschlüsselt bzw. nen hash-algorithmus drüber laufen lässt und das ergebnis davon in die datei legt
Hallo Wade1234,
Habe wohl nicht klar genug gemacht, dass es um "meine" Benutzerkennungen und Kennworte geht, sondern um diejenigen, die ich für Schnittstellenpartner benötige. Das sind technische User, die die Schnittstellenpartner bei sich für mich anlegen und deren Zugangsdaten ich für Hintergrundaktivitäten nutze.
Es geht also gar nicht darum, wie das Kennwort geprüft wird, sondern wie ich quasi einen Password-Safe in meiner Anwendung realisiere.Die Einfach-Lösung, die technischen User in der Konfig-Datei zu hinterlegen, ist halt unsicher und deshalb inzwischen verboten.
Ciao, Allesquatsch
-
Schlangenmensch schrieb:
Wenn ich dich richitg verstehe, willst du ein Client haben, der sich automatisch an einer Schnittstelle anmeldet, kannst aber dem Client System nicht vertrauen.
Nein, um Clients geht es hier nicht. Es geht um Server-Anwendungen.
Und die vertrauen sich leidlich und kommunizieren auch über https.
Und EIGENTLICH wäre auch alles abgesichert gewesen.Bloß hat jemand beim Aufsetzen eines Testsystems fälschlicherweise die Konfigurationsdatei des Produktionssystems mitkopiert. Und damit waren alle die Benutzerkonten, die ich bei meinen Schnittstellenpartnern hatte, potenziell kompromittiert, weil jeder Entwickler sie hätte sehen können.
Wenn jetzt tatsächliche Sicherheit nicht ganz so wichtig ist, könntest du auch überlegen das Passwort mit irgendeinem obskuren Verfahren zu ver bzw. entschlüsseln... aber das ist definitiv nicht best practice
Ich bin ja gerade auf der Suche nach best practice. Und die Verschlüsselung hätte ich über AES und base64 gemacht. Damit hätte ich das Risiko von einer Text-Datei in meinen Programmcode verlagert.
Das ist zwar auch nicht "secure" aber schon hundertmal besser, weil dann niemand was mit der Kopie der Konfigurationsdatei hätte anfangen können, sondern auch noch das Verfahren und den AES-Key hätte recompilieren müssen.
Oder einen Sniffer installieren, der vor dem https-Kanal die Anmeldung mitliest.Meine aktuelle Idee würde bedeuten, dass ich die echten Zugangsdaten erst zur Laufzeit entschlüssele und danach wieder aus dem Speicher gelöscht hätte.
Ciao, Allesquatsch