Heute entdeckte ich ein nettes Warnschild:
Der Inhalt wird bei Einbruch und Diebstahl vernichtet?
Die Frage die sich nun stellt ist ob der Inhalt bei einem Einbruchsversuch automatisch vernichtet wird, oder ob nur ein Mitarbeiter informiert wird, der das ganze vornehmen muss? Und dann gibt es natürlich noch die dritte Möglichkeit, das es sich einfach um einen schönen Aufkleber ohne Funktion handelt.
Vor einigen Tagen kam die Version 2.0 der Anwendung Outbank heraus. Dabei handelt es sich um eine Banking Software für Mac OS X und iOS. Allerdings hatte sich in die Version ein schwerer Fehler eingeschlichen. So wurde das Passwort welches zu lokalen Verschlüsselung der Daten benutzt wird, im Klartext in die „system.log“ geschrieben, was dann im Beispiel so aussieht:
Jan 17 09:17:03 delphi.localdomain OutBank[537]: Open Store:Core Data key:123456->abcdefghijklmnopqrstuvwxyzABCDEF
Neben diesem Problemen hatte die erste Version dank iCloud Synchronisierung auch mit Problemen wie doppelten Umsätzen und ähnlichem zu kämpfen. Problematisch an dem Fehler im Log ist auch das Mac OS X von Zeit zu Zeit das ganze archiviert und es so dazu kommen kann, das dieses Passwort an mehreren Stellen zu finden ist. Das gleiche trifft auch auf die Kombination mit Backupsystemen wie Time Machine zu. Um nach dem Update auf Outbank die entsprechenden Logeinträge zu entfernen wird von „stoeger it“ folgende Zeile empfohlen welche man im Terminal ausführen sollte:
sudo -i -- 'cd /var/log && grep -vE "OutBank\[" system.log > system.log.clean && mv system.log.clean system.log && if [[ -f system.log.0.bz2 ]]; then for a in system.log.*.bz2; do bunzip2 $a && grep -vE "OutBank\[" ${a%.*} > ${a%.*}.clean && mv ${a%.*}.clean ${a%.*} && bzip2 ${a%.*} ; done; fi; rm -f /var/log/asl/*.asl'
Witzig sind in diesem Zusammenhang Aussagen von Tobias Stöger aus der Zeitschrift SFT (Spiele | Filme | Technik) wo er auf die Frage ob Outbank sicher ist unter anderem wie folgt antwortet:
Der Artikel bezog sich mal wieder auf das unsichere Android-OS. […] Hinzu kommen noch unsere Sicherheitsmaßnahmen, wie automatische Passwortsperre oder verschlüsselte Datenbank.
Das war dann wohl ein Fall von pauschaler Aussage zum falschen Zeitpunkt. Natürlich stellt sich die Frage warum (wenn auch nur für Debugzwecke) Passwörter überhaupt im Klartext gespeichert werden. Auch war keine Auskunft zu erhalten ob die neue Version von Outbank die Bereinigung der Dateien selber vornimmt. Zur Sicherheit sollte man dies also auf alle Fälle manuell nachholen und anschließend das entsprechende Passwort ändern.
Weitere Informationen gibt es unter:
http://www.outbank.de/outbank-os-x-mac-sicherheitshinweis-zu-version-2-0-0/
http://www.heise.de/mac-and-i/meldung/Outbank-2-mit-Passwort-Leck-1786837.html
Vor einiger Zeit schrieb ich einen Artikel darüber wie man ein verschlüsseltes Verzeichnis in der der Dropbox mittels „Fuse4X“ und „EncFS“ unter Mac OS X Lion mountet. Der Wehrmutstropfen an meiner Methode war allerdings das Spotlight nicht funktionierte. Das hängt wohl damit zusammen das Spotlight standardmäßig nicht auf die mit Fuse eingehängten Systeme zugreifen kann.
Dazu sind auch nur einige Änderungen nötig. So muss das alte Skript zum mounten:
echo ultrageheimespasswort | encfs --stdinpass ~/Dropbox/Private ~/DropboxEncrypted
durch dieses ausgetauscht werden:
#!/bin/bash #Secure EncFS Dropbox mounter by Daniel Widerin #Edited by seeseekey SOURCE=~/Dropbox/Private TARGET=/Volumes/DropboxEncrypted VOLUME_TITLE=DropboxEncrypted PASSWORD=ultrageheimespasswort ENCFS=/usr/local/bin/encfs mount | grep $TARGET >/dev/null [[ "$?" -eq "0" ]] && /usr/sbin/diskutil unmount $TARGET if [ ! -d $TARGET ]; then echo "Create new mountpoint $TARGET" mkdir $TARGET chmod 0700 $TARGET fi echo $PASSWORD | $ENCFS $SOURCE $TARGET --stdinpass -ovolname=$VOLUME_TITLE -omodules=iconv -ofrom_code=UTF-8 -oto_code=UTF-8-MAC -oallow_root -olocal -ohard_remove -oauto_xattr -o nolocalcaches
Das neue Skript basiert dabei auf einer Variation eines Skriptes von Daniel Widerin und wurde etwas vereinfacht sowie um Angaben für den Zeichensatz erweitert. Nun kann man sich das ganze noch etwas bequemer machen, indem man das entschlüsselte Verzeichnis gleich beim Login einbindet. Das Skript sollte dabei einen Namen nach dem Schema „encryptDropbox.command“ tragen.
Nachdem dies geschehen ist, findet man in den Einstellungen unter „Benutzer & Gruppen“ -> „Anmeldeobjekte“ den entsprechenden Punkt. Dort wird einfach das entsprechende Skript hinzugefügt und schon wird dieses in Zukunft beim Login geladen.
Weitere Informationen gibt es unter:
https://seeseekey.net/archive/9455
http://fuse4x.github.com/faq.html
http://widerin.org/blog/secure-your-dropbox
In meiner Dropbox findet sich ein mittels „EncFS“ verschlüsselter Ordner. Dieser soll natürlich auch unter Mac OS X funktionieren. Im Netz gibt es einige Anleitungen um das ganze zum laufen zu bekommen, allerdings war darunter keine die bei mir funktionierte. Um den EncFS Ordner zu entschlüsseln muss man sich folgende Software herunterladen:
Nach dem Download muss man das ganze installieren und dann benötigt man nur noch ein kleines Skript zum mounten des ganzen. In dieser Skript trägt man folgendes ein:
echo ultrageheimespasswort | encfs --stdinpass ~/Dropbox/Private ~/DropboxEncrypted
Damit kann man das ganze mounten, ohne jedes mal das Passwort eingeben zu müssen. In Verbindung mit dem gemounteten Ordner gibt es leider ein Problem, so ignoriert Spotlight sämtliche Inhalte des entsprechenden Orders.
Weitere Informationen gibt es unter:
http://www.lisanet.de/?p=128
https://seeseekey.net/archive/6102
http://sohleeatsworld.de/?x=entry:entry120505-190714
In den letzten Tagen kursierten die Passworthashs der Communities Last.fm, eHarmony und LinkedIn durch das Netz. Bei Last.fm waren dies ungesalzene MD5 Hashs die man per Brute Force in relativ kurzer Zeit zurückrechnen kann.
Das Problem ist das sobald man dies „zurückrechnen“ kann, kann man die Passwörter bei anderen Diensten (Mail, Amazon, usw.) ausprobieren und damit Schindluder treiben. In einer perfekten Welt würde zwar jeder für jeden Dienst ein extra Passwort benutzen, aber es ist nun mal keine perfekte Welt.
Noch problematischer wird das ganze wenn man die Passwörter im Klartext (siehe Update) speichert (was man definitiv nicht tun sollte). So gibt es im Norden Deutschlands eine erfolgreiche Community mit knapp 140000 Mitgliedern welche auf den Namen NB-Town hört und unter www.nb-town.de zu finden ist.
Das Problem offenbart sich sobald man einmal die „Passwort vergessen?“ Funktionalität benutzt. Daraufhin bekommt man folgende Mail:
Die Passwort vergessen? Mail
Wie man sieht wird das Passwort im Klartext gespeichert (sonst könnte es die „Passwort vergessen?“ Funktionalität nicht zurücksenden), was bei einer solchen Community fahrlässig ist. Sobald jemand an die Datenbank herankommen so hat er 140000 Passwörter + die passenden Identitäten dazu. Ein anderes Problem bei Passwörtern welche im Klartext gespeichert werden, ist immer das die Betreiber Zugriff auf diese haben und damit (theoretisch) Schindluder betreiben können.
Deshalb gilt, Passwörter immer gehasht (aber nicht mit MD5 ;)) und gesalzen speichern. Einene schönen Artikel dazu gibt es bei Heise unter http://www.heise.de/security/artikel/Passwoerter-unknackbar-speichern-1253931.html.
Update:
Die Passwörter werden in der Datenbank nicht im Klartext gespeichert, sondern AES verschlüsselt. Bei der „Passwort vergessen?“ Funktion wird der Schlüssel in der Query übergeben, so das das Passwort entschlüsselt werden kann. Man müsste als böser Mensch also an den Webserver und den Datenbankserver herankommen und um Zugriff auf die Passwörter zu bekommen.