nicht angemeldet
Hi,
Ich beschäftige mich ja nun schon einige Zeit mit der Konstruktion und Programmierung einer halbwegs brauchbaren Bibliothek für Logins.
Ein Aspekt des "halbwegs brauchbar" ist die verschlüsselte Übertragung der Passwörter und/oder des Benutzernamens.
Nicht nur die Logindaten müssen verschlüsselt werden sondern alle Daten. Wenn nur die Logindaten verschlüsselt werden ist zwar das PW rudimentär geschützt aber die Sessioncookies und alle übertragenen Daten (deren Zugriff durch den Login geschützt wird) sind mitlesbar. Damit ist eine gesonderte Verschlüsselung der Logindaten witzlos.
Durch die Nutzung von komplexem JS (dazu gehört Crypto zweifellos) können weitere Angriffssvektoren hinzukommen z.B. XSS. So ließe sich das PW unverschlüsselt abgreifen.
Dazu habe ich jCryption gefunden.
Da hat ein Crypto-Laie ein jQuery-Plugin mit ein paar PHP-Scripten zusammengeschustert. Erst jüngst hat das Google Security Team eine kritische Sicherheitslücke darin gefunden: indirekt wurden $_POST-Eingaben ohne Escaping in einen Shell-Command eingebettet. Ein unabhängiger Security-Audit hat nicht stattgefunden. Es gibt keine automatisierten Tests, wenig Contributors, kein richtiges Changelog usw.
Da sollten alle Alarmglocken läuten. Sogar abgesehen von den gravierenden Konzeptschwächen (MITM) wäre es gefährlich das einzusetzen. Das zeigt wieder, daß schlechte Sicherheit schlimmer ist als keine Sicherheit.
Lasse ich das und verweise gleich auf https oder baue ich aus "markttechnischen Gründen" die ungeschützte Verschlüsselung in die Login-Bibliothek mit ein
Eine Loginbibliothek sollte User Authentication bereitstellen. Nicht mehr und nicht weniger. "Do one thing and do it well". Transportverschlüsselung zw. Client und Server ist eine andere Aufgabe die mit SSL/TLS umsetzbar ist, nicht mit PHP und JS.
Harry