Getaggt mit Sicherheit

Revelation – ein Passwortmanager für den GNOME-Desktop

Kürzlich schrieb ich ja einen Artikel über Sleutel, einem plattformunabhängigen Passwort-Manager. In den Kommentaren dazu wies mich ucn| auf eine interessante Alternative hin, die sich Revelation nennt.

Revelation befindet sich in den Ubuntu-Quellen, daher reicht ein einfaches

$ sudo apt-get install revelation

für die Installation. Anschließend kann das Programm über Anwendungen->Zubehör->Revelation Password Manager gestartet werden. Hier erscheint erstmal eine Fehlermeldung, in der verkündet wird, es sei keine Konfigurationsdatei vorhanden. Davon sollte man sich nicht irritieren lassen. Revelation erstellt natürlich automatisch eine, was beim ersten Start eines Programms ja nicht unüblich ist.

Revelation bietet Vorlagen für die verschiedensten Zwecke an – von der Kreditkarte, Zertifikat, Datenbank, E-Mail und FTP bis zu Webseiten und sogar Türschlössern. Hier bietet das Programm auch eine gute Anbindung an weitere Programme. So kann man direkt aus Revelation eine SSH-Sitzung beginnen oder einen FTP-Server in Nautlus einhängen. Nett. Welche Programme für welchen Zugangstyp verwendet werden, kann man selber festlegen.

Als zusätzliches Schmankerl gibts für GNOME-User noch ein Applet fürs Panel. Man kann damit über ein Suchfeld nach Passwörtern suchen oder sich selbst durch das Menü hangeln, ohne dass man Revelation starten muss.

Wie bei jedem Passwort-Manager lassen sich natürlich auch hier neue, sichere Passwörter generieren und vorhandene auf Sicherheit prüfen. Praktisch ist auch die Import/Export-Funktion, mit der sich die komplette Datenbank in die Formate von GPass, Password Safe 1.x + 2.x, PasswordGorilla, MyPasswordSafe und SplashID importieren bzw exportieren lassen. Simple XML-Dateien sind auch möglich. Auf diese Weise verhindert man einen Lock-in-Effekt und kann seine Passwörter jederzeit wieder aus dem Programm bekommen.

Was Revelation noch nicht kann ist die Möglichkeit, ein Ablaufdatum für temporär gültige Passwörter festzulegen. Unter KeePass kann man hier Einträge ablaufen lassen und am Tag X ausgrauen bzw. löschen lassen. Dateien anhängen geht auch nur begrenzt, z.B bei der Vorlage Schlüssel. Weiterhin läuft das Programm nur unter Linux. Will man die Daten auf verschiedenen Plattformen verwenden, muss man vorher zuerst in das passende Format exportieren.

Auto-Type, was beim im letzten Artikel vorgestellten Sleutel nicht ging, ist in Revelation zwar verfügbar, allerdings in einer etwas anderen Weise. Hierfür einfach folgenden Befehl ausführen:

$ gconftool-2 --set --type bool /apps/revelation/clipboard/chain_username true

Konsolen-Verweigerer können natürlich auch den grafischen Dialog unter Bearbeiten->Einstellungen bemühen. ;-)

Anschließend wird, wenn man die Funktion Passwort kopieren aufruft zuerst der Nutzername in die Zwischenablage kopiert. Auf einer Webseite fügt man ihn in das Benutzernamen-Feld ein, Revelation merkt das und kopiert das Passwort in die Zwischenablage, welches man dann ins Passwort-Feld kopieren kann. Halbautomatisch also.

@ucn|: Danke nochmal für den Tipp! :-)

Getaggt mit , , ,

Sleutel – Cross-Plattform Passwort-Manager

Passwörter sind so eine Sache. Jeder weiß, dass sie möglichst lang sein sollten, dass man sie nicht als Haftzettel an den Bildschirm kleben sollte und dass für jeden Account ein eigenes her muss. Regelmäßige Änderungen sind auch ganz sinnvoll.

Doch es fällt vielen Leuten schwer diese Regeln auch alle einzuhalten, weswegen viele zu Passwort-Managern greifen. Dabei werden alle Passwörter in einer Datenbank gespeichert, die mit einem möglichst komplexen Master-Passwort verschlüsselt wird.

Ein Programm, welches dies erledigt, ist Sleutel. Das Wort kommt aus dem Niederländischen und heißt Schlüssel. Sleutel ist ein Java geschrieben und setzt auf der Rich Client Plattform von Eclipse auf, weswegen es unter Linux, Windows und auf dem Mac funktioniert.

Leider ist Sleutel noch nicht als Ubuntu-Paket verfügbar, weswegen es manuell installiert werden muss. Man lädt sich das tar.gz-Archiv von der Projektseite herunter und entpackt es mit:

$ tar -xzvf sleutel-1.0-linux.gtk.x86.tgz
$ cd sleutel

Nun muss die Binärdatei ausführbar gemacht und gestartet werden:
$ chmod +x sleutel
$ ./sleutel

Nun kann mit File->New->New Password Entry ein neuer Eintrag angelegt werden.

Wie ihr seht, ähneln die Felder in etwa denen von anderen Passwort-Managern, wie etwa KeePassX. Allerdings kann man hier zusätzlich noch eine Geheimfrage hinzufügen, was in KeePassX nicht geht. Weiterhin können Einträge in Labels organisiert werden, was in etwa den Kategorien in KeePassX entspricht. Ein Passwort-Generator und ein Papierkorb sind auch mit an Bord. Eine Auto-Type-Funktion fehlt aber noch.

Die Einträge werden dann über eine Triple-DES-Verschlüsselung in einer XML-Datei abgelegt. Negativ aufgefallen ist mir, dass Sleutel offenbar seine Einstellungen im Programmverzeichnis ablegt oder sonst irgendwie auf sein Programmverzeichnis schreibend zugreift. Installiere ich Sleutel über

$ sudo tar -xzvf sleutel-1.0-linux.gtk.x86.tgz -C /opt

so beleibt er beim Laden hängen. Mit root-Rechnen läuft er allerdings dann. Eigentlich sollte längst bekannt sein, dass auf modernen Betriebssystemen normalerweise nicht als root gearbeitet wird. Hier sollte Sleutel wie Eclipse arbeiten und seine Einstellungen in ~/.eclipse bzw halt ~/.sleutel ablegen. Ansonsten dürfte es auch schwer sein ein Ubuntu-Paket zu bauen. Somit schon fast ein K.O Kriterium.

Besser als bei KeePassX ist die einheitliche Datenbank. KeePassX ist eigentlich ein Fork von KeePass 1, was mittlerweile schon als KeePass 2 weiterentwickelt wurde. KeePass 2 benutzt eine andere Datenbank als KeePass 1 und KeePassX sowie iKeePass und die zahlreichen anderen Forks. Außerdem ist KeePass 2 in .NET und KeePassX in Qt implementiert, was einen Codeaustausch wohl erschwert. Sleutel hingegen ist ein und dieselbe App auf jeder Plattform mit derselben Datenbankstruktur.

Am Ende läuft es wieder auf dasselbe hinaus: Jedes Programm ist anders und hat seine Vor- und Nachteile. Ich persönlich werde weiterhin auf KeePassX setzen und auf iKeePass für das iPhone warten (wo Apple derzeit leider bei der App Store Freigabe Probleme macht).

Wenn jemand noch einen Favoriten hat, dann ab damit in die Kommentare :-)

Getaggt mit , , ,

Erster Wurm fürs iPhone im Umlauf

Wer seinem iPhone oder seinem iPod touch einen Jailbreak verpasst hat, der wird wahrscheinlich auch einen Paketmanager wie Cydia benutzen. Beim ersten Start wird man gleich erstmal mit einem Auswahlfenster konfrontiert:

Cydia_Filters

Diese Modiauswahl hat natürlich einen Grund. Zwar bekommt man im Hacker- oder Entwickler-Modus mehr Pakete zur Auswahl gestellt, doch dies sind zusätzlich zu den grafischen Programmen auch Konsolenanwendungen oder auch Serverdienste. Einer dieser Serverdienste ist SSH. Mit SSH kann man über das Internet mittels einer verschlüsselten und authentifizierten Verbindung einen Rechner fernwarten. Dies ist vor allem für Serveradmins sehr nützlich und hat sich deshalb sehr gut etabliert. Allerdings lässt sich jedes Werkzeug auch missbrauchen und das ist beim iPhone jetzt passiert.

Das Betriebssystem von iPhone und iPod touch basiert genau wie der große Bruder Mac OS X auf BSD, einem Unix-Derivat. Und wie jedes Unix-Betriebssystem hat auch das iPhone einen Root-Account welcher per Default mit dem Passwort alpine geschützt ist. Das bedeutet: Jeder kann sich auf eurem iPhone einloggen und alles damit tun was er will, wenn ihr OpenSSH installiert und das Passwort nicht geändert habt.

Man möchte meinen, dass jeder, der SSH auf dem iPhone nutzt, ja entweder Hacker oder Entwickler ist und demnach wissen sollte, dass es keine gute Idee ist, einen Serverdienst mit Standard-Passwort laufen zu lassen ;) . Dem scheint aber nicht so zu sein. Wie apfeltalk.de berichtet, ist ein Wurm, der diese “Lücke” ausnutzt, bereits im Umlauf. Dabei geht der Wurm ganz simpel vor. Er scannt erstmal im WLAN-Netz nach weiteren iPhones (soll im Netz von amerikanischen Unis sehr erfolgreich sein) und versucht dann, sich über SSH auf dem Standard-Port 22 mit Benutzernamen root und Passwort alpine anzumelden. Ist dies erfolgreich, legt der Wurm eine Kopie von sich auf dem infiziertem Gerät ab welches daraufhin versucht weitere Geräte zu infizieren. Ein ganz normaler Wurm eben.

Doch gegen sowas gibt es Abhilfe. Es ist einfach eine Konfigurationssache. Zuerst einmal sollte man überprüfen, ob OpenSSH auf dem iPhone überhaupt installiert ist. Dies erreicht man, indem man in Cydia unter Verwalten auf Pakete geht und nach OpenSSH sucht. Braucht man den Dienst sowieso nicht, so kann man ihn auch gleich deinstallieren (und dadurch weniger Angriffsfläche bieten). Wenn man ihn braucht, dann sollte man schleunigst die Passwörter der Benutzer root sowie mobile ändern.

Am besten geht dies, in dem man eine SSH-Verbindung zum iPhone herstellt. Die IP kann man unter Einstellungen->Wi-Fi-Netzwerke->SSID des Netzwerks->IP-Adresse herausfinden. Dann kann man unter Linux und Mac OS X übers Terminal und unter Windows mit Putty die Verbindung zustandebringen:

$ ssh mobile@ip-des-iphones

Nach dem akzeptieren des Schlüssels und der Eingabe des Standard-Passworts ist man als Benutzer mobile auf dem iPhone eingeloggt. Mit
$ passwd mobile

lässt sich nun das Default-Passwort für den User mobile, unter dem die grafischen Programme laufen, ändern. Nun noch die Prozedur für root. Mit
$ su

öffnet sich eine root-Shell. Wieder mit dem Default-Passwort alpine erlangt man root-Rechte im Systen. Den nächsten Befehl kann man sich nun denken:
# passwd root

Nach einem zweimaligen
# exit
$ exit

wird die Verbindung unterbrochen und euer iPhone ist ein großes Stück sicherer geworden.

Getaggt mit , ,

Pidgin speichert Passwörter unverschlüsselt

Bekannte Linux-Desktopumgebungen wie GNOME oder KDE bieten ja beide die Möglichkeit an, Passwörter in einem sogennanten Keyring abzulegen, welcher verschlüsselt ist. Pidgin nutzt diese Möglichkeit jedoch nicht:

pidgin_passwoerter

Unter ~/.purple legt Pidgin seine Einstellungen im XML-Format ab – was ja nichts ungewöhnliches ist – leider steht in der Datei accounts.xml das Passwort von jedem in Pidgin eingegebenen Konto im Klartext drin. Besser wäre es, Passwörter wie oben besagt im Keyring abzulegen oder zumindest den Nutzer darauf hinzuweisen. #fail

Getaggt mit , ,

PrivaCy Opt-Out

In letzter Zeit gab es ja ziemlich viel Wirbel um Dienste wie Pinch Media, welche es iPhone-Entwicklern erlauben allerhand Daten über die Nutzer zu sammeln. Darunter fallen nicht nur Daten über die genau Dauer der App-Nutzung, sondern auch die aktuelle GPS-Position oder dass per Facebook Connect ermittelbare Geschlecht und das Geburtsdatum.
Um solchen Diensten einen Riegel einen vorzuschieben, kann man entweder über /etc/hosts die Domains der entsprechenden Firmen auf localhost umleiten, oder dafür das in Cydia erhältliche PrivaCy nutzen. Über Settings.app. kann man so einfach per Slider die Dienste blockieren.

privacyoptout

Getaggt mit ,

Firefox 3.5 Updates unter Ubuntu 9.04

Sowohl der Firefox 3.0 und der Firefox 3.5 liegen in den Ubuntu-Quellen. Allerdings liegt nur 3.0 im Main-Bereich und wird daher vom Ubuntu-Security-Team offiziell unterstützt. Gerade eben ist nämlich ein Update für den Firefox 3.5 erschienen, welches eine kritische Sicherheitslücke in der Just-in-Time Komponente der JavaScript-Engine schließt. Ich warte und warte und warte und das Update auf Firefox 3.5.1 erscheint nicht in Universe. Ich habe daher die Mozilla-Security-Quelle genutzt. Der Key:

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7EBC211F

Und die Quelle:

deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu jaunty main

Danach lässt sich Firefox 3.5.1 über die Aktualisierungsverwaltung installieren.
Edit: Hier ein Artikel von Linux und Ich, welcher sich ausführlich mit Firefox 3.5 unter Ubuntu beschäftigt.

Getaggt mit , ,

Wichtiges Security Fix für Flash

Adobe hat soeben ein wichtiges Sicherheitsupdate für den Flash Player veröffentlicht. Der Flash Player updatet sich eigentlich automatisch, allerdings macht er das defaultmäßig nur alle 30 Tage. Daher sollte man das Update von hier manuell für alle Browser einspielen; z.B besitzt der Internet Explorer ein eigenes (ActiveX-)Plugin, dass seperat aktualisiert werden muss. Danach sollte man im Einstellungsmanager von Flash den Update-Intervall zur Sicherheit auf 7 Tage runterdrehen. Sowas sollte eigentlich schon von Haus aus eingestellt sein, schließlich ist Flash von fast allen Internetusern installiert und im Browser aktiviert und stellt deshalb meiner Meinung nach ein lukratives Angriffsziel da.

Getaggt mit

Google vs Malware

Google sorgt sich sehr um die Sicherheit unserer Rechner. Anscheinend zu sehr.

Googles Antiviren-Wut

Googles Antivirenwut_iPod

Diese Website kann ihren Computer beschädigen heißt es auch bei Googles eigenen Seiten. Ich habe es mit verschiedenen Rechnern ausprobiert und überall kam die selbe Meldung. Mittlerweile scheint das Problem jedoch behoben zu sein und ich kann die Google-Suche wieder normal benutzen ohne beim anklicken von Ergebnissen auf eventuelle Risiken hingewiesen zu werden.

Getaggt mit ,
Follow

Bekomme jeden neuen Artikel in deinen Posteingang.