freifunk-mwu / technik-meta

Hier werden offene Punkte und Dokus zu Gateway, Software und Netzwerk verwaltet
5 stars 9 forks source link

Verwaltung der Passwörter #12

Closed spookey closed 6 years ago

spookey commented 9 years ago

Dieses Thema hatten wir schon, jedoch waren nicht alle daran beteiligt.

Momentan liegt an einer bekannten Stelle in einem nicht bare repo (um Änderungen erkennen zu können) ein KeypassX File ~ Das Passwort dazu sollten alle Leute haben, die es benötigen. Der Inhalt ist einmal alles Queerbeet einfach das worauf damals alle Beteiligten Zugriff hatten

Die Fragen die sich stellen:

kokel commented 9 years ago

Bei der Suche nach Alternativen bin auf die folgenden Lösungen gestoßen:

Nach einem kurzen, oberflächlichen Vergleich würde ich zunächst für einen tieferen Blick in RatticDB plädieren, weil:

Was denkt ihr?

ka-ba commented 9 years ago

Hi, danke für's Suchen! Cloud-/Web- based finde ich nicht so praktisch, muss ich leider sagen. Dabei denke ich im Wesentlichen grad an den BB-Einsatz: Wenn ich an einem neuen Standort bin, dort was einrichten will und eben gerade (nocht) kein Freifunk (und vielleicht auch keine anderes Netz) habe, bin ich aufgeschmissen. Da komme ich mir mit der KeyPass2-Lösung besser aufgehoben vor - mit dem lokalen Zugriff auf die Infos. Zugegeben, für den Gate-Einsatz zieht das Argument nicht so. Da scheint dieses Rattic schon gerade mit seinen Gruppen interessant (habe mir das aber grad nicht zu detailliert angesehen. Da ist mir nur grad das Konzept der externe Crypto etwas suspekt.

kokel commented 9 years ago

RatticDB unterstützt auch ein Export nach KeePass (kann man in der demo auch testen). Aktuell wird nur keepass v1 unterstützt, für keepass v2 gibt aber schon ein Issue, würde also wahrscheinlich auch bald kommen. Somit könnte man sich vor einem BB-Einsatz ein KeePass Export auf den Laptop ziehen und anschließen vernichten.

Hmm, also ich finde das Konzept, dass sich die WebApp den Schuh eigene Crypto zu machen nicht anzieht grade gut. Für die Verschlüsselung auf Dateisystem- und Transportebene kann man recht einfach sorgen.

Das ganze darf natürlich nicht aus dem Internet erreichbar sein ... ;-)

spookey commented 9 years ago

Uiui, hier tut sich was...

RatticDB geht schon voll in die Richtung, wie es ungefähr vom Frontend sein soll. Was mich dennoch daran stört ist, dass diese wirklich im Plaintext die Passwörter in die DB legen, die Filesystem-Crypto soll sich drum kümmern!?!

Ich finde das ist ein bisschen zu kurz gedacht, so lange der Server läuft, ist also das Filesystem entsperrt, und alles liegt im plaintext rum. Ich kann und will nicht ausschließen, dass wir die einzigen mit root-Zugriff auf unsere Kisten sind. Könnt ihr? Weiterhin haben wir dann das Problem dass wir den Schlüssel zum Filesystem irgendwo sicher unterbringen müssten..

Ich würde erst nochmal ein bisschen weiter suchen wollen:

https://clipperz.is/open_source/ (unklar ob man das selbst hosten kann)

https://github.com/github-archive/swordfish (wtf? unten in der readme)

https://fortnotes.com/

http://simplevault.sourceforge.net/

https://github.com/ehazlett/locksmith

http://www.teampass.net/

https://code.google.com/p/webpasswordsafe/

http://www.vaultier.org/

backstube commented 9 years ago

Hier steht ja schon echt eine Masse an Tools. Wow. Ohne daß ich die oben genannten kenne, möchte ich noch das hinzufügen, welches ich seit Jahren benutze: http://jpws.sourceforge.net/jpasswords.html Das Teil ist gut, plattformunabhängig und Bruce Schneier-approved :)

backstube commented 9 years ago

Aber PW zu verwalten ist ja nur ein Mittel zum größeren Ziel dahinter: den richtigen Leuten die passenden Zuänge zu den Systemen zu geben, ohne dabei Höherwertiges preiszugeben, als für diesen Fall nötig ist. Das läuft dann konkret auf mehrere PW-Safes hinaus, wie Spookey ganz oben schon anregte.

Maesto commented 9 years ago

Vorschlag: http://www.passwordstore.org Gibt auch GUIs für Win/Mac. Das ganze speichert als GPG files. Können auch in ein Git. Das ist zwar dann nicht so sauber aber das Masterpassword erübrigt sich.

ka-ba commented 9 years ago

passwordstore: Hab's nur mal überflogen & sieht gar nicht übel aus. Die einzigen zwei Nachteile, die mir auf Anhieb einfielen, wären:

Maesto commented 9 years ago

Kontext und Infos kann man afaik auch ablegen ist eine config sache. Sind ja alles GPG Files. Nur in git wird das ganze lustig daher gecrypteter Inhalt sich bei jedem neu crypten ändert.

spookey commented 9 years ago

Habe ebenfalls die Seite zu pass nur überflogen, klingt auf den ersten Blick echt gut.

Was noch offen bleibt, sind so Fragen nach dem Multi-User Handling, was muss man tun, um Leute hinzuzufügen, was müssen die anderen tun, wenn sich ein Passwort ändert, etc..

@ka-ba Ich denke nicht, dass git ein Problem wird.

Schlage vor das mal anzutesten, um zu schauen, ob dies unseren Anforderungen genügt. Was man dann jedoch noch braucht ist eine Anleitung für alle anderen Leute aus der Community, pass bietet einem Neuling schon eine steile Lernkurve..

ka-ba commented 8 years ago

Moinsn!

Dieses Thema haben wir vor nun über einen Jahr liegen gelassen. Wollen wir's mal wieder aufnahmen?

Klexx commented 8 years ago

Ich benutze seit einiger Zeit pass auf mehreren Geräten Mobil+Pc's. Die Geräte synchronisieren via GIT.

ka-ba commented 8 years ago

Für mich klingt das gut! :) Noch etwas besser fände ich, die Einträge wären auch signiert, aber das wäre vielleicht eher Kür. Wie aufwändig wäre das, wenn wir uns dafür einen eigenen kleinen git-server betrieben? Auch wenn die PWs ja verschlüsselt sind, würde ich sie nicht unbedingt auf github kippen wollen; ist ja auch nicht verbreitungswürdig.

Des Weiteren sollten wir uns dazu überlegen, wir wir die teamfähigkeit nutzen, sprich: gegen einen gemeinsamen pgp-key verschlüsseln, oder gegen unsere individuellen (die vielleicht auch spezielle, extra für den Zweck sein sollten?)? Individuelle hätten den Vorteil, dass man keinen private key verteilen müsste, aber den Nachteil, dass wir die bestehenden entreis rekey-en müssten, wenn sich das Team ändert.

Also, wie ist die Meinung?

kokel commented 8 years ago

+1 für pass ... nutze ich privat auch seit einiger Zeit.

+1 für individuelle Keys. Shared secrets zu verteilen wollen wir doch hiermit grad umgehen.

Ein rekey-en sollte zumindest laut Beschreibung einfach sein. Zum Signing: Zumindest signierte git commits wären möglich.

Am einfachsten wäre ein git repo auf einem unserer Server ohne viel schnick-schnack, z.B. so: https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server

repomaa commented 8 years ago

Hello, endlich kann ich mal was beitragen. Nutze pass seit längerem privat auch mit mehreren Keys. Es lässt sich ziemlich feingranular steuern, wer worauf Zugriff hat, da jedes Verzeichnis eine eigene .gpg-id-Datei enthalten kann (dort werden dann die key-ids hinterlegt, die Zugriff bekommen sollen. Ich bin auch der Autor von autopass und freue mich immer über mehr Nutzer, die Interesse an der (Weiter)Entwicklung haben.

Bzg. git kann ich gitolite wärmstens empfehlen. Ist nicht viel mehr Aufwand aufzusetzen als bare repos und bietet echt tolle Funktionen, wie User-Management, Server-Side-Hooks uvm. Falls ihr jemanden braucht, der das einrichtet, kann ich das gerne machen. :)

belzebub40k commented 8 years ago

Von mir auch ein +1 für pass

repomaa commented 8 years ago

@ka-ba hab versucht dir ne mail zu schreiben, kam aber nicht an. sicher dass es "kaipf" heißen soll? Mein key ist zu finden unter jreinert.keys

ka-ba commented 7 years ago

eingerichtet.

Klexx commented 7 years ago

close?

Maesto commented 7 years ago

Wenn Doku existiert im sinne von wen kann man fragen, und wo liegt das git. warum nicht.