Gedanken zum Thema "Passwort speichern"

[Warf]

Man kann es ja auch einfach so machen das man beim installieren der software ein masterpasswort festlegen muss

[corpsman]

Also mein Passwortmanager nutzt genau die vom m.fuchs beschriebene Variante

Die Datenbank ist mit einem 4KB Schlüssel Rjindal verschlüsselt und für jeden User ist dieser Schlüssel mit dem UserPasswort verschlüsselt abgelegt. Dadurch kann jeder User sein eigenes Passwort haben und auf die Datenbank Zugreifen.

Das Einzige Problem an der Nummer ist, dass jeder der so auf den Masterkey Zugriff hat, auch Zugriff auf alle Datensätze hat. Ich habe da zwar ein Rechtemanagement eingebaut das jedem Datensatz sagt welcher User ihn lesen darf, aber der böswillige Angreifer, der den Source der Anwendung umschreibt könnte sich seine Rechte "erweitern" und diese Abfrage deaktivieren. Um das zu lösen müsste ich für jeden Datensatz das MasterPasswort Prinzip einführen. Solange ich meine User kenne und deren IT-Fähigkeiten, ist der Aufwand aber noch nicht gerechtfertigt

[Nimral]

Ich denke Stand heute, Exportierbarkeit des Keys ist für meine Anwendung der beste Weg. Schließlich soll die Anwendung auch sicher gegen Angriffe durch Sabotage, Angriffe bei bekanntem Quellcode und Angriffe durch mich selbst sicher sein, und trotzdem für den Notfall eine gangbare Recovery-Option bieten. Ein zusätzliches Default-Konto (mit oder ohne änderbarem Passwort) wäre nur "Mehr vom Selben" und würde unnötig Angriffsmöglichkeiten öffnen, ohne ein Problem zu lösen.

Danke euch für die Denkanstöße!

Armin.

[Nimral]

Also mein Passwortmanager nutzt genau die vom m.fuchs beschriebene Variante

Das Einzige Problem an der Nummer ist, dass jeder der so auf den Masterkey Zugriff hat, auch Zugriff auf alle Datensätze hat. Ich habe da zwar ein Rechtemanagement eingebaut das jedem Datensatz sagt welcher User ihn lesen darf, aber der böswillige Angreifer, der den Source der Anwendung umschreibt könnte sich seine Rechte "erweitern" und diese Abfrage deaktivieren.

Wie willst Du das anders lösen? Nehmen wir an, eine Client/Server Architektur wäre vom Kunden nicht erlaubt, der komplette Zugriffscode muss also Teil jedes Clients sein, und quelloffen auch.

Der unterste Ansatz wäre vermutlich, dass jeder Datensatz einen eigenen Schlüssel bekommen müsste, aber was dann? Das endet m.E. bereits im nächsten Schritt in einer Sackgasse.

Armin.

[corpsman]

Wie gesagt ich bin auch nur auf diese Lösung gekommen.

Speziel bei meinem Usecase ist das aber kein Problem, weil wir den PWM in der Familie nutzen. Meine Kids und Frau können nicht Programmieren -> Schutz ist ausreichend.
Das Programm ist immer nur wenn benötigt auf, und sonst geschlossen und damit dann auch save gegen "Verlust" .

Für die Offene Variante in dem ich den Usern nicht Trauen kann, müsste ich dann die beschriebene Variante implementieren. Zum Glück habe ich aber keinen Bedarf daran Passwörter / Zugangsdaten mit Leuten zu teilen denen ich nicht trauen kann .

[Nimral]

Zum Glück habe ich aber keinen Bedarf daran Passwörter / Zugangsdaten mit Leuten zu teilen denen ich nicht trauen kann .

Reden wir nach der Scheidung nochmal drüber (grins)

[Warf]

Ich denke Stand heute, Exportierbarkeit des Keys ist für meine Anwendung der beste Weg. Schließlich soll die Anwendung auch sicher gegen Angriffe durch Sabotage, Angriffe bei bekanntem Quellcode und Angriffe durch mich selbst sicher sein, und trotzdem für den Notfall eine gangbare Recovery-Option bieten. Ein zusätzliches Default-Konto (mit oder ohne änderbarem Passwort) wäre nur "Mehr vom Selben" und würde unnötig Angriffsmöglichkeiten öffnen, ohne ein Problem zu lösen.

Du kannst halt keine absolute sicherheit haben und gleichzeitig eine backdoor für recovery.
Aber hier ist wie ich es machen würde:
Jeder abschnitt der datenbank ist separat mit einem schlüssel verschlüsselt, also wenn du zugang zu Datensatz A haben willst brauchst du Schlüssel A.
Jeder account generiert ein Public-Private key pair. Um einen account zugang zu bestimmten daten zu gewähren verschlüsselst du den schlüssel für das entspechende datensegment mit dem public key und speicherst diesen Text in der datenbank.
Um auf daten zuzugreifen lädt der user die Verschlüsselten schlüssel runter, decrypted sie mit seinem private key, und kann damit die daten entschlüsseln. Wenn ein neuer user hinzukommt kann ein user der auf die daten zugriff hat einfach das passwort wieder mit dem public key des neuen users verschlüsseln. Also jeder user der zugang zu schlüssel A hat kan jedem anderen user diesen zugang gewähren, falls er ihm vertraut, ohne dessen passwort kennen zu müssen. Wenn ein user entfernt wird, werden alle daten mit einem neuen schlüssel verschlüsselt, und das passwort wird jedem nutzer der immernoch zugang hat gegeben indem das neue passwort mit deren public key verrschlüsselt wird, während die user die entfernt wurden nur noch das alte nutzlose passwort haben

Recovery option: Erstellen eines master accounts, dessen private key du auf einem USB stick speicherst und den irgendwo in deinem Garten vergräbst, sodass niemand außer dir zugang dazu haben kann. Der Öffentliche schlüssel des masters wird dann in der datenbank abgelegt und jeder schlüssel wird immer dem master zugänglich gemacht. Solang niemand physischen zugang zu deinem garten hat ist die recovery backdoor also sicher.

Man kann auch noch einen mechanismus hinzufügen das die integrität von daten überprüft wird über eine signatur mittels des private keys. Somit kann zurückverfolgt werden welcher user wem welche rechte gegeben hat

[Nimral]

Hi Warf,

Herzlichen Dank für die Mühe, die Du Dir gemacht hast!

Das wäre ein guter Plan, aber er ist für meine Anwendung Overkill.

Thnx, Armin.