Ja dann hänge ich mich also mal hier mit ran.
Fände es ebenfalls sinnvoll, wenn sich der Connect-Dienst individuell anpassen ließe, sodass man wählen kann, ob WebFront (mobile), Verwaltungskonsole, Webhooks, Module, OAuth etc. darüber funktionieren oder nicht.
Klar kann ich zur Absicherung auch ein 128 Zeichen langes Kennwort bestehend aus alphanumerischen- und Sonderzeichen verwenden und dies in den Clients speichern und im LAN unterdrücken.
Aber wenn ich doch beispielsweise nur einen Webhook erreichbar machen will, warum soll man dann anderen erst die Möglichkeit bieten, das gesamte WebFront oder die Verwaltungskonsole aufrufen zu können?
Was mir nicht gefällt ist der Umstand das alle Webfronts gesehen werden und die Passwort Abfrage
erst erfolgt wenn man zugreifen möchte. So werde ich den Dienst nicht nutzen.
Ich würde es begrüßen das man sich erst anmeldet und dann zur Übersicht geleitet wird.
Und dann in der Konfiguration vom Webfront entscheiden kann, erreichbar via Symcon Connect oder eben nicht.
Aus Erfahrung weiß ich, alles was man sehen kann weckt Begehrlichkeiten.
btw. Schön wäre auch wenn ich mehrere User / Passwörter pro Webfront hinterlegen könnte.
So sind die schnell verbrannt …
Kann man schon eine vorsichtige Prognose abgeben, ob diesbezüglich noch Änderungen angedacht sind?
Ich finde es nach wie vor unpraktisch das Ganze durch kryptische Passwörter, Einschränkungen bzgl. Remote-Zugriff etc. abzusichern. Und wer den DNS-Request vom ipmagic-FQDN abgreifen kann, ist schon mal ein ganzes Stück weiter.
@DrFrank: Dieses Feature kommt zu IP-Symcon 4.4. Nach 5 Login-Versuchen wird eine Verzögerung von 5 Sek. hinzugefügt. Nach 15 versuchen ist ein Login für 15 Minuten vollständig blockiert.
@Slummi: Ich habe ein Feature Request daraus gemacht. Es hat aber zur Zeit keine Priorität und ist zudem eher kompliziert, da wir innerhalb des Connect Control die Pakete analysieren müssen, anstatt diese wie bisher einfach weiter zu reichen. (Die Erkennung von WebFront/Konsole erfordert zusätzlich die vollständige JSON-RPC anfrage, da die Befehle über die selbe API gehen)
Unabhängig von der Einstellbarkeit finde ich es sehr interessant, dass 15 Versuche von vielen als zu viel aufgefasst werden. Woran liegt das?
Wenn ich selber das Passwort vergessen habe, probiere ich erst einmal die verschiedenen Varianten meiner „Standardpasswörter“ durch. Wenn davon nichts klappt, versuche ich es vielleicht noch einmal, falls sich ja eventuell irgendwo ein Typo eingeschlichen hat. So komme ich beim gezielten Durchprobieren schon auf ein paar Versuche mehr, 15 sollten aber zumeist ausreichen.
Auf der anderen Seite soll die Sperre natürlich die aufhalten, die sich unrechtmäßig Zugriff zu meinem System beschaffen wollen. Hier wird üblicherweise auf mehr oder weniger intelligente Art und Weise eine große Menge von Passwörtern einfach durchprobiert. Jetzt hoffe ich einfach mal, dass ihr euer System nicht mit Passwörtern sichert, die auf so einer Liste auf den ersten 15 Positionen stehen, also man sein Heim nicht mit einem Passwort wie „passwort“ oder „1234“ sichert. Wenn also kein Trivialpasswort verwendet wird, dann beißt sich der Angriff an der Sperre schon die Zähne aus, da auf einmal alle 15 Versuche 15 Minuten Sperre kommen, der Vorgang extrem in die Länge gezogen wird und anstatt Stunden jetzt auf einmal Jahre benötigt um eine etwas umfangreichere Liste mit Standardpasswörtern durchzuprobieren.
Ich finde für beide Szenarien ist 15 also eine sehr angenehme Grenze. Welche Szenarien stellt ihr euch noch vor bei denen diese Grenze unpassend ist?
Wenn ich nach ~3 Passwörtern nicht das richtige Passwort „erraten“ habe, dann „errate“ ich es auch mit den nächsten 12 Versuchen nicht…ist meiner Meinung nach also sinn frei den Wert so hoch zu setzen. Kaum ein Produkt erlaubt annähernd so viele Fehlversuche.
Macht jemand (oder ein Bot) eine Brute-Force Attacke, dann macht es einen riesen Unterschied, ob er pro Stunde 60 oder nur 12 Passwörter ausprobieren kann… Das sind immerhin 1440 zu 288 Login-Versuche pro Tag…
Solltet ihr also an den 15 Versuchen festhalten und dies nicht einstellbar machen, dann müsste entweder die Sperr-Zeit deutlich erhöht werden (min. 1 Stunde), oder die Sperr-Zeit einstellbar gemacht werden.
Gerade weil es offensichtlich so unterschiedliche Ansichten diesbezüglich gibt sollten die Anzahl der Fehlvesuche und die Sperrzeit einstellbar sein. Ich bin kein Coder aber ich kann mir nicht vorstellen, dass das programmiertechnisch eine Herausforderung darstellt.
Eine Einstellschraube dafür ist überhaupt kein Problem. Ich würde dann jeweils die Sperrzeiten auch einstellbar machen.
Die Werte sind für den ersten Test einfach aus der Luft gegriffen. Wie viele Versuche und welche Zeitsperren haben denn andere gängige Systeme? Ich weiß, dass Forum hat eine 5 Versuche / 15 Minuten sperre. Eine Verzögerung gibt es quasi gar nicht.
Das hängt ganz vom System ab. Je nachdem wie „kritisch“ eine Anwendung bei uns ist - von 3/10 bis 3/60 und teilweise auch noch höher…
Oft wird es auch abgestuft gemacht, also z.B. 1. Stufe = nach 3 Fehlversuchen 10 Minuten Sperre, 2. Stufe = nach weiteren 3 Fehlversuchen 30 Minuten Sperre, usw…
Aber wenn du es einstellbar machst, dann ist alles wunderbar