Das Notes Forum
Lotus Notes / Domino Sonstiges => Projekt Bereich => Thema gestartet von: y20frank am 13.07.04 - 20:10:31
-
Hallo zusammen!
Täglich kommen ja schon fast unzählige Passwörter für dies und das auf einem hinzu (ok, etwas übertrieben ;D ). 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 :)
-
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.
-
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! ;)
-
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
-
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" ??? ;D
-
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 (http://www-10.lotus.com/ldd/today.nsf/f01245ebfc115aaf8525661a006b86b9/24d3f7b03bcaf0c388256abb00730519?OpenDocument)
-
Andreas: Vergiss aber bitte nicht, alle Deine Passwörter in der Datenbank drin zu lassen ........ ;D
-
Ich habe die Datenbank angehängt - allerdings ohne meine Passwörter ;D
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
-
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.
-
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
-
@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).
-
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)
-
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.
-
Hier die DB im R5 Format
-
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
-
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! :)
-
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.
-
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.
-
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 (http://www.atnotes.de/index.php?board=9;action=display;threadid=11391))
* Verbrannte Dokumente
* Löschen darf nur wer Autor ist
* diverse Kleinigkeiten
-
Die Feldvorschläge von TMC fand ich gut und habe das entsprechend übernommen.
Schön :D
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...
-
Noch was für eine nächste Version:
Wenn im Profildokument die SecretKeys leer sind, sollte beim Neuerstellen eines Doks eine Fehlermeldung kommen.
Vielleicht noch ein paar Automatismen
- eigenen Secret Key per Mail an Kollegen verteilen
- Möglichkeit User zu verbannen und Secret Key ändern (siehe oben)
- Switchen eines Dokumentes von Secret in Public - Verschlüsselung und umgekehrt
- evtl. Import-Funktion (z.B. von Excel / csv)
-
prima! die db sieht technisch schon goil aus...
hm, da ich als passwort-dokument ein profildokument vorgesehen habe (darin hat der user die möglichkeit 25 passwörter zu verwalten, was hier ausreicht), wollt ich mal nachhören, ob es ggf problematisch ist, verschlüsselte felder in einem echten profildokument zu verwenden...?!
danke
:)
-
Michael, ich hab ein paar kleinere Ergänzungen gemacht an Deiner DB:
+ da war noch ein Bug in der Applib, wo statt session.UserName session.CommonUserName verwendet wurde und dadurch pro User 2 Profildoks erzeugt wurden unter bestimmten Voraussetzungen
+ Jetzt ein Abbruch mit Msgbox beim Erstellen eines neuen Doks wenn User noch keinen SecretKey definiert aber so ein Dok erzeugen will
+ Profildoks mit Leserfeld (@Username + Rolle [Admin])
** Edit **:
Unten ist aktuelle Version
-
wollt ich mal nachhören, ob es ggf problematisch ist, verschlüsselte felder in einem echten profildokument zu verwenden...?!
Hab darüber noch nie was negatives gehört (außer dem generellen Gezeter mit Profildoks) - was aber überhaupt nichts heissen mag.
Aber in Deinem Fall musst Du ja unbedingt die Profildoks verschlüsseln. In Michael's DB muss es nicht unbedingt sein. Wobei mir da noch nicht wirklich gefällt, dass die "verbrannten" Passwörter nicht verschlüsselt sind. Muss ich mir noch genauer überlegen.....
Matthias
-
Michael, ich hab ein paar kleinere Ergänzungen gemacht an Deiner DB:
Danke :D
Ich habe mittlerweile auch noch einiges angepasst.
U.a. sind die Verbrannten Passwörter nun public verschlüsselt. Außerdem Erweiterung des Profildokumentes, damit man per Default eine Verschlüsselung einstellen kann. Dann noch diverse andere Kleinigkeiten.....
Die DB kann hier downgeloadet werden:
Download-Link Passwort-Datenbank (http://www.notes-links.de/cpo/eigenentwicklungen/index.php?PHPSESSID=8a9d232edd04955fd8ec00bb57564b78)
-
Auf Matthias' (TMC) Wunsch hin habe ich nun seine hilfreiche Unterstützung entfernt aus dem Text:
..Bitte nimm mich da raus. Ich habe Da eh nur mal drübergeschaut und ein paar Mini-Aktualisierungen gemacht. Den eigentlichen Job hast Du gemacht.
Es gibt eine aktuelle Version:
Yet another Password Database v1.60 (http://www.notes-links.de/cpo/eigenentwicklungen/index.php?PHPSESSID=7000263f733f62dc9a929cbab81d3c44&PHPSESSID=2c02a844b37b50477a9ebb55d301e515#407)
Bug Reports, weitere Wünsche etc. sind willkommen.
Was ich mir noch vorstellen könnte, wäre eine Fristsetzung für Passwörter (z.B. 30 Tage) zum Ändern. Dann E-Mail-Benachrichtigung oder ähnliches.
Was ich erst vor ein paar Tagen entdeckt habe: Es gibt ein sehr ähnliches Projekt bei OpenNTF:
Open Secure Password Repository (1.0) (http://www.openntf.org/Projects/pmt.nsf/HomeLookup/46516C453284002D86256ED60046B9A6?OpenDocument)
Ein paar Ideen daraus habe ich übernommen.
-
Hi, ich habe mir die Datenbank angeschaut und finde Sie super. Da ich mich aber erst neu mit dem Thema beschäftige, meine Bitte: Gibt es eventuell eine kleine Anleitung, z.b.: im Dokument "benutzen dieser Datenbank"? Ich weis zum Beispiel nicht, was verbrannte Kennwoerter sind, was ich bei Secret Verschlüsselung einsetzen soll usw. usw. Das wäre noch das Sahnehäubchen. Ansonsten ist es genau die Lösung die ich schon lange suche und dann hoffentlich nicht mehr meine gesamten Kennwörter in meinem Journal einhacken muß.
-
Hallo Widmaier,
danke für Dein Feedback.
Für eine Anleitung habe ich einfach noch keine Zeit gefunden :) Aber stimmt, das wäre bestimmt ganz hilfreich....
Ich beantworte Deine konkreten Fragen mal direkt:
a) Verbrannte Passwörter:
Du kannst unter Tools/User Preferences 'Burnt Passwords' eintragen. Z.B. allseits beliebte Passwörter wie "gott", "sex", etc. Oder eben Passwörter, die Du zukünftig nicht mehr verwenden möchtest (z.B. weil ein Mitarbeiter die Abteilung gewechselt hat, und das Passwort kennt). Wenn Du nun ein Passwort dieser Liste in einem Passwort-Dokument einträgst, dann kannst Du nicht speichern, da das Passwort 'verbrannt', also nicht erlaubt ist.
b) Secret Verschlüsselung
Das würde jetzt den Rahmen dieses Threads sprengen um genaue Hintergründe zu eräutern. Prinzipiell ist das die sicherste Verschlüsselung die uns Notes native bietet. Du kannst bei Dir in den Security-Preferences des Clients einen Secret-Key erzeugen. Den verteilst Du z.B. per Mail an Deine Abteilungskollegen. Die importieren den Key dann bei sich (im id-File).
Es haben nur Leute Zugriff auf - mit diesem Secret Key verschlüsselte- Passwörter, wenn diese eben diesen Key haben.
Key erzeugen: In ND6: unter Menü: File / Security / User Security, dann links 'Notes Data / Documents' auswählen und auf "New Secret Key" klicken.
Deinem Key gibst Du dann einen Namen, z.B. "widmaierDasGehtNiemandenWasAn" und kopierst diesen Namen noch in der Passwort-Datenbank in Tools/UserPreferences (ins Feld 'Secret encryption keys'). In R5 ist es Menü: File / Tools / User ID, dann "Encryption" und dann der Button "New...".
HTH,
Michael
-
Danke, das hat mir zum Verständnis schon weitergeholfen, ansonsten mein Kompliment für diese Datenbank
-
Keine Ahnung, ob das Projekt hier noch aktiv ist, aber ich benötige so eine Datenbank. Bisher habe ich mit der Datenbank von openntf gearbeit, aber habe jetzt Schwierigkeiten damit und bin auf der Suche nach einer Alternative..
Die Direktlinks zum Download funktionieren übrigens nicht. Nehmt den:
http://www.sw-guide.de/projekte/lotus-notes-projekte/password-database/
Ich danke schonmal im Voraus fürs Erstellen der DB!!
Eine Frage dazu habe ich aber schon: Ist es möglich die Berechtigung auch über Gruppen zu vergeben, weil ich sonst wenn ein neuer User Zugriff haben soll, ich hundert Dokumente ändern muss?