Diskussion:CRAM-MD5

Ich schlage vor Vor- und Nachteile gegenüber SSL einzufügen und einen Link zur SSL Seite zu machen

Authentifizierung hat nichts mit Verschlüsslung zu tun

Hm - ich denke, es gibt nicht unbedingt einen zwingenden Zusammenhang zwischen CRAM-MD5 als Authentifizierungsverfahren und SSL als Verschlüsselungsverfahren. Aus meiner Sicht würde ein Link irritieren.

(Da ja kein Klartext übertragen wird, ist SSL ja nicht mal notwendig -- jedenfalls nicht für die Authentifizierung!) -- Heiko

Speicherung des Passworts auf dem Server

Seit der heutigen Änderung widerspricht sich der Artikel nun darin ob der Server das Passwort im Klartext speichern muß oder nicht. Meines Wissens trifft die aussage im letzten Absatz zu, denn eine "vorgehashte" Version genügt. Dass der Server damit aber auf CRAM-MD5 festgelegt ist, ist auch nicht ganz richtig, da er das PW ja für verschiedene Verfahren in verschiedenen Formen speichern kann.

Für SCARM-SHA1 müsste dann ein anderer Wert abgelegt werden. Ist es unbedenklich, viele Hashes eines Passwortes abzulegen? Das könnte man ebenfalls erwähnen. SCARM hat noch keinen Artikel. ;-)--Dr Joerg Weule (Diskussion) 17:56, 19. Mär. 2016 (CET)

Weiterhin führt die Klartext-Aussage meines Erachtens auf eine falsche Fährte. Denn erstens bedeutet Klartext ja hier nicht unverschlüsselt, sondern nur nicht-einweg-verschlüsselt. Und zweitens ist eine solche Speicherung für die meisten Server sowieso gegeben da Authentisierung mittels PLAIN und LOGIN gang und gäbe sind.

Sollte das im Artikel berücksichtigt werden? --jailbird 12:42, 19. Mär. 2008 (CET)

Meiner Meinung nach ist die Formulierung, das Passwort würde nicht im Klartext auf dem Server abgelegt, bereits im RFC2195 missverständlich gewählt, da nach meinem Verständnis hier lediglich der Schlüssel mit zwei Konstanten (innerer und äußerer PAD) XOR-Verknüpft wird. Im RFC2104 heißt es deshalb auch ganz deutlich:

"We stress that the stored intermediate values need to be treated and protected the same as secret keys."

Wir sprechen hier also - zumindest so wie ich es verstehe - nicht über einen Hash, den der Server ablegt, sondern über die XOR-Verknüpfungen des Passwortes mit den beiden Pads. Diese vorberechneten Werte sollten auch mit anderen Verfahren als CRAM-MD5 funktionieren, insofern sich die Pads nicht ändern.

Ich lese in Diskussionen allerdings auch immer wieder, dass der Server die HMAC abspeichern würde, was aber nach meinem bisherigen Verständnis vollkommen sinnlos wäre, denn die HMAC wird ja genau wie die MAC immer wieder neu berechnet, auf Basis der nicht geheimen Nachricht (Zufallszahl, Zeitstempel, etc.).

Nach meinem Verständnis liegt der Sinn von Verfahren wie CRAM-MD5 keinesfalls darin das Passwort auf dem Server zu verschlüsseln, sondern sie bewirken lediglich, dass man statt der MAC eine HMAC (gehashte MAC) über das Netz zur Authentifizierung überträgt. Dadurch erreicht man einen sehr hohen kryptographischen Standard. Der Nachteil, dass der Geheimschlüssel (wie bei allen CRA-Verfahren) auf beiden Seiten im (quasi) Klartext vorliegen muss, bleibt nach meinem Kenntnisstand aber auch bei HMAC-basierten Verfahren wie CRAM-MD5 bestehen, denn mit denen im RFC2104 genannten "intermediate values" - $K\oplus \mathrm {opad}$ und $K\oplus \mathrm {ipad}$ - kann man mühelos die zur Authentifizierung erforderliche HMAC berechnen, vgl. Wiki-HMAC bzw. RFC2104. Oder habe ich da etwas falsch verstanden? Dann wäre es schön, wenn es mal jemand richtig erklären könnte. --Thiv8Oow 15:03, 10. Mai 2008 (CEST)

Verstehe ich auch so. In der englischen Version des Artikels wird die Speicherung des (reversibel umcodierten) Passworts auf dem Server explizit als Schwäche des Verfahrens angegeben. Ich plädiere für die Streichung des letzten Absatzes, weil er das Gegenteil suggeriert. 62.214.237.52 15:35, 23. Apr. 2009 (CEST)

CRAM-MD5 sicher, APOP nicht?

"kann CRAM-MD5 durchaus als ausreichend sicher gelten"

Dagegen wird APOP im entsprechenden Artikel als unsicher bezeichnet. Beide Verfahren arbeiten im Prinzip identisch, lediglich die Ausgangsdaten für die Hashbildung weichen leicht voneinander ab (enthalten aber logischerweise in beiden Fällen das Passwort).

IMHO ist CRAM-MD5 damit genauso unsicher wie APOP.

MD5 und auf MD5 basierende Verfahren sind seit vielen Jahren gebrochen und bieten praktisch keinen Schutz. (nicht signierter Beitrag von 92.208.245.101 (Diskussion) 11:33, 20. Nov. 2021 (CET))

Obsolete/historic?

Betreffend diese Änderung: Mir ist nicht klar, wo das ("obsolete") in RFC 2195 stehen soll. "While there are now suggestions in the literature that the use of MD5 and keyed MD5 in authentication procedures probably has a limited effective lifetime" ist alles. Und ist der Vorschlag einer Änderung ("historic") relevant, wenn diese keine Zustimmung fand? --StYxXx ⊗ 21:59, 27. Apr. 2020 (CEST)

CRAM-MD5 und POP3

Im Artikel sollte deutlich werden, ob ein Abschied von CRAM-MD5 bedeutet, dass dann nur noch imap-Abrufe möglich sind. Also, ob pop3-Abruf dann ganz generell "Geschichte" sind. --91.36.254.2 18:08, 19. Nov. 2021 (CET)

Das Deaktivieren des gebrochenen CRAM-MD5, hat nichts damit zu tun ob man nur POP3 oder IMAP verwenden kann. (nicht signierter Beitrag von 92.208.245.101 (Diskussion) 11:36, 20. Nov. 2021 (CET))

Fehlende Angabe des besseren Ersatzes für unsicheres CRAM-MD5

Im Artikel fehlt die Angabe, welches ein besserer Ersatz für das unsichere CRAM-MD5 ist. (nicht signierter Beitrag von 92.208.245.101 (Diskussion) 11:39, 20. Nov. 2021 (CET))

Das steht doch im Abschnitt „Alternativen” oder? Soweit ich weiß gibt es keinen direkten, empfohlenen 1-zu-1-Ersatz, die Ansatzweise wird heutzutage einfach nicht mehr verfolgt und das Passwort stattdessen über eine verschlüsselte TLS-Verbindung ohne weitere Challenge-Response-Techniken versand, so wie bei allen Webseiten bspw. auch. --rugk (Diskussion) 00:17, 21. Nov. 2021 (CET)