Guten Morgen,
ich habe ein PHP Script geschrieben, welches aus den Logindaten eine
verschlüsselte JSON Date erstellt und wollt emal fragen, ob ich es
grundsätzlich richtig (oder zumindest nicht gänzlich falsch) mache:
User-Login:
Nach dem Login gibt es also eine ID und ein Passwort in der Session, mit
denen dann die Datei aufgerufen und entschlüsslt wird.
Der Aufruf der secure() Funktion:
Generell sollte zumindest bei der Session noch ein nur für diese Session
gültiger Salt-String mit rein, um erstens das Passwort nicht ganz so
leichtfertig preis zu geben und zweitens wenigstens etwas gehen
Replay-Attacken zu tun.
Das ist natürlich schlecht für deinen Ansatz, der die ID aus Namen und
Passwort generiert, aber da bin ich mir auch ziemlich sicher, dass ich
das nicht so machen würde.
Das ist natürlich nur meine Meinung und kein "guter Rat", denn sowas ist
ein heißes Thema. Es kommt immer darauf an, gegen wen Du die Daten
schützen möchtest.
Kolja L. schrieb:
$key = hash('sha256', $key);
$init_vector = substr(hash('sha256', $init_vector), 0, 16);
du erzeugst den Key (und IV) als hash ohne "raw_output=true". Damit wird
das Ergebnis als Hexadezimal-Ziffern 0-9a-f kodiert, also sind pro Byte
im Key nur max. 4 Bit Passwort-Abhängig. ("maximal", weil evtl. vorher
das MD5 noch was wegnimmt...)
Damit schwächst du die Verschlüsselung extrem, sie ist dadurch
mindestens um den Faktor
340282366920938463463374607431768211456 schneller zu knacken. Das kann
den Unterschied zwischen "Nachmittag mit der Grafikkarte" und "Nach dem
Ende des Universums Gott um neuen Urknall bitten" machen.
Für die Anwendung Passwort -> Encryption-Key gibt's übrigens extra den
PBKDF2-Algorithmus, bei dem sich Leute mit mehr Ahnung Gedanken gemacht
haben.
https://de.wikipedia.org/wiki/PBKDF2https://www.php.net/manual/de/function.hash-pbkdf2.php
Wär schonmal um welten besser als dein einstufiges SHA. Wenn du noch
Angst vor ASIC-Minern hast, dann evtl. Scrypt. Das verwenden manche
Crypto-Währungen (Litecoin z.B), um das Minen auf ASIC/FPGA zu
erschweren.
Lukas T. schrieb:> Generell sollte zumindest bei der Session noch ein nur für diese Session> gültiger Salt-String mit rein, um erstens das Passwort nicht ganz so> leichtfertig preis zu geben und zweitens wenigstens etwas gehen> Replay-Attacken zu tun.
Im ersten Ansatz war in dem Passworthash auch noch der Timestamp des
Logins enthalten, das hielt ich für ne gute Idee und es funktioniert ja
auch, zumindest bis zum nächsten Login...
Lukas T. schrieb:> Das ist natürlich nur meine Meinung und kein "guter Rat", denn sowas ist> ein heißes Thema. Es kommt immer darauf an, gegen wen Du die Daten> schützen möchtest.
Danke und wie gesagt, den Ansatz "SessionSalt" kann ich nachvollziehen.
Für mich ist das Script als privater Link- und Passwortmanager gedacht
und da ich nicht reich&berühmt bin, müsste ich mich von jedem Angrif
wohl geehrt fühlen.
Εrnst B. schrieb:> du erzeugst den Key (und IV) als hash ohne "raw_output=true".
Danke, genau solche Hinweise sind für mich wichtig.
Εrnst B. schrieb:> Für die Anwendung Passwort -> Encryption-Key gibt's übrigens extra den> PBKDF2-Algorithmus,
Du meinst an den Stellen: