[vz-dev] Testing Pull Request 659 / jwt - Add basic login capabilities
Daniel Lauckner
vz at jahp.de
Sun Jan 21 15:20:17 CET 2018
Hallo,
am Sonntag, 21. Januar 2018 um 14:01 hat Frank Richter geschrieben:
> Hi Andreas,
> wow, das mit den eingeschränkten Tokens ging schnell!
> Hast recht, security by design ist sicher der bessere Ansatz,
> gerade bei neuen Installationen ist das weitaus sinnvoller als alles
> offen zu lassen. Lass es uns einfach probieren und abwarten, wie
> viele Reklamationen tatsächlich kommen, weil es nach dem Update
> nicht mehr so funktioniert wie vorher...
> Anpassung des Installscripts bzgl. Firewall-Einstellungen sollten
> wir dann auf die Agenda setzen. Zusätzlich sollten wir diesen Part
> vielleicht als Extra-Script liefern, damit die Image-User sich das
> passend konfigurieren können, ohne das komplette Installscript
> nochmal durchzuackern. Das Image sollte dann am besten ohne
> eingetragenen secretkey geliefert werden, oder?
> Wenn es machbar wäre, das Token aus dem Cookie auszulesen, wäre ich
> schwer dafür. Dann hätte ich keinen Grund mehr, GET ohne Authentifizierung zuzulassen.
> Viele Grüße
> Frank
> Am 21. Januar 2018 um 13:17 schrieb Andreas Goetz <cpuidle at gmail.com>:
> Ok, ich habe noch ein kleines Tool gebaut mit dem sich beliebige
> Token erzeugen lassen und den AuthorizatonController so angepasst
> dass die Tokens auch “constraints” haben können:
> ❯ php misc/tools/token-helper.php decode $(php
> misc/tools/token-helper.php create andig --operation add --context data --valid 1.1.2019)
>
> {"sub":"andig","iat":1516536798,"exp":1546297200,"vz:ctx":"data","vz:ops":"POST"}
> In diesem Fall darf das 1 Jahr gültige Token ausschließlich “POST”
> auf den “/data” Kontext, also nur neue Daten anlegen aber nix löschen.
> @Matthias: könntest Du im vzlogger eine Option einbauen mit der
> sich für das VZ API ein “Authorization: Bearer <token string>” Header mitschicken ließe?
> @Frank: Cookie schaue ich mir noch separat an.
> Viele Grüße,
> Andreas
> On 21. Jan 2018, at 12:07, Andreas Goetz <cpuidle at gmail.com> wrote:
> Moin
> On 20. Jan 2018, at 15:58, Frank Richter
> <frank.richter83 at gmail.com> wrote:
> ...
> Da bin ich einmal nicht so schnell :O
> kein Ding. Hab nur angefangen mich zu wundern, warum zweimal keine
> Reaktion zum selben Thema kommt...
> Du hast uns halt zu sehr verwöhnt was Reaktionszeit angeht ;-)
> Hoffe dein NAS-Recovery ist erfolgreich gewesen oder auf einem guten Weg!
> Gottseidank ja. Der Bootprozess klemmte weil metricbeat auf das
> defekte Volume zugreifen wollte- deshalb kam die Oberfläche nicht
> hoch. Nach Prozess killen gabs dann eine NAS Oberfläche mit der sich
> das defekte Volume reparieren ließ. Disk1 hatte seine
> Systempartition verloren- weiß der Geier warum….
>
> ...
> Dann greifen wir die Punkte doch auf:
> Am 25.12.2017 12:43 schrieb "Andreas Goetz" <cpuidle at gmail.com>:
> Servus,
> Der PR steht hier zur Verfügung:
> https://github.com/volkszaehler/volkszaehler.org/pull/659
> Vor Merge wär unabhängiger Test gut. Für die Installation im Image sind zwei Punkte wichtig:
> 1. unbeschränkten Zugang gibts jetzt nur noch von localhost und localnet
> 2. es werden ein secretkey (salt) und user/passwort für
> Schreibzugriffe benötigt, ggf -secretkey im installer automatisch erzeugen
> da fällt mir unsere alte Diskussion um manuelle, d.h. nicht vom
> Frontend abgesetzte API-Requests von extern ein. Diese funktionieren
> dann nicht mehr, weil man keine Möglichkeit hat, dem Request das
> nötige Authentifizierungs-Token mitzugeben. Das könnte ein Problem
> sein für alle, die ihren vz extern hosten.
> Auch vzlogger könnte Stand heute nicht zu einer externen,
> abgesicherten Installation loggen, oder? Außer man erlaubt POST
> standardmäßig, aber das macht ja die Absicherung irgendwie witzlos.
> Ich sehe zwei Möglichkeiten (da würde mich auch die Meinung von Justin interessieren):
> 1) wir erlauben die Erstellung von long-lived Tokens und bringen
> vzlogger bei so einen Token als curl Header mitzuschicken. Ist
> trivial, hat aber einen Nachteil: kommt so ein Token abhanden kann
> jeder damit machen was er will. Das ließe sich noch abmildern wenn
> wir dem Token eingeschränkte Rechte verpassen, z.B. nur POST oder
> nur für einzelne Kanäle. Das Grundproblem bliebe aber- Token weg, Tür offen.
> Ist das riskanter als eine verlorene
> Benutzername/Passwort-Kombination. Kann man ein fragliches Token serverseitig ungültig machen?
> Da Token nicht gespeichert werden kann man sie auch nicht einzeln
> ohne Codeeingriff ungültig machen. Änder man aber in der Config den
> secretkey dann sind alle Token ungültig.
> Standard ist eigentlich die Tokens kurzlebig zumachen. “Richtig”
> löst man das z.B. mit OAuth was bedeutet dass jede Applikation sich
> neue Tokens bei Bedarf mittels API Key (=secret) anfordert. Das
> müsste aber in den vzlogger, also ein größerer Eingriff mit überschaubarem Nutzen.
> 2) Man erlaubt tatsächlich POST von außen, und zwar nur auf /data:
> [
> 'path' => ‘/data',
> 'methods' => 'POST',
> 'action' => 'allow'
> ],
> damit lassen sich ausschließlich Daten schreiben, aber zumindest
> keine Löschen (m.E. auch nicht ändern, wäre zu testen). Wenn dazu noch GET verboten wird:
> [
> 'methods' => 'GET',
> 'action' => ‘auth'
> ],
> gibts auch ohne Login keine Möglichkeit mehr Daten oder Kanäle
> abzufragen. Das würde es mal deutlich schwieriger machen
> irgendwelche UUIDs rauszubekommen um dort Daten zu überschreiben.
> Das Risiko, dass UUIDs abhanden kommen, dürfte ähnlich sein wie beim Token?
> Ich verstehe die Frage nicht. Mir gings drum- wenn vzlogger per
> Token Zugang bekommt _und_ der Token verloren ginge- die Risiken zu
> ermitteln. Aus meiner Sicht beherrschbar und nicht größer als heute ohne jede Zugriffsbeschränkung.
>
> Variante 2) lässt sich heute per Config machen. Reicht das?
> Ich denke für den Moment reicht's, das mit den Tokens für vzlogger
> (und andere Clients) würde das Konzept aber IMHO noch runder machen.
> Gut, ich schau mal. Egtl. nicht schwierig. Ich schaue dass wir neue Tokens bauen die
> a) eine lange Laufzeit haben und
> b) nur bestimmte Rechte mitbringen wie etwa POST auf /data- mehr braucht der logger ja nicht
>
> In jedem Fall wirds nicht schlimmer als heute da die Systeme aktuell ja komplett auf sind.
> Das stimmt, so lang es den Status quo nicht verschlechtert, sollte
> das einem Merge nicht im Weg stehen.
>
> Wenn ich momentan Services ins Internet hänge stelle ich übrigens
> immer Traefik als Reverse Proxy davor- da lässt sich ganz einfach
> auch SSL und Basic Auth mit einschalten, auch das wären zusätzliche
> Absicherungsmöglichkeiten vor einer VZ Installation.
> Schau ich mir mal genauer an. Macht das auch in einem
> althergebrachten System ohne Docker und Konsorten Sinn?
> Absolut. Heute brauchst Du ja auch einen Reverse Proxy (apache,
> nginx). Traefik ist Welten einfache zu konfigurieren und kann viel
> mehr wie z.B selbst die LetsEncrypt Zertifikate erzeugen. Fertig ist die SSL Verschlüsselung...
>
> Letztlich bleibt dann die Frage ob es die ganze “public” Channel
> Mimik noch braucht oder die weggeschmissen werden sollte. Wer keinen
> Zugriff will kann ja einfach die Installation privat halten und hinter U//P verstecken.
> Du würdest also alle Kanäle so behandeln wie die die heutigen
> public channels? Wäre für mich okay, allerdings funktioniert damit
> demo.volkszaehler.org nicht mehr in der heutigen Form.
> Das stimmt uns ist auch noch nicht implementiert. Für Demo müsste
> es dann einen automatisch eingeloggten `guest` user geben der im
> Falle von Demo eben mehr Rechte als normalerweise bekäme.
> Der guest user sollte dann aber nicht alle vorhandenen Kanäle als
> öffentlich angezeigt bekommen. Deswegen kann die Unterscheidung
> public/private channels erst entfallen, wenn es eine Implementierung von
>
> Der letzte konsequente Schritt wäre dann eine echte Userverwaltung
> statt Konfigurationsdatei und damit auch “Owner” von Kanälen und
> Sichtbarkeitssteuerung. Aber das ist noch eine ganz andere
> Diskssuion und bräucht ein wenig Spec bevor losgecodet wird.
> Das wäre zumindest eine Lösung für o.g. Problem mit demo.
> gibt.
> Stimmt. Aber da ich dafür eh grad keine Zeit hab ist’s egal :)
> Aktuell relevant ist egtl. nur der Punkt mit vzlogger. Also was
> tun- rein damit und per Config lösen?
> Grundsätzlich rein damit. Ich bin mir nur unsicher, wie viel
> Support-Aufwand wir damit generieren. Was hältst du davon, die
> Firewall nicht "scharf geschaltet" auszuliefern ("allow" statt
> "auth" für alle verbleibenden Requests)? Dasselbe gilt für
> M.E. lieber AUTH. Wer Dinge mutwillig ins Internet hängt sollte
> sich damit auseinander setzen. Security by design? Im local net ist ja weiter alles offen.
> unpassende/unvollständige Config-Files: Lässt es sich mit wenig
> Aufwand so coden, dass die Firewall einfach offen bleibt, wenn die
> erforderlichen Optionen nicht gefunden werden?
> Security by design. Ja, würde ich aber nicht machen wollen.
> Wer die Absicherung verwenden will, muss sich dann halt damit beschäftigen.
> Ansonsten wär ein kleine Script für die einfache Erfassung von
> user/password/secretkey bestimmt sinnvoll. Wahrscheinlich macht es
> wenig Sinn, in zukünftigen Images schon einen secretkey einzutragen,
> weil der dann öffentlich bekannt wäre? Ich kann leider in Sachen Bash-Script nicht aushelfen.
> Hilfe willkommen. Ggf. ein kleines Tool das User anlegt, ich schau mal.
> Das einzige, was mir sonst noch fehlt, ist eine Lösung für den
> schnellen Middleware-Request zwischendurch, z.B. auch für deinen
> neuen query Kontext. Ich würde eigentlich auch für GET gerne "auth"
> verwenden, aber darüber stolpere ich regelmäßig. Kann die
> middleware.php irgendwie abfragen, ob der aufrufende Browser ein
> gültiges Token in den Cookies liegen hat?
> Ich glaub wir hatten das Thema schon mal, und du warst unschlüssig,
> ob das security-mäßig in Ordnung wäre. Also möglicherweise auch ein Frage an
> @justin?
> Du meinst falls kein Token im Header aber im Cookie auch ok? Klingt eigentlich plausibel (tm).
> @Justin: ist sowas eine gute Idee?
> Viele Grüße, Andreas
> ..snip..
> Viele Grüße
> Frank
> Viele Grüße, Andreas
> PS.: und vielen Dank für die aktive Diskussion :)
mfg Daniel
More information about the volkszaehler-dev
mailing list