PasswordManager unter LN

[y20frank]

Hallo zusammen!
Täglich kommen ja schon fast unzählige Passwörter für dies und das auf einem hinzu (ok, etwas übertrieben ). Gibt es eigentlich so etwas wie einen PasswordManager unter Lotus Notes?
Wie könnte man das ggf. angehen? Eine Datenbank mit jeweils userbozogenen Profildokument, welches alle Passwörter des Users beinhaltet und vor Aufruf nochmal selbst einer Passwortabfrage unterzogen wird (auslesen Profil-Passwort-Feld, vergleichen mit @Prompt-Passwort-Eingabe)? Oder wäre das alles zu unsicher? Gibt  es da "Sicherheitsrisiken"...? Hm, hat da jemand ne Idee oder Anregungen dazu...?!
Danke  

[TMC]

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.

[y20frank]

och mensch jau, die verschlüsselungsmechanismen hab ich ganz außer acht und neun gelassen... das lass' ich mir auch nochmal dabei durch die brine gehen! danke!  

[Glombi]

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

[y20frank]

ja, das ist eine schöne idee, wenn du das machen würdest... ich schau mit rein und versuche gerne noch was dazu beizutragen.
GIS = "Glombi Ist Sicher"  

[TMC]

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

[Semeaphoros]

Andreas: Vergiss aber bitte nicht, alle Deine Passwörter in der Datenbank drin zu lassen ........    

[Glombi]

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

[Glombi]

Ein Lesefeld wäre ebenfalls nicht schlecht.

Die drei Felder zum Einsortieren kann man eigentlich auf zwei reduzieren und per Auswahl über ein Konfig.-Dokument füllen.

[D. Roth.]

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

[TMC]

@Andreas:
Habe da kurz mal reingeschaut, aber wie arbeitest Du da mit "Codierungsschlüssel" ? Habe auch kein Feld "PIN" gesehen.

Ich kenne es nur so:
Man hat ein Feld SecretEncryptionKeys oder PublicEncryptionKeys.
PublicEncryptionKeys ist ein Namensfeld (Mehrfachwerte).
Bei SecretEncryptionKeys (Textfeld) hinterlegt man den Key den man via File / Tools / UserID / Encryption generiert hat.

Beides in 1 Maske zur Auswahl klappt nicht wirklich - meine Versuche scheiterten da ein wenig. Das löst man da wohl am besten via Popup-Entscheidungs-Fenster beim Erstellen eines neuen Doks - und zieht dann die entsprechende Sub-Maske an. (ähnlich wie im o.g. Link).

[TMC]

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)

[TMC]

Nochmal ich  

Die Idee "verbrannte Passwörter" finde ich prima.

Man braucht imho auch noch einen Automatismus für Fälle, wenn man User verbannt - aber eine Abteilung denselben SecretEncryptionKey nutzt. Also eine einfache Möglichkeit den zu switchen wenn ein User rausfliegt. Sollte imho kein größeres Problem darstellen - es gibt ja auch die Möglichkeit die SecretKeys per Mail zu verteilen. Also irgend so was denke ich wäre da schick. User mit altem SecretKey lässt per Agent neuen SecretKey eintragen. Dann alte SecretKeys aus den Docs entfernen. Dann noch eine Rundmail an die Leute die im Leserfeld stehen mit dem neuen SecretKey.

[Glombi]

Hier die DB im R5 Format

[Glombi]

Erläuterung zur Verschlüsselung: Zur Zeit benutze ich die DB für mich allein. Daher habe ich in den Maskeneigenschaften unter dem "Schlüssel"-Tab den Codierungsschlüssel hardcodiert.
Das ist aber nicht sehr geschickt, wenn man das für mehrere einsetzen will, da alle Dokumente mit demselben Schlüssel verschlüsselt werden.
Daher der Vorschlag:
- Pro User ein Profil
- in dem Profil den Codierungsschlüssel in einem Textfeld eintippen
- in der Maske dann den hardcodierten Schlüssel herausnehmen und ein Feld namens "SecretEncryptionKeys" implementieren
Der Inhalt wird dann zur Laufzeit aus dem Userprofil geholt

- "verbrannte Passwörter" sollten auch Userspezifisch sein


Andreas

[y20frank]

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!  

[-Michael-]

Ich habe hier auch noch eine DB zum Verwalten von Passwörtern - werde die noch ein wenig anpassen und poste ich dann auch.

Vielleicht kann man das ganze dann verschmelzen.

[-Michael-]

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.

[-Michael-]

Hier ein Update der Datenbank:

http://www.notes-links.de/cpo/eigenentwicklungen/index.php

Ich habe u.a. eingebaut
* Profildokumente (dank Klasse für UserProfil-Dokumente von Axel)
* Verbrannte Dokumente
* Löschen darf nur wer Autor ist
* diverse Kleinigkeiten

[TMC]

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