Möglichkeit Passwort für Links zu vergeben #57

gerhardbeck commented 2021年06月05日 09:20:16 +02:00

Um den Zugriff auf Links einschränken zu können, wäre es hilfreich, wenn man optional die Links bei teilen mit Passwörtern versehen könnte, so dass man dann nicht nur das Ticket, sondern auch ein Passwort bräuchte.

Mit Ticket ist gemeint:
grafik

Um den Zugriff auf Links einschränken zu können, wäre es hilfreich, wenn man _optional_ die Links bei teilen mit Passwörtern versehen könnte, so dass man dann nicht nur das Ticket, sondern auch ein Passwort bräuchte. Mit Ticket ist gemeint: 

PW commented 2021年06月06日 16:36:06 +02:00

Soll das Passwort dann für alles gültig sein, wie lange soll es per se gültig sein? Soll es ein Passwort geben zum Ansehen und eines zum Ansehen und Bearbeiten?

Soll das Passwort dann für alles gültig sein, wie lange soll es per se gültig sein? Soll es ein Passwort geben zum Ansehen und eines zum Ansehen und Bearbeiten?

gerhardbeck commented 2021年07月24日 19:19:37 +02:00

Würde ein passwort für ein Ticket vergeben.
Gültigkeit würde ich nicht beschränken.

Zwischen Ansehen und bearbeiten würde ich nicht unterscheiden. Das kann ich ja z.B. in der Ideensammlung über die Rechte steuern.
Einfach, damit man es öffnen kann ein Zusatzschutz für vertraulichere Gespräche/Sammlungen/umfragen.

Würde ein passwort für ein Ticket vergeben. Gültigkeit würde ich nicht beschränken. Zwischen Ansehen und bearbeiten würde ich nicht unterscheiden. Das kann ich ja z.B. in der Ideensammlung über die Rechte steuern. Einfach, damit man es öffnen kann ein Zusatzschutz für vertraulichere Gespräche/Sammlungen/umfragen.

monofox commented 2022年05月26日 19:31:58 +02:00

Ich erachte es als notwendig, die Anforderung noch etwas zu schärfen, denn die Ticket-Nummer im Beispiel ist ja gerade schon ein Schutz - beim Teilen ist natürlich die Ticket-Nummer dann in der URL. Man könnte argumentieren, dass man in solchen Fällen einfach nur den Link ohne die Ticket-Nummer übergeben müsste.

Was möchte man also im konkreten erreichen? Welches Schutzniveau soll erreicht werden?

1. Links teilen, die direkt zur entsprechenden Ressource führt und dann nach einem einheitlichen Kennwort für die Ressource abfragt - das Kennwort darf hierbei nie über die URL geteilt oder akzeptiert werden?
   Muss das Kennwort bzw. den Zugriff auf die Ressource gecached werden, damit der Nutzer die Seite erneut aufrufen kann (bspw. bei F5) ohne das Kennwort einzutippen?

2. Sollen nur bestimmte Personen Zugriff erhalten? => Wir benötigen eine Art Personalisierung? Bspw. pro Person ein eigenen Link?

3. Können / Sollen mehere Kennwörter manuell festgelegt werden, damit man einzelnen hinterher den Zugriff auch wieder entziehen kann?

Ich erachte es als notwendig, die Anforderung noch etwas zu schärfen, denn die Ticket-Nummer im Beispiel ist ja gerade schon ein Schutz - beim Teilen ist natürlich die Ticket-Nummer dann in der URL. Man könnte argumentieren, dass man in solchen Fällen einfach nur den Link ohne die Ticket-Nummer übergeben müsste. Was möchte man also im konkreten erreichen? Welches Schutzniveau soll erreicht werden? 1. Links teilen, die direkt zur entsprechenden *Ressource* führt und dann nach einem einheitlichen Kennwort für die *Ressource* abfragt - das Kennwort darf hierbei nie über die URL geteilt oder akzeptiert werden? Muss das Kennwort bzw. den Zugriff auf die *Ressource* gecached werden, damit der Nutzer die Seite erneut aufrufen kann (bspw. bei F5) ohne das Kennwort einzutippen? 2. Sollen nur bestimmte Personen Zugriff erhalten? => Wir benötigen eine Art Personalisierung? Bspw. pro Person ein eigenen Link? 3. Können / Sollen mehere Kennwörter manuell festgelegt werden, damit man einzelnen hinterher den Zugriff auch wieder entziehen kann?

gerhardbeck commented 2022年05月26日 23:10:04 +02:00

Ich dachte erstmal an 1.
Beispiel: ich verwende die Ideensammlung für etwas vertrauliches. Da ist der Schutz per Ticket etwas, aber zusätzlich über ein Passwort wäre noch besser.
In meiner Vorstellung könnte man in den Einstellungen der Ideensammlung festlegen,ob man ein Passwort haben möchte und es bei Bedarf festlegen.

Ich dachte erstmal an 1. Beispiel: ich verwende die Ideensammlung für etwas vertrauliches. Da ist der Schutz per Ticket etwas, aber zusätzlich über ein Passwort wäre noch besser. In meiner Vorstellung könnte man in den Einstellungen der Ideensammlung festlegen,ob man ein Passwort haben möchte und es bei Bedarf festlegen.

monofox commented 2022年11月03日 21:34:31 +01:00

Ich dachte erstmal an 1.
Beispiel: ich verwende die Ideensammlung für etwas vertrauliches. Da ist der Schutz per Ticket etwas, aber zusätzlich über ein Passwort wäre noch besser.
In meiner Vorstellung könnte man in den Einstellungen der Ideensammlung festlegen,ob man ein Passwort haben möchte und es bei Bedarf festlegen.

Eine Rückfrage ist mir noch eingefallen @gerhardbeck: wenn man eine Kennwortgeschützte "Seite" einrichtet - muss die administrierende Person in der Lage sein, später das Kennwort wieder einzusehen oder ist es ausreichend zu sagen: das Kennwort kann zwar jederzeit neu gesetzt oder generiert werden, aber es kann nicht später erneut angezeigt / ausgelesen werden?

Die Antwort hat unterschiedliche Auswirkungen auf die Anforderungen serverseitig (muss Kennwort entschlüsselbar sein oder nicht?).

> Ich dachte erstmal an 1. > Beispiel: ich verwende die Ideensammlung für etwas vertrauliches. Da ist der Schutz per Ticket etwas, aber zusätzlich über ein Passwort wäre noch besser. > In meiner Vorstellung könnte man in den Einstellungen der Ideensammlung festlegen,ob man ein Passwort haben möchte und es bei Bedarf festlegen. Eine Rückfrage ist mir noch eingefallen @gerhardbeck: wenn man eine Kennwortgeschützte "Seite" einrichtet - muss die administrierende Person in der Lage sein, später das Kennwort wieder einzusehen oder ist es ausreichend zu sagen: das Kennwort kann zwar jederzeit neu gesetzt oder generiert werden, aber es kann nicht später erneut angezeigt / ausgelesen werden? Die Antwort hat unterschiedliche Auswirkungen auf die Anforderungen serverseitig (muss Kennwort entschlüsselbar sein oder nicht?).

gerhardbeck commented 2022年11月03日 23:34:42 +01:00

Ich denke das einfachere zu programmieren. Mir fallen Usercases für beides ein.
Ich würde zu Zweiterem tendieren, aber beides kann sinnvoll sein
Daher: was einfacher ist

Ich denke das einfachere zu programmieren. Mir fallen Usercases für beides ein. Ich würde zu Zweiterem tendieren, aber beides kann sinnvoll sein Daher: was einfacher ist

w4ts0n commented 2022年11月03日 23:44:07 +01:00

Ich dachte erstmal an 1.
Beispiel: ich verwende die Ideensammlung für etwas vertrauliches. Da ist der Schutz per Ticket etwas, aber zusätzlich über ein Passwort wäre noch besser.
In meiner Vorstellung könnte man in den Einstellungen der Ideensammlung festlegen,ob man ein Passwort haben möchte und es bei Bedarf festlegen.

Eine Rückfrage ist mir noch eingefallen @gerhardbeck: wenn man eine Kennwortgeschützte "Seite" einrichtet - muss die administrierende Person in der Lage sein, später das Kennwort wieder einzusehen oder ist es ausreichend zu sagen: das Kennwort kann zwar jederzeit neu gesetzt oder generiert werden, aber es kann nicht später erneut angezeigt / ausgelesen werden?

Die Antwort hat unterschiedliche Auswirkungen auf die Anforderungen serverseitig (muss Kennwort entschlüsselbar sein oder nicht?).

Ich würde mich für "das Kennwort kann zwar jederzeit neu gesetzt oder generiert werden, aber es kann nicht später erneut angezeigt / ausgelesen werden" aussprechen.

Sollten Kennwörter nicht grundsätzlich nur verschlüsselt vorliegen (und ggf. mit einem Salt des Hashes) abgelegt werden? 😅

> > Ich dachte erstmal an 1. > > Beispiel: ich verwende die Ideensammlung für etwas vertrauliches. Da ist der Schutz per Ticket etwas, aber zusätzlich über ein Passwort wäre noch besser. > > In meiner Vorstellung könnte man in den Einstellungen der Ideensammlung festlegen,ob man ein Passwort haben möchte und es bei Bedarf festlegen. > > Eine Rückfrage ist mir noch eingefallen @gerhardbeck: wenn man eine Kennwortgeschützte "Seite" einrichtet - muss die administrierende Person in der Lage sein, später das Kennwort wieder einzusehen oder ist es ausreichend zu sagen: das Kennwort kann zwar jederzeit neu gesetzt oder generiert werden, aber es kann nicht später erneut angezeigt / ausgelesen werden? > > Die Antwort hat unterschiedliche Auswirkungen auf die Anforderungen serverseitig (muss Kennwort entschlüsselbar sein oder nicht?). Ich würde mich für "das Kennwort kann zwar jederzeit neu gesetzt oder generiert werden, aber es kann nicht später erneut angezeigt / ausgelesen werden" aussprechen. Sollten Kennwörter nicht grundsätzlich nur verschlüsselt vorliegen (und ggf. mit einem Salt des Hashes) abgelegt werden? 😅

monofox commented 2022年11月05日 10:27:53 +01:00

Sollten Kennwörter nicht grundsätzlich nur verschlüsselt vorliegen (und ggf. mit einem Salt des Hashes) abgelegt werden? 😅

Korrekt. Verschlüsselt heißt aber nicht zwangsläufig, dass es unumkehrbar ist. Es gibt durchaus valide Anwendungsfälle wo ein Kennwort wieder entschlüsselbar sein muss. Oder wie funktionieren sonst die Kennwortmanager? ;)

> Sollten Kennwörter nicht grundsätzlich nur verschlüsselt vorliegen (und ggf. mit einem Salt des Hashes) abgelegt werden? 😅 Korrekt. Verschlüsselt heißt aber nicht zwangsläufig, dass es unumkehrbar ist. Es gibt durchaus valide Anwendungsfälle wo ein Kennwort wieder entschlüsselbar sein muss. Oder wie funktionieren sonst die Kennwortmanager? ;)