Ich würde das mit Feldverschlüsselung und SecretEncryptionKeys machen. Damit haben nicht mal die Notes-Admins Zugriff auch wenn sie die ursprüngliche Notes.id mit Passwort haben.

Ich habe eine kleine Datenbank entwickelt, mit Dir ich meine Passworte verwalte. Das ganze funktioniert mit Codierungsschlüssel.
Falls Interesse besteht, würde ich den "GIS Passwort-Manager" auf meiner Homepage zum freien Download bereitstellen. Vielleicht können wir ja hier gemeinsam daran feilen...

Andreas

Vielleicht können wir ja hier gemeinsam daran feilen...

Klar, warum nicht  
Ich kann hier evtl. auch was dazu beitragen.

Hier noch ein Iris Today Artikel

Ich habe die Datenbank angehängt - allerdings ohne meine Passwörter  

Das ganze ist sehr rudimentär und war anfangs für die vielen Accounts bei meinen Kunden gedacht. Inzwischen nutze ich die aber für alle möglichen Accounts.

Die Passwörter werden hardcodiert durch die Maskeneigenschaften mit dem Codierungsschlüssel "PIN" verschlüsselt. Das muss zuerst geändert werden. Ich denke folgendes wäre am besten:
Pro User wird ein Profil hinterlegt, in dem er den Namen des Codierungsschlüssels hinterlegt.
In der Maske wird ein Feld "SecretEncryptionKeys" implementiert, das den Namen des Schlüssel aus dem Profil liest.
In den Maskeneigenschaften wird kein Schlüssel angegeben.

Mal sehen, was dabei herauskommt.

Mögen die Spiele beginnen...

Andreas

Hallo zusammen , ich bin  auch an solch einer DB intressiert!! Aber leider ist diese DB für Notes 6, hast Du die DB auch für Notes 5 ??

mfg

Ich würde auch vorschlagen, dass man dann ein paar mehr Felder integriert und auch mehr Felder verschlüsselt.

Z.B.:

- Category
- Company
- Title
- URL (verschlüsselt)
- Username (verschlüsselt)
- Password (verschlüsselt)
- E-Mail (verschlüsselt)
- Registered on (verschlüsselt)
- Remarks (verschlüsselt)

Nachteil ist natürlich immer: Verschlüsselte Felder sieht man nicht in Views.


Dann noch ein Leser- und ein Autoren-Feld.

Wobei bei PublicEncryption das Leserfeld gleichzeitig als das Feld PublicEncryptionKeys verwendet werden kann (wobei man dann über das Autorenfeld die Editor-Rechte weiter einschränkt: z.B. 10 Leute stehen im Leserfeld, aber nur 3 im Autorenfeld)

Hier die DB im R5 Format

danke an alle, die sich mit dem thema beschäftigt haben (insbes. an glombi, der eine datenbank zur verfügung gestellt hat),
ich habe das ganze allerdings ersteinmal wie folgt gelöst:
-profildokument pro user
-vor öffnen fragt es nach einem im profildok abgelegten passwort nach eben diesem ab, sonst tut sich nix
-ist passwort korrekt, wird profildokument geöffnet und man kann seine systeme und passwörter dazu eingeben bzw ansehen
-{verschlüsselung folgt}
DANKE!  

Habe jetzt mal meine DB angehängt (ND6).

Die Feldvorschläge von TMC fand ich gut und habe das entsprechend übernommen.

Beim Öffnen eines neuen Doks kommt eine Auswahl wie man verschlüsseln will (public oder secret).

Ein paar Dinge fehlen noch:
* Löschen von Dokumenten: sollte nur durch Autoren möglich sein (realisierbar über Database-Script Querydocumentdelete)
* Verbrannte Passwörter pro User
* Generell: Userprofile: In der jetzigen Lösung muss der User seine(n) SecretEncryptionKey(s) kennen und eintragen. Der User sieht auch alle anderen Keys (also die Namen).

etc.

--- Edit:
Im zip-Archiv ist nun auch eine R5-Version.

Die Feldvorschläge von TMC fand ich gut und habe das entsprechend übernommen.

Schön  

Die DB macht auf den ersten Blick einen guten Eindruck.

Was mir irgendwie noch nicht gefällt ist dass die Profildokumente ohne Lese-Zugriffsbeschränkungen sind.
Außerdem wissen DAU's bestimmt nicht beim Erstellen eines neuen Doks, was denn nun Public und Secret bedeutet. "Public" hört sich für viele User bestimmt extrem unsicher an.
---
Vielleicht sollte man diesen Thread in den Projekt-Bereich verschieben...