Lesspass: Möglichkeit, nur die Domain und nicht den FQDN zu übernehmen

Ich weiß nicht, warum ich eine Regression von der aktuellen FQDN-Implementierung möchte.
Aber solange FQDN Standard ist und bleibt und die Kürzungen (sofern implementiert) optional werden, würde mich das nicht stören.

@Kcchouette

Zögern Sie nicht zu fragen/diskutieren, was Sie an meiner Aussage verwirrt,
Ist das nicht ganz klar?

In https://github.com/lesspass/lesspass/issues/199#issuecomment -292981113 hast du selbst für FQDN als Standard gestimmt! Zumindest in diesem Aspekt sind wir uns also einig!

Ich bin verwirrt über die "Regression von der aktuellen FQDN-Implementierung".

Dieses Problem hat das Ziel, mehrere weitere Optionen zur Auswahl der Website-Adresse hinzuzufügen.

@Kcchouette
Soweit ich die Funktionsweise von LessPass verstehe, werden die im Feld site eingegebenen Informationen (sowie andere) als (zusätzlicher) Salt verwendet, um das Passwort zu berechnen.
Wenn also die Zeichen von accounts.google.com auf nur google.com oder google reduziert werden, würde dies weniger Salz und weniger Entropie bedeuten.
Deshalb nenne ich es "Regression aus der aktuellen FQDN-Implementierung".

Außerdem: Sie haben heute die Möglichkeiten: Löschen Sie einfach die nicht gewünschten Zeichen aus dem FQDN.
Es steht Ihnen völlig frei, beliebige Zeichen im Feld site hinzuzufügen/zu entfernen.

@SoftwUser Ich bin mir nicht sicher, ob die

Darüber diskutieren wir bereits:

• only domain (zB google) <- schwer zu finden ohne eine große Liste an Domainnamen
• domain und tld (zB google.com) <- die Option, die auf Lesspass mit #45 eingeführt, aber mit #148 entfernt wurde <- ohne tld-Liste schwer zu finden
• FQDN (zB accounts.google.com) <- die derzeit einzige Option für die Erweiterung

Die einzige einfache Verbesserung, die wir leicht vornehmen können, besteht darin, www. von der Site zu entfernen, wenn die Site mit www. beginnt
Ich möchte diese Funktion nicht als Standard einführen, da sie eine v3 erfordert. Neue Version sollte auf Sicherheitslecks beschränkt sein.

Vielleicht können wir dies in einer Konfigurationsoption hinzufügen.
Bezogen auf https://github.com/lesspass/lesspass/issues/245

@guillaumevincent

Ich bin mir nicht sicher, ob die Länge des Salzes wichtig ist. Wenn ein generiertes Passwort gestohlen wird (zB myspace), haben Sie die Site bereits (zB myspace.com).

Ich mache mir nicht nur Sorgen um das berechnete Passwort, sondern auch um das Masterpasswort.
Es macht einen Unterschied, ob accounts.google.com , google.com oder google verwendet wird, nicht wahr?

Wie auch immer, Ihre Lösung, nur eine Option zum Reduzieren des FQDN hinzuzufügen, scheint vernünftig zu sein. Dankeschön.

@guillaumevincent
Wegen #272 bin ich (wieder) über dieses Thema gestolpert.

Ich wäre sehr unglücklich, wenn der bisherige Ansatz auf etwas kürzeres reduziert oder "gefiltert" würde.
Ich freue mich, wenn so viele Informationen wie möglich in das "Site"-Feld aufgenommen werden und ich verstehe nicht, warum diese standardmäßig reduziert werden sollen.

Ich habe folgende Anwendungsfälle:

www.1.example.com
www.2.example.com
www.3.example.com

1,2,3 sind unterschiedliche Server, aber mit identischen Login-Namen.
Ich bekomme drei verschiedene Passwörter wegen unterschiedlichen FQDN - je nach Bedarf!
Wenn diese auf example.com reduziert wurden, waren meine Anwendungsfälle sofort kaputt.

Bitte belassen Sie es auf der Standardseite so, wie es heute ist!

Ich freue mich, Ihre obige Aussage zu lesen:

Ich möchte diese Funktion nicht als Standard einführen, da sie eine v3 erfordert. Neue Version sollte auf Sicherheitslecks beschränkt sein.

Für den Fall, dass es jemals eine v3 geben wird, berühren Sie bitte nicht den FQDN als Standard. Bitte bieten Sie Optionen zum Reduzieren/Filtern an und erzwingen Sie sie nicht, nicht einmal www entfernen Sie bitte. Ich halte FQDN eher für ein Feature als für einen Fehler.

Und wie @SoftwUser oben sagte, kann jeder, der kürzere Site-Namen möchte, die unerwünschten Zeichen auch heute noch manuell löschen. Dies ist weniger fehleranfällig als das manuelle Hinzufügen von Zeichen.

@panther2 interessant
Vielleicht können wir das konfigurierbar machen.

Im Grunde behalten wir den Standard wie heute bei.
Und wir fügen eine Option hinzu, um Subdomain und www zu entfernen

Vielleicht können wir das konfigurierbar machen.

Im Grunde behalten wir den Standard wie heute bei.
Und wir fügen eine Option hinzu, um Subdomain und www zu entfernen

Genial, danke!

Wie ich schon sagte, als ich #199 eröffnete, ist eine Option perfekt für mich, und ich würde sie gerne testen.

@guillaumevincent
Du denkst nur eine klassische Option die wir ankreuzen können oder etwas fortgeschritteneres wie eigene Regex etc ?

Vielen Dank im Voraus für diese Option

@kidburglar welche Option möchtest du? Entfernen von www. oder nur Domainname?

@guillaumevincent Ich würde es vorziehen, nur das Domainnamen-Beispiel zu halten
doc.domain.com => es enthält domain.com

Aber wenn Sie eine Regex-Möglichkeit hinzufügen können, ist dies für alle flexibler, denke ich

Eine Option zum Entfernen der Subdomain wäre großartig!

Es gibt verschiedene Anwendungsfälle, in denen ich es sehr nützlich finden werde:

• Websites können ihre Subdomain in einer neuen Version aktualisieren, zB: example.com/fr -> fr.example.com ;
• example.com und www.example.com verweisen im Allgemeinen auf dieselbe Site;
• viele Sites verwenden Subdomains, jedoch mit derselben Authentifizierung, dh: mail.google.com und drive.google.com oder tex.stackexange.com und math.stackexange.com;
• manchmal hängt die Subdomain vom Kontext ab, zB: example.com und m.example.com.

Ich entferne die Subdomain tatsächlich manuell, um Fehler zu vermeiden, aber ja, behalte das tatsächliche Verhalten standardmäßig bei, um Authentifizierungsprobleme für viele Benutzer zu vermeiden. ;)

@kidburglar und @roipoussiere gibt es keine einfache Lösung, um nur eine ~FQDN~
Dazu benötigen wir eine Liste von TLDs.

Ich mag die Idee einer TLD-Liste nicht, weil:

• erzwingt die Aktualisierung der Liste nach jeder neuen TLD
• Fügen Sie viel KB nur für eine Funktion hinzu

Die Liste wird bereits erstellt von https://data.iana.org/TLD/tlds-alpha-by-domain.txt (10,2kB), https://publicsuffix.org/list/public_suffix_list.dat (196 kB) oder Bibliotheken, zum Beispiel https://github.com/oncletom/tld.js .

@guillaumevincent

Der FQDN ist eigentlich das, was lesspass jetzt macht.
https://chrome.google.com/webstore/search/lesspass => chrome.google.com in lesspass

Um die Domain zu erhalten, müssen Sie nur die letzten 2 Elemente durch "." trennen.
Ich weiß nicht, wie man das in lesspass macht, aber vielleicht wird ein Beispiel in bash klarer.
Ich benutze rev, um die Zeichenfolge umzukehren, damit ich nicht überprüfen muss, wie viele Vorkommen ich habe, aber es gibt sicherlich etwas Besseres.

# site.tld => site.tld
echo 'site.tld' | rev | cut -d '.' -f1,2 | rev
# my.super.site.tld => site.tld
echo 'my.super.site.tld' | rev | cut -d '.' -f1,2 | rev

Um die Domain zu erhalten, müssen Sie nur die letzten 2 Elemente durch "." trennen.

@kidburglar das ist nicht wahr. Versuchen Sie zu verstehen, dass es einige beliebte TLDs gibt, die mehr als einen Punkt enthalten. .co.uk zum Beispiel.

echo 'https://www.bbc.co.uk/' | rev | cut -d '.' -f1,2 | rev

@Kcchouette LessPass hat bereits tld.js von Oncle Tom verwendet. Die Menge an zusätzlichen Daten für nur eine Funktion war der Grund, warum wir sie aufgegeben haben. tlds-alpha-by-domain.txt vermisst einige beliebte TLDs. Und public_suffix_list.dat ist zu groß.
Wir können wahrscheinlich unsere Liste der TLDs in der Top 1M meistbesuchten Site von alexa erstellen.

@guillaumevincent
Ich denke, dass die meisten Erweiterungen diese Idee verwenden (ich teste keine anderen, aber meine vorherige Anwendung Passwordmaker hat sie verwendet).
=> http://passwordmaker.org/passwordmaker.html

Was halten Sie von den Regex-Optionen?

Ich denke, dass die meisten Erweiterungen diese Idee verwenden

@kidburglar Ich bin mir dieser Behauptung nicht sicher.

Was halten Sie von den Regex-Optionen?

Zu komplex wird das Ziel nur Power-User sein.

Die Lösung vorerst:

• Erstellen Sie eine kleine Liste beliebter TLDs basierend auf Alexa-Ranking-Sites.
• Fügen Sie eine Option hinzu, um nur den Domainnamen ohne die Subdomain zu erhalten.

@guillaumevincent
Was passiert, wenn die Site keine der kleinen Listen enthält?
Ein Fallback wie das, was ich zuvor gesagt habe?

@kidburglar ja wahrscheinlich

Bitte warten Sie eine Sekunde...

Worum geht es hier also?

Jeder Benutzer wäre gezwungen, mit LessPass eine Liste von einigen Tausend Domains herunterzuladen, zu installieren und zu laden, von denen der einzelne Benutzer nur einen kleinen Bruchteil nutzt?
Und der einzige Vorteil wäre, nicht ein paar Mal del im einzelnen "Site"-Feld drücken zu müssen, um ein paar unerwünschte Zeichen in diesen speziellen Anwendungsfällen zu entfernen?

Interpretiere ich das richtig?

@SoftwUser
Ich verstehe es wie eine Liste, die in den Weberweiterungen enthalten sein wird.
In meinem Fall geht es nicht nur darum, "ein paar Mal auf del zu drücken", sondern sich daran zu erinnern, welche Website ich dafür aufpassen muss oder nicht, von welchem ​​Einstiegspunkt aus habe ich mich abonniert...
Und wenn es eine Option ist, bin ich mir nicht sicher, ob es etwas für andere Leute ändert, die diese Funktion nicht verwenden.

@SoftwUser keine Liste beliebter Domainnamen, sondern nur eine Liste der beliebtesten TLD

['com', 'org', 'co.uk', ...]

@SoftwUser Ich hatte kürzlich einen Anwendungsfall für impots.gouv.fr , das französische Finanzministerium, bei dem sich der FQDN der Seite zum Festlegen eines neuen Passworts von dem anderswo verwendeten unterscheidet, cfspart.impots.gouv.fr . Im Grunde eine andere Subdomain. Da .gouv.fr ein öffentliches Suffix ist, sollten beide Sites das gleiche Passwort unter impots || .gouv.fr .

Es geht nicht darum, del ein paar Mal drücken zu müssen. Es geht darum, Benutzern die Konzepte hinter Domänennamen nicht erklären zu müssen und warum und wie sie einen Teil der Subdomäne bearbeiten sollten, bevor sie ein Passwort generieren.

@guillaumevincent Die public_suffix_list.dat kann bereits durch Entfernen aller ICANN-Domains vereinfacht werden, da sie offensichtlich alle ein gültiges Suffix sind. Damit soll der Anstieg durch die Registrierung neuer Top-Level-Domains zumindest begrenzt werden. Dies wurde in tld-list.js gemacht .

@serianox Ja, diese Fälle gibt es. Dies rechtfertigt jedoch keine Regression für Benutzer, die bereits Hunderte von erstellten Passwörtern einschließlich des FQDN verwalten. Denken Sie nicht nur an den neuen Benutzer, der über ein spezielles Szenario stolpert. Denken Sie bitte auch an diese bestehenden Benutzer.
Es gibt keinen Grund, den Benutzern irgendwelche Konzepte von Domains/Subdomains zu erklären.
Ich sage, lassen Sie den Benutzer entscheiden, wie er seine Passwörter zusammenstellt! Und schneiden Sie es nicht standardmäßig!

Wie auch immer, ich freue mich, die obige Aussage von @guillaumevincent zu beachten, dass die Regression optional wäre (https://github.com/lesspass/lesspass/issues/258#issuecomment-328555486). So können alle glücklich sein.

@SoftwUser Einverstanden, dies sollte das bestehende Verhalten nicht ändern, zB optional für V2, möglicherweise Standardverhalten für V3.

... möglicherweise Standardverhalten für V3.

Autsch, @serianox , bitte ignoriere nicht https://github.com/lesspass/lesspass/issues/258#issuecomment -328520490

Wir hatten diese Diskussion und sie wurde hier gelöst https://github.com/lesspass/lesspass/issues/258#issuecomment -328555486

Denken Sie daran, dass lesspass standardmäßig Datenschutz verwendet und wir möchten, dass es offline und eigenständig funktioniert. Das Hinzufügen von Drittanbietern ist für mich also ein No-Go. Eine Alternative wäre daher, eine beliebige TLD-Liste in den Build aufzunehmen, sie auf dem neuesten Stand zu halten und sicherzustellen, dass wir keine Benutzerpasswörter knacken…

@guillaumevincent Glaubst du, das ist testbar?

@serianox für Ihr Problem haben Sie derzeit zwei Möglichkeiten, diese Szenarien zu verwalten:

• Merken Sie sich die Site selbst und füllen Sie sie manuell aus;
• Verwenden Sie den verbundenen Modus , um die Reibung zu reduzieren.

Ich schließe dieses dank der Vorschlagsbox in der letzten Version.