Artikel mit Tag sicherheit

Bob schickt Alice eine Nachricht - wie sicher ist das denn?

red mailbox on blue wall

Zur Einordnung: Dieser Artikel soll keine fachlich bis ins kleinste fundierte Betrachtung von Verschlüsselungs- und Sicherheitesmechanismen sein. Dazu fehlt mir sicherlich auch die Expertise. Vielmehr möchte ich auf etwas vereinfachte Weise anschaulich darstellen, was man bei der Nutzung von Messengern für die Sicherheit tun kann und beachten muss.

Bob schickt Alice über $Messenger eine private Nachricht mit einem netten privaten Bild. Natürlich möchte Bob, dass die Nachricht sicher bei Alice ankommt und - da sie ja privat ist - auch nur von Alice gelesen werden kann. Mal schauen, was die beiden dabei so alles beachten müssen.

(Als Vorraussetzung nehmen wir mal an, dass Bob und Alice einen Messenger benutzen, bei dem ein Provider mit einer Server-Infrastruktur beteiligt ist. Dieses Konzept verfolgen die meisten Messenger, um die Problematik zu lösen, dass nich immer alle Beteiligten einer Konversation ständig online sind. Es gibt auch Messenger, die eine direkt Peer-to-Peer-Verbindung herstellen, aber diese Konstallation muss nochmal anders betrachtet werden.)

Abhörsicher

Zunächst einmal wollen Bob und Alice natürlich sicher gehen, dass ihre Nachricht dem Transportweg von Bobs auf Alice' Endgerät nicht von von unbeteiligten mitgelesen werden kann, die zufällig den Datenstrom von Bob zum Provider oder vom Provider zu Alice mitbekommen. Hierzu eignet sich ersteinmal eine Transportverschlüsselung über SSL. Dieses bewährte Verfahren sichert den Datenverkehr zwischen zwei Geräten (z.B. Smartphone und Server des Providers) mittels Zertifikaten ab, die - sofern sie richtig implementiert wurden - sicherstellen, dass der Datenverkehr vom und zum Provider verschlüsselt ist und sich niemand dazwischen schalten kann.

Das Problem bei diesem Verfahren ist, dass die Verschlüsselung nur bis zum jeweiligen Endpunkt der Server-Software beim Provider genutzt wird. Sobald Bobs Nachricht dort ankommt, wird sie entschlüsselt und vom Provider im Klartext gepeichert, bevor sie - dann wieder verschlüsselt - an Alice weitergereicht wird. Der Provider und jeder, der irgendwie Zugriff auf den Server erlangt, könnte also mühelos alle Nachrichten der Nutzer lesen. Dieses Verfahren reicht daher auf jeden Fall nicht aus, um Bobs Nachricht an Alice zuverlässig abzusichern.

(Heutzutage dürfte es keinen Messenger-Dienst mehr geben, der ausschließlich eine solche Transportverschlüsselung ohne zusätzliche Verschlüsselungsmechanismen nutzt.)

Hinter verschlossenen Türen

Um zu verhindern, das Bobs Nachricht auf dem Weg zu Alice entschlüsselt und eventuell sogar im Klartext gespeichert wird, sollte der Provider von $Messenger also zumindest eine serverbasierte Verschlüsselung einsetzen, um die Daten seiner Nutzer zu schützen.

(Wie funktioniert so eine Verschlüsselung eigentlich?
Grob gesagt nutzt man immer ein Schlüsselpaar, jeder Teilnehmer einer Konversation besitzt einen privaten Schlüssel, den nur er kennt, und einen öffentlichen Schlüssel, den er weiter geben kann.
Teilnehmer A kann etwas mit dem öffentlichen Schlüssel von Teilnehmer B verschlüsseln. Diesen verschlüsselten Inhalt kann danach nur noch Teilnehmer B mit seinem privaten Schlüssel wieder lesbar machen. Genauso funktioniert das in der anderen Richtung. Teilnehmer B verschlüsselt etwas mit dem öffentlichen Schlüssel von Teilnehmer A, der mit seinem privaten Schlüssel wieder lesbar macht.
Eine zweite Funktion dieses Schlüsselpaares ist das Signieren von Inhalten. Teilnehmer A kann mit seinem privaten Schlüssel etwas signieren und jeder andere kann mit dem öffentlichen Schlüssel von Teilnehmer A diese Signatur überprüfen, also die Herkunft des Inhalts sicherstellen. Beides, verschlüsseln und signieren funktioniert einzeln und kann auch kombiniert werden.)

Bei der serverbasierten Verschlüsselung benutzt der Provider einen einzigen Schlüssel für alle Benutzer. Je nach Verfahren werden die Nachrichten noch mit einer Session-ID des Clients oder einer Nachrichten-ID verschlüsselt. Die so verschlüsselten Nachrichten werden dann bei Bedarf auf dem Server des Providers gespeichert und können dann auch sicher an den Client des Empfängers weitergeleitet werden. Das ist schonmal insoweit gut, dass jemand, der den Server des Providers unter Kontrolle bekommt, die dort gespeicherten Nachrichten nicht lesen kann, sofern der Provider seinen privaten Schlüssel entsprechend abgesichert hat. So weit so gut, Bob und Alice können also beruhigt sein, oder?

Das Problem bei dieser Art der Verschlüsselung ist aber, dass der Provider jederzeit Zugriff auf die Inhalte hat (und haben muss). Ein Fehler im Sicherheitssystem des Providers oder auch eine Anfrage einer Regierungsorganisation, mit der der Provider zusammen arbeitet, würde die Offenlegung der Inhalte von Bobs Nachricht an Alice zur Folge haben. Wie kann man das also noch besser machen?

Du siehst mich nicht

Das Zauberwort heisst: Ende-zu-Ende-Verschlüsselung.

Hierbei nutzt der Provider keinen einheitlichen Schlüssel, um die Inhalte der Nutzer abzusichern. Die Schlüssel der Benutzer werden direkt ausgetauscht und Bob verschlüsselt seine Nachricht direkt mit dem öffentlichen Schlüssel von Alice. Nur Alice hat also mit ihrem privaten Schlüssel Zugriff auf diese Nachricht. Auch der Provider hat keine Möglichkeit, die Inhalte von Bobs Nachricht an Alice zu entschlüsseln, er kann auch nicht von dritter Seite dazu gezwungen werden. Bob und Alice können also sicher sein, dass ihre Inhalte sicher und nur für die beiden lesbar transportiert werden? Ja, allerdings gibt es dabei einige Voraussetzungen, die die beiden beachten und umsetzen müssen.

Wer bin ich und wie viele?

Erstes Problem: Wie erhält Bob den öffentlichen Schlüssel von Alice, um anschließend die Nachricht an sie damit zu verschlüsseln. Das sicherste wäre hier, die beiden würden sich treffen und Alive übergibt ihren öffentlichen Schlüssel direkt an Bob, der ihn dann auf seinem Client speichern kann. Es wäre aber ziemlich mühsam, wenn jeder Nutzer von $Messenger das mit jedem seiner Chat-Partner so machen müsste. Also sendet $Messenger den öffentlichen Schlüssel von Alice automatisch an Bob. Bob hat dann verschiedene Möglichkeiten, um die Echtheit des Schlüssels zu prüfen. So kann Bob zum Beispiel Alice anrufen und dann mit ihr gemeinsam am Telefon den Hash-Wert der Schlüsselsignatur zu vergleichen, den beide in ihrem Client aufrufen können. Sollten sich die beiden doch einmal persönlich treffen, könnten Bob mit seinem Smartphone auch einen QR-Code scannen, den Alice auf ihrem Device anzeigen lässt. Nach diesem Vergleich ist Bob also sicher, dass der öffentliche Schlüssel, den er bekommen hat, auch wirklich von Alice stammt.

Das Schlüsselpaar von Alice wird automatisch per Zufallsgenerator erzeugt, wenn sei $Messenger auf ihrem Smartphone installiert. Wenn sie $Messenger neu installieren muss oder ein neues Gerät erhält, wird ein neues Schlüsselpaar erzeugt, dessen öffentlicher Teil auch wieder direkt an Bob gesendet wird. Das ist auch wichtig, denn Nachrichten, die Bob mit dem alten öffentlichen Schlüssel von Alice verschlüsseln würde, könnte Alice ab sofort nicht mehr lesen. Der Client von Bob macht ihn auf diesen Umstand auch aufmerksam, in dem er einen Text wie "Die Sicherheitsnummer von Alice hat sich geändert." anzeigt. Für Bob bedeutet das, dass er ab jetzt nicht mehr sicher sein kann, ob dieser neue öffentliche Schlüssel immer noch von Alice stammt. Erst, wenn die beiden über eine der oben beschriebenen Möglichkeiten die Herkunft des Schlüssels sicher gestellt haben, ist die Kommunikation wieder sicher.

(Ihr macht das bei allen Kontakten in eurem E2E-verschlüsselnden Messenger so, oder? ;-) )

Es gibt noch ein Problem bei der E2E-Verschlüsselung. Die Sicherheit funktioniert nur dann, wenn Bob und Alice sicher sein können, dass sie jeweils das Original ihrer privaten Schlüssel besitzen und es keine weiteren Kopien (z.B. beim Provider) gibt. Das die Erzeugung und Verteilung der Schlüssel automatisch durch den Client von $Messenger erfolgt, haben die beiden hier keine Möglichkeit, auf diesen Prozess Einfluß zu nehmen. Um hier eine Kontrollmöglichkeit zu haben, könnten Bob und Alice zum Beispiel einen $Messenger verwenden, dessen Programmcode offengelegt ist, also Open Source ist. Hier hätte man die Möglichkeit zu überprüfen, ob der Client ordentlich mit den erzeugten Schlüsselpaaren umgeht. Natürlich ist auch eine Bestätigung durch einen unabhängigen Prüfer möglich, hierbei ist es aber immer nötig, dass Bob und Alice diesem Prüfer auch vertrauen.

Zum schlechten Schluß

Nun haben Alice und Bob alle oben beschriebenen Aspekte berücksichtigt, nutzen Ende-zu-Ende-Verschlüsselung, haben die Echtheit und Vertraulichkeit ihrer Schlüsselpaare sichergestellt. Bob kann seine Nachricht mit dem privaten Foto also sicher an Alice schicken. Allerdings habe ich jetzt noch eine schlechte Nachricht für die beiden. Sobald Nachricht und Foto auf Alice' Device angekommen sind, werden sie wieder entschlüsselt, damit Alice sie lesen kann. Ab jetzt hat Bob leider keinerlei Kontrolle mehr darüber, was Alice (oder ihr Smartphone) mit den Inhalten macht. Wird das Foto auf eine (wie auch immer gesicherten) Cloud hochgeladen? Wer hat dort Zugriff darauf? Gibt Alice das Smartphone ab und zu an ihre Kinder, damit diese damit spielen? Landet die Nachricht auf dem Uralt-Laptop von Alice, der noch unter Windows XP läuft und von dem ein oder anderen Trojaner verseucht ist?

Es ist für unsere beiden wichtig und richtig, einen sicheren $Messenger zu nutzen und sicherzustellen, dass Inhalte vertraulich und sicher an den jeweils anderen Gesprächspartner weitergeleitet werden. Wir sollten uns aber auch bewusst sein, dass unser Kontent, wenn er erstmal beim (sicher richtigen) Empfäger angekommen ist, weiter gesichert und geschützt werden muss. Nur das hängt dann in keinster Weise mehr vom genutzten Messenger ab.

Sicherheitsupdate für Serendipity verfügbar

Kurzmeldung: Das Team um meine Lieblings-Blogengine Serendipity (S9y) hat ein Sicherheitsupdate herausgebracht. Die Version 2.0.5 bzw. 2.1-beta3 behebt zwei Sicherheitsprobleme. Mehr dazu im offiziellen Blogpost.

Also, husch husch, updaten. :-)

 

Sicherheitshinweis: Nutzer von KDE Neon sollten ihre Installation aktualisieren oder neu aufsetzen

Neon-Logo

KDE Neon ist eine Distribution, die es sich zum Ziel setzt, immer die aktuellste Version und Features der Desktopumgebung KDE auszuliefern. Als Basis wird jeweils das aktuelle Ubuntu LTS verwendet.

In einem Security Advisory wird jetzt darauf hingewiesen, dass das Paketarchiv der Distribution falsch konfiguriert war und deshalb jeder beliebig Pakete in das Archiv hochladen konnte. Daraufhin wurde das Archiv komplett gelöscht und neu aufgesetzt. Nutzer, die KDE-Neon vor dem 10.11.2016 16:00 UTC installiert haben, sollten zumindest ein Upgrade ihrer Installation durchführen, alle Pakete haben höhere Versionsnummern bekommen. Am sichersten dürfte jedoch eine Neuinstallation sein, da man nicht weiß, ob eventuell Schadsoftware oder anders manipulierte Pakete in das alte Archiv eingespielt wurden.

(Quelle: Softpedia)

Einbruch bei Linux Mint: ISOs vom 20.2.2016 teilweise kompromitiert

Linux Mint

Wie die Entwickler der beliebten Linuxdistribution Mint in ihrem Blog bekannt gaben, kam es zu einem Einbruch in deren Server, wobei die zum Download zur Verfügung gestellten ISOs der Cinnamon Edition kompromitiert wurden. Die Installations-Abbilder enthalten Schadsoftware, die eine Backdoor für Botnetze öffnen.

Laut Chefentwickler Clement Lefebvre sind nur Downloads betroffen, die am Samstag, den 20. Februar 2016 durchgeführt wurden. Besitzer solcher Dateien sollten die im Blogpost angegebenen Checksummen prüfen und, falls mit einem betroffenen Abbild installiert wurde, diese Installation umgehend löschen.

Außerdem wurde das Benutzerforum des Servers ausgelesen. Die Benutzerdaten inklusive verschlüsselten Passwörtern werden bereits zum Verkauf angeboten. Dies hat Zack Whittaker von ZDNET in einem verschlüsselten Chat vom mutmaßlich verantwortlichen Hacker mit dem Pseudonym "Peace" erfahren. Die Erkenntnisse aus dem Chat sind in seinem Artikel bei ZDNET nachzulesen.

Serendipity 2.0.3 Security Update

Ich wünsche allen Lesern noch alles Gute für das neue Jahr.

Nur ganz kurz für alle Nutzer des Blogsystems Serendipity (S9Y): Es gibt ein Sicherheitsupdate auf die Version 2.0.3.

Also bitte updaten. ;-)

Onlinebanking-Sicherungsverfahren: PushTAN Verfahren der Sparkasse ist angreifbar

Bereits als ich das PushTAN-Verfahren im Juli 2014 hier auf dem Blog vorstellte, hatte ich Zweifel, ob sich die Trennung der beiden Sicherheitsfaktoren auf einem Gerät sicher darstellen lässt.

Und nun hat Vincent Haupert auf einem Vortrag beim 32C3 in Hamburg demonstriert, wie er zunächst eine ältere Version der PushTAN-App und dann auch die aktuellste angreifen konnte und Zahlungen, die auf dem selben Androidhandy ausgeführt wurden, bei der Anzeige uns Ausführung manipulieren konnte. Dabei wird dem Nutzer die von ihm gewünschte Transaktion sowohl in der Banking-App als auch in der PushTAN-App angezeigt, im Hintergrund wird jedoch eine Überweisung mit einem anderen Betrag an einen anderen Empfänger gesendet.

Leider ist zu befürchten, dass auch die TAN-Apps anderer Bankengruppen einem gleichartigen Angriff ebenfalls nicht standhalten würden. Ein echtes Zwei-Faktor-Verfahren scheint nur auf getrennten Geräten möglich zu sein. Die Nutzung der App für eine Überweisung, die man zum Beispiel auf seinem PC ausführt und dann die TAN über die App auf dem Smartphone anzeigen lässt, ist wiederum ähnlich sicher wie das MobileTAN bzw. SMS-TAN-Verfahren. Hier müssen immerhin zwei Geräte gekapert werden, um einen Angriff möglich zu machen.

Und hier ist das Video von Vincent Hauperts Vortrag, das sehr interessant und kurzweilig ist. ;-)

Ist ein Paketfilter auf einem Rootserver sinnvoll?

Wer einen Rootserver - egal ob es eine physische oder virtuelle Maschine ist - im Internet betreibt, muss sich Gedanken um dessen Absicherung machen. Früher oder später kommt man dann auch an den Punkt, wo man entscheiden muss, ob man einen Paketfilter wie Iptables auf seinem Server konfigurieren soll. Hier gibt es unterschiedliche Meinungen im Netz, ob das sinnvoll ist oder nicht. Schauen wir die Argumente doch mal an.

Gründe, warum man keinen Paketfilter auf dem Rootserver benötigt

Auf einem Rootserver gibt es normalerweise nur ein Netzwerkinterface, dass nach außen auf das Internet routet. Daneben haben wir immer noch das lokale Interface, dass nur intern auf dem Rechner erreichbar ist. Auf dem "klassischen" Rootserver sollen Dienste, die man installiert, in der Regel auch vom Internet erreichbar sein. Auf Ports, die nicht erreichbar sein sollen, sollte auch kein Dienst erreichbar sein. Ein Beispiel ist der Webserver, der natürlich vom Internet erreichbar sein soll. Das Datenbankbackend sollte aber nur vom Webserver auf dem internen Interface erreichbar sein. Wenn also alle Dienste auf dem Server korrekt installiert sind, macht ein Paketfilter keinen wirklichen Sinn. 

Ein Schutz gegen DDOS-Angriffe oder ein Lastverteilung muss immer auf den Routern vor dem Rootserver laufen, um zu funktionieren. Also ist auch dies kein Grund für eine Iptables auf dem Server selbst.

Szenarien, in denen ein Paketfilter Sinn macht

Zunächst einmal kann man den Paketfilter als "Sicherheitsnetz" betreiben. Wenn man mal einen Dienst, der eigentlich nur auf der internen Schnittstelle erreichbar sein soll, falsch konfiguriert, wäre er dann aufgrund den dann nicht freigeschalteten Ports eben nicht erreichbar und die Fehlkonfiguration hätte keine Auswirkungen auf die Sicherheit des Servers. Außerdem könnte ein installierter Dienst eine Sicherheitslücke haben, durch die ein Angreifer einen Dienst im Benutzerkontext etablieren könnte, der dann von außen erreichbar ist und entsprechend ausgenutzt werden könnte. Ein Paketfilter würde so etwas verhindern.

Dann gibt es noch einige spezielle Szenarien, die einen Paketfilter nötig machen. So wäre zum Beispiel ein Portknocking möglich, bei dem ein Dienst erst erreichbar ist, nachdem man auf einem anderen nicht bekannten Port "angeklopft" hat.

Fazit

Grundsätzlich macht ein Paketfilter auf einem Rootserver erstmal keinen Sinn. Zur Absicherung von Fehlkonfigurationen oder Folgen von Angriffen auf erreichbare Dienste kann Iptables aber durchaus Sinn machen und genutzt werden. Für einige spezielle Aufgabenstellungen wird der Paketfilter sogar explizit benötigt. Jeder Betreiber eines Rootservers sollte die Notwendigkeit also selbst beurteilen und eine entsprechende Konfiguration einsetzen.

Habt ihr einen Rootserver in Betrieb? Wie sieht es bei euch mit dem Betrieb eines Paketfilters aus. Gibt es Szenarien, die ich nicht angesprochen habe? Lasst es mich in den Kommentaren wissen.

Sicherheitsupdate für Serendipity verfügbar

Habt ihr es schon mitbekommen? Für die Blogsoftware Serendipity (s9y) ist heute ein Sicherheitsupdate erschienen. Mit der Version 2.0.2 werden drei Sicherheitslücken geschlossen.

Für Nutzer einer älteren Version vor 2.0 steht die bereinigte Version 1.7.9 zur Verfügung. Alle Nutzer sollten möglichst bald ihre Installationen aktualisieren.

Hier geht es zur offiziellen Ankündigung.

 

Warum ich schliesslich doch WhatsApp nutze

WhatsApp-Logo

Lange Zeit habe ich mich gesträubt und dagegen gewehrt, WhatsApp zu nutzen. Jetzt habe ich den Widerstand aufgegeben und auf meinem Smartphone WhatsApp installiert. Und hier sind die Gründe dafür:

Warum wollte ich WhatsApp nicht nutzen?

Als BlackBerry-Nutzer nutze ich schon immer den BlackBerry-Messenger, und versuche immer, andere zur Nutzung dieser App zu bewegen, zumal sie auch für alle gängigen Plattformen (BlackBerry, iPhone, Android, Windowsphone) zur Verfügung steht. WhatsApp ist schon immer verschriehen, nicht besonders sicher zu sein. Die Verschlüsselung und der Datenschutz sind fragwürdig und die ein oder andere Sicherheitslücke wurde bereits gefunden.

Jeder, der meine Handynummer hat, kann mich automatisch über WhatsApp anschreiben. Bei anderen Messengern - wie auch beim BBM - muss man sich erst über eine wie auch immer geartete ID verknüpfen. Ich kann mir also meine Chatpartner gewissermaßen aussuchen.

Und überhaupt hat der BBM viel bessere Funktionen bei den Gruppenchats und andere Vorzüge, die ich nicht missen möchte.

Das ganze hat nur einen Haken: Es gibt zu wenige, die BBM nutzen und fast alle nutzen WhatsApp.

Warum ich WA jetzt doch installiert habe

Selbst bei kleinen Gruppen, mit denen ich kommunizieren möchte, hat es nicht funktioniert, alle zur Installation von BBM zu bewegen. Und es ist dann immer ziemlich umständlich, alle zu kontaktieren oder auch mal innerhalb einer Gruppe etwas abzusprechen. Natürlich funktioniert SMS noch immer, aber das ist nicht wirklich komfortabel und nicht jeder hat eine SMS Flatrate und somit entstehen beim Senden von SMS unter Umständen Kosten.

Wenn ich Facebook nutze, habe ich nicht wirklich einen Vorteil gegenüber WhatsApp. Und dann kommt es natürlich immer wieder vor, dass es in Klassen oder anderen Gruppen unserer Kinder eine WhatsApp-Gruppe gibt. Wenn man da mitmischen möchte und nichts verpassen dann hat man also fast keine andere Wahl, als den Messenger mit dem grünen Logo zu nutzen.

Wie gehe ich mit den Datenschutz und Sicherheitsbedenken um?

Ich nutze soziale Netzwerke wie Twitter und Facebook, gebe also ohnehin Daten von mir in die Hände von Diensten, die von eben diesen Daten leben müssen. Da WhatsApp ja von Facebook gekauft wurde, wäre es nich logisch, Facebook zu nutzen aber gleichzeitig WhatsApp aus Datenschutzgründen nicht zu nutzen. Bei der Verschlüsselung ist WhatsApp auf gar keinem so schlechten Weg, indem es schrittweise die Ende-zu-Ende Verschlüsselung einführt. Man muss sich eben bei der Nutzung im Klaren sein, dass momentan die Daten auf dem Server des Anbieters durchaus mitgelesen oder anderweitig gespeichert oder weitergegeben werden können. Aber das ist selbst beim BBM der Fall, sofern man nicht die Variante für Geschäftskunden mit eigenem BlackBerry-Server nutzt.

Fazit

Der WhatsApp Messenger ist genial einfach und unkompliziert zu bedienen. Der Kniff, den Kontakt über die Handynummer herzustellen, so dass ich alle Bekannten, von denen ich diese Nummer ohnehin im Adressbuch habe, sofort erreichen kann, wenn diese WhatsApp auch nutzen, sind ein unschlagbarer Vorteil für viele Nutzer, war für mich als BBM Nutzer aber immer eher abschreckend (siehe oben).

Ich nutze WhatsApp also jetzt auch, präferiere aber weiterhin den BBM, da ich viele seiner Funktionen sehr zu schätzen weiss. Wer es etwas genauer wissen will, kann sich meine kleine Artikelserie dazu auf dem Blog der BlackBerry-User-Group Kassel anschauen. Welche und wieviel private Daten und Informationen in einem Messenger preisgibt (egal welchem), sollte jeder für sich entscheiden und dabei immer im Hinterkopf haben, wer was mit diesen Daten anfangen könnte.

Ich werde mal beobachten, wie sich der Messenger so nutzen lässt und bei Neuigkeiten oder anderen Erkenntnissen natürlich hier im Blog berichten.

Twitter gehackt - besser Passwort ändern

Bei Twitter hat es in der letzten Woche einen Einbruch in die Server gegeben. Wie das Unternehmen in seinem Unternehmensblog mitteilt, wurde der Angriff live bemerkt und konnte gestoppt werden. Die bisherigen Ermittlungen ergaben, dass die Daten von ca. 250.000 Konten in die Hände der Einbrecher gelangt sind. Die Täter haben Anmeldenamen, Mailadressen und die verschlüsselten Passwörter erbeuten können.

Die Besitzer der kompromittierten Konten wurden von Twitter per Mail informiert, die Accounts wurden gesperrt und es muss ein neues Passwort vergeben werden.

Twitter weißt in seinem Blog auf darauf hin, ein sicheres Passwort zu verwenden (mindestens 10 Stellen, Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen) und das Passwort für keine anderen Dienste zu verwenden.

Da man nicht sicher sein kann, ob alle betroffenen Accounts erkannt wurden, würde ich allen Twitter-Nutzern empfehlen, das Kennwort zu ändern und auch die Empfehlung zu beherzigen, unterschiedliche Passwörter für die Dienste im Internet zu verwenden.

Die Änderung des Twitter-Passworts ist natürlich mit ordentlich Arbeit verbunden, muss man ja alle Geräte und Anwendungen, die man so in Gebrauch hat, mit dem neuen Kennwort versorgen. Aber, wie sagt man so schön: Sicher ist sicher. Bis später.

(via Caschy)


Warning: Undefined variable $headcss in /homepages/41/d26790088/htdocs/serendipity/plugins/serendipity_event_lightbox/serendipity_event_lightbox.php on line 212