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

[Frank Richter]

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 :)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20180121/f5174ebd/attachment-0001.html>