nicht angemeldet
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.