Diskussion:HTTP-Authentifizierung

XSA

Meiner Meinung nach wäre vielleicht eine Verlinkung zum Artikel Cross-Site_Authentication sinnvoll.

erledigt. Fürs nächste Mal: Sei mutig! --Flominator 09:52, 4. Mär. 2009 (CET)

Beschreibung Http Header

Der Link [1] ist nicht mehr erreichbar deswegen habe ich den mal entfernt. Kennt jemand eine eine andere Seite auf deutsch? Habe mal eben zwar gesucht aber nichts auf anhieb gefunden.

Form-based Authentication

Bin kein Fachmann, aber kann man die Basic Authentication tatsächlich als "häufigste Art der HTTP-Authentifizierung" bezeichnen? Ist das nicht eher FORM-Authentication? Allerdings find ich zu der gar nix in der deutschen Wikipedia, was mich auch wieder etwas verwundert... (nicht signierter Beitrag von 91.128.68.59 (Diskussion | Beiträge) 20:49, 9. Feb. 2010 (CET))

Risiken von (MD5)Hashes

Mich stört der Satz: "Ein Abhören der Kommunikation nützt einem Angreifer nichts, da sich durch die Nutzung einer Hashfunktion die Zugangsdaten nicht rekonstruieren lassen und für jede Anforderung anders lauten". Gerade MD5 hashes gellten schon längst als gebrochen. Der englische Artikel weist hier besser auf die Problematik hin: http://en.wikipedia.org/wiki/Digest_access_authentication (nicht signierter Beitrag von Jschnelli (Diskussion | Beiträge) 13:08, 28. Nov. 2011 (CET))

Dieser Abschnitt kann archiviert werden. Quassy_.DE 01:10, 19. Jan. 2014 (CET)

Link zum obsoleten RFC

RFC 2617 gilt als obsolet und wurde von einer Reihe von RFCs abgelöst. Die Links zu den aktuellen RFCs sind im Titel-Bereich von RFC 2617 verlinkt

RFC	Inhalt
RFC 7235	Hypertext Transfer Protocol (HTTP/1.1): Authentication
RFC 7615	HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields
RFC 7616	HTTP Digest Access Authentication
RFC 7617	The 'Basic' HTTP Authentication Scheme

Die neue Version der Digest Authentication (RFC 7616) erlaubt MD5 nur noch als Fallback für Kompatiblität mit alten Implementierungen und sieht SHA-256 bzw SHA-512/256 als kryptografischen Hash vor, welche derzeit als sicher gelten.

--178.11.218.47 11:25, 10. Jul. 2016 (CEST)

Beschreibung zu Browser-spezifisch

Der Artikel hat derzeit m.E. die Schwäche, HTTP-Requests ausschließlich als Browser-Requests zu beschreiben. HTTP-Requests können aber auch von Maschine zu Maschine abgesetzt werden. In diesem Fall können ebenfalls diverse Authentifizierungs-Schemata zum Einsatz kommen, d. h. diese sind völlig unabhängig von Browsern. Der Artikel müsste insofern insgesamt generalisiert werden. Die vorhandenen Browser-spezifischen Beschreibungen können in einem Unterabschnitt entsprechend eingepflegt werden. --Mkleine (Diskussion) 08:51, 10. Jan. 2020 (CET)

Der Sprung vom Browser zur automatisierten Anfrage dürfte meines Erachtens kein großer sein und dem Durchschnittsleser ist ein Browser sicher näher als Maschine-zu-Maschine-Kommunikation. (Allgemein ist HTTP ja völlig unabhängig von Browsern.) Man könnte den Artikel also wahrscheinlich gut „minimalinvasiv“ erweitern. --2A02:8108:50BF:C694:2CF7:301A:710:8BF0 21:33, 5. Jan. 2021 (CET)

"Nicht sicher".

Sollte man nicht einen Abschnitt hinzufügen, was es bedeutet, wenn ein Browser meldet, die Verbindung sei "nicht sicher" ? Welche Gefahren bestehen, wenn man eine Seite öffnet, die als "nicht sicher" gemeldet wird  ? --2003:EA:F1D:2487:9162:71A9:CAE4:A55A 10:21, 8. Apr. 2023 (CEST)

Das hat nicht direkt etwas mit HTTP-Authentifizierung zu tun, sondern mit fehlendem HTTPS. Am Ende des Abschnitts #Funktion wird HTTPS kurz erwähnt; da könnte man einen Satz ergänzen, dass heutige Webbrowser die Verbindung als "nicht sicher" kennzeichnen, wenn sie nicht über HTTPS abgesichert ist. Längere Erläuterungen passen besser in einen der Grundlagenartikel wie Webbrowser, Hypertext Transfer Protocol oder Hypertext Transfer Protocol Secure. --Matthäus Wander 12:42, 8. Apr. 2023 (CEST)