Die folgenden Abschnitte beschreiben …
Eine ausführliche Bedrohungsanalyse und Sicherheitsbetrachtung für OAuth 2.0 [4] ist in [3] zu finden.
Der code_verifier wird im OAuth 2.0 PKCE-Flow verwendet, um unter Einsatz der code_challenge_method die code_challenge zu bilden. Der Parameter code_challenge_method kann die Werte plain oder S256 (=SHA256) annehmen. Für code_challenge_method = plain gilt
code_challenge = code_verifier
und im Falle von code_challenge_method = S256
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))).
Das Sicherheitsmodell beruht auf der Bedingung, dass ein etwaiger Angreifer den code_verifier nicht erraten kann. Um diese Bedingung zu erfüllen muss er kryptografisch zufällig gewählt werden und ausreichen Entropie aufweisen. Die Entropie des Parameters sollte 256-Bit betragen. Die Bedingungen können über einen geeigneten Zufallszahlengenerator, im Falle von Java/Android durch die SecureRandom-Klasse erfüllt werden [1,2].
Wird der code_verifier mit ausreichend Entropie und kryptografisch zufällig (uniform gewählt) erzeugt, ist das zusätzliche “salzen” nicht notwendig, da er somit ausreichen Entropie zum Schutz vor Brute-Force-Angriffen besitzt. Das Verketten eines nicht sicherheitskritischen Werts (dem salt) mit dem code_verifier (mit 256 Bit Entropie) und die anschließende Verarbeitung durch eine kryptografische Hash-Funktion (z.B. SHA256), würde die Anzahl der Rateversuche eines potentiellen Angreifers nicht erhöhen [1].
Beim Verwendung des PKCE-Flows muss der Server S256 als code_callenge_method unterstützen. Im Kontext des Movi-Projektes darf code_challenge_method = plain nicht unterstützt werden, da der sicherheitskritische code_challeneg-Parameter hierbei im Klartext übertragen wird und es einem Angreifer mit zugriff auf den Kommunikationskanal möglich wäre diesen abzuhören [1].
[1] https://tools.ietf.org/html/rfc7636
[2] https://developer.android.com/reference/java/security/SecureRandom
[3] https://tools.ietf.org/html/rfc6819
[4] https://tools.ietf.org/html/rfc6749