5.1. User Code Brute Forcing (用户代码暴力破解)
🇬🇧 English
Since the user code is typed by the user, shorter codes are more desirable for usability reasons. This means the entropy is typically less than would be used for the device code or other OAuth bearer token types where the code length does not impact usability. Therefore, it is recommended that the server rate-limit user code attempts.
The user code SHOULD have enough entropy that, when combined with rate-limiting and other mitigations, a brute-force attack becomes infeasible. For example, it's generally held that 128-bit symmetric keys for encryption are seen as good enough today because an attacker has to put in 2^96 work to have a 2^-32 chance of guessing correctly via brute force. The rate-limiting and finite lifetime on the user code place an artificial limit on the amount of work an attacker can "do". If, for instance, one uses an 8-character base 20 user code (with roughly 34.5 bits of entropy), the rate-limiting interval and validity period would need to only allow 5 attempts in order to get the same 2^-32 probability of success by random guessing.
A successful brute forcing of the user code would enable the attacker to approve the authorization grant with their own credentials, after which the device would receive a device authorization grant linked to the attacker's account. This is the opposite scenario to an OAuth bearer token being brute forced, whereby the attacker gains control of the victim's authorization grant. Such attacks may not always make economic sense. For example, for a video app, the device owner may then be able to purchase movies using the attacker's account (though even in this case a privacy risk would still remain and thus is important to protect against). Furthermore, some uses of the device flow give the granting account the ability to perform actions that need to be protected, such as controlling the device.
The precise length of the user code and the entropy contained within is at the discretion of the authorization server, which needs to consider the sensitivity of their specific protected resources, the practicality of the code length from a usability standpoint, and any mitigations that are in place, such as rate-limiting, when determining the user code format.
🇨🇳 中文
由于用户代码由用户键入,出于可用性原因,更短的代码更为理想。这意味着熵通常低于设备代码或其他 OAuth 承载令牌类型使用的熵,在后者中代码长度不影响可用性。因此,建议服务器对用户代码尝试进行速率限制。
用户代码应该 (SHOULD) 具有足够的熵,当与速率限制和其他缓解措施相结合时,暴力攻击变得不可行。例如,通常认为用于加密的 128 位对称密钥在今天已经足够好,因为攻击者必须付出 2^96 的工作量才能有 2^-32 的机会通过暴力破解正确猜测。用户代码上的速率限制和有限生命周期对攻击者可以"完成"的工作量设置了人为限制。例如,如果使用 8 字符 base 20 用户代码(大约 34.5 位熵),速率限制间隔和有效期将只需要允许 5 次尝试,就能获得通过随机猜测获得成功的相同 2^-32 概率。
成功暴力破解用户代码将使攻击者能够使用他们自己的凭据批准授权许可,之后设备将收到链接到攻击者帐户的设备授权许可。这与 OAuth 承载令牌被暴力破解的场景相反,在后者中攻击者获得对受害者授权许可的控制。此类攻击可能并不总是具有经济意义。例如,对于视频应用,设备所有者随后可能能够使用攻击者的帐户购买电影(尽管即使在这种情况下隐私风险仍然存在,因此保护很重要)。此外,设备流程的某些用途赋予授权帐户执行需要保护的操作的能力,例如控制设备。
用户代码的精确长度及其包含的熵由授权服务器自行决定,授权服务器在确定用户代码格式时需要考虑其特定受保护资源的敏感性、从可用性角度来看代码长度的实用性以及已采取的任何缓解措施(例如速率限制)。
🇯🇵 日本語
ユーザーコードはユーザーによって入力されるため、ユーザビリティの理由から短いコードがより望ましいです。これは、エントロピーが通常、コードの長さがユーザビリティに影響しないデバイスコードや他の OAuth ベアラートークンタイプに使用されるものよりも少ないことを意味します。したがって、サーバーがユーザーコードの試行に速度制限を実施することが推奨されます。
ユーザーコードは、速度制限やその他の緩和策と組み合わせた場合、ブルートフォース攻撃が実行不可能になるのに十分なエントロピーを持つべきです (SHOULD)。たとえば、暗号化用の 128 ビット対称鍵は今日十分に良いとされています。これは、攻撃者がブルートフォースで正しく推測する 2^-32 の確率を得るために 2^96 の作業を行う必要があるためです。ユーザーコードの速度制限と有限のライフタイムは、攻撃者が「実行」できる作業量に人工的な制限を設けます。たとえば、8 文字の base 20 ユーザーコード(約 34.5 ビットのエントロピー)を使用する場合、速度制限間隔と有効期間は、ランダムな推測による成功の同じ 2^-32 の確率を得るために 5 回の試行のみを許可する必要があります。
ユーザーコードのブルートフォースに成功すると、攻撃者は自分の資格情報で認可グラントを承認できるようになり、その後デバイスは攻撃者のアカウントにリンクされたデバイス認可グラントを受け取ります。これは、OAuth ベアラートークンがブルートフォースされるシナリオとは逆のシナリオであり、攻撃者が被害者の認可グラントの制御を取得します。このような攻撃は常に経済的に意味をなすとは限りません。たとえば、ビデオアプリの場合、デバイスの所有者は攻撃者のアカウントを使用して映画を購入できる可能性があります(ただし、この場合でもプライバシーリスクは依然として残るため、保護することが重要です)。さらに、デバイスフローの一部の使用では、デバイスの制御など、保護が必要なアクションを実行する能力が付与アカウントに与えられます。
ユーザーコードの正確な長さとそれに含まれるエントロピーは認可サーバーの裁量に委ねられており、ユーザーコード形式を決定する際には、特定の保護されたリソースの機密性、ユーザビリティの観点からのコード長の実用性、速度制限などの実施されている緩和策を考慮する必要があります。
🇫🇷 Français
Étant donné que le code utilisateur est saisi par l'utilisateur, des codes plus courts sont plus souhaitables pour des raisons d'utilisabilité. Cela signifie que l'entropie est généralement inférieure à celle utilisée pour le code d'appareil ou d'autres types de jetons bearer OAuth où la longueur du code n'affecte pas l'utilisabilité. Par conséquent, il est recommandé que le serveur limite le taux de tentatives de code utilisateur.
Le code utilisateur DEVRAIT avoir suffisamment d'entropie pour que, lorsqu'il est combiné avec la limitation de taux et d'autres atténuations, une attaque par force brute devienne infaisable. Par exemple, on considère généralement que les clés symétriques de 128 bits pour le chiffrement sont considérées comme suffisantes aujourd'hui car un attaquant doit effectuer 2^96 travaux pour avoir une chance de 2^-32 de deviner correctement par force brute. La limitation de taux et la durée de vie finie sur le code utilisateur placent une limite artificielle sur la quantité de travail qu'un attaquant peut "faire". Si, par exemple, on utilise un code utilisateur base 20 de 8 caractères (avec environ 34,5 bits d'entropie), l'intervalle de limitation de taux et la période de validité devraient seulement permettre 5 tentatives pour obtenir la même probabilité de 2^-32 de succès par devinette aléatoire.
Un forçage brutal réussi du code utilisateur permettrait à l'attaquant d'approuver l'autorisation avec ses propres informations d'identification, après quoi l'appareil recevrait une autorisation d'appareil liée au compte de l'attaquant. C'est le scénario opposé à un jeton bearer OAuth étant forcé brutalement, où l'attaquant prend le contrôle de l'autorisation de la victime. De telles attaques peuvent ne pas toujours avoir de sens économique. Par exemple, pour une application vidéo, le propriétaire de l'appareil pourrait alors être en mesure d'acheter des films en utilisant le compte de l'attaquant (bien que même dans ce cas, un risque de confidentialité subsisterait et il est donc important de s'en protéger). De plus, certaines utilisations du flux d'appareil donnent au compte accordant la capacité d'effectuer des actions qui doivent être protégées, telles que le contrôle de l'appareil.
La longueur précise du code utilisateur et l'entropie qu'il contient sont à la discrétion du serveur d'autorisation, qui doit considérer la sensibilité de leurs ressources protégées spécifiques, la praticité de la longueur du code d'un point de vue utilisabilité, et toutes les atténuations en place, telles que la limitation de taux, lors de la détermination du format du code utilisateur.
🇩🇪 Deutsch
Da der Benutzercode vom Benutzer eingegeben wird, sind kürzere Codes aus Gründen der Benutzerfreundlichkeit wünschenswerter. Dies bedeutet, dass die Entropie typischerweise geringer ist als bei dem Gerätecode oder anderen OAuth-Bearertoken-Typen, bei denen die Codelänge die Benutzerfreundlichkeit nicht beeinträchtigt. Daher wird empfohlen, dass der Server Versuche mit Benutzercodes ratenbegrenzt.
Der Benutzercode SOLLTE genügend Entropie haben, dass in Kombination mit Ratenbegrenzung und anderen Gegenmaßnahmen ein Brute-Force-Angriff nicht durchführbar wird. Zum Beispiel wird allgemein angenommen, dass 128-Bit-symmetrische Schlüssel für Verschlüsselung heute als gut genug angesehen werden, weil ein Angreifer 2^96 Arbeit leisten muss, um eine 2^-32 Chance zu haben, durch Brute Force richtig zu raten. Die Ratenbegrenzung und die endliche Lebensdauer des Benutzercodes setzen eine künstliche Grenze für die Menge an Arbeit, die ein Angreifer "leisten" kann. Wenn man beispielsweise einen 8-Zeichen-Base-20-Benutzercode verwendet (mit etwa 34,5 Bits Entropie), müssten das Ratenbegrenzungsintervall und die Gültigkeitsdauer nur 5 Versuche zulassen, um die gleiche 2^-32 Wahrscheinlichkeit des Erfolgs durch zufälliges Raten zu erhalten.
Ein erfolgreiches Brute-Forcing des Benutzercodes würde es dem Angreifer ermöglichen, die Autorisierungsgenehmigung mit seinen eigenen Anmeldeinformationen zu genehmigen, wonach das Gerät eine mit dem Konto des Angreifers verknüpfte Geräteautorisierungsgenehmigung erhalten würde. Dies ist das umgekehrte Szenario zu einem OAuth-Bearertoken, das durch Brute Force geknackt wird, wobei der Angreifer die Kontrolle über die Autorisierungsgenehmigung des Opfers erhält. Solche Angriffe sind möglicherweise nicht immer wirtschaftlich sinnvoll. Zum Beispiel könnte der Gerätebesitzer bei einer Video-App dann in der Lage sein, Filme mit dem Konto des Angreifers zu kaufen (obwohl selbst in diesem Fall ein Datenschutzrisiko bestehen würde und es daher wichtig ist, sich dagegen zu schützen). Darüber hinaus geben einige Verwendungen des Geräteablaufs dem gewährenden Konto die Möglichkeit, Aktionen auszuführen, die geschützt werden müssen, wie z.B. die Steuerung des Geräts.
Die genaue Länge des Benutzercodes und die darin enthaltene Entropie liegen im Ermessen des Autorisierungsservers, der bei der Bestimmung des Benutzercode-Formats die Sensibilität seiner spezifischen geschützten Ressourcen, die Praktikabilität der Codelänge aus Sicht der Benutzerfreundlichkeit und alle vorhandenen Gegenmaßnahmen wie Ratenbegrenzung berücksichtigen muss.
🇮🇹 Italiano
Poiché il codice utente viene digitato dall'utente, codici più corti sono più desiderabili per motivi di usabilità. Ciò significa che l'entropia è tipicamente inferiore a quella utilizzata per il codice dispositivo o altri tipi di token bearer OAuth in cui la lunghezza del codice non influisce sull'usabilità. Pertanto, si raccomanda che il server limiti la frequenza dei tentativi di codice utente.
Il codice utente DOVREBBE avere entropia sufficiente affinché, se combinato con la limitazione della frequenza e altre mitigazioni, un attacco di forza bruta diventi impraticabile. Ad esempio, generalmente si ritiene che le chiavi simmetriche a 128 bit per la crittografia siano considerate sufficientemente buone oggi perché un aggressore deve svolgere 2^96 lavori per avere una probabilità di 2^-32 di indovinare correttamente tramite forza bruta. La limitazione della frequenza e la durata finita sul codice utente pongono un limite artificiale sulla quantità di lavoro che un aggressore può "fare". Se, ad esempio, si utilizza un codice utente base 20 a 8 caratteri (con circa 34,5 bit di entropia), l'intervallo di limitazione della frequenza e il periodo di validità dovrebbero consentire solo 5 tentativi per ottenere la stessa probabilità di 2^-32 di successo tramite ipotesi casuale.
Un attacco di forza bruta riuscito del codice utente consentirebbe all'aggressore di approvare la concessione di autorizzazione con le proprie credenziali, dopodiché il dispositivo riceverebbe una concessione di autorizzazione del dispositivo collegata all'account dell'aggressore. Questo è lo scenario opposto a un token bearer OAuth sottoposto a forza bruta, per cui l'aggressore ottiene il controllo della concessione di autorizzazione della vittima. Tali attacchi potrebbero non avere sempre senso economico. Ad esempio, per un'app video, il proprietario del dispositivo potrebbe quindi essere in grado di acquistare film utilizzando l'account dell'aggressore (anche se anche in questo caso rimarrebbe comunque un rischio per la privacy ed è quindi importante proteggersi). Inoltre, alcuni usi del flusso del dispositivo danno all'account concedente la possibilità di eseguire azioni che devono essere protette, come il controllo del dispositivo.
La lunghezza precisa del codice utente e l'entropia in esso contenuta sono a discrezione del server di autorizzazione, che deve considerare la sensibilità delle proprie risorse protette specifiche, la praticità della lunghezza del codice da un punto di vista di usabilità e tutte le mitigazioni in atto, come la limitazione della frequenza, quando determina il formato del codice utente.