Zur Sache: Ich habe mir Kippo aus dem SVN geholt und die entsprechenden Pakete installiert. Beim starten kam folgende Fehlermeldung:

 ./start.sh
Starting kippo in background...Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/twisted/application/app.py",
line 626, in run
    runApp(config)
  File "/usr/lib/python2.6/dist-packages/twisted/scripts/twistd.py",
line 23, in runApp
    _SomeApplicationRunner(config).run()
  File "/usr/lib/python2.6/dist-packages/twisted/application/app.py",
line 374, in run
    self.application = self.createOrGetApplication()
  File "/usr/lib/python2.6/dist-packages/twisted/application/app.py",
line 439, in createOrGetApplication
    application = getApplication(self.config, passphrase)
---  ---
  File "/usr/lib/python2.6/dist-packages/twisted/application/app.py",
line 450, in getApplication
    application = service.loadApplication(filename, style, passphrase)
  File
"/usr/lib/python2.6/dist-packages/twisted/application/service.py", line
390, in loadApplication
    application = sob.loadValueFromFile(filename, 'application', passphrase)
  File "/usr/lib/python2.6/dist-packages/twisted/persisted/sob.py", line
210, in loadValueFromFile
    exec fileObj in d, d
  File "kippo.tac", line 15, in 
    from twisted.conch.ssh import factory, keys
  File "/usr/lib/python2.6/dist-packages/twisted/conch/ssh/factory.py",
line 21, in 
    from twisted.conch.ssh import keys
  File "/usr/lib/python2.6/dist-packages/twisted/conch/ssh/keys.py",
line 20, in 
    from pyasn1.type import univ
exceptions.ImportError: No module named type

Failed to load application: No module named type

Bei Meinem Debian 6 ist wohl etwas in der Paketverwaltung schief gegangen, denn es hat pyasn1 nicht richtig initialisiert.

Einen Tip für die Lösung des Problems lieferte ein Blick in die postint-Behandlung des pyasn1-Pakets:

 dpkg  -I /var/cache/apt/archives/python-pyasn1_0.0.11a-1_all.deb postinst
#!/bin/sh
set -e
# Automatically added by dh_pysupport
if which update-python-modules >/dev/null 2>&1; then
        update-python-modules  python-pyasn1.public
fi
# End automatically added section

Bei mir war das update-python-modules-Skript nicht im $PATH drin.
Die Lösung war ganz einfach:

sudo /usr/sbin/update-python-modules  python-pyasn1.public

Hat alle Probleme behoben und nun kann Kippo gleich loslaufen…

[edit] Da habe ich den Lösungsansatz her: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622086 [/edit]

Wenn man dann noch das Internet weiterreichen will: OpenVPN Bridge

Ich möchte hier meinen Blickwinkel auf die Problematik darstellen und hoffe, es schleichen sich nicht allzu viele Fehler ein.

Nutzer

Jeder Admin sagt dir: nimm ein sicheres Passwort! (zumindest sollte er dies tun). Ich möchte hier nicht beschreiben, wie du ein gutes Passwort wählst, da musst du dir a) selbst Gedanken machen, b) im Internet recherchieren.

Problem 1: Beliebte Passwörter

Mein Gedankengang ist folgender: Der Mensch ist faul – das ist ja erst mal nichts negatives. Deshalb versucht er es sich möglichst einfach zu machen und nimmt als Passwort was?

• ein Geburtsdatum (beliebt: DDMMYYYY) von sich, einem Familienmitglied, etc.
• Den Namen eines lieben Menschen (Kinder, Partner, Freunde, etc.)
• Die beliebte Kategorie 123456…
• Eine alte Telefonnummer
• Ein beliebter Urlaubsort
• Name eines Haustiers

Das Problem: Er weiß, dass das nicht Passwort sicher ist, aber er kümmert sich nicht darum. »Ich hab nichts zu verbergen«, »Von mir will doch eh niemand was«, »Dieses Passwort ist nicht so wichtig« usw… sind beliebte Phrasen solcher Menschen.

Das freut natürlich das Script-Kiddie, dann muss es nicht solange warten.

Problem 2: 1 Passwort, überall

Dann denkt sich der Mensch: Hmm… vielleicht hat er recht der Admin, und ich denk mir mal ein sicheres Passwort aus. Dann hat er ein sicheres Passwort mit mindestens 8 Zeichen, Groß-/Kleinschreibung, Sonderzeichen. Aber: Er nimmt immer und überall das gleiche Passwort.

Hat das Script-Kiddie ein Passwort erschnüffelt, kann es sich überall einloggen und freut sich, dass es spielen kann.

Der Admin

Hiermit mein ich nicht nur den Admin aus deinem Unternehmen, sondern jeden, der einen Dienst betreibt, bei dem man sich einloggen kann.

Problem 1: Arroganz

»Bei mir kommt eh niemand rein.«, »Wer soll sich bei mir einhacken?«. Kommt dir das bekannt vor? Hast vielleicht du selber das gesagt? Dann überlege dir noch mal deine Position.

Du hast vielleicht alles Abgeriegelt, deine Firewall blockt alles, auch Wikipedia, Mitarbeiter kommen von außen nur mit Vollverschlüsselten Firmen-Notebooks rein, beim Eintreten zum Serverraum gibt es Iris-Scan, Urinkontrolle, und 100-stellige Passwörter. Aber: Jemand der rein will, wirklich reinkommen will, und Ahnung von z.B. Social Engineering hat, kommt rein. Wenn der Angreifer im System ist, hast du verloren. Das musst nicht mal du sein, welcher den Angreifer rein lässt, vielleicht jemand vom Sicherheitspersonal oder ein Mitarbeiter. Wenn jemand Hardwarezugriff hat, dann ist deine Datenbank mit den Passwörtern weg. Dann kommt Problem 2 ins Spiel:

Problem 2: Unwissenheit, keine Lust

Ups, jemand hat da wohl deine Datenbank mit den Passwörtern geklaut. Du denkst dir: »Kann ja mal passieren, Die Passwörter sind eh gehasht«. Hach, das Script-Kiddie wird sich freuen. Es wirft John an und freut sich über die 1000 Passwörter, die John in der ersten Sekunde rauswirft. Was hast du falsch gemacht?

Ich sag es noch einmal: MD5 ist UNSICHER!!! Verdammt noch mal, müsst ihr alle md5 nutzen???? Ein Passwort, welches mit md5 kodiert (Verschlüsselung wars noch nie, sondern ein Hash) ist, kann man mit wenig Aufwand ganz schnell knacken.

Wie man das Problem etwas beheben kann? SHA256 oder SHA512 ist auf jeden Fall eine bessere Wahl, da es langsamer ist, und deshalb dauert es einfach länger, die Passwörter zu knacken.

Das Grundsätzliche Problem sind Rainbow-Tables. Das sind einfach Listen mit Hashes und den Passwörtern dazu. Die gibt es zum Beispiel hier.

Lösungsansätze

Nutzer

Wie macht man es so, dass man den Nutzer nicht überfordert, und dennoch ein bisschen Sicherheit bietet?

Ich denke, dass lokal gespeicherte Passwörter Grundsätzlich sicherer sind, als solche in der Cloud. Denn wenn man nur 1 Passwort nutzt, dann braucht es nur einen »doofen«, und das eigene Passwort ist weg. Also denke ich, dass man sich einen lokalen Passwortmanager zulegen sollte, der die Passwörter mit einem sicheren Algorithmus verschlüsselt. Dann muss man sich nur noch 1 sicheres Passwort merken und man hat zumindest ein bisschen Sicherheit.

Die Passwörter für die Dienste sollte ein guter Passwortgenerator erzeugen, wobei man darauf achten sollte, dass die Passwörter mindestens 15 Stellen haben und alle möglichen Zeichen umfassen. Das unschöne hier ist, dass man den Passwortmanager auf allen Geräten bräuchte, und das schon wieder in Richtung Cloud–Dienst tendiert. Aber aus den Erfahrungen der letzten Monaten würde ich sagen: Traue keinem Cloud–Dienst. Also muss eine mächtige Open–Source Lösung ran, die freie Apps für alle wichtigen und unwichtigen Plattformen bietet und die Kommunikation kryptografisch absichert. Am besten ist hier auch, wenn man einen eigenen Passwort-Server betreiben kann.

Wenn nun bei einem Cloud–Dienst mal wieder Passwörter gestohlen werden, brauchst du dir keine Gedanken um die Integrität der anderen Passwörter machen, denn du nutzt nur einmalige Passwörter.

Die größte Sicherheitslücke ist nun DEIN System und nicht ein System, welchem du per Definition nicht trauen darfst. Hoffe nun, dass kein Trojaner dein Passwort abfischen kann. Ach ja, und weil es gerade so schön ist, krame ich mal den guten, alten XKCD raus. Ganz einverstanden bin ich zwar nicht, aber so in der Art kann man es machen.

Admin/Anwendungsprogrammierer

Dich bitte ich, meine Passwörter nicht als MD5-Hash abzuspeichern, sondern wähle einen langsamen und besseren Algorithmus dafür und bitte, bitte salze die Passwörter, damit die Hashs nicht in irgendwelchen Rainbow–Tables auftauchen. Du kannst dir zum Beispiel einen langen (>100 Zeichen) langen String ausdenken und danach noch in irgendeiner Weise den Nutzernamen dazu mixen und so das Passwort gehashed abspeichern. Das dürfte wohl die billigste Lösung für dich sein, und du musst dir bei einem Diebstahl deiner Datenbank weniger Sorgen machen.

Außerdem sollte es heutzutage wirklich kein Problem sein, die Seite, zumindest wenigstens die Passwort-Abfrage per SSL oder etwas Adäquaten abzusichern, damit die Passwörter nicht im Klartext durchs Netz gehen.

Mein Wunsch

Ich wünsche mir eigentlich eine 2-Faktor-Authentifizierung für alle Dienste. Optimaler weise ist der zweite Faktor kein Smartphone, da dies ein potentielles Angriffsziel ist, sondern ein Hardware-Token mit starker Kryptographie.

Das Problem hierbei ist wieder, dass du dem Hersteller nicht vertrauen kannst. Erinnerst du dich an den Hack bei Lockheed Martin und RSA? Bei dir könnte es genauso laufen. Deshalb wünsche ich mir eine Freie Lösung, die freie Software und vor allem freie Hardware enthält.

So eine Lösung hat den Vorteil, dass viele Augen besser Fehler finden, als nur wenige und man damit einen freien Standard hat, wodurch sich auch die Preise für die Hardware stark reduzieren lassen könnten. Wie wäre es mit 5€ für einen Token? 5€ wird wohl jeder gerne zum Schutze seiner digitalen Identität ausgeben können.

Firmen müssen dann auch weniger um ihre Sicherheit bangen.

Klar ist, dass Passwörter nur ein kleiner, aber extrem wichtiger Teil einer Sicherheitsinfrastruktur ist, man darf nicht vergessen, dass alles potentiell unsicher ist, und man sollte seine Infrastruktur so planen, dass sich auch bei einem erfolgreichen Angriff der Schaden in Grenzen hält.

Das größte Einfallstor ist nach wie vor der Mensch. Denn über Social Engineering wird sich wohl noch lange ein Weg in Unternehmen, auch in die größten davon finden. Dazu noch ein Buchtipp: »Die Kunst der Täuschung: Risikofaktor Mensch« von Kevin Mitnick (ohne Affiliate-Link )

Dafür gibt es seit langer Zeit das tolle Tool PasteBin. Einziges Manko: Die Sachen werden unverschlüsselt gespeichert. Vor einiger Zeit hat Sébastien Sauvage das tolle Tool ZeroBin veröffentlicht, welches Einträge per JavaScript verschlüsselt. So sieht der Server nie, was eigentlich geschrieben wurde.

Ich habe nun einen eigenen ZeroBin-Server laufen, und zwar hier: zero.azapps.de.

Noch ein paar  technische Informationen und Tipps zur Installation:

Technische Informationen

URL

Die URL eines Eintrags ist folgendermaßen aufgebaut:

http://zero.azapps.de/?4c31c4883b6dd29f#A5rWM2NAkRD8QMbaADmDT2fHMaXSwwz2rs09JQVO9Nk=

Der Interessante Teil ist logischerweise der nach dem »?« .

Als erstes steht dort die ID des Eintrags (4c31c4883b6dd29f). Dies ist einfach eine JSON-Datei auf dem Server, die sich PHP holt und an den Browser schickt. Soweit so gut, aber der Interessante Teil ist der nach der Raute. Das ist der Schlüssel zum Ent– und Verschlüsseln. Dieser wird vom Browser nicht an den Server geschickt, also kann der Server selber die Daten nicht entschlüsseln, und außerdem kann man auch über einen unsicheren Kanal mit dem Server kommunizieren, ohne dass ein Angreifer mitlesen kann. Es ist natürlich klar, dass, sobald der Key dem Angreifer bekannt ist, er alles mitlesen kann.

Verschlüsselung

Das eigentlich interessante an ZeroBin ist die Verschlüsselung und Entschlüsselung. Diese funktioniert nämlich im Browser und basiert auf AES-256. Das ist zum heutigen Zeitpunkt ein ziemlich guter Verschlüsselungsalgorithmus. Da dieser Symmetrisch ist, kann man sogar Konversationen mit einem einzigen Schlüssel führen.

Die JavaScript-Implementierung des Algorithmus stammt von der Stanford–Universität: Stanford Javascript Crypto Library.

Installation

Lade dir das aktuelle Script hier herunter, oder noch besser, klone es dir aus dem Git-Repo:

git clone git://github.com/sebsauvage/ZeroBin.git

Dann lege noch folgende Ordner an:

mkdir data
mkdir tmp

Der data-Ordner ist für die Text(JSON)-Dateien (ZeroBin braucht keine Datenbank) und der tmp-Ordner ist für das Template (RainTPL) da. Logischerweise müssen beide Ordner für PHP beschreibbar sein:

chmod 777 -R tmp/ data/

Das wars auch schon. Viel Spaß mit ZeroBin.

Ich werde vielleicht noch versuchen einen Syntax-Highlighter und einen Datei-Upload (Unverschlüsselt ) für ZeroBin zu basteln.

Für Konversationen eignet sich bekanntlich Jabber am besten und deshalb ist meine neue Jabber-Adresse az@azapps.de

Und hier noch meine Fingerprints:

E-Mail:

80A0 F191 7E3F 4032 42B0 732F 0FB0 FB40 92ED 8863

OTR:

4C42CCAC 2284EE19 15FADD2A A929DB10 7466083C

Demnächst wird es hoffentlich eine SSL-Version dieser Website geben, ich muss nur noch die Zeit finden, diese einzurichten.