vorschlag: apikey statt csrfToken ?

[justme1968]

wie wäre es den aktuellen csrfToken mechanismus zu einem apikey mechanismus zu erweitern?

die idee wäre folgende:
- zugriff per http ist nur noch mit gültigem apikey in der url erlaubt
- jede fhemweb instanz kann zu jedem zeitpunkt mehr als einen apikey haben
- es gibt statische apikeys -> zur verwendung mit externen url aufrufen
- fhem/fhemweb bekommt die möglichkeit diese statische apikeys zu verwalten (anlegen, löschen)
- ein apikey kann mit allowed regeln verknüpft werden
- wenn fhemweb ohne basicauth/login verwendet wird wird ein dynamischer apikey erzeugt
- wenn fhemweb per basicauth/login verwendet wird wird dynamisch ein apikey für diese sitzung erzeugt
- durch basicauth/login erzeugte apikeys werden bei einem expliziten logout gelöscht
- dynamische apikeys laufen nach einer bestimmten zeit der nichtbenutzung ab

mögliche erweiterungen wären:
- verwenden von cookies mit laufzeit?
- erweiterung auch für das telnet interface?

[herrmannj]

gespaltene Meinung: ich vermute das Andre in einem anderen thread richtiger weise analysiert hat das der der token nur begrenzt hilft. Wenn man javascript einschleusen kann oder die böse Seite komplett kontrolliert lässt sich per CORS -> xhtml (liefere 8083 inkl token) -> js extract token -> "be evil" der token "erbeuten" ...

Api key hat aber einen Rattenschwanz, viele user suchen sichtlich einfache Lösungen. Von daher sollte er imho komplett optional sein (deutlicher Hinweis cmdref). Außerdem würde ich den api key nicht im Klartext anhängen sonder den weg gehen

1 Abfrage konstruieren
2 Hash aus Abfrage und key konstruieren
3 Abfrage und hash *ohne key* übertragen

Sonst lässt sich der Key nicht wirksam geheim halten. Das ist aber eben auch ein gutes Stück Arbeit und nach den threads der vergangenen Tage denke ich das nur wenige user da profitieren werden.

vg
joerg

[betateilchen]

Mal abgesehen vom (für mich) unverständlichen paranoia-Modus, der hier aktuell um sich greift, eine ernstgemeinte Frage:

Wieviele Fälle sind denn bisher bekannt, in denen diese Schwachstelle tatsächlich ausgenutzt wurde und zu Schäden führte?

Indem man hier tage-/wochen-/seitenlang über die MÖGLICHKEIT diskutiert, bringt man doch den einen oder anderen vielleicht erst auf die Idee.

[rudolfkoenig]

@andre: ich habe kein Problem mit deinem Vorschlag, aber erst mittelfristig, nachdem die csrfToken "Wellen" sich wirklich gelegt haben.

@joerg: das Problem mit "optional" ist (wie csrfToken das gezeigt hat), dass es dann keiner verwendet. Natuerlich muessen wir es "reifen" lassen, bevor sie die Voreinstellung wird, und diesmal hinkriegen, dass es vorher getestet wird. Ist als Probe zu sehen, was wir bei csrfToken gelernt haben

@betateilchen: mir sind keine Probleme bekannt, allerdings will ich nicht, dass "Journalisten" das naechste mal FHEM als Beweis fuer

Smarthomes sind alles andere als sicher

nehmen. Das war der Schlussatz der PlusMinus Sendung, hier aufgegriffen: https://forum.fhem.de/index.php?topic=67192.0

[zap]

Ihr könnt gerne apikeys und / oder tokens einbauen.
ABER: bitte bitte macht es abschaltbar!
Ich brauche es nicht, denn es macht meine Smarthome Intgration, die nicht nur aus FHEM besteht, unnötig kompliziert. Unnötig, weil mein Netz nur per VPN von außen erreichbar ist und die og Mechanismen eh nur ein wenig mehr Schutz bieten.
Und gegen Journalisten und sog. IT-Experten, die mutwillig Sicherheitslücken öffnen, ist eh kein Kraut gewachsen.

[justme1968]

die probleme die das token oder ein spikes beheben sollen sind unabhängig vom zugang, haben damit nichts zu tun und lassen sich auch mit vpn nicht verhindern.

wie groß das risiko tatsächlich ist, ist aber eine andere frage.

ein erzeugbarer apikey macht eine integration nicht schwieriger.