![[HaBo]](/styles/default/logoklein.png){kind=small}
Hallo zusammen,
ich hätte wie der Titel ein frage bezüglich der Speicherung von User Passwörter. Da ich mich mit Hacken/Cracken absolut nicht auskenne und nicht die Vorgehensweise kenne ist es mir nur schwer möglich ein Konzept zu erstellen. Ich bitte darum Falls ich total auf dem Holzweg zu verzeihen.
Folgende Konzepte Spukt mir das Internet vor die Füße:
Hash
Hash + Salt
Hash u. Verschlüsseln + Salt
Hash + Salt u. Verschlüsseln + Salt
Funktions Erklärung:
Ich denke Als erstes muss man sich Fragen was das Ziel ist. Für mich lautet es:
Im falle eines erfolgreichen Diebstahls sollen es die Diebe sehr Schwer haben die Passwörter und Daten der Nutzer zu verwenden.
ich hätte wie der Titel ein frage bezüglich der Speicherung von User Passwörter. Da ich mich mit Hacken/Cracken absolut nicht auskenne und nicht die Vorgehensweise kenne ist es mir nur schwer möglich ein Konzept zu erstellen. Ich bitte darum Falls ich total auf dem Holzweg zu verzeihen.
Folgende Konzepte Spukt mir das Internet vor die Füße:
Hash
Hash + Salt
Hash u. Verschlüsseln + Salt
Hash + Salt u. Verschlüsseln + Salt
Funktions Erklärung:
Hash:
Ist denke ich soweit klar man zieht die Prüfsumme mit z.B. SHA512 und Vergleicht diese.
Hash + Salt:
Man fügt dem Passwort davor danach oder mittendrin eine zufällige Zeichen Folge ein und zieht dann die Prüfsumme. Der Salt wert und die Stelle an der er eingefügt wird, wird in der DB (in den meisten Vorschlägen steht sogar in der Gleichen Tabelle) gespeichert. So ist der Wert reproduzierbar.
Hash u. Verschlüsseln + Salt
Die Passwörter werden geHasht und anschließend mit einer Methode z.B. Blowfish verschlüssel. Der Schlüssel ist ein Festwert oder über eine Formel oder generierten Zufallswerten die in Der DB oder anderer Form abrufbar sind.
Hash +Salt u. Verschlüsseln + Salt
Die Passwörter werden geHasht mit einem Salt versehen (DB speicherung) und anschließend mit einer Methode z.B. Blowfish verschlüssel. Der Schlüssel ist ein Festwert oder über eine Formel oder generierten Zufallswerten die in Der DB oder anderer Form abrufbar sind.
Ist denke ich soweit klar man zieht die Prüfsumme mit z.B. SHA512 und Vergleicht diese.
Hash + Salt:
Man fügt dem Passwort davor danach oder mittendrin eine zufällige Zeichen Folge ein und zieht dann die Prüfsumme. Der Salt wert und die Stelle an der er eingefügt wird, wird in der DB (in den meisten Vorschlägen steht sogar in der Gleichen Tabelle) gespeichert. So ist der Wert reproduzierbar.
Hash u. Verschlüsseln + Salt
Die Passwörter werden geHasht und anschließend mit einer Methode z.B. Blowfish verschlüssel. Der Schlüssel ist ein Festwert oder über eine Formel oder generierten Zufallswerten die in Der DB oder anderer Form abrufbar sind.
Hash +Salt u. Verschlüsseln + Salt
Die Passwörter werden geHasht mit einem Salt versehen (DB speicherung) und anschließend mit einer Methode z.B. Blowfish verschlüssel. Der Schlüssel ist ein Festwert oder über eine Formel oder generierten Zufallswerten die in Der DB oder anderer Form abrufbar sind.
Ich denke Als erstes muss man sich Fragen was das Ziel ist. Für mich lautet es:
Im falle eines erfolgreichen Diebstahls sollen es die Diebe sehr Schwer haben die Passwörter und Daten der Nutzer zu verwenden.
Wenn ich mir jetzt die Aktuellen Methode anschaue, gerade mit dem Salt auf den Viele schwören, wenn der Salt in der Gleichen DB liegt und Sogar in der Gleichen Tabelle (So manches CMS system hat das) dann frage ich mich ob das nicht ziemlich dämlich ist weil man den Schlüssel beim Schloss lässt.
Das andere mit dem Verschlüsseln ist das der Schlüssel meist auch in der DB aufbewahrt wird. Und wenn er im script liegt oder vom Script aus einer Datei ausgelesen wird ist dieser auch "beim Schloss".
Ich gehe davon aus das die Bösen Jungs Zugriff über eine Lücke z.B. ungeprüfte Benutzer Eingabe an Script übergeben. Sich Zugang verschaffen damit können sie eigentlich schon alles Auslesen von der Datenbank über Dateistrukturen usw.
Das andere ist wenn sie sich über die Fernwartungstools Zugangs verschlafen. Z.B. Plesk, FTP-Server, SSH usw. ist denke ich mal auch jeder versuch die Benutzerdaten zu schützen fast schon als gescheitert zu erklären.
Gerade bei großen Unternehmen wenn ich lese das Tausende/Mio an Benutzerdaten und Kreditkarten Daten geklaut wurden, Frage ich mich 1. Wie kamen die da eigentlich rann (das schreiben die nie bei) 2. Wie haben die das Eigentlich festgestellt (Log im Server oder auf dem Schwarzmarkt entdeckt)
Das andere mit dem Verschlüsseln ist das der Schlüssel meist auch in der DB aufbewahrt wird. Und wenn er im script liegt oder vom Script aus einer Datei ausgelesen wird ist dieser auch "beim Schloss".
Ich gehe davon aus das die Bösen Jungs Zugriff über eine Lücke z.B. ungeprüfte Benutzer Eingabe an Script übergeben. Sich Zugang verschaffen damit können sie eigentlich schon alles Auslesen von der Datenbank über Dateistrukturen usw.
Das andere ist wenn sie sich über die Fernwartungstools Zugangs verschlafen. Z.B. Plesk, FTP-Server, SSH usw. ist denke ich mal auch jeder versuch die Benutzerdaten zu schützen fast schon als gescheitert zu erklären.
Gerade bei großen Unternehmen wenn ich lese das Tausende/Mio an Benutzerdaten und Kreditkarten Daten geklaut wurden, Frage ich mich 1. Wie kamen die da eigentlich rann (das schreiben die nie bei) 2. Wie haben die das Eigentlich festgestellt (Log im Server oder auf dem Schwarzmarkt entdeckt)
So nachdem ich mir also über die Oben liegenden Punkte Intensiv Gedanken gemacht habe bin ich zur Folgenden Überlegung gekommen:
Ein Server gerade wenn er beim Hoster steht und nach der Anmietung nackt ist hat meist Fernwartungstools bereits Installiert. Wie Plesk oder ähnliche. Zudem ist die Firewall bis auf die Kritischen Systeme Datenbank etc. offen wie ein Scheunen Tor. Das heißt im Allgemeinen man muss der ganzen Fremdsoftware Trauen und sich auf diese Verlassen.
Die "Sichere" Methode ist wenn man die Server am eigenen Standort/Firma/Heim betreibt und durch selbst Konfiguration der Router und des Servers schon mal die Gefahr des Fremdfehlers teilweise Ausschließen kann. Es sei den man hat einen Router der Durch den Provider verwaltet wird dann ist dieser Auch eine Schwachstelle und durch ein Router -> Router -> Client am besten Auszuschließen.
Freigegebene Ports sollten nur HTTP/S und Email falls vorhanden. Konfiguration erfolgt Lokal an den Rechnern.
Die "Sichere" Methode ist wenn man die Server am eigenen Standort/Firma/Heim betreibt und durch selbst Konfiguration der Router und des Servers schon mal die Gefahr des Fremdfehlers teilweise Ausschließen kann. Es sei den man hat einen Router der Durch den Provider verwaltet wird dann ist dieser Auch eine Schwachstelle und durch ein Router -> Router -> Client am besten Auszuschließen.
Freigegebene Ports sollten nur HTTP/S und Email falls vorhanden. Konfiguration erfolgt Lokal an den Rechnern.
Ich denke mal das in einer Config Datei die Zugangsdaten liegen, diese sollte nicht direkt von Draußen abrufbar sein sondern nur über das Script an sich. (z.B. in einem Unterordner der per .htaccess gesperrt ist)
Die Methode Hash+Salt u. Verschlüsselung + Salt anwenden.
Wobei schlüssel Salts usw. in eigenen Datenbanken liegen mit jeweils anderen zugriffsdaten.
So kann ich den Zugang erschweren aber wie bereits gesagt ist wahrscheinlich so ballt auch nur eine Lücke ist alles fürn Hintern. Wenn sie Code ausführen können.
Die Methode Hash+Salt u. Verschlüsselung + Salt anwenden.
Wobei schlüssel Salts usw. in eigenen Datenbanken liegen mit jeweils anderen zugriffsdaten.
So kann ich den Zugang erschweren aber wie bereits gesagt ist wahrscheinlich so ballt auch nur eine Lücke ist alles fürn Hintern. Wenn sie Code ausführen können.
)