Beskidy - OwcaIch habe gerade einen sehr interessanten Artikel auf Ars Technica (in englisch) gelesen, über eine einfache und recht offensichtliche Methode um freie WLAN Hotspots gegen das böse Feuershaf abzusichern.

Der Grundgedanke ist, bisher offene und unverschlüsselte WLANs mit Hilfe von WPA abzusichern und das verwendete Passwort aber frei zur Verfügung zu stellen. Dadurch würde man eine etablierte Schicht Sicherheit erhalten.

Ich kann mir das gut vorstellen, dass zum Beispiel in Werbespots von Fast-Food-Ketten im Nachsatz läuft: “Benutzen Sie unser kostenloses Hochgeschwindigkeits-Internet-Funknetz mit dem Passwort Gast in jedem Teilnehmenden Restaurant.” Ähnlich wie bei der Verwendung von anonymen FTPs oder Network-Share Zugängen könnte sich dabei eine Reihe von Passwörter etablieren: Gast, frei, offen, usw…

Die einfachste Möglichkeit, das Passwort zu verbreiten, währe zum Beispiel direkt über die SSID den Namen des Funknetzes. Dabei könnten sich ebenfalls Gepflogenheiten etablieren. Zum Beispiel, dass man das Passwort in [eckigen Klammern] anhängt. Hot Spot [pw: kostenlos] oder Fast [Food].

Für Anbieter und Benutzer währe das, denke ich, eine machbare un verschmerzliche Lösung für ein Problem, dass man eigentlich nicht haben müsste, bei konsequent durchgezogener SSL-Verschlüsselung. Auch Otto-Normal-Verbraucher könnte sich an diese Verwendung gewöhnen. Für jeden Interessierten gibt es nach wie vor die Möglichkeit, sich am Hotspot seines (nicht-)vertrauens durch SSH-Tunnel, VPN und ähnliches natürlich weiter abzusichern. 😉

Allesblog#Cookies#firesheep#Schaf#security#sicherheit#technisches#WLAN

Michael: User Management

Gerade mein gesteigertes Interesse an den Datenschutzdiskussionen in Deutschland führt bei mir zu einem bewussteren Umgang mit Benutzer/Passwort Kombinationen. Seit neuestem lege ich mir Accounts an, dessen Passworte aus 21+ Zeichen bestehen, die ich mir gar nicht merken kann. Getreu dem Motto: “Wass ich nicht weiß, kann ich nicht vergessen”. In einigen Fällen benötige ich das Passwort nicht, weil ich auf die Accounts über andere Profile zugreifen kann. In anderen Fällen benutze ich lieber Public Key Files oder richte Systemzugänge einmalig ein, speichere das Passwort in einer Keychain und diese ist dann mit einem Masterpasswort gesichert. Beispiele?

WordPress bietet die Möglichkeit über XML-RPC Posts in Blogs einzutragen. Flickr kann auf genau diese Schnittstelle zugreifen. Jetzt könnte ich natürlich in Flickr meinen Standard-Wordpress-Benutzer angeben. Aber wer weiß wie sicher die Daten bei Flickr sind? (völlig Wertungsfreie Aussage gegenüber Flickr!) Stattdessen habe ich einen Zugang im WordPress angelegt, der speziell für die Flickr-2-Blog-Funktion zugeschnitten ist. Das Passwort hat 64 Zeichen, nicht nur Buchstaben und Zahlen, sondern alles was es so in UTF-8 gibt. Das Passwort interessiert mich auch nicht wirklich, da sich Flickr selbiges merken kann und ich es sowieso nur einmal abtippen muss. Sollte also bei Flickr jetzt eine Datenpanne passieren, dann ändere ich einfach das Passwort für den Flickr-Account im Blog und schon ists mir (relativ) egal.

Nach dem gleichen Prinzip habe ich bei @allesblog verfahren, nur dass ich hier nicht ganz so wahllos das Passwort erstellen konnte, denn Twitter lässt leider bestimmte Zeichen wie das Leerzeichen nicht zu. Dann gibt es einen weiteren Account für das mobile Bloggen vom iPhone. (Sollte mal mein Telefon in die falschen Hände geraten habe ich sichere größere Probleme als dieser Blog…)

Beim Schreiben dieser Zeilen ist mir aufgefallen, wie einfach es ist, das Risiko hier und da etwas zu minimieren. Man muss sich nur die Arbeit machen, die Dinge etwas mehr im Zusammenhang zu sehen, statt sie zum Beispiel auf die Kategorisierung von Beiträgen zu verschwenden.

Sollte ich doch irgendwann mal in die Lage kommen, ein Passwort eingeben zu müssen, dann kann es in der Regel ganz einfach wiederhergestellt oder neu erstellt werden.

Allesblog#account#benutzer#passwort#sicherheit