[vz-dev] Testing Pull Request 659 / jwt - Add basic login capabilities

[Daniel Lauckner]

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