nicht angemeldet
Datenbankpasswort sichern
Hallo liebes Internet,
ich habe eine Frage an Dich, die mich seit wirklich langer Zeit beschäftigt. Du kennst ja das Problem, dass Du eine Webseite schreibst, vielleicht in Perl oder PHP, und dass Du normalerweise Dein Passwort möglichst gut versteckst, wenn Du dabei eine MySQL-Datenbank betreibst.
Liebes Internet, im Quelltext lege ich dieses Passwort grundsätzlich nicht ab, meist in einem externen File, das nicht in einem für www-data erreichbaren Pfad liegt. Doch das reicht mir nicht. Man kann nicht an alles denken und auch ein kleines Bug in einem kleinen Tool kann dazu führen, dass jemand eventuell Zugriff auf dieses File erlangt und dann sensible Daten aus meiner Datenbank stehlen und in aller Ruhe analysieren kann.
Mich beschäftigt nun also der Gedanke, eine Art Passwort-Server zu schreiben. Ein kleines Programm, dass ich als Admin manuell starte und am Leben halte. Es soll die Passworte im Arbeitsspeicher halten, nachdem ich sie ihm übergeben habe. So liegen die Passworte nicht mehr als Datei vor. Und wenn das Programm, vielleicht durch eine Automatisierung glaubt, es würde angegriffen, killt es sich selbst und die Passworte sind für einen Angreifer nicht mehr erreichbar.
Nun, meine Frage ist, wie kann ich soetwas möglichst sinnvoll anstellen? Gibt es eine Möglichkeit, die mir erlaubt, von einem laufenden C- oder vorzugsweise Perl-Programm aus, Anfragen entgegen zu nehmen und zu schauen, was das für ein Programm ist, was da die Anfrage an den hier fiktiven Passwort-Server stellt? Ich habe mir vorgestellt, dass das Programm die MD5-Summe einer Perl-Datei bilden könnte, um seine Identität zu prüfen. Außerdem kann ich mir vorstellen, dass man den Apache-Server oder besser noch die einzelnen Aufrufe über Prozess-IDs identifizieren könnte, um sicher zu stellen, dass es auch "mein" Perl-Skript ist, was mich da nach dem Passwort fragt.
Was meint ihr dazu? Ich betreibe einen Debian-Server. Eigentlich denke ich ja daran, etwas selbst zu schreiben, aber da gibts ja auch lustige Keyrings für "normale" User. Könnte man sowas umfunktionieren? Gibt es ggf. schon andere Ansätze in dieser Richtung, die ich einfach nicht gegooglet kriege?
Viele Grüße
0l1
p.s. ich habe in den letzten Tagen viele Ratschläge erhalten. Die meisten gehen in die Richtung: "Das brauchst Du nicht, schau Dir doch mal die Riesen an, die machen es auch nicht" oder andere Verschlüsselungsmechanismen an anderer Stelle. Ich habe große Firmen fallen sehen, mein liebes Internet, und es geht mir hier eigentlich mehr um das Prinzip als eine "bequeme, schnelle und praktische" Lösung.
-
Mich beschäftigt nun also der Gedanke, eine Art Passwort-Server zu schreiben. Ein kleines Programm, dass ich als Admin manuell starte und am Leben halte. Es soll die Passworte im Arbeitsspeicher halten, nachdem ich sie ihm übergeben habe. So liegen die Passworte nicht mehr als Datei vor. Und wenn das Programm, vielleicht durch eine Automatisierung glaubt, es würde angegriffen, killt es sich selbst und die Passworte sind für einen Angreifer nicht mehr erreichbar.
Für einen größeren Server der eine hohe Ausfallsicherheit braucht, ist das aber nicht mehr praktikabel. Du müsstest ja bei jedem Start das Passwort eingeben.
Ansonsten find ich das ne coole Idee.Nun, meine Frage ist, wie kann ich soetwas möglichst sinnvoll anstellen?
Sockets?
dass man den Apache-Server oder besser noch die einzelnen Aufrufe über Prozess-IDs...
die ändern sich aber immer.
Wer den Server wirklich in der Hand hat, der kriegt da sicher irgendwie auch das Passwort raus, sofern er genügend Zeit und Interesse hat. Solange das Programm läuft.
Du umgehst damit aber auf jeden Fall schon mal ein fest gespeichertes Passwort.-
Für einen größeren Server der eine hohe Ausfallsicherheit braucht, ist das aber nicht mehr praktikabel. Du müsstest ja bei jedem Start das Passwort eingeben.
Ansonsten find ich das ne coole Idee.Yeay! Er hat "coole Idee" gesagt :D
Also mein Server braucht diese Ausfallsicherheit nicht und ein größerer Server hat dann vielleicht auch eine größere Organisation hinter sich, bei der ein Admin sich über den Shutdown informieren lassen kann um dann Maßnahmen zu ergreifen. Also, ich bin mir auch nicht sicher, wie praktikabel es ist, die Kiste laufen zu lassen, wenn man sich gerade hat nachweisen lassen, dass einem die Sourcen manipuliert wurden ... wer weiß, was die Endnutzer dann gerade auf dem Bildchirm sehen.Nun, meine Frage ist, wie kann ich soetwas möglichst sinnvoll anstellen?
Sockets?Ich kenne Sockets aus der praktischen Anwendung noch nicht. Alle meine Ideen basieren darauf auf schlimmen Irrwegen pipes laufen zu lassen.
Könnte ich den Aapache irgendwie dazu bringen, mich per Socket mit einem "Server" zu verbinden, der die gefragten Scripts besorgt und auf diesem Weg mit entsprechenden Passworten füttert? Wäre sowas praktikabel?
Wer den Server wirklich in der Hand hat, der kriegt da sicher irgendwie auch das Passwort raus, sofern er genügend Zeit und Interesse hat. Solange das Programm läuft.
Das stimmt alles. Aber nehmen wir mal einen gut randomisierten 256-bit AES-Schlüssel (solche Passwort sind in so einem Kontext meiner Meinung nach sogar praktikbale und wünschenswert
), den Du heute irgendwo ausgraben willst und so ein Passwort-Server würde dabei Brute-Force-Angriffe unangemessen langsam machen.Damit zwinge ich dann den Angreifer wieder an die Datenbank, die dann entsprechend verschlüsselt ist oder an den Speicher, indem das Passwort steht. Das ist dann schon etwas mehr Zeit...
Du umgehst damit aber auf jeden Fall schon mal ein fest gespeichertes Passwort.
Das ist so eine Schlüsselfrage. Da gabs doch noch diesen Gedanken, "everything is a file" und so. Könnte diese Idee, dass die Passworte "im Speicher" sicher sind vielleicht auch einfach falsch sein?
Grüße
0l1-
Ich kenne Sockets aus der praktischen Anwendung noch nicht.
Das ließe sich durch einen ersten Versuch ja ändern.
Könnte ich den Aapache irgendwie dazu bringen, mich per Socket mit einem "Server" zu verbinden, der die gefragten Scripts besorgt und auf diesem Weg mit entsprechenden Passworten füttert?
Wie meinen?
Was soll der Apache machen? Der führt halt dein Script aus und das muss dann schauen dass es sich das Passwort irgendwoher besorgt. Wo genau siehst du da dich ("mich" per Socket...)?
Wer soll sich ein Script besorgen?Da gabs doch noch diesen Gedanken, "everything is a file" und so.
Nur ein File ist ein File. Speicher ist Speicher. Wenn du das Passwort dann doch als File ablegst, hast du ja nix gewonnen.
Könnte diese Idee, dass die Passworte "im Speicher" sicher sind vielleicht auch einfach falsch sein?
Die sind da so sicher wie sie der Server sicher sein lässt. Wenn du da ein böses Programm drauf laufen hast das den Speicher irgendwie auslesen kann, ists nicht mehr sicher.
Aber *eigentlich* sollte man so einen Server ja gescheit abgesichert haben. Das ist viel besser als sich über Passwort-Schieben Gedanken zu machen.-
Da gabs doch noch diesen Gedanken, "everything is a file" und so.
Nur ein File ist ein File. Speicher ist Speicher. Wenn du das Passwort dann doch als File ablegst, hast du ja nix gewonnen.
Und wenn der Speicher auf HDD swapped wurde? Ist er dann ein File? :-D
Solange der OP meine Fragen aus https://forum.selfhtml.org/?t=209304&m=1424313 nicht beantwortet, ist das Ganze sowieso witzlos.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Solange der OP meine Fragen aus https://forum.selfhtml.org/?t=209304&m=1424313 nicht beantwortet, ist das Ganze sowieso witzlos.
Ich will gern wissen, wie ich dieses MySQL-Passwort sicher wegsperren kann, und nicht, wie ich mich vor anderen Problemen auf meinem Server schütze (was natürlich keineswegs heißt, dass mir diese Sachen egal sind). Der Thread heißt ja nicht "wie mache ich einen Server dicht", sondern "Datenbankpasswort sichern".
Solange Du also andere Fragen, als die eigentlich gestellte beantworten willst, ist das Ganze hier genauso "witzlos".
Verstehst Du? Es gibt ja ausreichend Lücken, die dazu führen, dass Deine Sicherheitskonzepte sich in Luft auflösen können. Einmal ist es ein über Jahre kaputter sshd, ein ander mal ein FTP-Server, der per Überlauf die Türen öffnet, ein im Detail falsch implementiertes Protokoll... lauter solche Dinge passieren, ganz außerhalb Deiner Reichweite, wahrscheinlich sogar gänzlich ohne Dein Wissen und Du kannst dagegen auch nichts tun.
Über den Punkt, dass diese Dinge passieren können und kein Admin der Welt sich vor solchen Exploits schützen kann, möchte ich in dieser Diskussion gerne hinweg und einen Sicherheitsmangel in Form von Klartextfiles der Datenbank-Passworte mit euch besprechen.
-
Hello,
Solange der OP meine Fragen aus https://forum.selfhtml.org/?t=209304&m=1424313 nicht beantwortet, ist das Ganze sowieso witzlos.
Ich will gern wissen, wie ich dieses MySQL-Passwort sicher wegsperren kann, und nicht, wie ich mich vor anderen Problemen auf meinem Server schütze (was natürlich keineswegs heißt, dass mir diese Sachen egal sind). Der Thread heißt ja nicht "wie mache ich einen Server dicht", sondern "Datenbankpasswort sichern".
Wozu willst Du ein Datenbankpasswort sicher machen, wenn Du noch noch icht einmal weißt, von wo aus es wie eingesetzt werden soll?
Dann wäre es doch das Sicherste, das Passwort (den Zugang) gar nicht erst zu erteilen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hey, ich will ja wirklich nicht unfreundlich sein, aber wenn Du keine Antworten auf meine Fragen hast, dann musst Du nicht antworten. Ich würde ich Dich bitten, mir nicht meine Ziele auszureden, ok? Das ist destruktiv, nachdem ich praktisch dreimal darum gebeten habe, fühle ich mich regelrecht getrollt. Seit wann muss man begründen, dass man eine Methode sucht, Klartextpassworte zu vermeiden?! Selbst wenn ich nicht einmal einen Server habe, kann ich diese Frage stellen. Ich möchte dieses Problem aus Prinzip lösen.
Und jetzt werde ich wohl gehen müssen, denke ich. Der Rat, sich ein anderes Board zu suchen, ist wohl angebracht. Der Thread hier scheint mir eh gestorben zu sein.
-
Hello,
Hey, ich will ja wirklich nicht unfreundlich sein, aber wenn Du keine Antworten auf meine Fragen hast, dann musst Du nicht antworten. Ich würde ich Dich bitten, mir nicht meine Ziele auszureden, ok? Das ist destruktiv, nachdem ich praktisch dreimal darum gebeten habe, fühle ich mich regelrecht getrollt. Seit wann muss man begründen, dass man eine Methode sucht, Klartextpassworte zu vermeiden?! Selbst wenn ich nicht einmal einen Server habe, kann ich diese Frage stellen. Ich möchte dieses Problem aus Prinzip lösen.
Du vermeidest ein Klartextpasswort am besten dadurch, dass Du gar keinen Zugang einrichtest.
Wenn Du das aber doch willst, dann muss irgendwann einmal das Passwort doch im Klartext bestehen. Und nun ist die Frage erlaubt, wie es denn von wo nach wo übertragen werden soll. Wenn Du diese Frage nicht verstehst, dann daher nicht beantworten kannst, hat doe übrige Diskussion wenig Sinn.
Und jetzt werde ich wohl gehen müssen, denke ich. Der Rat, sich ein anderes Board zu suchen, ist wohl angebracht. Der Thread hier scheint mir eh gestorben zu sein.
Nur weil Du lernresistent bist, musst Du unsere Antworten nicht als Trollerei darstellen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Du vermeidest ein Klartextpasswort am besten dadurch, dass Du gar keinen Zugang einrichtest.
Dir sollte bewusst sein, dass diese Antwort in keiner Weise die Problemstellung löst.
Wenn Du diese Frage nicht verstehst, dann daher nicht beantworten kannst, hat doe übrige Diskussion wenig Sinn.
Wenn Du noch einmal liest, wirst Du feststellen, dass ich Deine Fragen beantwortet habe.
Nur weil Du lernresistent bist, musst Du unsere Antworten nicht als Trollerei darstellen.
"Nur weil Du..." - so fangen die besten Argumente an. Also erstens habe ich mich nicht über "euch" beschwert, sondern über Dich und zweitens fühlte ich mich getrollt, ->nachdem ich Deine Fragen beantwortet habe<- und Du meine Ansicht als ->witzlos<- bezeichnet hast. Ich habe derweil weitergesucht und auch meine Antworten gefunden. Ich hab mich dabei übrigens weder witzlos noch lernresistent gefühlt.
Tschüss
-
-
-
-
-
-
Was soll der Apache machen? Der führt halt dein Script aus und das muss dann schauen dass es sich das Passwort irgendwoher besorgt. Wo genau siehst du da dich ("mich" per Socket...)?
Genau, ich möchte, dass der Apache nicht das Skript selbst aufruft, sondern einen laufenden Prozess nach dem Skript fragt. Der Prozess (oben "Server") frisst das Skript, liefert sensible Daten und gibt es dann an Apache weiter.
Da gabs doch noch diesen Gedanken, "everything is a file" und so.
Nur ein File ist ein File. Speicher ist Speicher. Wenn du das Passwort dann doch als File ablegst, hast du ja nix gewonnen.Und was ist mit so Dingern wie /dev/mem?
Könnte diese Idee, dass die Passworte "im Speicher" sicher sind vielleicht auch einfach falsch sein?
Die sind da so sicher wie sie der Server sicher sein lässt. Wenn du da ein böses Programm drauf laufen hast das den Speicher irgendwie auslesen kann, ists nicht mehr sicher.
Aber *eigentlich* sollte man so einen Server ja gescheit abgesichert haben. Das ist viel besser als sich über Passwort-Schieben Gedanken zu machen.Der Punkt ist, dass es mich interessiert, ob beispielsweise zur Laufzeit eines Programms (ich nenne das Programm laienhaft Passwort-Server), irgendwer die initialisierten Variablen dieses laufenden Programms lesen kann.
Verstehst Du, in meinen Augen ist es ein enormer Unterschied, ob ich die Passworte in einer Datei speichere, die man auf die ursimpelste Weise lesen kann oder es an einen Ort bringen könnte, der eben nur für den Prozess lesbar ist und dabei, falls der Prozess stirbt, auch direkt die Variablen leert und damit unverfügbar macht.
Ich finde, dass ist nicht einfach nur Passwortschieberei. Ich wäre auch persönlich davon überrascht, dass mit Zugriff auf /dev/mem oder ähnliches, Passworte, die zum Verschlüsseln verwendet werden (nicht nur zum Hashen), praktisch lesbar sind, denn schließlich wäre es demnach total Stulle, welche noch so harten Verschlüsselungsverfahren ich verwende, wenn jemand doch nur mit einem kleinen Dämon meinen Arbeitsspeicher überwachen bräuchte.
Da würde ich direkt auch ein anderes Bild von diesen Keyrings etc. bekommen.
-
-
-
-
Hello,
Wo soll denn der Server laufen?
Wo steht der Host?
Ist die gesamte Datenbank verschlüsselt?
Wie wird auf den Server zugegriffen? Über SSL/TSL?
Wie wird das Passwort an den Server übertragen?
Wo laufen die Applikationen, die den Server nutzen?Und dann würde ich mir als Angreifer gar nicht solche Arbeit machen, wenn ich Zugriff auf Files auf dem Server hätte. Dann würde ich mir einfach einen Useraccount anlegen in den entsprechenden Files des DBMS, oder ich würde gleich die kompletten relevanten Datenfiles klauen.
Der Zugriff auf das Backupsystem ist dafür immer ein begehrter Angriffspunkt :-P
Da sichern Leute ihre Vordertür zur Datenbank doppelt und dreifach ab und die Hintertür zum gesamten DBMS steht einladend offen...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hellooo,
Wo soll denn der Server laufen?
Wo steht der Host?also das sind Fragen, auf die ich keine Antwort habe. Ich denke, es wird zumindest ein root-Server werden,
Ist die gesamte Datenbank verschlüsselt?
Ja. Die sensiblen Daten selbst sind alle verschlüsselt. Zwiebelprinzip und so. Ich habe die Daten einmal durch die Nutzer verschlüsseln lassen und dann noch eine äußere Schicht, die vom System kommt (die hier zu versteckenden Passwort).
Wie wird auf den Server zugegriffen? Über SSL/TSL?
Ja.
Wie wird das Passwort an den Server übertragen?
Die Passworte, um die es hier geht, werden nicht an den Server übertragen. Aber es wird wohl ab und zu eine SSH-Verbindung geben, die sie dennoch überträgt. Davon gehe ich aus.
Wo laufen die Applikationen, die den Server nutzen?
Die Frage verstehe ich vielleicht nicht richtig. Ich hoffe, dass Du es mir nicht übelnimmst, wenn ich "auf dem Server" antworte.
Und dann würde ich mir als Angreifer gar nicht solche Arbeit machen, wenn ich Zugriff auf Files auf dem Server hätte. Dann würde ich mir einfach einen Useraccount anlegen in den entsprechenden Files des DBMS, oder ich würde gleich die kompletten relevanten Datenfiles klauen.
Ja, genau diesem Fall möchte ich vorbeugen. Die Daten selbst sollen am Ende in einer Form sein, dass mir bei einem Einbruch die Daten geklaut werden können und ich kann trotzdem gut schlafen, weil ich weiß, vor 2030 sind die nicht lesbar.
Der Zugriff auf das Backupsystem ist dafür immer ein begehrter Angriffspunkt :-P
Da sichern Leute ihre Vordertür zur Datenbank doppelt und dreifach ab und die Hintertür zum gesamten DBMS steht einladend offen...Ja, das ist richtig.
Das stimmt. Ich habe eine Update-Strategie, aber ich glaube, wenn ich die jetzt ausführe, gerate ich mit meiner eigenen Frage ins Off-Topic :D
Liebe Grüße aus dem schönen Oberharz
Liebe Grüße zurück in den schönen Oberharz!
-
Hello,
Wo steht der Host?
also das sind Fragen, auf die ich keine Antwort habe. Ich denke, es wird zumindest ein root-Server werden,Der sollte in einer sicheren Zone stehen, also bei einem Deiner vertrauenswürdigen Nachbarn im nicht dokumentierten Keller. Das Datenkabel dorthin sollte nicht ortbar sein, also fddi ;-)
Ein Backupsystem sollte am besten auf dem Mond stehen, ebenfalls über FDDI-Angekoppelt. Das solte dann zumindest den Kreis der möglichen Verletzer stark eingrenzen...
Mal ganz ernsthaft. Du weißt überhaupt nicht, worum, es geht und hast kein Konzept.
Mach dich mit Sicherheitskonzepten der theoretischen und der praktischen Art vertraut, bevor Du anfängst, Geld für irgendwelche Hardware oder "Hosting" auszugeben.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Naja, das ist richtig. Ich habe kein Konzept und ich habe keinen richtigen Plan und ich denke, insofern ich mich nicht richtig wohlfühle, wird es auch kein Projekt dazu geben.
Und trotzdem interssiert mich das einfach mal brennend und ich würde das Problem auch gerne lösen.
Dass da ein ziemlich zentrales Passwort irgendwo per Standard in der Gegend herumliegt, finde ich persönlich ein bisschen kritisch und wer weiß, vielleicht findet ja da draußen irgendwann irgendwer unseren kleinen Thread hier und nagelt nicht nur seinen Server dicht mit einem super Plan und einem super Konzept, sondern kann auch noch sein Datenbankpasswort und alles, was er sonst noch außer Reichweite bringen will, schön verschlüsselt ablegen ;D
Das wäre imho eine zusätzliche Sicherheitsschicht.
-
-
-
-
Tach!
Liebes Internet, im Quelltext lege ich dieses Passwort grundsätzlich nicht ab, meist in einem externen File, das nicht in einem für www-data erreichbaren Pfad liegt.
Letzteres ist schonmal gut. Aber ob du es als Textdatei oder als kleine zu inkudierende Code-Datei ablegst, ist egal, denn letzlich wird es von deinem Script eingelesen und steht in einer Variable im Speicher.
Mich beschäftigt nun also der Gedanke, eine Art Passwort-Server zu schreiben. Ein kleines Programm, dass ich als Admin manuell starte und am Leben halte. Es soll die Passworte im Arbeitsspeicher halten, nachdem ich sie ihm übergeben habe. So liegen die Passworte nicht mehr als Datei vor. Und wenn das Programm, vielleicht durch eine Automatisierung glaubt, es würde angegriffen, killt es sich selbst und die Passworte sind für einen Angreifer nicht mehr erreichbar.
Wenn jemand Zugriff auf dein System hat, kann er dein legales Script so ändern, dass es das Passwort abfragt und dann einfach ausgibt. Wie willst du so etwas erkennen? An welche automatische Erkennung unerlaubter Zugriffe hast du gedacht? Anhand der Masse in einer bestimmten Zeit kannst du es kaum festmachen. Dieser Schwellwert wird bei normalen Webseitenzugriffen erreicht werden. Und bereits ein einzelner "gut getarnter" Zugriff reicht, um dein Passwort zu bekommen.
Gibt es eine Möglichkeit, die mir erlaubt, von einem laufenden C- oder vorzugsweise Perl-Programm aus, Anfragen entgegen zu nehmen und zu schauen, was das für ein Programm ist, was da die Anfrage an den hier fiktiven Passwort-Server stellt?
Ersteres ja, letzteres kaum. Du müsstest feststellen, dass das zugreifende Programm es selbst ist und nicht manipuliert wurde. Vielleicht bekommst den Namen noch aus der Prozessliste gelesen. Aber wie willst du im Speicher feststellen, dass es nicht manipuliert wurde? Eine Checksumme über alles geht kaum, es sind ja auch Variablen mit unterschiedlichen Inhalten im Spiel. Nur über den Codebereich prüfen setzte voraus, dass du den kennst. Und wenn du darauf zugreifen kannst, kann das jemand anderes auch, um sich nach der Prüfung das Passwort zu holen.
Ich habe mir vorgestellt, dass das Programm die MD5-Summe einer Perl-Datei bilden könnte, um seine Identität zu prüfen.
Das kann man auch vorher und den so ermittelten Wert einfach direkt vom manipulierten Programm weitergeben lassen.
Was meint ihr dazu? Ich betreibe einen Debian-Server. Eigentlich denke ich ja daran, etwas selbst zu schreiben, aber da gibts ja auch lustige Keyrings für "normale" User. Könnte man sowas umfunktionieren?
Irgendwie muss man ja an den Keyring rankommen. Er liegt also ungesichert rum oder die Zugangsdaten stehen im Code deines Scripts, woraus sie ein Angreifer auch lesen kann. Alle Passwort-Verfahren basieren darauf, dass es einen geheimen Teil gibt. Wenn du den anderswo als in deinem Gedächtnis aufbewahrst, kann man prinzipiell mit mehr oder weniger Aufwand darauf zugreifen.
dedlfix.
-
Moin!
Alle Passwort-Verfahren basieren darauf, dass es einen geheimen Teil gibt. Wenn du den anderswo als in deinem Gedächtnis aufbewahrst, kann man prinzipiell mit mehr oder weniger Aufwand darauf zugreifen.
Allein dafuer gabs von mir nen Stern. Das bringt die Sache auf den Punkt. Wenn man ein Passwort fuer andere nicht abgreifbar vorhalten will, dann im Gedaechtnis. Das heisst: Wie die Pin beim Geldabheben jedesmal neu eingeben. (Und hoffen das besagter Angreifer nicht dazwischen haengt.)
--
Signaturen sind blöd!-
Allein dafuer gabs von mir nen Stern. Das bringt die Sache auf den Punkt. Wenn man ein Passwort fuer andere nicht abgreifbar vorhalten will, dann im Gedaechtnis. Das heisst: Wie die Pin beim Geldabheben jedesmal neu eingeben. (Und hoffen das besagter Angreifer nicht dazwischen haengt.)
Also, das ist natürlich richtig. Das hier sind allerdings keine Nutzerpassworte. Die Werden praktisch auf dem System aus einer Zufallsquelle bezogen und dann in einem Passwort-Server zur Verschlüsselung sensibler Daten vorgehalten.
Und am Rande: Ich glaube die TANs haben übrigens weniger kryptologische Relevanz als viel mehr Endnutzer-PIN-Missbrauchsschutz.
Aber das Grundproblem, worauf ich hier ja aus will, das haben wir eigentlich alle irgendwann einmal. Du möchtest eine Anwendung schreiben, die eine Datenbankabfrage absetzt. Dafür musst Du der Datenbankanfrage einen Nutzernamen und ein Passwort in die Hand geben. Dafür schreibt man heute in der Praxis in der Regel den Nutzer und das Passwort A) entweder in den Quelltext oder B) besser in eine Datei, die außerhalb der öffentlichen Reichweite liegt.
Der unbefriedigende Zustand dabei ist, dass jemand Zugang auf Deine Datenbank erhält, sobald er durch Methode A oder B Dein Datenbank-Passwort erhalten hat.
Das - nur ein bisschen erweitert - ist im Grunde momentan die Problemstellung, die ich lösen möchte. Die Idee ist, dass die Passworte nicht mehr in einer Datei, lesbar für jemanden mit Zugriff zur Verfügung stehen.
Das muss übrigens nicht immer ein Angreifer von außen sein. Dass kann auch mal ein Datenbank-Admin machen, der die falsche Mail geöffnet hat (ein imho sehr häufiges Szenario).
Viele Grüße
0l1-
Tach!
Der unbefriedigende Zustand dabei ist, dass jemand Zugang auf Deine Datenbank erhält, sobald er durch Methode A oder B Dein Datenbank-Passwort erhalten hat.
Müssen denn sensible Daten auf einem Server im Web rumliegen? Naiv gedacht, reicht es nicht, wenn da nur der sowieso öffentliche Katalog liegt und alles, was weiter so anfällt, regelmäßig "in Sicherheit" gebracht wird?
dedlfix.
-
Müssen denn sensible Daten auf einem Server im Web rumliegen? Naiv gedacht, reicht es nicht, wenn da nur der sowieso öffentliche Katalog liegt und alles, was weiter so anfällt, regelmäßig "in Sicherheit" gebracht wird?
Selbst wenn ich beide Fragen richtig beantworte, existiert doch dieses Problem und wenn ich das richtig verstehe, haben sich die meisten Datenbanker damit abgefunden und versuchen es irgendwie durch andere Maßnahmen abzuschotten.
Ich weiß nicht, vielleicht sollte ich die Frage nochmal abseits jeglicher praktischer Arbeit stellen ;D
Die Konsequenz für meinen Server ist hier ja grad eher sekundär.
0l1
-
-
Was ich nicht verstehe:
Du moechtest Diese sensiblen Daten irgendwo lagern wo jemand, der an das Script rankommt, sie nicht sehen kann. Ok. soweit ist das noch verstaendlich.
Was fuehrt dich aber zu der Annahme, das jemand der an so ein Skript kaeme, nicht auch an alle anderen Skripte kommt? Oder selber welche schreiben/editieren darf? Er hat damit also auf alles Zugriff, auf das diese Skripte Zugriff haben und kann sich, wenn er wollte, die Daten ausgeben lassen. Noetig haette er das nicht, da er nur den Zugriff, den Du benutzt, kopieren muss. Mir egal, wenn ich nicht weiss, was in Variable $password steht, solange $password als Passwort funktioniert.
Ich sehe keinen Sinn in dieser Aktion. Das ist, wie die Pin statt auf die EC Karte, auf nen Zettel neben der EC Karte zu schreiben. Dummerweise muss man bei solchen Dingen die Pin irgendwo aufschreiben, damit das System und damit jeder der Zugriff auf das System hat, sie finden kann. Das man sich die Pin dann nicht auf die Stirn schreibt is klar.
--
Signaturen sind blöd!
-
-
-
Aber ob du es als Textdatei oder als kleine zu inkudierende Code-Datei ablegst, ist egal, denn letzlich wird es von deinem Script eingelesen und steht in einer Variable im Speicher.
Ja, das ist natürlich richtig. Da spielt imho generell die Quelle der Daten keine Rolle. Meine naive Annahme war aber eigentlich immer, dass Du wirklich root-Zugriff brauchst, um an solche Informationen zu gelangen. Ich persönlich wüsste nicht einmal, wo ich genau lesen muss, um diese Variablen zu finden und zu verstehen (ist vielleicht auch eine kleine Hürde für manch andere da draußen).
Wenn jemand Zugriff auf dein System hat, kann er dein legales Script so ändern, dass es das Passwort abfragt und dann einfach ausgibt. Wie willst du so etwas erkennen?
Also das ist tatsächlich meine größte Angst. Jemand könnte einfach mein Skript nehmen, es ändern und ausführen. Meine Idee dabei war, dass der Passwort-Server auch die Prüfsumme der Anwendung im Speicher hält (also vom Source der Anwendung) und dann praktisch alle 5 Minuten ein weiterer Prozess patroulliert und meldet, ob die Prüfsumme noch stimmt. Der Passwortserver würde sich bei falscher oder fehlender Meldung selbst herunterfahren und damit die notwendigen Passworte außer Reichweite bringen.
Auch das kann man natürlich verhindern, indem man den Wächter ersetzt. Da dieses Wächter-Tool aber vollkommen unabhängig vom Programm und vom Passwort-Server läuft, wüsste ein Angreifer zunächst nicht, welcher Prozess es ist und ich könnte ihn wirkungsvoll im System verstecken. Im Schnitt hat ein Angreifer dann bestensfalls fünf Minuten, realistisch dann aber wohl weniger als drei Minuten, um Wirkungsvoll die Passworte zu erlangen. Damit sind dann wieder 90% der Trial-and-Error-Soldaten ausgesiebt.
So richtig zufriedenstellend ist das natürlich alles auch nicht. Denn, selbst wenn ich alle 30 Sekunden die Prüfsumme nehme und mal einen Profi in meinen Daten annehme, der sich Zeit nimmt, den Wächter findet und sich nicht nur meinen Code durch den Kopf gehen lässt, sondern sich auch noch ein Skript schreibt, dass direkt alle notwendigen Infos extrahiert, braucht er im Grunde wahrscheinlich weniger als eine Sekunde für den Vorgang an sich.
An welche automatische Erkennung unerlaubter Zugriffe hast du gedacht? Anhand der Masse in einer bestimmten Zeit kannst du es kaum festmachen. Dieser Schwellwert wird bei normalen Webseitenzugriffen erreicht werden. Und bereits ein einzelner "gut getarnter" Zugriff reicht, um dein Passwort zu bekommen.
Also, soetwas hatte ich auch nicht im Sinn. Ich gehe irgendwie davon aus, dass der Angreifer meinen Code verändern muss, um so an die Passworte zu gelangen. Ich bin mir aber nicht einmal bei dieser Annahme sicher, muss ich zugeben.
Ich habe, was die Zugriffe von extern angeht, auch nicht an eine Erkennung gedacht. Ich behandle eigentlich jeden Nutzer wie den Teufel in Person und mache diese Vorgänge alle einfach unheimlich langsam. Man Zugriff von außen, von einem einzelnen Nutzer können auf die Schnittstellen individualisiert nur in relativ langen Zeitabschnitten wiederholt Zugriffe ausüben. Also ein Login-Versuch ist beispielsweise nur alle 5 Sekunden möglich und auch nur dann, wenn vorher von mir ein Skript ausgeliefert wurde, dass einen Key für das Formular generiert hat, sodass auch Cross-Site-Angriffe und sowas nicht alle erfolgreich sind.
Aber das ist im Grunde auch ein etwas anderes Thema. Meine Annahme ist im Grunde schon Worst Case. Ich gehe davon aus, mein FTP-Server hat ein Bug und jemand hat bereits Zugriff auf meine Quelltexte. Der wird meine Webseite dann kaum noch angreifen (vermute ich zumindest).
Nur über den Codebereich prüfen setzte voraus, dass du den kennst. Und wenn du darauf zugreifen kannst, kann das jemand anderes auch, um sich nach der Prüfung das Passwort zu holen.
Also ich denke, ich kann den sensiblen Scope genau abgrenzen. Wenn die Prüfsumme dem Passwortserver im Speicher "versteckt" vorliegt, genau wie Passworte, sollte die Prüfung doch eigentlich schwer unterbunden werden können. Ein Angriff würde dann doch auf dem Bruch des Prüfsummenverfahrens liegen, sodass ich den Code so umbauen oder auffüllen muss, dass eine Kollision mit der ursprünglichen Summe entsteht. Ich gehe fast davon aus, dass ein so einstehendes Code-File größer ist als Speicher auf meinem Dateisystem vorhanden ist, sodass ich eine Kollision in der Praxis ausschließen kann (MD5 war übrigens nur ein beispiel, ich verwende keine MD5-Summen).
Irgendwie muss man ja an den Keyring rankommen. Er liegt also ungesichert rum oder die Zugangsdaten stehen im Code deines Scripts, woraus sie ein Angreifer auch lesen kann. Alle Passwort-Verfahren basieren darauf, dass es einen geheimen Teil gibt. Wenn du den anderswo als in deinem Gedächtnis aufbewahrst, kann man prinzipiell mit mehr oder weniger Aufwand darauf zugreifen.
Das glaube ich nicht. Du kannst ja auch asymmetrisch Verschlüsseln und dabei den privaten Schlüssel assymetrisch verschlüsselt auf der Platte liegen lassen. Dann entschlüsselst Du den privaten Schlüssel einmal symmetrisch beim Start Deiner Anwendung (oder beim Login in Deine Benutzeroberfläche in den Speicher) und hälst ihn dort vorrätig, bis die Sitzung inaktiviert wird. Das ist dabei auch nur ein Szenario. Also imho kann man schon einen gewissen Grad an Sicherheit erreichen, sodass nirgendwo Passworte im Klartext vorhanden sein müssen.
-
Tach!
Aber ob du es als Textdatei oder als kleine zu inkudierende Code-Datei ablegst, ist egal, denn letzlich wird es von deinem Script eingelesen und steht in einer Variable im Speicher.
Ja, das ist natürlich richtig. Da spielt imho generell die Quelle der Daten keine Rolle. Meine naive Annahme war aber eigentlich immer, dass Du wirklich root-Zugriff brauchst, um an solche Informationen zu gelangen. Ich persönlich wüsste nicht einmal, wo ich genau lesen muss, um diese Variablen zu finden und zu verstehen (ist vielleicht auch eine kleine Hürde für manch andere da draußen).Ich ging von einer Script-Sprache aus, bei der der Code in lesbarer Form vorliegt. Dieser ist dann relativ einfach zu verstehen und zu ändern. Bei einem kompilierten Code ist es lediglich mit mehr Aufwand verbunden aber nicht unmöglich.
Wenn jemand Zugriff auf dein System hat, kann er dein legales Script so ändern, dass es das Passwort abfragt und dann einfach ausgibt. Wie willst du so etwas erkennen?
Also das ist tatsächlich meine größte Angst. Jemand könnte einfach mein Skript nehmen, es ändern und ausführen. Meine Idee dabei war, dass der Passwort-Server auch die Prüfsumme der Anwendung im Speicher hält (also vom Source der Anwendung) und dann praktisch alle 5 Minuten ein weiterer Prozess patroulliert und meldet, ob die Prüfsumme noch stimmt. Der Passwortserver würde sich bei falscher oder fehlender Meldung selbst herunterfahren und damit die notwendigen Passworte außer Reichweite bringen.Wie stellst du sicher, dass nur dein kontrollierter und kein irgendwo anders abgelegter Code abgearbeitet werden kann? Wie stellst du überhaupt eine Verbindung her zwischen Teil, der sich zu deinem Passwort-Server verbinden will und der dazugehörigen Code-Datei?
Auch das kann man natürlich verhindern, indem man den Wächter ersetzt. Da dieses Wächter-Tool aber vollkommen unabhängig vom Programm und vom Passwort-Server läuft, wüsste ein Angreifer zunächst nicht, welcher Prozess es ist und ich könnte ihn wirkungsvoll im System verstecken. Im Schnitt hat ein Angreifer dann bestensfalls fünf Minuten, realistisch dann aber wohl weniger als drei Minuten, um Wirkungsvoll die Passworte zu erlangen. Damit sind dann wieder 90% der Trial-and-Error-Soldaten ausgesiebt.
Und du schreibst dann jedes Mal dein System so um, dass sich beim Angreifer beim nächsten Versuch eine neue Verwirrung breit macht? Die Sicherheitslücke finden und stopfen, durch die er hereingekommen ist, musst du nebenbei auch noch.
Nur über den Codebereich prüfen setzte voraus, dass du den kennst. Und wenn du darauf zugreifen kannst, kann das jemand anderes auch, um sich nach der Prüfung das Passwort zu holen.
Also ich denke, ich kann den sensiblen Scope genau abgrenzen.Ich gehe mal davon aus, du hast mich so verstanden, dass ich ein Verzeichnis auf der Festplatte meinte. Ich meinte jedoch den Codebereich im Arbeitsspeicher. Wenn du solche guten Systemkenntnisse hättest, würdest du vermutlich nicht solche Fragen stellen müssen.
Alle Passwort-Verfahren basieren darauf, dass es einen geheimen Teil gibt. Wenn du den anderswo als in deinem Gedächtnis aufbewahrst, kann man prinzipiell mit mehr oder weniger Aufwand darauf zugreifen.
Das glaube ich nicht. Du kannst ja auch asymmetrisch Verschlüsseln und dabei den privaten Schlüssel assymetrisch verschlüsselt auf der Platte liegen lassen. Dann entschlüsselst Du den privaten Schlüssel einmal symmetrisch beim Start Deiner Anwendung (oder beim Login in Deine Benutzeroberfläche in den Speicher) und hälst ihn dort vorrätig, bis die Sitzung inaktiviert wird.Dann liegt der Schlüssel also doch wieder irgendwo rum, nämlich im Speicher, und mit einem Debugger (und einem kleinen Root-Exploit vorher) kann man ihn erreichen. Damit bleibt das Prinzip wie beschrieben bestehen.
Versuch lieber deine(n) Server insgesamt sicher zu halten. Jedes Tool, das du zusätzlich verwendest, erhöht auch die Komplexität, die Anzahl der einbaubaren Fehler und damit die möglichen Angriffspunkte.
dedlfix.
-
Und du schreibst dann jedes Mal dein System so um, dass sich beim Angreifer beim nächsten Versuch eine neue Verwirrung breit macht? Die Sicherheitslücke finden und stopfen, durch die er hereingekommen ist, musst du nebenbei auch noch.
Das ist alles richtig. Auf diese Fragen muss dann jemand Antworten finden. Aber ich fand die Idee, es wenigstens zu merken und erstmal Schlimmeres zu verhindern ganz sexy.
Nur über den Codebereich prüfen setzte voraus, dass du den kennst. Und wenn du darauf zugreifen kannst, kann das jemand anderes auch, um sich nach der Prüfung das Passwort zu holen.
Also ich denke, ich kann den sensiblen Scope genau abgrenzen.Ich gehe mal davon aus, du hast mich so verstanden, dass ich ein Verzeichnis auf der Festplatte meinte. Ich meinte jedoch den Codebereich im Arbeitsspeicher. Wenn du solche guten Systemkenntnisse hättest, würdest du vermutlich nicht solche Fragen stellen müssen.
Das habe ich tatsächlich nicht verstanden...
In meinem Kopf könnte der Apache vom Passwort-Server eine Ausgabe anfordern. Der Passwort-Server hätte die Prüfsumme einer Datei, die er dann wiederum ausführt, so "wüsste" ich, was ich da ausführe. Aber wie Du weiter unten ja beschreibst, sollte die Prüfsumme ja doch im Speicher lesbar sein, was den Schritt ad absurdum führt. Ich führe keine Prüfungen im Speicher durch.
Dann liegt der Schlüssel also doch wieder irgendwo rum, nämlich im Speicher, und mit einem Debugger (und einem kleinen Root-Exploit vorher) kann man ihn erreichen. Damit bleibt das Prinzip wie beschrieben bestehen.
Nun, wenn der Angreifer soweit ist, es dann doch grundsätzlich egal. Denn wenn er in der Lage ist, das zu lesen, dann brauch er ja einfach nur die echten Inputs der User, die genauso durch den Speicher wandern müssen, auszulesen (ok, das gibt dann vielleicht auch nicht gleich die ganze Datenbank her, aber zumindest einen aktiven Teil).
Gibt es praktisch eine Lösung für dieses Problem? Kann man die Variablen im Speicher in irgendeiner Weise davor schützen, für andere als den schreibenden Prozess lesbar zu sein?
Versuch lieber deine(n) Server insgesamt sicher zu halten. Jedes Tool, das du zusätzlich verwendest, erhöht auch die Komplexität, die Anzahl der einbaubaren Fehler und damit die möglichen Angriffspunkte.
Naja, dem will ich auch gar nicht widersprechen. Ich finde diesen Baustein, dass Passworte irgendwo im Klartext rumliegen müssen, trotzdem nicht akzeptabel ;D
-
Tach!
Kann man die Variablen im Speicher in irgendeiner Weise davor schützen, für andere als den schreibenden Prozess lesbar zu sein?
Das muss bereits im Betriebssystem vorhanden sein und darf auch nicht durch irgendein Root-Kit ausgehebelt werden. Die Abschottung von Anwendungen untereinander ist ein bekanntes Thema und es gibt dafür Lösungsansätze. Auch solche, die den Speicher durcheinanderwürfeln, so dass der Angreifer nicht gezielt auf etwas zugreifen kann.
Schau dich lieber in den bestehenden Sicherheitsansätzen um und lies auch die Kritiken (sprich: Liste der Nachteile und Schwächen) dazu. Monitoring-Tools, die neben vielem anderen mehr auch Veränderungen an Verzeichnissen feststellen, sind ebenfalls ein Ansatz. Und wenn du an deinem Vorhaben weiterarbeiten möchtest, such dir zum Diskutieren (auch) die Foren, die sich hauptsächlich mit dem Sicherheits"kram" beschäftigen.
dedlfix.
-
-
-
-
-
Hello,
Was meint ihr dazu? Ich betreibe einen Debian-Server. Eigentlich denke ich ja daran, etwas selbst zu schreiben, aber da gibts ja auch lustige Keyrings für "normale" User. Könnte man sowas umfunktionieren? Gibt es ggf. schon andere Ansätze in dieser Richtung, die ich einfach nicht gegooglet kriege?
Für SuSE gibt es AppArmor. Für Debian habe ich das ben auf Anhieb nicht gefunden, aber da gibt es bestimmt auch was Vergleichbares.
Außerdem solltest Du für dein Passwort eine passende Skalierung betreiben. Der User sollte z.B. nur vom Localhost aus zugreifen können und dann auch nicht alles in der Datenbank dürfen, sondern nur die nötigsten Dinge. Besser ist es noch, einen "Standarduser" einzurichten, der nur die Abfragen erreichen kann, am besten nur Zugriff auf die Stored Procedures bekommt, die die Selects ausführen. Und dann einen "besseren User", der auch Datenveränderungen durchführen kann, am besten aber auch nur über Stored Procedures und nicht über Direktzugriff auf die Tabellen.
Dazu brauchst Du selbstverständlich ein sauberes Konzept und eine gute Datenmodellierung.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach,
Für SuSE gibt es AppArmor. Für Debian habe ich das ben auf Anhieb nicht gefunden, aber da gibt es bestimmt auch was Vergleichbares.
mfg
Woodfighter-
Für SuSE gibt es AppArmor. Für Debian habe ich das ben auf Anhieb nicht gefunden, aber da gibt es bestimmt auch was Vergleichbares.
Danke für die Tipps...
-
-