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.