Wie Tinkerforge mit Passwörtern umgeht II/II

[Quantasy]

Ich finde es auch nach vielen Jahren Tinkerforge Fan-Boy immer noch absolut unverantwortlich, dass die WLAN-Extensions das WLAN-Passwort freimütig herausgeben.

 

Natürlich kann das Passwort dann (mit ein bisschen mehr Aufwand) ausgelesen werden, wenn man in den physikalischen Besitz der WLAN-Extension kommt. Aber eben... es sollte halt nur dann gelingen.

 

Ansonsten plärrt diese das Passwort sowohl per USB als auch per IP und in der Default Einstellung sogar per Web einfach raus.

 

Warum gebt Ihr das Passwort preis?

Gibt es einen echten Grund, dies zu tun?

Es gibt auf jeden Fall einen Grund es nicht zu tun: Security!

 

Bitte, überlegt euch die öffentliche API diesbzgl. nochmals!

Die öffentliche API (USB/TCP/Web) sollte anzeigen ob ein Passwort gesetzt ist oder nicht, aber nicht... welches!

 

 

Momentan können die Stacks an Schulen (bei denen die Studenten ihre persönlichen WLAN-Passworte in die WLAN-Extension schreiben) nicht benutzt werden, ohne dass die Studenten ihre Zugangsdaten für E-Mail / und Eduroam / ... auch gleich vollständig kompromittieren.

 

Die Möglichkeit, die Verbindung zu authentisieren (welche ja per Default nicht eingestellt ist), nutzt in diesem Fall ja auch nichts.

Wenn die Studenten die verschiedenen Projekte übers Netz zur Verfügung stellen möchten, kann man zwar nur drauf, wenn man die Authentisierung kennt... aber dann hat man wieder vollen Zugriff auf das eingegeben Passwort.

 

Ich bitte euch, schaltet das ab! Die WLAN-Extension ist kein Passwort-Recovery IoT-Unit (wie so viele leider andere auch).

 

[borg]

Im Gegensatz zum fehlendem https im Forum haben wir darüber schon häufiger intern diskutiert.

 

Grundsätzlich kommst du nicht an das Passwort der WIFI Extension wenn du keinen physikalischen Zugriff hast (dazu zählen wir Zugriff per USB) und nicht im gleichen Netz bist. Für den Fall dass eine WIFI Extension in einem ansonsten öffentlichen Netz betrieben werden soll, gibt es Authentifizierung: https://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/WIFI_V2_Extension.html#authentifizierung

 

Das ist IMO soweit OK. Wenn ich im Netz einer FritzBox bin und das Passwort des Webinterfaces kenne (Authentifizierung), kann ich auch das WLAN-Passwort auslesen. Der vergleich passt sogar noch besser zur Webseite der WIFI Extension.

 

Eine berechtigte Frage dazu ist: Sollte die Authentifizierung für die WIFI Extension per Default aktiviert sein?

[Quantasy]

Da muss ich in mehrerlei Hinsicht widersprechen.

 

Zuerst vielleicht nochmals die konkrete Frage:

Welchen Grund dafür gibt es, das Passwort preiszugeben?

Die Fritz-Box, welche ja als Beispiel von Borg aufgeführt wurde, die schreit das auch nicht einfach so raus. Da muss man schon die Fritz-Box selbst administrieren (ein Admin-Passwort kennen), um das WLAN-Passwort in Klartext zu sehen!?

 

Die Authentisierung von Tinkerforge aber ist nicht gleichzusetzen mit dem Admin-Passwort der Fritz-Box. Denn die Fritz-Box bietet ihre Dienste auch Teilnehmern an, welche das Admin-Passwort nicht kennen.

 

Hier zwei Beispiele, bei denen das 'Sicherheitskonzept' Tinkerforge ins leere geht:

 

1. Einfacheres und gegebenes Szenario (Jedes Semester wieder):

Ein WLAN-Netzwerk an der Uni, bei dem jeder Student und Dozent sich mit seinem persönlichen Passwort anmelden muss. (802.1x EAP)

 

Wenn nun ein Student/Dozent mit Tinkerforge und einer WLAN-Extension etwas demonstrieren soll... (simples Beispiel: Ein Dual-Button-Sensor, der von jedem beliebigen Teilnehmer im Netz ausgelesen werden können soll) und dazu sein persönliches Passwort dafür benutzt (etwas anderes gibt es nicht an der Uni)... wie soll er das Passwort denn 'schützen'?

 

Mit der Tinkerforge Authentisierung geht das nicht, da wird sichergestellt,  dass fremde im gleichen Netz überhaupt nicht an die Komponente kommen.

Die Authentication ist also genau dann hilfreich, wenn jemand Tinkerforge-Komponenten betreibt und nicht will, dass andere 'mitmachen'; was das Gegenteil von dem ist, was das erste Beispiel aufzeigen soll.

 

 

 

2. Beispiel (Das ist ein wüster Hack)

Ein Gerät (z.B. ein Android oder iPhone) ist im Netz eingebucht. Die Apps kennen aber das WLAN-Passwort nicht. Nun möchte eine App einer dritten Partei das WLAN-Passwort zukommen lassen... (Vielleicht über Twitter   )

 

Ganz einfach (und ganz ohne Social-Engineering und sogar App-Store-tauglich): Schreibe eine App, welche nach Tinkerforge-Komponenten scanned. Ist auch nur eine einzige Tinkerforge-Komponente im Netz, welche darauf antwortet... bedankt sich das Internet für einen 'easy-Access'. Wenn dann noch mehr an diesem Passwort hängt... um so besser! Kostenlose 'anonyme' E-Mail, oh, das Intranet mit allen Diensten der Uni... herrlich!

 

(Ich werde diese App schreiben und als Tinkerforge-Projekt jedem zur Verfügung stellen... ;-)  )

 

 

Wo genau wäre denn das Problem, wenn die öffentliche API für IP und USB einfach nur zurückgibt ob das Passwort gesetzt ist, das Passwort aber zurückhält? Ist das aus Design-Gründen nicht möglich? Wo ist der Show-Stopper für diesen Security-Request?

 

 

Zur Frage, ob die Authentisierung per Default aktiviert sein soll:

Hier kommt dann aber sofort das Schlüssel-Verteil-Problem zum Tragen. Wie soll denn dieser Schlüssel bekanntgegeben werden? Per Default aktiv mit: '123456' oder 'changeOnInstall'? Oder klebt dann an jeder Extension ein Zettel?

 

Nein, das erzeugt nur unnötigen Aufwand auf der Benutzerseite, den es nicht geben würde, wenn das WLAN-Passwort zurückgehalten würde.

 

 

[borg]

Wo genau wäre denn das Problem, wenn die öffentliche API für IP und USB einfach nur zurückgibt ob das Passwort gesetzt ist, das Passwort aber zurückhält?

 

Die Frage ist: Wann darf ich das Passwort setzen? Wenn ich das Passwort nicht auslesen darf, aber es neu setzen kann hab ich ja nichts gewonnen.

 

Wenn ich das Passwort weder per IP noch per USB setzen kann, dann müssen wir die Extension mit einem festen und unveränderlichem PW ausliefern? Oder wie stellst du dir das vor?

 

Als einzige alternative könnte ich mir noch vorstellen das man zum ändern des PWs das alte PW mit übertragen muss. Damit hätte man dann aber die WIFI Extension gebrickt wenn man das PW vergisst...

 

Man könnte als Kompromiss das auslesen/setzen von PWs über WLAN verbieten und nur über USB erlauben.

[Quantasy]

...Wann darf ich das Passwort setzen? Wenn ich das Passwort nicht auslesen darf...

 

Die Antwort auf das 'gekürzte' Zitat von Borg in Bezug auf meinen Security-Request ist:

Setzen 'immer', auslesen 'nie'.

 

Das Setzen bzw. Überschreiben eines Passwortes ist ein Akt der momentan noch nicht geregelt ist (ausser durch die ultimative Autentisierung). Falls auch dieser Akt geregelt werden soll, müsste tatsächlich ein Rollenkonzept eingeführt werden. So z.B durch ein Admin-Passwort (siehe Fritz-Box). Dieses könnte dann nur noch per Hard-Reset zurückgesetzt werden, wobei sämtliche Geheimnisse verloren gehen müssten. Aber so weit sind wir ja bei Tinkerforge noch nicht.... Eins nach dem anderen ;-)

 

Das Wesen meines konkreten Security-Requests gilt aber einzig dem Schutz

des Geheimnisses in Bezug auf 'Wissen'. Also, dass kein Geheimnis ausgeplappert wird, dass kein Dritter (über die API) Kenntnis über das Geheimnis erlangen kann. Ob es überschrieben werden darf und von wem, das ist nicht Teil dieses Requests.

 

Die API sollte also um folgende Fähigkeit erweitert werden: Niemand drittes soll Kenntnis erlangen können, welches Passwort gesetzt wurde.

 

 

Übrigens:

Es ist bemerkenswert, dass die grundsätzliche Frage bei dieser Diskussion nicht berührt wurde. Ich will sie somit erneut in den Raum stellen:

 

Welchen Grund dafür gibt es, das Passwort preiszugeben?

 

Diese 'triezende' Frage sollte doch bloss eine Hilfestellung bei der API-Definition sein!

 

• Falls es keinen Grund dafür gibt, soll das API dies auch nicht tun. (Hier ist es ein Konjunktiv)
  
• Falls es im Gegenzug aber einen Grund gibt, das Passwort nicht preiszugeben... dann darf das API dies auch nicht tun. (Hier wird es zum Imperativ)
  

 

 

[borg]

Welchen Grund dafür gibt es, das Passwort preiszugeben?

Der Grund ist damit ich das Passwort wieder auslesen kann wenn ich es brauche. Aus dem gleichen Grund aus dem ich es auch aus der FritzBox wieder rausbekomme.

 

Wie häufig haben wir folgende Situation¹: Es ist jemand in deinem WLAN (vielleicht über Ethernet), er soll vollen Zugriff auf die Bricks/Bricklets bekommen, er soll aber nicht das Passwort auslesen können.

 

Das ist ein bisschen als hättest du jemanden in deinem Netz der deine FritzBox konfigurieren können soll, aber nicht das Passwort auslesen.

 

¹: Dein Szenario 1 ist so nicht möglich da die WIFI Extension 2.0 kein EAP unterstützt.

[Equinox]

...Wann darf ich das Passwort setzen? Wenn ich das Passwort nicht auslesen darf...

 

Die Antwort auf das 'gekürzte' Zitat von Borg in Bezug auf meinen Security-Request ist:

Setzen 'immer', auslesen 'nie'.

 

 

Das mag für dein Szenario ausreichend sein, da es hier aber um Security geht, ist das natürlich der Security-GAU, zumindest wenn das funktioniert, ohne das aktuelle Passwort zu kennen.

[Quantasy]

Freut mich, dass sich auch andere darüber Gedanken machen!

 

1. Zu EAP: Stimmt, Die WLAN-Extension kann das tatsächlich nicht! Nun verstehe ich auch, warum die Studenten sich immer einen eigenen Access-Point aufspannen, den sie ins Netz bridgen. (Darf man laut der internen IT nicht... macht man aber :-|  )

 

 

Zurück zum Problem:

 

Das ist ein bisschen als hättest du jemanden in deinem Netz der deine FritzBox konfigurieren können soll, aber nicht das Passwort auslesen.

 

Für mich ist dieser Vergleich ganz klar nicht zulässig! Denn aus meiner Sicht ist das Nutzen eines Gerätes nicht das selbe wie das Konfigurieren eines Gerätes.

 

So darf eine 0815-App auf meinem Smartphone die Fritz-Box (die muss nochmals zum Vergleich herhalten) zwar nutzen, aber sie darf sie nicht konfigurieren.. (und schon gar nicht das Passwort kennen.)

 

Das zielt genau auf den berechtigten Aufschrei von Equinox:

Es darf doch nicht sein, dass jemand das Passwort einfach so neu setzen darf, ohne dass er dazu berechtigt ist.

Das sehe ich zwar genau so, aber das ist (noch) nicht Teil des Security-Features, welches ich in diesem Thread anstrebe. Es geht hier erst mal 'nur' um die Geheimhaltung eines Geheimnisses.

 

Ach ja, und da bin ich an der Uni doch tatsächlich fündig geworden:

In einem fremden Netz (per WPA gesichert), welches der hiesigen Abteilung für Medizininformatik gehört, habe ich eine Tinkerforge-Lösung gefunden, welche via Port-Weiterleitung in das Informatiker Netz zeigt. (Ob das so legitim sei oder nicht... sei nun mal dahingestellt; ich bin fast froh, diesen echten Case gefunden zu haben.)

 

Da hab ich also glatt mal aus dem Informatiker-Netz heraus den brickv auf die Weiterleitung zeigen lassen... und nun bin ich Mitwisser eines Geheimnisses geworden, welches nie für mich bestimmt war. Das ist schlecht.

 

Hier also der practical Proof, dass es mindestens einen Fall gibt, bei dem dank Tinkerforge ein Passwort über die Netzgrenzen hinweg auslesbar ist.

 

Ich frage mich gerade, ob es Leute gibt, welche ihre Tinkerforge-Anlage per NAT/Portforwarding dem Internet zur Verfügung stellen... (So z.B. eine Wetterstation o.ä. ;-) )

 

...Es ist jemand in deinem WLAN (vielleicht über Ethernet), er soll vollen Zugriff auf die Bricks/Bricklets bekommen, er soll aber nicht das Passwort auslesen können.

Siehe oben... es ist sogar noch schlimmer.

 

 

Die Beantwortung der Frage nach dem 'warum ist das Passwort einsehbar' durch Borg ergibt 'spitz gesagt', dass die WLAN-Extension einen Merkzettel für (alle) vergesslichen und unwissenden darstellt. Ist das die (?heroische?) Aufgabe der WLAN-Extension... Gibt's dafür nicht 'Merkzettel'?

 

Die insecurity-News in Sachen IoT sprudeln ja momentan nur so! Meistens geht es dabei um das hinausposaunen des WLAN-Passwortes. Ich sehe hier, dass Tinkerforge genau auf Linie fährt; also beim heiteren Rausgeben gut dabei ist.

 

Wie soll also eurer Meinung nach der User eines Smartphones das Problem angehen, dass nun jede App das WLAN-Passwort frei Haus bekommt, sofern sich im Netz eine Tinkerforge-WLAN-Extension tummelt?

 

Denn eigentlich erhält keine App das Passwort, weder durch die Public API von Android noch von iOS. Sie muss das normalerweise über den Benutzer (Social) oder 'dirty-hacks' machen (Rooten). Mit Hilfe von Tinkerforge wird das ganze aber ein legitimer Prozess, der von Tinkerforge ja sogar unterstützt wird und so die Sicherheitsvorkehrungen der anderen Hersteller komplett unterwandert.

 

 

 

Lasst doch einfach die Klaranzeige des Passworts weg, dann hat dieser insecurity Thread und Threat ein gutes Ende.

Für Vergessliche gibts einen Zettel, auf den diese das Passwort schreiben (und von mir aus hinten auf die WLAN-Extension kleben).

[borg]

Wie soll also eurer Meinung nach der User eines Smartphones das Problem angehen, dass nun jede App das WLAN-Passwort frei Haus bekommt, sofern sich im Netz eine Tinkerforge-WLAN-Extension tummelt?

 

Authentifizierung aktivieren. Dafür ist die da. Im Zweifeilsfall wäre ein Zugriff auf das Relay welches das Aquarium steuert auch viel schlimmer als der Zugriff auf das WLAN-Passwort.

 

Wenn ich das Authentifizierungspasswort der FritzBox kenne kann eine App auf dem Smartphone auch das WLAN-Passwort der FritzBox auslesen.

[Quantasy]

Ich sehe, dass Du (Borg) nicht zwischen Konfigurieren und Nutzen unterscheidest. Ist das richtig?

 

Es ist für mich verblüffend zu lesen wie sehr unsere Positionen sogar bei Metaphern divergieren!

 

Wenn 'ich' das Authentifizierungspasswort (für die Konfiguration der FritzBox) kenne, heisst das überhaupt nicht, dass die 0815-App dies kennt!?

 

Wenn 'ich' das WLAN-Passwort (für die Nutzung der FritzBox) kenne, heisst das überhaupt nicht, dass die 0815-App dies kennt!?

 

Woher soll sie es denn nehmen? Von der FritzBox kriegt die App diese Angaben auf keinen Fall.

 

Aber egal, wie ich das hier zu beschreiben versuche, es scheint als hätten wir hier nicht die gleiche Sprache?

 

 

Ich habe mir das mit der authentisierung enablen per Default auch noch einmal angeschaut und muss genau noch einmal darauf hinweisen, dass wir da ganz klar andere Meinungen haben:

 

Wenn die spezialisierte (aber dennoch böse) Tinkerforge-App gezwungenermassen das Authentisierungspasswort erhält, dann kann sie als Beiprodukt auch noch gleich das WLAN-Passwort des Netzes weitergeben.

 

Das könnte sie nicht, wenn sie es gar nicht lesen könnte.

 

Ist das denn so missverständlich?

Für mich ist der Angriff so sonnenklar, so deutlich vor Augen...

 

Wo ist mein Fehler, dass meine Beschreibung das Ziel nicht erreicht?

 

[borg]

Wo ist mein Fehler, dass meine Beschreibung das Ziel nicht erreicht?

 

Keine Angst, ich verstehe dich vollkommen. Nur leider du mich nicht :-).

 

Du hast mich noch nicht davon überzeugt das ich ein WLAN-Passwort anders absichern muss als ein Zugriff auf ein Relay.

 

 

Nochmal zur FritzBox: Ich kann von meinem Handy aus die Webseite der FritzBox aufrufen, dort das Authentifizierungspasswort eingeben und dann das WLAN-Passwort auslesen.

 

Jetzt sagst du: Eine Smartphone App kann Port 4223 öffnen und das WLAN-Passwort einer WIFI Extension auslesen. Dazu sage ich: Dafür gibt es die Authentifizierung.

 

Damit haben wir die gleiche Situation wie bei der FritzBox. Denn wenn ich das Authentifizierungspasswort kenne kann ich eine App schreiben die Port 80 öffnet um die Webseite der FritzBox zu öffnen, sich dort authentifiziert und danach das WLAN-Passwort ausliest.

 

Wenn ich das Authentifizierungspasswort der Extension/FritzBox nicht kenne, kann ich in beiden Fällen das WLAN-Passwort nicht auslesen.

 

 

Was bleibt ist der Use Case wo ich jemanden Zugriff auf Bricks/Bricklets in einem WLAN-Netz mit einer WIFI Extension geben möchte, aber nicht das WLAN-Passwort.

[Loetkolben]

Will nur 2 Dinge anmerken:

 

1. Ein zusaetzlicher AP (ggf. mit Multi SSID) fuer die IoT Test in einem Netzwerk kostet 15.-- Euro

 

2. Auch hat die aktuelle c´t das Thema aufgegriffen.

 

 

BTW: Ich kann mir auch vorstellen, dass Tinkerforge das WLAN Passwort (als Option) verschluesselt im EEPROM ablegt und nicht im Interface anzeigt. Ist Geschmackssache ob man es sehen moechte. [burn deep to EEPROM]

 

 

Bei der FritzBox hat es mir schonmal geholfen das ich es sehen konnte, aber "begeistert" ist man von so etwas nicht. 

 

 

Der Loetkolben

 

 

[Quantasy]

Hey Borg, ich sehe es aber genau so, wie Du das beschreibst!

 

Da ergreife ich doch das letzte Szenario also Strohhalm, den wir als Brücke unserer beiden Anschauungen weiter nutzen können...

 

Was bleibt ist der Use Case wo ich jemanden Zugriff auf Bricks/Bricklets in einem WLAN-Netz mit einer WIFI Extension geben möchte, aber nicht das WLAN-Passwort.

 

Also formuliere ich meinen Security Request erneut:

Ich ersuche Tinkerforge genau das zu tun:

Erlaubt den Zugriff auf die WIFI Extension, ohne dass man dabei zwangsläufig Geheimnisträger wird. (im Security-Model Honest but Curious)

 

Dies erhöht die Sicherheit des (Heim-)netzes ohne die Funktionalität der WIFI Extension oder irgend einer Funktionalität von Tinkerforge negativ zu beeinflussen. Dass die WIFI Extension als Merkzettel dienen muss... das will ich nicht gelten lassen...

 

Hey, wenn Du das Passwort vergessen solltest... schau beim Access-Point nach (e.g. FritzBox). Denn genau dies ist eine der Kernfunktionen die ein Access-Point anbieten muss: Das Passwort berechtigten Benutzern vorzuzeigen...

 

Somit gilt natürlich auch: Wenn die WIFI2 im AccessPoint Mode läuft... ja dann ist überhaupt nichts einzuwenden, wenn dann dieses AccessPoint-Passwort ausgegeben werden kann! Toll wäre dann ein Rollenkonzept, welches die Konfiguration und die Nutzung unterscheidet... Aber das ist ein anderer Security-Request.

 

 

Besser?

 

Zu Loetkolbens Anmerkungen:

Dass mit der beschriebenen Option, wäre für mich natürlich auch ein riesen Schritt vorwärts! Wenn das dann noch die 'Default-Option' wäre, dann wäre das spitzenmässig.

 

Zur ersten Anmerkung: Die kann ich so nicht ganz einordnen? Was wäre genau das Szenario mit der Multi-SSID?

[Quantasy]

Das wars?

Ruhe bis zum Sturm?

 

Dann würde ich diesen also nun entfachen sollen?

Die App und das Paper zum Auslesen der WLAN-Passwörter also schreiben?

 

Das wäre dann soz. ein Tinkerforge-Projekt, bei dem jeder herzlich eingeladen ist zu partizipieren und wenn gewollt als Mitautor des Papers mitzuwirken.

 

Provozierender Working title ist dann:

"When IoT gets Too Chatty"

A practical example using a explicite design flaw in Tinkerforge's security concept for WLAN-Passwords.

 

Ich würde euch dann bitten... Section 3 und die Conclusion mit zu verfassen, dann können wir die gegensätzlichen Standpunkte dort vertreten.

 

Wer wäre dabei?

 

 

 

[Equinox]

Hallo,

 

bevor du hier einen Sturm entfachst, möchte ich zumindest sichergehen, dass ich das Problem richtig verstanden habe:

Was bleibt ist der Use Case wo ich jemanden Zugriff auf Bricks/Bricklets in einem WLAN-Netz mit einer WIFI Extension geben möchte, aber nicht das WLAN-Passwort.

 

Wenn ich das richtig verstanden habe, dann ist das "nur" ein Problem, wenn sich die Wifi-Extension in einem anderen Netz befindet als das Gerät, das Zugriff darauf möchte. Wenn sie im gleichen Netz wären, dann muss das Gerät ja eh zwangsläufig das WLAN-Passwort kennen.

Also das "Problem-Szenario" ist:

Wifi-Extension ist in WLAN1. WLAN1 ist mit einem anderen Netzwerk (LAN2) verbunden. Es ist möglich aus LAN2 auf WLAN1 zuzugreifen. Richtig?

[Quantasy]

Hallo Equinox

Dein Beispiel ist ein Spezialfall (der es auch in sich hat).

Hier aber das Grundsatzproblem:

 

Meine Arbeitshypothese:

Eine App (sagen wir mal eine WetterApp), welche ich vom AppStore auf mein Smartphone runterlade und in meinem WLAN-Heimnetz betreibe... kennt das WLAN-Passwort nicht.

Sind wir uns da einig?

 

Weiter nehme ich folgendes an:

Diese App kann zwar im WLAN-Heimnetz Meldungen austauschen oder gar über den AccessPoint und

das Gateway ins Internet gehen, lernt aber kein einziges Passwort... weder das vom AccessPoint noch vom Gateway...

Siehst Du das auch so?

 

Meine Erkenntnis:

Wenn nun im Netz aber eine Tinkerforge WLAN-Extension ihren Dienst tut...

Dann kann die WetterApp (der NSA-Teil davon :-)  ) sich das WLAN-Passwort ganz leicht holen.

Genau das kann man ganz einfach per API-Call (oder per Default gar per Browser (connect auf die WLAN-Extension)) nachvollziehen.

 

Diese Erkenntnis bezeichne ich als Schwäche denn ich kann einen Angriff darauf beschreiben.

 

Ist das nachvollziehbar?

 

Der ganze obere Teil dieses Threads kann ich prima nutzen, um im Paper eine Discussion Section zu erarbeiten (sofern die Autoren einverstanden sind).

 

Als erste Lösung würden natürlich die 'low-hanging fruits' wegnehmen und den Default-Web-Access abstellen. Dann würde die Authentisierung (mit SHA1, aber das ist ein anderes Problem) per Default eingeschalten.

 

Ja?

 

Doch insbesondere der zweite Schritt würde wohl vielen Tinkerern zu viel der 'Security vs. Usabilty' sein, denn jetzt muss sich jede gute Tinkerforge Applikation, welche auf die Stacks verbinden möchte... sich ein Passwort merken… Und dann passiert, was allen dann passiert, das Passwort landet bei GitHub, denn es ist hart in der Applikation des Tinkerers drin ;-)  Und das ist schlussendlich wohl ein No-Go.

 

Ja?

 

Solution

Und da käme dann meine super geniale noch von niemand anderem (ausser von Mac, Microsoft, Linux, Android und all den anderen) ausgedachten Lösung ins Spiel, bei dem ein Passwort fürs WLAN gesetzt... aber nicht mehr ausgelesen werden kann.

 

Später wäre es dann vielleicht sinnvoll, dass das WLAN-Passwort auch nicht mehr 'einfach so' überschrieben werden kann... aber das ist ein anderes Paper, bei dem es nicht um die Privacy geht.

 

Conclusion

 

Dann müssten all diese 'Not-Patches' überhaupt nicht gemacht werden.

 

Und jeder könnte seine WetterApp mit "NSA-Extension" in seinem Heimnetz betreiben, ohne Angst haben zu müssen, dass Tags darauf die ganze Welt sein WLAN-Passwort kennt.

 

 

So in etwa würde Projekt "Privacy for Tinkerforge" gestaltet.

 

 

 

 

[Equinox]

Hallo Quantasy,

 

Meine Erkenntnis:

Wenn nun im Netz aber eine Tinkerforge WLAN-Extension ihren Dienst tut...

Dann kann die WetterApp (der NSA-Teil davon :-)  ) sich das WLAN-Passwort ganz leicht holen.

Genau das kann man ganz einfach per API-Call (oder per Default gar per Browser (connect auf die WLAN-Extension)) nachvollziehen.

 

Diese Erkenntnis bezeichne ich als Schwäche denn ich kann einen Angriff darauf beschreiben.

 

Ist das nachvollziehbar?

 

Hmmm, nicht ganz. Vielleicht stehe ich ja irgendwie auf dem Schlauch, aber genau dafür gibt es doch die Authentifizierung.

 

Zitat:

Für den Fall, dass Brick und Bricklets vor dem Zugriff nicht-vertrauenswürdiger Teilnehmer geschützt werden sollen, kann Authentifizierung verwendet werden. Wenn Authentifizierung aktiviert ist können Brick und Bricklets nur noch von Teilnehmer kontrolliert werden, die das Authentifizierungsgeheimnis kennen.

 

Wenn deine WetterApp also das Authentifizierungsgeheimnis nicht kennt, kann sie auch kein WLAN-Passwort auslesen.

Das entspricht doch genau deinem Beispiel mit dem AccessPoint: Wenn du das Passwort (=Authentifizierungsgeheimnis) nicht kennst, dann kannst du auch die Konfiguration nicht auslesen/ändern.

Was übersehe ich?

[Quantasy]

Habe ich beschrieben... lies weiter!

Dann würde die Authentisierung (mit SHA1, aber das ist ein anderes Problem) per Default eingeschalten.

 

Ja?

 

Doch insbesondere der zweite Schritt würde wohl vielen Tinkerern zu viel der 'Security vs. Usabilty' sein, denn jetzt muss sich jede gute Tinkerforge Applikation, welche auf die Stacks verbinden möchte... sich ein Passwort merken… Und dann passiert, was allen dann passiert, das Passwort landet bei GitHub, denn es ist hart in der Applikation des Tinkerers drin ;-)  Und das ist schlussendlich wohl ein No-Go.

 

Es ist nicht Aufgabe einer Komponente im Netz (ausser dem Access-Point selber), das WLAN-Passwort zu verraten. Nie. Warum mutet sich Tinkerforge zu, diese Aufgabe übernehmen zu müssen?

 

Die Authentisierung ist genau dafür gedacht, dass die WetterApp mit StuxNet Erweiterung nicht an den Parametern der Bricks und Bricklets rumspielt...

Und selbst wenn ich einer App erlauben möchte, an den Bricks und Bricklets rumzuhantieren... will ich immer noch nicht, dass diese App mein WLAN-Passwort kennt.

 

Das WLAN-Passwort hat rein gar nichts mit Tinkerforge zu tun. Also warum dieser schreckliche Verrat?

ob mit oder ohne Authentisierung

 

Dann wärest Du also auch dabei als Autor der 'anderen Seite' die Meinung zu vertreten, dass Tinkerforge das Passwort preisgeben soll? Ich sehe... meine Seite ist (noch) ziemlich einsam hier ;-)

 

Kein Problem, nehme das nicht persönlich... sondern sportlich :-)

 

 

 

 

 

 

[Equinox]

Hallo Quantasy,

 

Dann wärest Du also auch dabei als Autor der 'anderen Seite' die Meinung zu vertreten, dass Tinkerforge das Passwort preisgeben soll? Ich sehe... meine Seite ist (noch) ziemlich einsam hier ;-)

 

Im Moment würde ich sagen, dass ich mich noch nicht für eine Seite entschieden habe. Grundsätzlich stimme ich dir zu. Ich sehe auch keine Notwendigkeit, dass ein Gerät (wie die Wifi-Extension) das WLAN-Passwort preisgeben muss. Es ist vmtl. nur aus Bequemlichkeit/Einfachheit/Usability.

Auf der anderen Seite sehe ich aber jetzt auch kein soooo großes Risiko, da es ja Mechanismen gibt, die das Risiko beseitigen. Man muss sie eben anwenden.

Es ist also letztlich die Frage, ob der Gewinn an Sicherheit (und weiterer Einsatzmöglichkeiten) den Verlust an Bequemlichkeit/Einfachheit/Usability aufwiegt. Ich persönlich habe die Möglichkeit, das WLAN-Passwort über die Wifi-Extension auszulesen noch nie gebraucht (und mir fällt auch jetzt kein Grund ein, warum dies unbedingt notwendig ist), aber da mag es andere Ansichten geben.

[Quantasy]

Hey Equinox

...da es ja Mechanismen gibt, die das Risiko beseitigen. Man muss sie eben anwenden.

 

Genau dafür stehe ich auch ein! Deshalb habe ich den Thread gestartet... damit der 'Mechanismus' zum Einsatz kommt... und der/die Threat ein Ende hat.

"Hast Du gelesen... Tinkerforge: Bring uns 'den Mechanismus'."

 

(Oder drehe ich Dir da die Worte im Munde herum und nutze diese bloss für meine niederen Zwecke? ;-)  )

 

 

 

[Equinox]

Hallo Quantasy,

 

Tinkerforge hat den "Mechanismus" schon gebracht. Wie schon erwähnt: Authentifizierung. Es liegt in der Verantwortung jedes Tinkerforge-Anwenders, diese zu benutzen.

[Loetkolben]

Ich verstehe das Problem aber ich verstehe nicht warum es so kompliziert ist das zu loesen.

 

WORN!

 

Einfach der READapi immer den Wert "Aetsch" ausgeben lassen. Ich kenne eben auch keinen sinnvollen Grund warum ueberhaupt ein Device das WLAN Passwort rausruecken sollte. (Ausser zur eigenen berechtigten Verarbeitung).

 

Der Loetkolben.

[borg]

In den neuesten Releases vom Master Brick, WIFI Extension 2.0 und Brick Viewer werden jetzt nur noch leere Strings von den Password-Gettern zurückgegeben und die GUIs wurden entsprechend angepasst .

[Loetkolben]

Zum Abschluss dieses Punkte noch was aus der Rubrik: Die Menschheit wird immer irrer, oder warum darf ich nicht bei dir einfach wohnen?

 

---

heise.de: Windows 10 verteilt WLAN-Schlüssel an Freunde

 

Auf Wunsch teilt jetzt auch Windows 10 das eigene WLAN-Passwort mit Freunden aus Facebook und Kontakten von Skype und Outlook.

...

Microsoft zufolge wird das Passwort immer verschlüsselt übertragen und liegt auch verschlüsselt auf einem Microsoft-Server.

---

 

Gut´s naechtle.

 

 

Der Loetkolben

[Quantasy]

Ich bin begeistert!

(Nicht über das schön umschriebene Artefakt, das Loetkolben gefunden hat... da zuckt mir das Auge wie bei Scratty)

 

Die neuen Versionen von brickv, Masterbrick und WiFi2-Extension sind super! Genau so sollte es sein! (Haben auch kurz mit Wireshark das Netz beobachtet... Kein Verrat mehr vom Brick zum BrickV... Umgekehrt... das haben wir nicht so genau angeschaut ;-)  )

 

Nun kann ich fleissig und freudig am privacy-Paper weiterschreiben, bei dem ab nun zu lesen sein wird, dass TF das Problem angegangen sei und es vorbildlich gelöst habe...