Schlagwortarchiv: osbn

Tag OSBN

Roundcube mit PGP-Unterstützung

4 Antworten

Vor Kurzem wurde Roundcube Webmail[1. Roundcube Webmail] in Version 1.2.0 veröffentlicht. Zu einer der Neuerungen zählt die Unterstützung von PGP. Dabei hat man die Wahl zwischen der client-seitigen Verschlüsselung, basierend auf der Browser-Erweiterung Mailvelope und der server-seitigen Variante mittels Enigma-Plugins.

In diesem Artikel stelle ich beide Varianten kurz vor und zeige einige Punkte auf, die beim Einsatz zu beachten sind.

Zu Beginn noch einmal kurz zur Erinnerung: OpenPGP verwendet asymmetrische Verschlüsselung[2. Asymmetrische Verschlüsselung], bestehend aus einem privaten und einem öffentlichen Schlüssel. Dabei gilt, dass der private Schlüssel unbedingt vor unberechtigtem Zugriff zu schützen ist.

Enigma-Plugin

Das Enigma-Plugin ist bereits Bestandteil von Roundcube 1.2.0. Aleksander Machniak beschreibt in seinem englischsprachigen Blog die Installation und Nutzung des Plugins.[3. Enigma plugin (PGP encryption)]

Das Plugin befindet sich demnach bereits auf dem gleichen Server, auf dem auch die Roundcube-Installation läuft. Besitzt man selbst die vollständige Kontrolle über diesen Server, ist die Nutzung des Enigma-Plugins eine komfortable Lösung.

In meinem Fall läuft der Server, welcher die Roundcube-Installation hostet, jedoch bei einem Hosting-Provider. Zwar habe ich root-Zugriff auf diesen Host, doch besitze ich nicht die vollständige Kontrolle über diesen Server. Es besteht die Möglichkeit, dass beim Provider ein Zugriff auf meinen Server und damit auch auf meinen privaten Schlüssel erfolgen kann.

Mir persönlich ist das Risiko der Kompromittierung meines privaten Schlüssels bei dieser Variante zu groß. Daher scheidet sie für mich aus.

Mailvelope

Mailvelope[4. Mailvelope Webseite] stellt über eine Browser-Erweiterung eine client-seitige OpenPGP-Verschlüsselung für Webmailer bereit. Es existieren Erweiterungen für Chrome und Firefox. Die Schlüssel werden dabei im Benutzerverzeichnis von Chrome bzw. im Profilordner von Firefox gespeichert.[5. Mailvelope – Wo werden meine Schlüssel gespeichert?] Die Chrome-Einstellung „Nutzungsstatistiken und Absturzberichte automatisch an Google senden“, sollte man jedoch besser deaktivieren. Andernfalls könnten im Falle eines Absturzes Speicherinhalte mit privaten Schlüsseln an Google gesendet werden.

Verschlüsselt man die Festplatte mit der Installation, in der sich der private Schlüssel befindet, ist dieser zusätzlich bei Verlust oder Diebstahl des Endgeräts geschützt.

Der Vorteil dieser Variante liegt in jedem Fall darin, dass sich die Schlüssel auf einem Endgerät befinden, über das der Besitzer in der Regel die vollständige Kontrolle hat. Gerade wenn die Roundcube-Installation bei einem Hosting-Provider betrieben wird, ist diese Variante daher in meinen Augen vorzuziehen.

Fazit

Dass Roundcube nun zwei Varianten zur Nutzung von OpenPGP-Verschlüsselung unterstützt, finde ich grundsätzlich positiv. Für beide genannten Varianten gibt es sinnvolle Einsatzszenarien.

In jedem Fall sollte man für einen konkreten Anwendungsfall abwägen, bei welcher Variante der private Schlüssel besser geschützt ist.

Für mich persönlich habe ich beschlossen, dass keine der beiden beschriebenen Varianten für mich in Frage kommen. Die Variante mit dem Enigma-Plugin scheidet für mich aus, da mein Mailserver bei einem Hosting-Provider betrieben wird und ich nicht die vollständige Kontrolle über den Host habe.

Die Variante mit Mailvelope kommt für mich nicht in Frage, da es mir nicht gefällt, dass die Schlüssel im Webbrowser gespeichert und verwaltet werden. Ich besuche mit meinem Webbrowser täglich dutzende Webseiten und nutze verschiedenste Webdienste. Dabei besteht grundsätzlich das Risiko, dass mein Webbrowser durch Malware kompromittiert wird. Mir persönlich ist die Gefahr zu groß, dass dabei auch mein privater Schlüssel kompromittiert bzw. entwendet wird.

Meinen E-Mail-Client verwende ich hingegen ausschließlich zum Lesen und Schreiben von E-Mails. Die Angriffsfläche ist hier wesentlich kleiner und das Risiko geringer, dass mein privater Schlüssel kompromittiert wird.

Erstellung eines Yum-Repositories

Schreibe eine Antwort

Nachdem ich im Artikel „Lokaler Spiegelserver für CentOS, Fedora und RHEL“ beschrieben habe, wie man Paketquellen auf den eigenen Server spiegeln kann, möchte ich in diesem Artikel dokumentieren, wie man ein Yum-Repository erstellt, um darüber z.B. eigene RPM-Pakete zur Verfügung zu stellen.

Auch für diesen Artikel gilt, dass es keine Schritt-für-Schritt-Anleitung ist. Weiterführende Informationen findet man unter den Links am Ende des Artikels oder in der manpage des jeweiligen Programms.

Voraussetzung dafür ist, dass wie beim lokalen Spiegelserver ein Webserver läuft, über welchen das Repository ausgeliefert werden kann. Darüber hinaus muss das Programm createrepo installiert sein, welches über das gleichnamige Paket bereitgestellt wird.

Für das eigene Yum-Repository wird ein Verzeichnis erstellt, welches vom Webserver ausgeliefert werden kann. Unter CentOS, RHEL und Fedora kann dies z.B. wie folgt erfolgen:

:~# mkdir /var/www/html/custom-rpms

In dieses Verzeichnis werden die RPM-Pakete kopiert, welche man über dieses Repository bereitstellen möchte. Anschließend wechselt man in das Verzeichnis und erstellt durch den Aufruf von createrepo die erforderlichen Meta-Daten.

:~# cd /var/www/html/custom-rpms
:~# createrepo --database /var/www/html/custom-rpms

Damit ist die Erstellung des Yum-Repositories bereits abgeschlossen.

Ergänzend kann man noch eine *.repo-Datei erstellen, um die Verwendung des Repository zu vereinfachen.

Quellen und weiterführende Links

Lokaler Spiegelserver für CentOS, Fedora und RHEL

4 Antworten

Durch die Nutzung eines lokalen Spiegelservers lassen sich Softwarepakete im lokalen Netzwerk bereitstellen. Dies schont die Internetverbindung und spart damit Bandbreite und evtl. Kosten.

Dieser Artikel beschreibt und dokumentiert die Einrichtung eines lokalen Spiegelservers für CentOS, Fedora und RHEL. Er bietet jedoch keine Schritt-für-Schritt-Anleitung. Für detaillierte Informationen wird auf die Quellen am Ende des Artikels sowie auf die manpages der einzelnen Kommandos verwiesen.

Konfiguration des Spiegelservers

Für den Betrieb eines lokalen Spiegelservers müssen ein Webserver sowie die CLI-Programme reposync und createrepo auf dem Host installiert werden, welcher als Spiegelserver dienen soll.

Hinweis für RHEL: Bei Verwendung von RHEL könnten nur jene Paketquellen gespiegelt werden, für welche der Spiegelserver eine gültige Subskription besitzt. Sollen auch solche Paketquellen gespiegelt werden, für die der Host keine Subskription besitzt, ist der Einsatz des kostenpflichtigen Satellite Servers erforderlich.

Diese Pakete befinden sich in der Regel in den Paketquellen, welche standardmäßig zur jeweiligen Distribution gehören. Für CentOS/RHEL können die Pakete zum Beispiel mit den folgenden Befehlen installiert werden:

$ sudo yum groupinstall "Einfacher Webserver"
$ sudo yum install yum-utils createrepo

Verwendet man bereits eine Fedora-Version mit dem YUM-Nachfolger DNF, so können die Pakete wie folgt installiert werden:

$ sudo dnf groupinstall "Web Server"
$ sudo dnf install yum-utils createrepo

Für eine Minimalkonfiguration des Webservers ist es erforderlich, den FQDN des Hosts als ServerName in der Datei /etc/httpd/conf/httpd.conf zu setzen.

Verwendet man die Hostfirewall, so ist der Zugriff auf den Webserver in dieser noch freizugeben.

$ sudo firewall-cmd --add-service http

Im nächsten Schritt wird unterhalb des Webserver-Wurzelverzeichnisses ein Verzeichnis erstellt, in dem zukünftig die gespiegelten Repositories abgelegt werden.

sudo mkdir /var/www/html/repomirror

Nun können mit reposync Pakete aus Online-Quellen auf den Spiegelserver heruntergeladen werden:

$ sudo reposync --gpgcheck -l --repoid= --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Die benötigte Repo-ID kann der ersten Spalte der Ausgabe von sudo yum repolist entnommen werden. Mit dem Parameter -n wird nur die aktuellste verfügbare Paketversion heruntergeladen.

Möchte man bspw. das base-Repository von CentOS spiegeln, so geschieht dies mit dem Kommando:

$ sudo reposync --gpgcheck -l --repoid=base --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Dadurch wird im Verzeichnis /var/www/html/repomirror das Unterverzeichnis base erstellt.

Damit die lokale Paketquelle nun von anderen Servern im lokalen Netzwerk genutzt werden kann, müssen noch die Metadaten mit Hilfe des folgenden Befehls erstellt werden. Beispiel für das base-Repository aus CentOS:

# cd /var/www/html/repomirror/base
# createrepo -v /var/www/html/repomirror/base/ -g comps.xml

Um den Abgleich der Paketquellen und die Erstellung der Metadaten zu automatisieren, kann folgendes Skript über den Cron-Dienst ausgeführt werden. Hier sind lediglich noch die REPO-ID und der Download-Pfad für die entsprechenden Variablen zu definieren.
#!/bin/bash
#
# Beschreibung: Skript zur Synchronisierung des RHEL-Repositories
# auf dem Spiegelserver
# Autor: Joerg Kastning <joerg(Punkt)kastning(aet)uni-bielefeld.de>

LOG="/var/log/do_reposync.log"
REPOID=" "
DOWNLOADPATH=" "

echo \# `date +%Y-%m-%d` - START REPOSYNC \# > $LOG

reposync --gpgcheck -l --repoid=$REPOID --download_path=/var/www/html/$DOWNLOADPATH --downloadcomps --download-metadata -n >> $LOG

echo \# `date +%Y-%m-%d` - END REPOSYNC \# >> $LOG
echo \# `date +%Y-%m-%d` - START CREATEREPO \# >> $LOG

cd /var/www/html/$DOWNLOADPATH/$REPOID
createrepo -v /var/www/html/$DOWNLOADPATH/$REPOID -g comps.xml >> $LOG

echo \# `date +%Y-%m-%d` - END CREATEREPO \# >> $LOG

exit 0

Erzeugung einer *.repo-Datei

Um die Paketquellen auf dem Spiegelserver zu verwenden, müssen diese auf dem Client bekannt gemacht werden. Dies geschieht zum Beispiel, indem auf dem Client eine *.repo-Datei im Verzeichnis /etc/yum.repos.d/ angelegt wird. Der Aufbau dieser Datei wird am Beispiel des CentOS-Repositories base demonstriert:

[base]
name= CentOS-$releasever - Base (local)
baseurl=http://FQDN/repomirror/base/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Legt man diese Datei auf dem lokalen Spiegelserver in einem Verzeichnis ab, welches über den Webserver erreichbar ist, kann sie von einem Client mit dem folgenden Kommando importiert werden:

# yum-config-manager --add-repo http://FQDN/repomirror/DATEINAME.repo

Besonderheit bei Verwendung von SELinux

Bei Verwendung von SELinux, müssen die Dateien noch mit dem Attribut httpd_sys_content_t ausgestattet werden. Für Dateien in /var/www/html geschieht dies mit:

restorecon -R -v /var/www/html/*

Quellen und weiterführende Links

Bash-Skript zur Aktualisierung einer Roundcube-Installation

Schreibe eine Antwort

In diesem Artikel möchte ich euch ein kleines Bash-Skript vorstellen, mit dem die Aktualisierung von Roundcube gesteuert werden kann.

Es führt ein Backup der Roundcube-Installation inkl. der dazugehörigen MySQL-Datenbank durch, lädt das TAR-Archiv der neuen Version herunter und aktualisiert die existierende Version.

Das Skript habe ich auf GitHub Gist unter der GPLv3 veröffentlicht. Ihr dürft es also gern unter den Bedingungen der GPLv3 verwenden, ändern und in eigene Projekte einbauen. Es kann auch am Ende dieses Artikels als ZIP-Archiv heruntergeladen werden.

Um das Skript nutzen zu können, müssen die vier Variablen am Anfang des Skripts definiert werden:

# Variablen
INSTALL_PATH=" " # Pfad zur Roundcube-Installation
RC_DB_NAME=" " # Name der zur Roundcube-Installation gehörenden MySQL-Datenbank
PACKAGE_URL=" " # Download-URL der akutellen Roundcube-Version
MYSQL_ROOT_USER=" " # MySQL-Benutzer mit Root-Rechten auf der Roundcube-Datenbank

Anschließend muss das Skript noch mit dem Befehl chmod a+x updating_roundcube.sh ausführbar gemacht werden.

Nun kann das Skript zur Aktualisierung der Roundcube-Installation ausgeführt werden. Getestet habe ich das Skript heute, um meine Roundcube-Installation von Version 1.0.8 auf Version 1.0.9 zu aktualisieren.

Downloads:

2017-03-25_updating_roundcube.zip

Testinstanz für einen WordPress Blog erstellen

1 Antwort

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.[1. http://www.mysqldumper.de/] Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.[2. http://www.filezilla.de/]

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.[3. http://nginx.org/]

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.[4. http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html] Nutzer von Apache können .htaccess-Dateien[5. .htaccess – Wikipedia] verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigt, kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name < db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)

Update vom 24.12.2016

Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.

Die Ursache für diese Fehler liegt darin begründet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul mod_rewrite.

Eine Lösung für dieses Problem habe ich ziemlich schnell in der Nginx Library[6. Nginx Library - WordPress Permalinks {en}] gefunden. Es wird die try_files-Direktive[7. Nginx try_files directive {en}] verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.

Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide Fälle betrachtet.

WordPress im Wurzelverzeichnis

Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter http://www.example.com, sucht man in der Konfigurationsdatei der Seite nach dem Block location /. Diesem Block wird folgende Zeile hinzugefügt:

try_files $uri $uri/ /index.php?$args;

Der vollständige Block sollte anschließend wie folgt aussehen:

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

WordPress in einem Unterverzeichnis

Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter http://www.example.com/wordpress, muss der Konfigurationsdatei ein Block nach dem Muster location /wordpress/ hinzugefügt werden, welcher wie folgt aussieht:

location /wordpress/ {
  try_files $uri $uri/ /wordpress/index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

Sichere Passwörter und wie man sie verwaltet

4 Antworten

Alle Sicherheitsexperten haben Ratschläge zur Wahl sicherer Kennwörter. Auch Zeitschriften schreiben immer wieder davon. Auch am Arbeitsplatz wird man durch Richtlinien dazu angehalten sich ein sicheres Passwort auszudenken.

Dabei haben viele Ratschläge gemein, dass die Passwörter möglichst lang sein sollen. Häufig ist von 16-20 Stellen die Rede. In keinem Wörterbuch sollen sie stehen, damit man sie nicht per Wörterbuchattacke erraten kann. Ausserdem sollen sie immer aus Zahlen, Sonderzeichen, großen und kleinen Buchstaben bestehen. And last but not least soll man für verschiedene Dienste, Programme oder Webseiten auch noch verschiedene dieser sicheren und hochkomplexen Passwörter verwenden.

An dieser Stelle kommt häufig die Frage auf, wie man sich all diese Kennwörter merken soll. Sind doch viele von uns schon überfordert sich die PIN ihrer EC Karte zu merken. Und die besteht immerhin nur aus 4 Ziffern.

Dabei ist die Lösung ganz einfach. Man kann z.B. zu einem kleinen Programm greifen, mit dem sich die Passwörter verwalten lassen. Der Clou dabei ist, dass die Kennwörter nicht einfach in einer Textdatei oder Tabelle gespeichert werden, sondern in einer verschlüsselten Datenbank, welche durch ein Kennwort geschützt ist. Nun muss man sich nur noch ein einziges Kennwort merken, welches dazu dient die übrigen Kennwörter zu schützen.

Ich selbst setze dabei auf das kostenlos erhältliche Programm KeePass Password Safe. Hiermit kann ich Benutzernamen, Passwörter und weitere Informationen übersichtlich und sicher verwalten.

Hier können sie ihre Zugänge zu E-Mail Postfächern, dem Online-Banking, Online-Shopping Seiten, Online-Auktionsplattformen, etc. pp. sicher organisieren und speichern.

Doch nicht nur bei der Verwaltung, auch beim erstellen bietet uns dieses Programm eine große Hilfe. Mit dem integrierten Passwortgenerator ist es möglich lange und komplexe Passwörter zu generieren.

Sie können die Länge und die Komplexität wie gewünscht einstellen. Wenn sie die entsprechenden Passwörter und verwenden möchten, müssen diese jedoch nicht abgetippt werden. Keepass stellt hierfür zwei Methoden zur Verfügung, um Passwörter in andere Anwendungen zu übertragen.

„Keepass bietet zwei Möglichkeiten, die Passwörter in die Zielanwendungen, wie zum Beispiel den Browser, zu übertragen. Bei der ersten werden Benutzername und Passwort nacheinander in die Zwischenablage kopiert und können so in die Anwendung eingefügt werden. Gut daran ist, dass Keepass den Eintrag nach 12 Sekunden (dieser Wert lässt sich bei den Einstellungen ändern) wieder aus der Zwischenablage löscht, und so von anderen später nicht einfach darauf zugegriffen werden kann. Bei der zweiten Möglichkeit, die weit komfortabler ist, gibt Keepass die Daten direkt in den Browser ein („Auto-Type“) wobei die Zeichenfolge, die Keepass an die Anwendung sendet, angepasst werden kann. Die Steuerung zu den Eingabefeldern findet dabei zum Beispiel mit dem Senden „Tabulatortaste“ an die Anwendung statt, die Bestätigung so zum Beispiel mit dem Senden „Entertaste“. Der Nachteil dabei ist, dass Passwörter durch Keylogger ausgespäht werden können.

Eine dritte Variante ist unter Mozilla Firefox, und allen darauf basierenden Browsern, die Erweiterung KeeFox. Das Addon stellt ein Verbindung zwischen Firefox und KeePass her. Mit den in KeePass abgelegten entsprechenden Anmeldedaten können so in wenigen Schritten Login-Sites aktiviert werden. Auch neu erstellte Login-Daten können via KeeFox in KeePass gespeichert werden.“ Auszug aus der Wikipedia – Stand 20.01.2011

Dieses kleine nützliche Programm ist kostenlos und für die gängigsten Betriebssysteme erhältlich. Es gibt auch eine protable Version, welche sich direkt von einem USB-Stick starten lässt und nicht installiert werden muss. So können sie ihre Kennwörter und PINs stehts sicher geschützt bei sich tragen. Ich hoffe sie erkennen wie einfach es sein kann sichere Kennwörter zu verwenden.

Wikipedia-Artikel
Projekt-Homepage

Update vom 18.12.2016: Neben der oben genannten Programmversion existieren auch noch Versionen für Linux und Android, welche ich hier ebenfalls mit aufführen möchte: