uname hat geschrieben:Daher wäre es wohl weit sinnvoller mindestens in Webanwendungen clientseitig z.B. mit Javascript bereits irgendeine (zusätzliche) Hashfunktion über das Passwort auszuführen. Leider weiß ich nicht wie man sicherstellt, dass ein Angreifer nicht einfach diesen z.B. per POST-Request übermittelten Hash-Wert abfängt bzw. wiederverwendet. Vielleicht wäre eine Art Challenge-Response-Verfahren möglich.
Haben sich 1999 schonmal schlaue Leute gedacht.
https://tools.ietf.org/html/rfc2617 (Bitte nicht den deutschen Wikipedia-Artikel dazu lesen auch da werden Sachen fehlerhaft zitiert, die die Leute nicht verstanden haben. Der Artikel ist von jemandem geschrieben, der sein Hauptgebiet bei Basketball sieht. Aber halt Steward keine Chance da irgend was zu korrigieren.)
Digest Authentification ist bei weitem nicht state of the Art. MD5 als HMAC ist eher untauglich. (Wenn auch bis heute nicht gebrochen.) Keine Absicherung gegen replay angriffe. Schützt bis heute das Passwort solange das ordentlich ist. (Auch hier gibt es kein PBKDF2 o.ä.)
Problem ist, dass das bie heute absolut nicht verbreitet ist. z.B. im Nginx gilt das noch immer nicht als stabil. Die Browser können es aber alle.
MS hatte btw. die gleiche Idee kurz später. Nahm NTLM statt MD5-HMAC und der ist auch als preimage gebrauchen. – Nicht verwenden.
uname hat geschrieben:Ajax bietet so schöne Möglichkeiten. Kann man nicht eine Passwortverwaltung programmieren, die zwar clientseitig eine Passworteingabe erfordert, dieses jedoch nie dem Webserver mitteilt?
Auch die Idee ist nicht neu. Haben viele auch schon umgesetzt.
Das ist aber Prinzipbedingt ziemlich unsicher:
Das Problem bleibt grundsätzlich: Fast alle in der Vergangenheit bekannten Angriffe setzten voraus, dass du bereits Daten in der Verbindung manipulieren kannst. Ein entsprechender Angreifer schmeist einfach das Ajax-script weg und kann wie gehabt fortfahren. (Die oben genannte Digest Authentifizieren ist da in sofern besser, dass sie in Webserver und browser implementiert sind und über HTTP-Header laufen. XSS-Angriffe die nur zugriff auf den Inhalt des Browsers haben oder Angreifer mit lokalen Nutzerrechten (also nicht auf den Webserver sondern nur auf die Webanwendung selbst) können da dann nichts mehr ausrichten.)
Auf der anderen Seite: Für die Angriffe, die nur lesen können schafft es abhilfe. Heartbleed war da eine berühmte Ausnahme. Für IMAP und SMTP nutze ich CRAM-MD5 statt PLAIN oder LOGIN. Deswegen musste ich danach keine Passwörter austauschen.
Dafür hast du halt zusätzlichen Code den man prinzipiell angreifen kann. Ich für meinen Teil sage: Wenn das in den Browser kommt ist es toll. (Bei Mozilla laufen da wohl ein paar ansätze in die Richtung.) Irgend welches vergleichsweise selten reviewtes oder gar selbst geschriebenes lasse ich lieber sein.