Puh, was hier denn alles diskutiert wird, es gibt schon mehrere Faktoren die ein Passwort sicher machen und andere die es leichter machen dieses zu erraten. Viele Attacken fallen aber auch schon durch Schutzeinrichtungen oder den Gegebenheiten weg.. dennoch finde ich sollte man sich mal mit den Arten der Attacken, den Möglichkeiten sich also ein Passwort zu ergreifen und den Folgen daraus bewusst sein.
Gerne könnte ich da mal für Interessierte eine kleine Liste zusammenfassen die ich so über die Jahre einfach kennen gelernt hatte insbesondere da ich mich selbst mit den Entschlüsseln und Angriffen verschiedenster Art beschäftigt habe. Aber nicht um anderen Personen zu schaden, sondern da ich mich als Website-Betreiber (schon etwas länger her - eine etwas größere Community) selber dazu verpflichtet gefühlt habe mir da keine Fehler zu erlauben. Und weil ich mich auch selbst gerne absichere.
Zuerst sollte man mal unterscheiden wie man Zugriff (an das Passwort/den Account) erlangen kann.
Account
Session Hijacking
Ist der User im selben Netzwerk wie sein Angreifer so kann man bei unverschlüsselten Verbindungen (z.B: HTTP ohne gesicherte VPN) teilweise die Sessions/Cookies mitschneiden und somit sich als der User einloggen, dies zählt zumindest so lange wie die Session gültig ist. Natürlich könnte sich der Angreifer als User eingeloggt das Passwort/E-Mail (für PW-Recovery) zurecht rücken. Aber zum Schutz dagegen verlangen viele Portale nochmal das aktuelle Passwort, obwohl man doch bereits eingeloggt ist. Somit ist die Attacke recht unattraktiv aber doch nützlich weil Sie schnell und einfach funktioniert, nur an ein Passwort kommt man so nicht.
Cross-Site-Request-Forgery
Einen User wird ein Link untergeschummelt (eventuell hinter einen Short-Link) der vom Angreifer gewünschte Aktionen durchführt, dies kann oft per Tokens oder im Script selbst (POST/GET/REQUEST) serverseitig unterbunden werden. Ganz simples - aber in MyBB nicht funktionierendes - Beispiel wäre jemand versteckt hinter einem Short-Link die URL member.php?action=logout und man klickt nichts-ahnend darauf - in dem Fall würde der Logout Key fehlen der mit den Login-Key generiert wird. Aber generell ist dies ebenfalls eine Technik die man anwenden kann insbesondere bei Formularen die Daten per URL-Adresse übertragen.
Die ganze Technik selbst kann auch in Zusammenhang mit Cross-Site-Scripting angewendet werden - dazu später mehr.
Datenbank
In den seltenen Fall, dass jemand die Datenbank (zum Teil) kapert, kann er natürlich ebenfalls entweder direkt aktuelle Session-ID bekommen oder aber eine eigene generieren (bei direkten Zugriff). Somit kommt er natürlich ebenfalls am Account - und vieles mehr, dazu aber später dann mehr unter Passwort.
Passwort
Bruteforce
Tja was soll man sagen, eine Presshammer-Methode, meist wird dies per vollautomatischen Script erledigt, es werden einfach random generierte Passwörter genommen und diese eins nach dem Anderen versucht. Diese Methode wird gerne per maximale Versuche oder aber mit einem zusätzlichen Captcha ab x Versuchen unterbunden. Dennoch kann die Attacke mit kleineren vorgefertigten Listen die nach und nach über mehrere Tage abgearbeitet werden, sehr erfolgreich sein. Insofern der Betreiber nicht die Zugriffsversuche mitloggt und selbst reagiert.
Keylogger
Diese gibt es sowohl in Hardware als auch Software-Form. Also entweder wird einem eine Schadsoftware untergeschummelt die jeden Tastendruck mitloggt - oder aber es wird eine Hardware z.B. kleiner USB-Keylogger zwischen Keyboard und USB angesteckt (natürlich physischer Zugriff notwendig). Nutzt ein Benutzer natürlich immer automatischer Login bringt diese Form der Attacke natürlich nicht viel, denn der Nutzer muss das Kennwort wirklich eintippen. Hiergegen gibt es auf manchen Seiten sogar PIN-Felder bei denen man per Mausklicks ein PIN-Code zusätzlich zum Passwort eingeben muss, denn wenn nur die Tastatur gesnifft wird bringt einem das Passwort auch nicht mehr viel wenn dahinter noch ein PIN-Code steckt. Damit ein Maus-Sniffer ebenfalls wenig bringt werden die Zahlfelder manchmal zufällig platziert generiert.
Cross-Site-Scripting
Bei dieser Art der Attacke muss es einem möglich sein zumindest HTML in irgendeiner Form ins Forum einzubinden. Ungefiltert kann man so JavaScript ausführen lassen und folglich Cookies auslesen (insofern nicht geschützt) oder Inputs/Felder auslesen, dies kann auch codiert sein sodass es durch diverse Filter durchrutscht - letztlich kann dies aber Serverseitig unterbunden werden. Daher ist es auch nur zu empfehlen sowohl auf Seiten als auch bei Plugins wirklich nur vertrauenswürdige JS-Dateien einzubinden, liegen Sie extern ist dies schon eine Gefahrenquelle, da diese nachträglich modifiziert werden könnten - egal ob vom Besitzer oder von einem Angreifer, manchmal sind Drittserver leichter zu kapern als die Server auf die die Website betrieben wird.
Datenbank
Hierbei bekommt der Angreifer entweder temporär (z.B. Sicherheitslücke (SQL Injection)) oder kompletten Zugriff auf die Datenbank und kann somit z.B. User-Datensätze auslesen. Somit bekommt er sämtliche User-Daten, allerdings das Passwort nur in einer gehashten Form mitsamt den notwendigen Salt - insofern vorhanden. Um dies nun zu verstehen muss man leider etwas weiter ausholen:
Passwörter werden generell nie in Klartext gespeichert, damit Sie sowohl für Betreiber als auch für Angreifer nicht ohne weiteres lesbar sind. Sie werden sozusagen in einem Einweg-Prinzip unlesbar gemacht, heißt das Klartext-Kennwort ist nicht wie bei einer normalen Verschüsselung wieder zum entschlüsseln sondern kann nur bei der Eingabe und den selben Hash-Verfahren abgeglichen werden, ist der Hash der selbe Wert so stimmt wohl das Kennwort.
Später ergänzte sich zum normalen Hash noch ein Salt hinzu, dieser soll förmlich Angreifern die Suppe versalzen. Denn zum Klartext-Kennwort wird (neben mehreren Werten) auch noch der Salt hinzugefügt und abgespeichert, dies soll verhindern, dass man eine universell einsetzbare - sogenannte "Rainbow-Table" - anwenden kann. Dazu dann später wieder mehr.
Mittlerweile gibt es nochmal zusätzliche Sicherheitsfaktoren zum Beispiel einen Site-Salt der nur am Webserver im Script direkt steht und somit bei Datenbank-Diebstahl nicht erreichbar ist. Außerdem hilft es oft schon wenn Betreiber den Hash-Algorithmus etwas abändert oder einen eigenen schreibt (Zumindest was die Zugabe von Werten betrifft).
Zum Ende noch etwas mehr Allgemeines.. weil hier schon gesagt wurde das Sonderzeichen nicht sonderlich viel bringen solange die Kennwörter lange sind, stimmt teilweise.
Dazu muss man verstehen, dass man für viele der Angriffe (Bruteforce, Hash-Decrypting etc) sogenannte Charsets verwendet (der sieht einfach so aus z.B. "abcdefgh....xyzABCDEFGH...XYZ01234...789!"§") und wird je nach Inhalt dann oft auch benannt (ALPHANUM für Alphanumerisch uvm). Und dann gibt man noch die Zeichenlänge des Kennworts ein z.B. 4-10. Je nach Charset und Länge generiert ein System eine sehr lange Liste oder eine eher kleine welches die Versuche natürlich stark einschränkt aber die Erfolgschance mindert. Gibt auch direkt die sogenannten Wörterbücher die eben wie das Wort schon sagt Listen mit Kombinationen aus verschiedenen Wörtern beinhaltet.
Die meisten Rainbow-Tables beinhalten lange Kennwörter mit a-Z0-9 oder eher kürzere mit a-Z0-9 + verschiedenen Sonderzeichen. Also ein langes Kennwort nur mit Kleinbuchstaben muss nicht unbedingt sicherer sein als ein kürzeres Kennwort mit Sonderzeichen. Der Angreifer muss den Nutzer auch etwas abschätzen können um hier einzugrenzen. Daher sollte man auch nie die ungefähre Länge / Inhalte eines Kennworts verraten, so könnte der Angreifer schon einmal die Suche stark einschränken.
Nichts desto-trotz, dies gilt nur in diversen Szenarien und die größeren davon sind Bruteforce (welcher bei uns durch Captcha abgesichert ist) und den sehr unwahrscheinlichen Fall das jemand Datensätze aus der Datenbank bekommt (Welches zumindest die zuvor genannten Salts verwendet) somit müsste für jeden Nutzer & Salt eine komplett eigene Rainbow-Table generiert werden, welches einfach zu aufwändig wäre.
So das war mal so grundsätzliches ich habe sicher genug vergessen (oder absichtlich weggelassen *hust*), aber ich denke so kann man auch teilweise die Hintergründe zu manch nerviger Eingabe verstehen (Aktuelles Passwort bei E-Mail/PW Änderung, Captcha nach fehlerhaften Versuchen etc).
Absichern kann man sich in vielerlei Hinsicht lange Kennwörter, Zahlen & Sonderzeichen verwenden. Two-Way-Authentication verwenden, für mehrere Portale verschiedene Kennwörter nutzen oder für nicht so wichtiges auch einfachere. Nur Dinge (z.B. Userscripts) verwenden denen man wirklich vertrauen kann und nicht blind auf jeden Link klicken den man geschickt bekommt - insbesondere Vorsicht ist bei Short-Links geboten. Aber eine richtige Paranoia muss man jetzt auch nicht schieben deswegen.
Natürlich aber auch versuchen seine Software am aktuellen Stand zu halten, gilt natürlich genauso auch für Betreiber denn durch Sicherheitslücken kann man auch mal schnell an relevante Dateien oder Aktionen gelangen.
Zu der Passwort-Debatte noch kurz wegen den Comic oder Leon's Beitrag, ich persönlich wähle ja eine Kombination aus Beiden, natürlich ohne irgendwelche persönlichen / Profilbezogenen Infos einzukalkulieren. Durch "leichter" merkbare Ketten kann man ein Passwort schnell in die Länge ziehen lassen und durch Zahlen oder Sonderzeichen kann man dann dem ganzen noch zusätzlich etwas absichern gegen die 0815 Alpha-Num Tabellen. Wo und wie man das ganze kombiniert kann jeder für sich entscheiden (Anfang-Mitte-Ende) oder man entwickelt generell eine eigene Schreibweise wodurch man schnell und effizient sozusagen sein "leichtes" Kennwort etwas "verschlüsselt", man kann ja auch 10-Finger-System dafür herhalten lassen und die "Art" etwas abändern - man muss nur kreativ sein. (Blöd dann bei der Eingabe am Smartphone
)
Ach speziell zu diesem Fall, offenbar betreibt eine gewisse Person ja ein Forum in dem er das Script/Server soweit manipuliert hat, dass er das Passwort ebenfalls als Klartext abspeichert/abrufen kann. Ich bin mir nicht ganz sicher, könnte mir aber gut vorstellen, dass dies eine Straftat wäre, aber dazu müsste man jemand befragen der sich in Deutschland mit den § auskennt und das nötige Know-How hat.