Hallo Apollonius.
Zitat von
Apollonius:
Darf ich ein paar Verbesserungsvorschläge machen?
Ja, gerne.
Zitat von
Apollonius:
Dann macht es auch nichts mehr, wenn SessionID oder SecretKey bekannt werden.
Der "SecretKey" (dieser Begriff wäre dann ja eigentlich durch die neue Technik veraltet) ist ja nichts geheimes mehr. Er darf ja auch im Verlauf des Zielrechners bleiben. Nur in Kombination mit der dazugehörigen SessionID ist er eine Bombe
. Die SessionID kommt aber eigentlich nur ans Tageslicht, wenn die Antwort des Initialisierungsrequests mit einem
TCP/
IP-Sniffer mitgeschnitten wurde. Und im Falle eines Hackangriffs (durch Spionagesoftware auf dem Zielrechner) würde ein Keylogger das Passwort des Account-Managers ja bereits erfassen.
Zitat von
Apollonius:
Der Nachteil an diser Methode (bei deiner allerdings auch), ist, dass der Server die Passwörter im Klartext speichern muss.
Falsch. Bei meiner Methode mit dem verschlüsselten SecretKey und der geheimen serverseitigen einmaligen SessionID bekommt das PHP-Script zwar durch das Entschlüsseln kurzzeitig das Klartextpasswort, verfährt dann jedoch weiter wie bei einem
HTML-Loginformular. Es wird MD5(Klartextpasswort)=DatenbankMD5Passwort abgeglichen. Mein System speichert die Passwörter in MD5-Form in der Datenbank.
Zitat von
Apollonius:
Verschlüssele nicht die Daten, sondern hashe sie.
Leider scheint deine Idee mit dem Hashen nichts für mein System zu sein. Da das Klartext-Passwort nicht bekannt ist, bringt mir die Informationen SecretKey=Hash(SessionID+Klartextpasswort) und SessionID nichts.
Zitat von
Apollonius:
(dann muss der Server nicht alles durchprobieren - das ist ineffektiv)
Das mit der Ineffiktivität und der leicht erhöhten Serverlast (jedoch werden ja nur soviele SessionIDs durchprobiert, wie gerade Loginanfragen pro Minute reinkommen sind) sowie die Kollissionen bei dem Entschlüsseln mit dem Delimiter bleiben weiterhin ein Problem.
Gruß
blackdrake