Hallo liebe MyBBler!
Wir hatten unlängst eine Sicherheitsüberprüfung, bei der auch unser mybb-Forum unter die Lupe genommen wurde. Dabei ergab sich die Frage, ob der loginkey, der ja nach erfolgreichem login als Cookie gesetzt wird (als Kombination aus uid und loginkey) auch verschlüsselt in der Datenbank gespeichert werden kann?
Falls es einem Eindringling gelingt, die Datenbank zu knacken, ist es momentan möglich, die Identität eines Benutzers zu übernehmen, ohne dessen Passwort kennen zu müssen, da der loginkey im Klartext abgelegt ist! Es wäre für uns also sehr wichtig, den loginkey verschlüsselt ablegen zu können! Gibt es eine Möglichkeit, das Forum entsprechend zu konfigurieren?
Und wie willst du den loginkey beim Login ans Cookie übergeben, wenn du ihn nirgends unverschlüsselt gespeichert hast?
Verstehe, das scheint nicht zu gehen. Dann anders gefragt: gibt es eine Möglichkeit, die geschilderte Problematik zu umgehen? Oder ist die Kombination aus Cookie, uid und loginkey die einzige Möglichkeit sich einzuloggen?
Grundsätzlich gibt es auch eine Möglichkeit über Verschlüsselung das ganze zu lösen. (Nicht hashen!)
Dafür eignet sich z.B. die mcrypt Bibliothek von PHP.
Damit könnte man die keys z.B. mit AES oder Blowfish verschlüsseln, und auch zur Laufzeit wieder entschlüsseln.
Die einzige Frage, die sich dann noch stellt ist, woher der Key für die Verschüsselung kommt. (Statisch in einer Datei? Dynamisch aus verschiedenen Datenbankfeldern z.B. dem Reg-Datum oder Salt des Users?)
Grundsätzlich ist es also durchaus möglich die Loginkeys verschlüsselt abzulegen. Es ist keine Kernfunktionalität, lässt sich aber ggf. via Plugin nachrüsten.
(Bevor die Frage kommt: Nein, mir ist bisher kein Plugin bekannt, das dies leistet)
Lg
Raphael
(07.05.2013, 11:19)Raphael schrieb: [ -> ]Die einzige Frage, die sich dann noch stellt ist, woher der Key für die Verschüsselung kommt.
In einer Datei ist insofern ungeschickt, dass meist erst der Webspace/Server gehackt ist. In der Datenbank ist im vorgegebenen Fall auch Quatsch, da die ja schon dem Angreifer vorliegt. Der Nutzen ist daher eher fraglich.
Ich würde bei einem Hack die Login-Keys zurücksetzen und fertig. Das ist aber meist das kleinste Problem.
Ich denke der Sinn für Inkapinka liegt vor allem im Schutz vor SQL-Injection Schwachstellen.
Zudem müsste einem Angreifer die genaue Routine sowie Bestandteile des Schlüssels bekannt sein, ehe er die Daten natürlich entschlüsseln könnte.
Wenn der Schlüssel gar aus einem zusätzlichem statischem Salt, welcher in einer Datei liegt, + konstante vorhandene Daten (Reg-Datum, Reg-IP, etc.) besteht (daraus noch z.B. ein SHA-Hash bilden), erzielt man auch eine recht große Streuung für die Schlüssel, wodurch ein erfolgreicher Brute-Force Angriff auf einen einzelnen Eintrag nicht automatisch Rückschlüsse auf die anderen Einträge zulässt.
Im Falle eines vollständigen Webspace / Server-Hacks hat man für gewöhnlich andere Probleme, als gespoofte Logins.
SQL-Injections sind nach wie vor ein gängiger Angriffsvektor. Wenn nicht durch den durchaus robusten MyBB-Core bereitgestellt, können immernoch Plugins (Eigenentwicklungen oder bereitgestellte) eine diesbezügliche Schwachstelle darstellen.
Zudem muss eine entsprechende Injection nicht einmal über das Foren-System erfolgen, sofern dieselbe Datenbank von mehreren Applikationen des Webspaces verwendet wird.
Meiner Meinung nach ist es daher durchaus sinnvoll diese Daten verstärkt zu schützen.
Wenn man das ganze noch auf die Spitze treiben möchte, könnte man die Verschlüsselungsroutine auf einen zweiten Webspace-/Server auslagern, welcher über ein entsprechenden Request die verschlüsselten/entschlüsselten Daten zurückgibt. (Der Server lässt dabei via Firewall-Regeln oder .htaccess-Regeln ausschließlich Requests von der IP der Foreninstallation zu).
Damit hätte der Angreifer selbst bei einem erfolgreichen Hack dieses einen Servers keinen Zugriff auf die Verschlüsselungsroutine. Das geht allerdings zu Lasten der Seitenperformance.
MfG
Raphael
(07.05.2013, 10:15)Inkapinka schrieb: [ -> ]gibt es eine Möglichkeit, die geschilderte Problematik zu umgehen?
Session mit Ablaufdatum und jedesmal neue Keys auswürfeln. Dann sind die Keys in einem alten DB-Abbild nutzlos. Obs deinen Usern Spaß macht sich ständig neu einloggen zu müssen, ist die andere Frage.
Die Datenbank muß einfach sicher gehalten werden, fertig aus.
(07.05.2013, 09:35)Inkapinka schrieb: [ -> ]Hallo liebe MyBBler!
Wir hatten unlängst eine Sicherheitsüberprüfung, bei der auch unser mybb-Forum unter die Lupe genommen wurde. Dabei ergab sich die Frage, ob der loginkey, der ja nach erfolgreichem login als Cookie gesetzt wird (als Kombination aus uid und loginkey) auch verschlüsselt in der Datenbank gespeichert werden kann?
Falls es einem Eindringling gelingt, die Datenbank zu knacken, ist es momentan möglich, die Identität eines Benutzers zu übernehmen, ohne dessen Passwort kennen zu müssen, da der loginkey im Klartext abgelegt ist! Es wäre für uns also sehr wichtig, den loginkey verschlüsselt ablegen zu können! Gibt es eine Möglichkeit, das Forum entsprechend zu konfigurieren?
Wenn jemand die Datenbank knackt und Zugriff drauf hat, kann er einfach seinen Account zum Admin machen - dann muss er nicht mal mehr eine Identität stehlen. Deine Begründung weshalb du den loginkey verschlüsseln willst, ist deshalb unkonklusiv.
Offtopic On
unkonklusiv? Gibt es das Wort. Schlag lieber noch mal nach.
Offtopic Off
Sorry ich konnte nicht anders.
(07.05.2013, 17:20)NetHunter schrieb: [ -> ]Offtopic On
unkonklusiv? Gibt es das Wort. Schlag lieber noch mal nach.
Offtopic Off
Sorry ich konnte nicht anders.
Ja, das Wort gibt es (Google mal "definition konklusiv"). Ich meinte damit, dass kein effektives Resultat erzielt werden kann. Verschlüsselung ist ja schön und gut, aber ineffizient, wenn weder die Datenbank noch die Verschlüsselungs-Routine sicher ist.