Ist diese Passwortdatenbank sicher genug?

Na schön, ich hab eine Zeichenkette: FRSNVA+sft6V7/sv4b+ysg==

Und ich weiß, dass es mit base64 , mcrypt_ecb MCRYPT_3DES verschlüsselt worden ist.

Wie einfach ist es dies zu knacken?

Wenn man Zugang zum Server hat, eben sehr einfach, dein Skript tut es ja auch.

Deine Frage sollte daher statt "wie gut sind die Daten verschlüsselt" eher sein:
Wie sicher ist mein Server geschützt vor unberechtigten Zugriffen.

Und diese Frage wirst du nicht mit "absolut" beantworten können.

Vielleicht sollte ich noch mal erläutern, worauf ich hinaus will:
Etwas verschlüsseltes kann man entschlüsseln, ein hash jedoch nicht.

Um sich zu authentifizieren, ist es nicht notwendig, irgendwo das Passwort(verschlüsselt) zu Speichern.
Du speicherst lediglich einen hash aus dem Passwort.
Bei der Anmeldung prüfst du den Hash des eingegebenen Passwortes gegen den in der DB gespeicherten Hash.
Sind beide identisch, war es ein korrektes Passwort.

Dies ist der Grund, warum du bei den meisten Diensten, welche ein Authentifizierung verlangen, bei einem vergessenen Passwort nicht die Möglichkeit hast, dieses PW genannt zu Bekommen...es ist nirgends gespeichert.

Jemand könnte die tutorials.de-Datenbank hacken.
Er hätte keine Möglichkeit, die Passwörter zu Entschlüsseln, weil sie einfach nirgends in irgendeiner Form gespeichert sind.
 
Wenn man Zugang zum Server hat, sehr einfach, dein Skript tut es ja.

Deine Frage sollte daher statt "wie gut sind die Daten verschlüsselt" eher sein:
Wie sicher ist mein Server geschützt vor unberechtigten Zugriffen.

Und diese Frage wirst du nicht mit "absolut" beantworten können.

Da hast Du natürlich Recht, das kann man nie ausschließen! Schließlich habe ich mit meinen laienhaften Wissen es auch geschafft mit NAVICAT eine Verbindung zu meinen Datenbanken bei Strato herzustellen, obwohl das nach übereinstimmenden Aussagen des Support's unmöglich ist.

Dann mal eine ketzerische Frage, ist hier im Forum jemand in der Lage diese Zeichenfolge zu entschlüsseln?

FRSNVA+sft6V7/sv4b+ysg==

Wenn ja, dann ist mein Vorhaben zum Scheitern verurteilt :(
 
Sven Mintel hat gesagt.:
das generelle Problem bei dieser Variante ist, dass du das Passwort überhaupt speicherst(ob nun verschlüsselt oder nicht, ist egal).

Gumbo hat gesagt.:
Und vergiss beim Hashing nicht einen Salt zu verwenden.

Ich schmeiß mal eine ganz junge Idee von mir in die Runde passend dazu. Zwei Tabellen:

userID:
uniqueID, Name

Hierbei wird uniqueID für alle Aktivitäten und Relationstabellen des Benutzers verwendet. Name ist demnach selbstverständlich ebenfalls ein Unikat (und "nicht Case-Sensitive").

userLogin:
ID, Hash

Eine nichts sagende ID mit einem Hash aus Passwort und Name gleichzeitig. Dieser wird stets beim Eintragen auf Einzigartigkeit in der gesamten Tabelle geprüft, damit es keine Überschneidungen gibt. Somit gibt es keinen universellen Salt mehr, sondern der Benutzername ist der Salt. Das klingt erst gut, jedoch ist es genau das gleiche wie die übliche Benutzertabelle wo Name und Passwort direkt nebeneinander stehen, sofern der Angreifer den Algorithmus der Verschlüsselung kennt. Synthese: Das Passwort müsste teil der Verschlüsselung sein. Dies ist zwar Möglich jedoch sehr rechenintensiv mit jedem Login: O(n²) mit n = Anzahl Benutzer.

Viel wichtiger ist also die Frage: Wie verhindere ich, dass jemand an meinen Algorithmus kommt?
 
Zuletzt bearbeitet:
Das ist doch nicht wahr :(

Ich bin schockiert!

Hast Du vielleicht auch noch den Schlüssel dazu?

Sicher ist also, dass nichts sicher ist!

Das hast du doch alles hier geschrieben...
Code:
base64_decode(mcrypt_ecb (MCRYPT_3DES, $schluessel, base64_decode('FRSNVA+sft6V7/sv4b+ysg=='), MCRYPT_DECRYPT))
fertsch.

Wenn niemand auf deinen Server kommt, weiss er nicht
1.was er entschlüsseln soll
2. wie er es entschlüsseln soll

Kommt er auf den Server, weiss er
1. was er entschlüsseln soll(steht in der DB)
2. wie er es entschlüsseln soll(er muss nur die Verschlüsselung umkehren, und die Verschlüsselung findet er im Skript)
 
@Sven Mintel

Bei Deinem hübschen Entschlüsselungsbeispiel ist natürlich ein Schnitzer!

Du kannst es nur entschlüsseln, wenn der Algorithmus UND der Schlüssel bekannt ist!

Der Schlüssel war hier in dem Fall bekannt, normalerweise muß er in ein Formular eingegeben werden.

Somit denke ich steht (sagen wir fast) jeder vor der Tür, wenn er den Schlüssel nicht hat, selbst wenn er DB Zugriff, Algorithmus und verschlüsselte PW's hat.
 
Zurück