AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
22.09.21 - 20:45:10
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News:
Schnellsuche:
+  Das Notes Forum
|-+  Lotus Notes / Domino Sonstiges
| |-+  Projekt Bereich (Moderator: Hoshee)
| | |-+  PasswordManager unter LN
« vorheriges nächstes »
Seiten: [1] 2 Nach unten Drucken
Autor Thema: PasswordManager unter LN  (Gelesen 17717 mal)
y20frank
Gast
« 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 Grin ). 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  Smiley
Gespeichert
TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #1 am: 13.07.04 - 20:31:06 »

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

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

y20frank
Gast
« Antworten #2 am: 13.07.04 - 20:48:43 »

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!  Wink
Gespeichert
Glombi
Gast
« Antworten #3 am: 13.07.04 - 21:00:40 »

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
Gespeichert
y20frank
Gast
« Antworten #4 am: 13.07.04 - 21:04:30 »

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" Huh  Grin
Gespeichert
TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #5 am: 13.07.04 - 21:05:42 »

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

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

Hier noch ein Iris Today Artikel
Gespeichert

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

Semeaphoros
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 8152


ho semeaphoros - agr.: der Notesträger


WWW
« Antworten #6 am: 13.07.04 - 21:11:26 »

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

Jens-B. Augustiny

Beratung und Unterstützung für Notes und Domino Infrastruktur und Anwendungen

Homepage: http://www.ligonet.ch

IBM Certified Advanced Application Developer - Lotus Notes and Domino 7 und 6
IBM Certified Advanced System Administrator - Lotus Notes and Domino 7 und 6
Glombi
Gast
« Antworten #7 am: 13.07.04 - 21:23:55 »

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

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
Gespeichert
Glombi
Gast
« Antworten #8 am: 13.07.04 - 21:25:24 »

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.
Gespeichert
D. Roth.
Aktives Mitglied
***
Offline Offline

Beiträge: 111


Ich liebe dieses Forum!


« Antworten #9 am: 14.07.04 - 12:18:23 »

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
Gespeichert
TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #10 am: 14.07.04 - 22:32:04 »

@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).
Gespeichert

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #11 am: 14.07.04 - 22:37:13 »

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)
« Letzte Änderung: 14.07.04 - 22:42:22 von TMC » Gespeichert

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #12 am: 14.07.04 - 22:48:17 »

Nochmal ich  Smiley

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

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

Glombi
Gast
« Antworten #13 am: 15.07.04 - 09:03:01 »

Hier die DB im R5 Format
Gespeichert
Glombi
Gast
« Antworten #14 am: 15.07.04 - 09:05:57 »

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
« Letzte Änderung: 15.07.04 - 09:06:27 von Glombi » Gespeichert
y20frank
Gast
« Antworten #15 am: 16.07.04 - 16:13:25 »

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!  Smiley
Gespeichert
-Michael-
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 153



WWW
« Antworten #16 am: 17.07.04 - 19:17:06 »

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

-Michael-
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 153



WWW
« Antworten #17 am: 17.07.04 - 20:57:33 »

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.
« Letzte Änderung: 17.07.04 - 21:04:16 von -Michael- » Gespeichert

-Michael-
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 153



WWW
« Antworten #18 am: 18.07.04 - 21:50:33 »

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
Gespeichert

TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #19 am: 19.07.04 - 23:11:50 »

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

Schön  Cheesy

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

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

Seiten: [1] 2 Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: