Gut, dass Sie den letzten Punkt in Klammern erwähnt haben, denn er hat mich überzeugt. ;-P

@TX und ich hatten eine große Diskussion über das Einfügen von Konfigurationsteilen in die Statusseite im IRC und es ist mir immer noch sehr unangenehm, die Statusseite schreib- und skriptbasiert zu machen (weil es die Möglichkeit für Sicherheitslücken eröffnet). Und das größte Problem sehe ich noch immer im "Codewort": Die Leute werden dort blind ihr gewohntes Passwort eingeben, egal wie groß, fett, fett und blinkend die Warnung ist, dies nicht zu tun. Und die Einstellung des Codeworts sollte wirklich in den Expertenmodus gehen, denke ich.

Wenn dies implementiert wird, ist es vielleicht möglich, die Authentifizierung mit HTTP Digest zu implementieren? Auf diese Weise müsste ein Angreifer MITM verwenden, anstatt einfach zu schnüffeln.

Ja, ich stimme dem Workflow-Problem zu. Und meine Meinung ist, dass dies eine Kuss-genug-Lösung ist. Trotzdem muss der Benutzer die IP-Adresse des Knotens herausfinden, um auf die Schnittstelle zuzugreifen. Daher schlage ich vor, dass wir den möglichen http-ipv6-Link auf der letzten Seite des Router-Assistenten anzeigen sollten.

Aber um besorgt zu sein, wird die Implementierung dieses Features andere Beschwerden darüber aufwerfen, dass Feature X auf ähnliche Weise zugänglich sein sollte. Und meiner Meinung nach sollten wir den Benutzern keine Steine ​​in den Weg legen, aber auch ein Benutzer, der Technologie installiert, sollte sich dessen bewusst sein und in der Lage sein, damit umzugehen. Vor allem, wenn es sich um eine Dachinstallation im Freien handelt.

Komprimiert: Implementieren Sie es, aber bereiten Sie Ihre Argumente vor.

HTTP-Digest

Ich würde gerne Digest-basierte Authentifizierung verwenden. Leider unterstützt uhttpd dies nicht.

Sicherheitsprobleme / Codeinjektion

Ich bin sicher, dass wir damit gut umgehen können. Ich habe noch nie von Code-Injection-Problemen mit luci gehört, also gibt es wahrscheinlich nur wenige. Wir könnten auch Fuzzer ausführen, um es zu testen.

Codewort / Passwort des Benutzers

Wir könnten das Eingabefeld im configmode zu einem normalen Feld machen (dh keine Sterne) und wir sollten auf jeden Fall eine kurze, aber prägnante Erklärung der Sicherheitsrisiken hinzufügen und den Benutzer wiederum davon abhalten, überhaupt ein Codewort zu setzen.

Sollten sie dennoch ihr Standardpasswort eingeben, können wir nicht viel tun und sie sind sowieso in Schwierigkeiten.

Link zum Knoten

Dies ist in der Tat ein ungelöstes Problem. Ich könnte mir vorstellen, die IPv6-Adresse des Knotens direkt unter dem Codewort-Eingabefeld anzuzeigen, wie zum Beispiel: "Lesezeichen für diesen [Link], um die Koordinaten Ihres Knotens zu ändern, sobald er ausgeführt wird."

Andere, ähnliche Funktionsanfragen

Ich habe dies absichtlich sehr eng gefasst, weil ich mir dieser anderen Fragen bewusst bin. Das größere Ziel, das ich immer noch erreichen möchte, ist, den Konfigurationsmodus loszuwerden und alles während des normalen Betriebs aus der Ferne über das Mesh zu tun. Damit dies jedoch sicher ist, müssen wir viele Probleme lösen.

Sollte jemand eine ähnliche Funktion wünschen, sollten wir ihn entweder auf dieses Problem hinweisen oder auf eine Wiki-Seite, die alles zusammenfasst. In jedem Fall sollten wir ihn bitten, eine umfassende Ausgabe über das gewünschte Feature zu schreiben, in der alle Sicherheitsbedenken angesprochen werden, die hier und in Diskussionen mit anderen Entwicklern erwähnt wurden. Wenn er erfolgreich ist, könnte er tatsächlich einen gültigen Punkt haben.

Einmaliges Codewort

Ich hatte gerade eine andere Idee, aber ich möchte sie hier nicht diskutieren, da sie den Workflow zu sehr stören könnte. Wir werden es sicherlich besprechen, nachdem meine aktuelle Lösung entweder akzeptiert oder abgelehnt wurde.

Das Codewort könnte einmalig verwendet werden. ZB der erste, der die Koordinaten (auf der Statusseite) ändert und das richtige Codewort eingibt, ist erfolgreich. Danach ist es gesperrt und ein weiteres Codewort muss im configmode gesetzt werden.

Dies könnte optional gemacht werden, aber ich fürchte, es könnte den configmode wieder zu komplex machen (2 Checkboxen, 3 Eingabefelder zum Setzen von Koordinaten).

Sollte HTTP Digest nicht auch im Skript hinter uhttpd implementiert werden können? Es sind schließlich nur Kopfzeilen und so...

Ich stimme definitiv dagegen, dies für das erste Gluon-Release zu implementieren. Wir haben es abgelehnt, die Statusseite schöner zu machen, was eine relativ unwichtige Änderung ist, also sollten wir diesen Haufen Fragen nicht in die erste Runde werfen, denke ich.

Es ist nicht mit einem Meilenstein versehen, daher ist es definitiv kein Showstopper für 2014.1, aber wenn wir zustimmen, es zu bauen, könnte es 20141 schaffen.

Ja, du hast Recht. HTTP-Digest könnte möglicherweise nur mithilfe von Headern implementiert werden.

Die Rückkehr zur passwortbasierten Authentifizierung für alles erscheint mir wie ein großer Rückschritt.

Ich dachte wir hätten schon eine Lösung für das Kartenproblem? Fast alle Nutzer befinden sich beim Einrichten ihres Nodes sowieso in einem WLAN, sodass wir einfach eine Karte aus dem Internet laden können. Wir müssen nur einen guten Fallback (Eingabefelder) für den Fall bereitstellen, wenn dies nicht der Fall ist.

Und ich sehe kein Problem darin, dass Benutzer einmal in den Konfigurationsmodus zurückkehren müssen, wenn sie irgendwo einen Knoten installieren.

Eine andere Möglichkeit könnte darin bestehen, eine spezielle Konfigurationsseite mithilfe von SSH-Reverse-Tunneling zugänglich zu machen. Dies würde erfordern, dass der Benutzer seinen öffentlichen SSH-Schlüssel während des Konfigurationsmodus eingibt.

Warum nicht eine spezielle Konfigurationsseite haben, auf die über http://node.ffhh zugegriffen werden kann, wenn der Knoten zuerst mit dem Freifunk-Netzwerk verbunden wird (über Mesh oder VPN). Wenn der Besitzer den Konfigurationsmodus nicht aufruft, funktioniert freifunk nicht. vielleicht mit dem Reset-Button als eine Art Authentifizierung ("Drücken Sie diesen HTML-Button und den Reset-Button innerhalb von 30s, um die Konfiguration des Knotens zu ermöglichen").

Ich betrachte das als eine Art Plug-and-Play-Setup mit automatischer Registrierung des Knotens beim ersten Booten. die automatische verbindung zum freifunknetz (mesh oder vpn) würde es ermöglichen, eine karte anzuzeigen und so weiter.

Ich glaube nicht, dass eine Hardware-Interaktion möglich ist, wenn sich der Knoten bereits an einem entfernten Standort befindet. Auch für Geräte, zB ubnt-Geräte, ist der Zugriff auf einen Hardware-Button etwas schwierig.
Anstelle einer direkten http-Schnittstelle sollten wir eine ssh-basierte Konfigurationsschnittstelle in Betracht ziehen.
Auf die dann über eine https-gesicherte Schnittstelle eines Drittanbieters zugegriffen werden könnte.
Die Implementierung der ssh-Konfigurationsschnittstelle erfordert einen Benutzer mit einer speziellen Konfigurations-Shell,
die keine anderen Interaktionen zulassen sollte.

Irgendwelche Lösungen mittlerweile? Hat jemand so etwas schon lokal implementiert?

hexa hatte die Idee, ein zeitbasiertes OTP (zB RFC 6238) zur Authentifizierung zu verwenden. Ich mag diesen Ansatz. Damit dies funktioniert, würde dem Benutzer ein QR-Code (+String) zum Einrichten des OTP-"Clients" (dh eines Smartphones) angezeigt. Der Benutzer muss in der Lage sein, das Token zurückzusetzen (oder die Funktion vollständig zu deaktivieren).

Dies ist alles andere als die bequeme Idee, Geo mit Statusseite (mit welchem ​​Authentifizierungsmodus auch immer) einzustellen . /github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ können Sie standardmäßig zu Ihren Knoten oder Ihrer Firmware hinzufügen

Wie wäre es mit einem großen Hinweis

Stellen Sie sicher, dass Sie die Geokoordinaten aufgeschrieben haben, bevor Sie fortfahren

das nach einer Neuinstallation nur einmal beim ersten Aufruf des Konfig-Modus angezeigt wird?

@blocktrron @mweinelt @rotanid Können wir das schließen?

NeoRaider sagte

Und ich sehe kein Problem darin, dass Benutzer einmal in den Konfigurationsmodus zurückkehren müssen, wenn sie irgendwo einen Knoten installieren.

Ich denke, das ist wahr ... Zurück in den Konfigurationsmodus zu gehen ist machbar. Hier braucht es keine allzu komplizierte Lösung und diese wurde in 5 Jahren nicht umgesetzt. Also wird das vielleicht nie fertig...