Nun, ich persönlich schätze eine solche Verschlüsselung direkt auf dem Client, zumal es mir bei diesen Diensten hauptsächlich um das zusätzliche Online-Backup und die Synchronisation zwischen verschiedenen Geräten geht. Die Sharing-Funktion benötigte ich nur für einen kleinen Teil meiner Dateien. Vom Webinterface mache ich praktisch nie Gebrauch — abgesehen von Google Drive, wenn es um die Dokumente im Google-Docs Format geht.

Bei einem Teil der Dienste (etwa der Dropbox) ist es möglich mit einem verschlüsselten TrueCrypt Container zu arbeiten, da die Dateien hier auf Block-Basis synchronisiert und somit nur die Änderungen hochgeladen werden. Ist aber nicht wirklich benutzerfreundlich und bringt verschiedene Gefahren mit sich. So muss man etwa aufpassen, dass man den entsprechenden Container nicht gleichzeitig auf verschiedenen Rechnern gemountet hat und sich Änderungen gegenseitig überschreibt. Ebenso ist die Gefahr von korrupten Containern bei einer Synchronisation über das Internet grösser wie Lokal.

Einen in gewisser Weise eleganteren Ansatz bietet die Software BoxCryptor. In letzter Zeit habe ich viel darüber gelesen und heute ausprobiert. Kurz gesagt ist BoxCryptor ein zusätzlicher Layer zwischen der eigentlichen Datei und dem Cloud Storage Anbieter. Es wird jede Datei on-the-fly inklusive dem Dateinamen verschlüsselt und erst dann im Zielordner, beispielsweise Google Drive gespeichert. Lokal bleiben die Daten also unverschlüsselt und in der Cloud wird einzig die verschlüsselte Version davon abgelegt. Es ist somit weiterhin möglich von der Versionierung einzelner Dateien Gebrauch zu machen, was bei TrueCrypt nicht der Fall ist.

Die Technik dahinter kann mit EncFS (Unix) verglichen werden, basiert allerdings nicht darauf. «As we used EncFS ourselves, we wanted to bring the EncFS experience of file-by-file encryption to the Windows world. Therefore we built BoxCryptor from scratch with the compatibility with EncFS in mind.»

Auch wenn BoxCryptor selber nicht Open Source ist, schätze ich sehr, dass die Jungs mit recht offenen Karten spielen was das Thema anbelangt. Immerhin wird im Hintergrund der offene Standard AES-256 verwendet. Der ganze Spass ist (>5 GB) nicht gratis, aber für den einmaligen Preis von 30 Euro kann man nicht viel sagen. Scheinbar gibt es auch noch einen akademischen Rabatt.

Hinweis: Die Idee dahinter funktioniert nur, wenn man die verschlüsselten Dateien nicht für andere Benutzer freigeben möchte. Das ist durch den gemeinsamen Schlüssel für alle Dateien nicht möglich. Auch der mobile Zugriff auf die Daten ist auf die von BoxCryptor unterstützten Dienste beschränkt.

Das Praktische an BoxCryptor ist in meinen Augen, dass man damit von den Vorteilen der Cloud profitieren kann, ohne auf ein gewisses Level an Datensicherheit verzichten zu müssen. Zudem hat man es durch das gezielte Platzieren der Ordner und Dateien selber in der Hand, welche Dateien man wie (verschlüsselt oder unverschlüsselt) im Cloud Storage ablegen möchte.

Klar, optimal wäre in meinen Augen eine direkte Integration von EncFS oder einer anderen Open Source Software in Windows. Das ist jedoch aktuell nicht bzw. nicht ganz so einfach möglich.

Verwendet jemand von euch BoxCryptor oder ein anderes Programm / Verfahren zum Verschlüsseln der Dateien innerhalb vom Cloud Storage?

Ebenso hat die Stiftung Warentest einen neuen Test veröffentlicht und dabei rund 15 verschiedene Sicherheitslösungen getestet. Folgend wurde der entsprechende Test heftig kritisiert und ein offener Brief an die Stiftung Warentest geschrieben. Dieser wurde wiederum beantwortet - scheinbar aber unbefriedigend.

Der Sicherheitsexperte und Blogger Kristian hat sich seine eigene Meinung zu dem Thema gebildet und erklärt sehr treffend anhand von einem Beispiel wie schnell sich Viren verändern und was das für Auswirkungen auf die Wirkung/Effektivität der Virenscanner hat.

Zu den entsprechenden Tests meint er: «Statt gegen unbekannte frische Programme zu testen, testet man gegen einen Zoo von nicht mehr verwendeter Altware.»

Inklusive Erklärung, was für Möglichkeiten man hat, um sich an einem SSH-Server zu authentifizieren und welche davon sich für welchen Fall eignet. Ich selber nutze das Public-Key Verfahren für meinen Webserver. Bequem, schnell und sicher. Nutze ich nebenbei auch zum Verschlüsseln von Dateien oder zum Surfen.

Die Rede ist auch vom Google Authenticator in Zusammenhang mit einer Zwei-Faktor-Authentifizierung. In Verbindung mit der Public Key Authentication aber eher kompliziert zu integrieren und fraglich, ob es Sinn macht? Spannend ist, dass der Google Authenticator als Open Source zur Verfügung steht und in praktisch jede Anwendung integriert werden kann/könnte.

In Chrome gibt es eine Möglichkeit (Einstellungen — Inhalt — Plugins — «Alle blockieren»), mit der man diese Plugins standardmässig deaktivieren kann. Verwendet eine Webseite eines dieser Plugins, wird das in der Adressleiste angezeigt und man kann die Ausführung des Plugins auf der entsprechenden Seite oder kompletten Domain zulassen.

Laut Carsten könnte das Ganze nun auch in einer der nächsten Firefox-Versionen kommen. Ohne Erweiterung. Finde ich — im Gegensatz zu vielen anderen Benutzern — gut, da es während dem Surfen schlicht für mehr Sicherheit sorgt.

Und ganz so umständlich, wie das Dirk formuliert («umständlicher geht es dann ja wohl kaum noch») ist es in meinen Augen überhaupt nicht, da die Klassiker wie YouTube und Viemo schnell auf der Whiteliste sind. Sieht Alexander auch so: «Bei meinem Surfverhalten kann ich wahrscheinlich sehr gut damit leben».

Bei mir ist die entsprechende Einstellung im Google Chrome aktiviert und ich komme gut damit zurecht. Auch was Cookies anbelangt, regle ich das wohl anders als die meisten Benutzer.

Java ist übrigens nicht mit JavaScript zu verwechseln. JavaScript kommt praktisch auf jeder Webseite zum Einsatz und das Deaktivieren von JavaScript hat oft direkten Einfluss auf die Funktionalität einer kompletten Webseite. Java hingegen kann in meinen Augen ohne Probleme deaktiviert — und wo benötigt aktiviert — werden.

Wie seht ihr die Thematik mit dem Plugins? Lieber mehr Benutzerfreundlichkeit und weniger Sicherheit?

Die Switch bzw. deren Abteilung SWITCHcert hat darauf in meinen Augen super reagiert. Sie haben vom Flashback-«Entdecker» Dr. Web Informationen bezüglich infizierten Computern in der Schweiz erhalten und diese Informationen (wohl die IP-Adressen der betroffenen Computer) an die Internet-Provider weitergeleitet.

Anhand der Logdateien können die Provider die IP-Adressen nun einem Kunden zuordnen und diesen entsprechend über die mögliche Verseuchung seiner Rechner informieren. Sehe ich als ein positives Beispiel für die Vorratsdatenspeicherung. Auf Wikipedia mehr dazu. Ihr?

Kurz erklärt: Die Switch ist eine Non-Profit-Organisation, die sich neben Internetzugängen für Universitäten auch um diverse Themen für mehr Sicherheit im Internet (zumindest in der Schweiz und Liechtenstein) kümmert.

Meist natürlich kleingedruckt, sodass es vom Laien — der möglichst schnell zu seiner Information kommen möchte — übersehen wird und zu lästigen Briefen mit Zahlungsaufforderungen führt. Betroffen? Einfach ignorieren oder allenfalls den Vertrag wegen Täuschung anfechten. So sieht das zumindest der Kassensturz oder die Verbraucherzentrale Hamburg, um zwei Beispiele zu nennen.

Vor einem guten halben Jahr hat auch Udo Vetter (Anwalt und Blogger) über den Dauerbrenner Abo-fallen geschrieben und seine Tipps erläutert:  «Am besten kommt man um Forderungen von Abofallen übrigens herum, wenn man – natürlich wahrheitsgemäß – jeden Besuch auf der betreffenden Seite abstreitet.»

Weiterhin wurde heute ein Beitrag auf der Webseite der Schweizerischen Kriminalprävention veröffentlicht. Es geht konkret um Seiten, die als Abofallen bekannt sind. Bei der SKP finden sich übrigens sehr viele andere Tipps rund um das Thema Sicherheit im Internet.

Tipps bevor es passiert? Im Zweifelsfall seine Daten nicht eingeben und allenfalls einen fachkundigen Kollegen hinzuziehen. Sowie natürlich genau lesen — auch das Kleingedruckte.

Ist jemand von euch schon Opfer einer Abofalle geworden? Wie habt ihr allenfalls darauf reagiert und was ist dabei herausgekommen?

Eine sichere Möglichkeit für den Fernzugriff bzw. darum herum ist die Verwendung von einer VPN-Lösung. Beispielsweise OpenVPN. Viele Router und vor allem Firewalls bieten bereits von Haus aus einen entsprechenden VPN-Server an, welchen man nur noch aktivieren und wenig konfigurieren muss. Alternativ gibt es für Synology NAS ein entsprechendes Paket - wobei ich das Ganze persönlich lieber direkt auf dem Gateway (=Firewall) habe.

Grundsätzlich verbindet man sich so vom Internet aus über eine verschlüsselte Verbindung zum VPN-Server und erhält dann im dort vorhandenen Netz eine IP-Adresse, von wo aus man auf die anderen Ressourcen im LAN zugreifen kann. Alle Verbindungen in das LAN werden dabei durch das verschlüsselte Tunnel geschleust. Der entsprechende Client dazu (OpenVPN GUI für Windows) reicht und man ist dabei. Mehr bei Wikipedia.

Im OpenVPN HowTo im Kapitel «Routing all client traffic (including web-traffic) through the VPN» findet man zudem eine Anleitung, wie man seinen kompletten Internetverkehr über die VPN Verbindung schleusen kann. Als Alternative zum SSH-Tunnel und für nicht vertrauenswürdige Netzwerke (WLAN) geeignet.

Ich persönlich habe vor gut zwei Wochen OpenVPN auf einer IPFire Firewall eingerichtet und kann nun das komplette Netzwerk aus der Ferne administrieren und auf die CloudStation zugreifen.

Auch hier gilt: Vor Gebrauch lieber mal noch den Informatiker über die Konfiguration schauen lassen. Danke übrigens an Daniel für die Beitragsidee! Weitere Informationen zu OpenVPN und auch zu der Einrichtung findet man unter anderem beim OpenVPN e.V.

Doch, was eigentlich nie erwähnt wird (gefunden bei) ist, dass das Ganze auch bei praktisch allen anderen Betriebssystemen, so auch unter Windows der Fall ist. Ein Programm, welches in Kontext von einem Benutzer ausgeführt wird, hat nun mal Zugriff auf die «Eigenen Bilder» des entsprechenden Benutzers.

Ich sage nicht, dass ich das Ganze gut finde, im Gegenteil, ich bin grundsätzlich dafür, dass man diese App-Berechtigungen noch detaillierter setzen und einsehen können soll. Die Frage ist nur, wie weit man hier gehen kann und will?

Es ist schlussendlich eine Frage der Benutzerfreundlichkeit und der Sicherheit. Sowie Vertrauen. Interessant wäre es meiner Meinung nach jedoch, wenn man beispielsweise einzelne Apps isolieren könnte, sodass diese auf keinerlei Daten zugreifen können. Ich denke hier an eigenständige und unabhängige Apps wie etwa Converter und Spiele. Oder was meint ihr dazu?

Unter Android zumindest ist aktuell die komplette SD-Karte als Public-Readable deklariert. Es kann also von Haus aus jede App auf die SD-Karte zugreifen. Dazu gehören neben den Fotos auch etwa die Downloads: «and there’s no security enforced upon files you save to the external storage. All applications can read and write files placed on the external storage and the user can remove them».

Bei iOS Geräten ist es ähnlich. Dort haben Apps Zugriff auf die Fotos, sobald der Benutzer seinen Standort für die entsprechende App freigegeben hat: «This allows access to location information in photos and videos». Hierzu muss man jedoch sagen, dass der Benutzer dem so ausdrücklich zustimmt, was bei Android nicht direkt der Fall ist.

Hatten wir alles schon hier im Blog. Ein Grund mehr, warum man solche Newsmeldungen immer zuerst hinterfragen sollte. Zudem empfehle ich jeweils (wo verfügbar) die entsprechenden Kommentare von anderen Lesern auf die Newsmeldung hin zu lesen. Speziell bei Heise Online immer sehr spannend! Nicht selten findet man darin mehr interessante Informationen, wie sie im eigentlichen Artikel zu finden sind.

Bevor man loslegen kann, benötigt man ein serielles Kabel sowie einen dazu passenden Anschluss am Computer. Neuere Rechner haben nicht immer einen solchen Anschluss, daher am Besten mal bei den älteren Modellen im Haushalt schauen. Ansonsten gibt es entsprechende Adapter für USB.

Weiter muss man im Besitz von einem CompactFlash Kartenleser sein. Ich habe hier einen entsprechenden Cardreader von Kingston. Kann zudem mit verschiedenen anderen Karten umgehen.

Anschliessend kann man sich das fertige IPFire Image auf deren Webseite herunterladen. Direkt auf ALIX Boards zugeschnitten. Gibt zwei verschiedene Images. Für mein Modell (alix2d13) wird die Variante mit dem Prozessortyp i586 benötigt. Falls die weiteren Schritte nicht funktionieren sollten, einfach mal das andere Image verwenden.

Bevor man weiterfahren kann, muss man das Image mit 7-ZIP o.ä. entpacken, sodass man schlussendlich die IMG-Datei hat. Zur Sicherheit dann noch die MD5-Checksumme überprüfen.

Im nächsten Schritt geht es darum die CompactFlash Karte mit dem Image zu bestücken. Hier hilft das Tool physikwrite von monowall. Unter Windows 7 muss man die Karte zuerst vorbereiten und vorhandene Partitionen löschen (diskpart / clean). Ist die Karte grösser wie 2 GB den Parameter «-u» anhängen. Hier gilt jedoch zu erwähnen, dass man bei falscher Wahl auch ohne Problem die komplette Festplatte mit einem Tastendruck löschen kann. Vorsicht also. Der Vorgang kann gut 20 Minuten dauern, das ist normal.

Sind alle Schritte bis hier hin erfolgreich durchgeführt, kann man die CompactFlash Karte im Board einbauen und das Gehäuse zuschrauben sowie die Netzwerkkabel (z.B. LAN und Internet) anschliessen.

Sofern man das board über den seriellen Anschluss mit dem Rechner verbunden hat, kann man jetzt das Netzteil anschliessen, womit das Board startet.

Nun sollte man auf dem Computer Putty öffnen und eine neue serielle Verbindung (COM1) mit der Übertragungsgeschwindigkeit 115200 öffnen. Komische Zeichen? Falsche Übertragungsgeschwindigkeit.

Hat man alles richtig gemacht, erscheint auf dem Bildschirm der IPFire Setup-Assistent, in welchem man die ersten Einstellungen konfigurieren muss. Speziell geht es darum die verschiedenen Netzwerkkarten zu konfigurieren. Dabei muss man auch die einzelnen Netzwerkkarten einem Netz (GREEN=LAN und RED=Internet, …) zuordnen. Wenn man nicht weiss, welches Kabel man an welchem Slot eingesteckt hat, wählt man die nächst freie Karte aus.

Nach dem Setup ist ein Reboot gefragt, denn man weiter auf der Konsole verfolgen kann. Kann einige Minuten dauern. Danach merkt man recht schnell, ob die Kabel am richtigen Port eingesteckt sind. Problem? Kabel an anderem Port einstecken bis man die richtige Kombination gefunden hat. Ifconfig hilft.

Mit etwas Glück und/oder Können kommt man jetzt vom LAN aus auf das IPFire Webinterface. Dazu im Browser die der LAN-Schnittstelle zugewiesene IP-Adresse sowie den Port 444 und HTTPS angeben. Beispielsweise https://192.168.50.1:444.

Die Grundinstallation der IPFire Firewall auf einem ALIX-Board ist nun soweit erledigt. Der restliche Teil kann anschliessend direkt über das Webinterface konfiguriert werden. Darauf werde ich wohl in einem weiteren Beitrag eingehen, muss hier nun jedoch aber zuerst selber einige Erfahrungen sammeln.

Kurz zusammengefasst: Image herunterladen, CF-Card vorbereiten und beschrieben, Board seriell mit PC verbinden, einschalten und via Putty den Setup durchklicken.

Die hier beschriebenen Schritte findet man fast alle auch im Wiki von IPFire. Nebenbei möchte ich erwähnen, dass man das Ganze nicht 1:1 nachmachen, sondern seinem eigenen Setup anpassen sollte.

Zudem kann man mit einer falschen Konfiguration der Firewall durchaus mehr Sicherheitslücken schaffen wie schliessen. Daher besser jemanden Fragen, der sich mit der Thematik auskennt.

Gestern ist die Version 3.0, zumindest mal die Beta davon erschienen. Die Aussage install, set and forget aus dem Video gefällt mir. Dafür wurde die neue Version auch entwickelt, denn neu ist die Auto-Update Funktion von Haus aus aktiviert und die Oberfläche stark vereinfacht worden. Mehr dazu auch bei Brian.

Secunia PSI wurde in der anfangs Monat vom Bundesamt für Sicherheit veröffentlichen Guideline zum Thema Internet-Sicherheit für Privatanwender erwähnt.

Meiner Meinung nach sollte jede Software eine automatische Update-Funktion mit sich bringen, wie das bei Google Chrome sehr gut gelöst ist. Oder aber auch gleich ein fix verankerter Paketmanager im Betriebssystem analog Linux oder Mac OS X. Ich bin auf alle Fälle mal auf den Windows Store (unter Windows 8) gespannt.

Ich persönlich setze kein Tool ein, welches meine Programme automatisch aktualisiert. Dafür verwende ich auf meinem Client nur eine Hand voll Programme, die sich entweder komplett selber aktualisieren, oder zumindest eine Meldung ausgeben, wenn eine neue Version bereit steht. Ihr?

Wie auch immer: Wichtig ist, dass die installierten Programme auf dem Computer jeweils auf dem neusten Stand sind. Mehr Funktionen und mehr Sicherheit.

Fail2ban interagiert mit dem error-log von nginx und überprüft dieses auf fehlerhafte Logins. Im konkreten Fall auf fehlerhafte Auth-Basic Logins. Nach x fehlerhaften Versuchen wird die entsprechende IP-Adresse temporär oder dauerhaft via iptables gesperrt. Funktioniert natürlich auch mit anderen Log-Dateien. Die auth.log (SSH) ist etwa direkt schon in Fail2ban vorkonfiguriert.

Ganz spannend wäre natürlich, wenn man das Konstrukt zu einer minimalen Web Application-Firewall ausbauen könnte.

Als simple Funktion könnte ich mir ein dazu etwa WordPress Plugin vorstellen, welches die fehlerhaften Login-Versuche in eine Log-Datei schreibt, die dann ebenfalls mit Fail2ban ausgelesen und verarbeitet werden kann. Werde mal schauen, ob es bereits ein entsprechende Plugin gibt. Ansätze ohne iptables, sondern rein WordPress basiert gibt es ja mit Limit Login Attempts schon. Hat jemand von euch so was im Einsatz? Eventuell sogar zusammen mit Fail2ban oder generell iptables?

Insgesamt sind Fail2ban und aber auch DenyHosts zwei einfache Möglichkeiten seinen Server etwas sicherer zu gestalten und herkömmliche Angriffe abzuwehren. Zumindest dann, wenn man nicht die nötige Infrastruktur oder die finanziellen Mittel hat, um eine dedizierte Firewall mit integriertem IDS/IPS zu betreiben oder snort auf einem separaten Host einzusetzen. Trifft speziell auf gewöhnliche vServer zu, bei denen man die Security im Normalfall direkt auf dem Server selber definieren muss.

An die Server-Besitzer unter Euch: Hat jemand Tools im Bereich IDS oder IPS im Einsatz? Wenn ja, welche?

Diese Boards wurden vom Schweizer Hersteller PC Engines entwickelt und sind dafür ausgelegt möglichst klein zu sein und wenig Strom (ca. 5 Watt) zu verbrauchen. Dennoch eignen sie sich für verschiedene Zwecke: Beispielsweise als Hardware für eine Firewall oder einen Thin-Client. Ausser dem Netzteil ensteht zudem praktisch keine Hitze, womit auch der Lüfter überflüssig wird.

Es gibt verschiedene Modelle. Mehr oder weniger besteht das Board jedoch aus einem 500 MHz Geode Prozessor und 256 MB Ram. Speicherplatz via CompactFlash. Preislich zahlt man für das board, gehäuse, netzteil und 8GB CF zusammen nicht mehr wie 150 CHF.

Anschliessend hat man die Qual der Wahl, was das passende Firewall-Projekt angeht. Es gibt an dieser Stelle zahlreiche Open Source Lösungen die sehr gut mit einem ALIX-board zusammen arbeiten. Eine Auswahl daraus: Monowall, pfSense, Endian Firewall Community, IPCop und IPfire.

Mein Favorit? Bis jetzt noch nicht getestet, aber IPFire macht mir einen soliden Eindruck. Regelmässige Updates und eine ganze Menge Erweiterungen verfügbar. So auch Snort mit Guardian (IDS + IPS) oder ClamAV (Virenscanner).

Werde ich die Tage in einer virtuellen Maschine testen. Sollte mir das Ganze taugen, kaufe ich ein solches ALIX board dazu und installiere IPFire darauf. Kann es aktuell sehr gut für den Einsatz als Firewall bei einem Bekannten von mir brauchen

PS: Sollte der Raspberry PI auch mal noch einen zweiten Netzwerkanschluss erhalten  - was bis jetzt laut Forum aber noch nicht als Ziel angesehen wird — könnte auch dieser eine interessante Alternative zu den ALIX boards darstellen. Bietet noch mehr Leistung und ist (zumindest in der aktuellen Version) günstiger wie die ALIX Modelle.

Was habt ihr für Firewall-Lösungen im Einsatz? Setzt jemand auf die ALIX boards? Eventuell auch noch IPFire dazu?

Fakt ist: Die Meinungen gehen auseinander. Während die Hersteller von Sicherheitssoftware Umsatz damit generieren möchten, diskutieren andere an anderer Stelle darüber, was denn nun als Schadsoftware bezeichnet werden kann und was nicht. René beschreibt das Ganze nochmals aus Sicht eines Anwenders und Mobile-Experte.

Ein Merkmal von Android ist halt nun mal, dass das Ganze Konstrukt sehr offen gebaut ist. Es gibt keine Kontrolle beim Einreichen von Apps und der Nutzer kann problemlos Apps aus unsicheren Quellen installieren. Ähnlich ist das auch unter Windows: Jeder kann grundsätzlich die Software installieren die er möchte. Woher sie kommt ist für das Betriebssystem eigentlich egal.

Meine Meinung: Im Gegensatz zum AppStore bei Apple (wo Apps vorgängig überprüft werden) bedeutet das Installieren von Apps unter Android eine erhöhte Gefahr für den Benutzer, da die Apps — wie beschrieben — nicht überprüft werden. Als schädlich gemeldete Apps werden erst im Nachhinein überprüft oder entfernt. Diese Offenheit von Android hat halt eben Vor– und auch Nachteile. Die Gefahren habe ich schon einmal in einem Beitrag angesprochen.

Und was mache ich um mich vor diesen — nennen wir sie jetzt einfach mal so — schädlichen Apps schützen zu können? Zuerst habe ich in den Android-Einstellungen die Option «Unbekannte Quellen» (unter Anwendungen zu finden) deaktiviert. So können nicht irgendwelche APK-Pakete installiert werden. Weiterhin habe ich nur eine Hand voll Apps installiert, deren Entwickler ich vertraue. Ich installiere generell sehr selten neue Apps und fühle mich daher recht sicher.

Was meint ihr zu dem Thema? Macht ihr euch vor dem Installieren einer App Gedanken über die Seriösität? Oder verwendet ihr schlicht ein iPhone?

Grundsätzlich sind solche Pseudonyme sehr hilfreich - auch ich verwende sie. Man muss und möchte ja nicht überall seinen echten Namen angeben. Zumindest ich habe das so, auch wenn ich Blogger bin und entsprechend meine Meinung im Netz veröffentliche. Zumindest was Technik-Themen angeht. Bei privaten oder beruflichen Themen sieht das nochmals anders aus.

Es gibt jedoch eine Gefahr, die sich viele Personen nicht bewusst sind. Diese ensteht dann, wenn ein Pseudonym durch Kombination oder andere Hinweise einer «echten» Person mit Name und Vorname zugeordnet werden kann.

Ist dies möglich, ist die entsprechende Anonymität bzw. Pseudonymität (?) nicht mehr gegeben. Wer im Besitz dieser Kombination ist, kann im Web sehr einfach nach allen Einträgen suchen, die unter dem Pseudonym geschrieben worden sind. Hat die entsprechende Person dann nur ein und nicht verschiedene Pseudonyme verwendet, findet man so meist eine Menge über sie heraus — gewollt oder nicht. Zusammen mit Webdiensten wie NameChk sogar ohne grossen Aufwand und mit einem Klick!

Kurz und knapp: Wer von Pseudonymen Gebrauch macht, sollte sich dieser Gefahr bewusst sein und entsprechend handeln: Verschiedene Pseudonyme verwenden und nicht jedem von seinem Pseudonym erzählen bzw. keine Verbindung zwischen Realname und Pseudonym herstellen. Zumindest, wenn man eben genau die Verbindung zur echten Person vermeiden möchte.

Im Zusammenhang einer Awareness Kampange in der Firma hat mich ein Arbeitskollege zudem auf eine Folge vom (leider eingestellten) c’t TV hingewiesen. Da geht es unter anderem um das Thema — inklusive einem Beispiel: Die zerstörte Privatsphäre — Auf der Suche nach persönlichen Spuren im Internet.

Bild: Luciano C. unter CC By 2.0. Zeigt eine Person mit der von Anonymous bekannten Maske. Passt meiner Meinung nach sehr gut zum Thema Privatsphäre, Internet, Anonymität und eben Pseudonymen.

Nun behauptet Martin jedoch in seinem Artikel, dass diese 2-Faktor-Authentifizierung bei Google (Zitat) eine Mogelpackung ist! Das darum, weil man für bestimmte Anwendungszwecke — Applikationen und Protokolle, die nicht mit der der Two Step Verification zurecht kommen — spezielle Passwörter generieren kann. Diese Passwörter nennt Google Anwendungsspezifische Passwörter. Die Passwörter bestehen jedoch jeweils nur aus 16 Kleinbuchstaben.

Ich habe darauf im Netz noch etwas recherchiert und bin auf einen weiteren Blogbeitrag sowie einen Eintrag im Google Apps Forum gestossen, wo es ebenfalls um dieses Thema geht.

Ein Anwendungsspezifische Passwort kann zwar nicht dafür verwendet werden, sich via Browser im Google Konto einzuloggen, dafür aber in jeder beliebiger Applikation. Ein Cracker könnte also eine eigens geschriebene Applikation bzw. eine bestehende Applikation für einen Brute-Force Angriff verwenden.

Zudem scheint es so, dass es kein Limit an aufeinanderfolgender falschen Login-Versuche gibt. Ich habe zumindest keine Informationen zu diesem Thema gefunden.

In den verlinkten Beiträgen wird jedoch auch erwähnt, dass man mit den Passwörtern nicht alle Funktionen des Google Kontos nutzen kann. Man kann beispielsweise also nicht das eigentliche Passwort zurücksetzen. Es reicht von mir aus gesehen aber bereits, dass der Angreifer so meine Mails lesen könnte.

Zum Ende vom Artikel und nach weiteren Recherchen und Versuchen bin ich dann aber zum Schluss gekommen, dass wohl auch ein Passwort, welches nur aus Kleinbuchstaben besteht zum heutigen Zeitpunkt nicht als schwach eingestuft werden kann. Vor allem aufgrund der Länge von 16 Zeichen.

Wobei es hier zu bemerken gibt, dass man bei Google verschiedene Anwendungsspezifische Passwörter generieren kann. Je mehr Passwörter man hat, desto mehr richtige Möglichkeiten gibt es für einen Angreifer.

Anyway: Interessantes Thema, ich werde die Zwei Faktor Authentifizierung bei Google weiterhin verwenden. Finde es aber schade, dass man die Anwendungsspezifischen Passwörter bei Google nicht selber generieren kann.

Was sagt ihr zum Thema? Habt ihr euch auch schon damit beschäftigt? Verwendet ihr eine 2 Faktor Authentifizierung für euer Google Konto oder andere Dienste?