5.4. Remote Phishing (远程钓鱼)
🇬🇧 English
It is possible for the device flow to be initiated on a device in an attacker's possession. For example, an attacker might send an email instructing the target user to visit the verification URL and enter the user code. To mitigate such an attack, it is RECOMMENDED to inform the user that they are authorizing a device during the user-interaction step (see Section 3.3) and to confirm that the device is in their possession. The authorization server SHOULD display information about the device so that the user could notice if a software client was attempting to impersonate a hardware device.
For authorization servers that support the "verification_uri_complete" optimization discussed in Section 3.3.1, it is particularly important to confirm that the device is in the user's possession, as the user no longer has to type in the code being displayed on the device manually. One suggestion is to display the code during the authorization flow and ask the user to verify that the same code is currently being displayed on the device they are setting up.
The user code needs to have a long enough lifetime to be useable (allowing the user to retrieve their secondary device, navigate to the verification URI, log in, etc.) but should be sufficiently short to limit the usability of a code obtained for phishing. This doesn't prevent a phisher from presenting a fresh token, particularly if they are interacting with the user in real time, but it does limit the viability of codes sent over email or text message.
🇨🇳 中文
设备流程有可能在攻击者拥有的设备上启动。例如,攻击者可能发送一封电子邮件指示目标用户访问验证 URL 并输入用户代码。为了缓解此类攻击,建议 (RECOMMENDED) 在用户交互步骤(参见第 3.3 节)中通知用户他们正在授权一个设备,并确认该设备在他们手中。授权服务器应该 (SHOULD) 显示有关设备的信息,以便用户可以注意到软件客户端是否试图冒充硬件设备。
对于支持第 3.3.1 节中讨论的"verification_uri_complete"优化的授权服务器,确认设备在用户手中尤为重要,因为用户不再需要手动键入设备上显示的代码。一个建议是在授权流程中显示代码,并要求用户验证他们正在设置的设备上当前是否显示相同的代码。
用户代码需要有足够长的生命周期才能使用(允许用户检索他们的辅助设备、导航到验证 URI、登录等),但应该足够短以限制为钓鱼获取的代码的可用性。这不能防止钓鱼者提供新鲜令牌,特别是如果他们实时与用户交互,但它确实限制了通过电子邮件或短信发送的代码的可行性。
🇯🇵 日本語
デバイスフローは、攻撃者が所有するデバイスで開始される可能性があります。たとえば、攻撃者は、ターゲットユーザーに検証 URL にアクセスしてユーザーコードを入力するよう指示する電子メールを送信する可能性があります。このような攻撃を軽減するために、ユーザー対話ステップ(セクション 3.3 を参照)でユーザーにデバイスを認可していることを通知し、デバイスが自分の所有物であることを確認することが推奨されます (RECOMMENDED)。認可サーバーは、ソフトウェアクライアントがハードウェアデバイスになりすまそうとしている場合にユーザーが気付くことができるように、デバイスに関する情報を表示すべきです (SHOULD)。
セクション 3.3.1 で説明されている "verification_uri_complete" 最適化をサポートする認可サーバーの場合、ユーザーがデバイスに表示されているコードを手動で入力する必要がなくなるため、デバイスがユーザーの所有物であることを確認することが特に重要です。1 つの提案は、認可フロー中にコードを表示し、設定中のデバイスに現在同じコードが表示されていることをユーザーに確認するよう求めることです。
ユーザーコードは、使用可能であるのに十分な長い寿命を持つ必要があります(ユーザーがセカンダリデバイスを取得し、検証 URI に移動し、ログインするなど)が、フィッシングのために取得されたコードの使いやすさを制限するのに十分短い必要があります。これは、フィッシャーが新しいトークンを提示することを防ぐものではありません。特にリアルタイムでユーザーと対話している場合はそうです。しかし、電子メールまたはテキストメッセージで送信されたコードの実行可能性は制限されます。
🇫🇷 Français
Il est possible que le flux d'appareil soit initié sur un appareil en possession d'un attaquant. Par exemple, un attaquant pourrait envoyer un e-mail demandant à l'utilisateur cible de visiter l'URL de vérification et d'entrer le code utilisateur. Pour atténuer une telle attaque, il est RECOMMANDÉ d'informer l'utilisateur qu'il autorise un appareil pendant l'étape d'interaction utilisateur (voir Section 3.3) et de confirmer que l'appareil est en sa possession. Le serveur d'autorisation DEVRAIT afficher des informations sur l'appareil afin que l'utilisateur puisse remarquer si un client logiciel tentait d'usurper l'identité d'un appareil matériel.
Pour les serveurs d'autorisation qui supportent l'optimisation "verification_uri_complete" discutée dans la Section 3.3.1, il est particulièrement important de confirmer que l'appareil est en possession de l'utilisateur, car l'utilisateur n'a plus besoin de saisir manuellement le code affiché sur l'appareil. Une suggestion est d'afficher le code pendant le flux d'autorisation et de demander à l'utilisateur de vérifier que le même code est actuellement affiché sur l'appareil qu'il configure.
Le code utilisateur doit avoir une durée de vie suffisamment longue pour être utilisable (permettant à l'utilisateur de récupérer son appareil secondaire, de naviguer vers l'URI de vérification, de se connecter, etc.) mais doit être suffisamment court pour limiter l'utilisabilité d'un code obtenu pour le phishing. Cela n'empêche pas un hameçonneur de présenter un jeton frais, en particulier s'il interagit avec l'utilisateur en temps réel, mais cela limite la viabilité des codes envoyés par e-mail ou message texte.
🇩🇪 Deutsch
Es ist möglich, dass der Geräteablauf auf einem Gerät initiiert wird, das sich im Besitz eines Angreifers befindet. Beispielsweise könnte ein Angreifer eine E-Mail senden, die den Zielbenutzer anweist, die Verifizierungs-URL zu besuchen und den Benutzercode einzugeben. Um einen solchen Angriff abzuschwächen, wird EMPFOHLEN, den Benutzer während des Benutzerinteraktionsschritts (siehe Abschnitt 3.3) darüber zu informieren, dass er ein Gerät autorisiert, und zu bestätigen, dass sich das Gerät in seinem Besitz befindet. Der Autorisierungsserver SOLLTE Informationen über das Gerät anzeigen, damit der Benutzer bemerken kann, wenn ein Software-Client versucht, sich als Hardware-Gerät auszugeben.
Für Autorisierungsserver, die die in Abschnitt 3.3.1 besprochene "verification_uri_complete"-Optimierung unterstützen, ist es besonders wichtig zu bestätigen, dass sich das Gerät im Besitz des Benutzers befindet, da der Benutzer den auf dem Gerät angezeigten Code nicht mehr manuell eingeben muss. Ein Vorschlag ist, den Code während des Autorisierungsablaufs anzuzeigen und den Benutzer aufzufordern zu überprüfen, ob derselbe Code derzeit auf dem Gerät angezeigt wird, das er einrichtet.
Der Benutzercode muss eine ausreichend lange Lebensdauer haben, um verwendbar zu sein (damit der Benutzer sein Sekundärgerät abrufen, zur Verifizierungs-URI navigieren, sich anmelden usw. kann), sollte aber kurz genug sein, um die Verwendbarkeit eines für Phishing erhaltenen Codes zu begrenzen. Dies verhindert nicht, dass ein Phisher ein frisches Token präsentiert, insbesondere wenn er in Echtzeit mit dem Benutzer interagiert, aber es begrenzt die Realisierbarkeit von Codes, die per E-Mail oder Textnachricht gesendet werden.
🇮🇹 Italiano
È possibile che il flusso del dispositivo venga avviato su un dispositivo in possesso di un aggressore. Ad esempio, un aggressore potrebbe inviare un'e-mail che indica all'utente target di visitare l'URL di verifica e inserire il codice utente. Per mitigare tale attacco, è RACCOMANDATO informare l'utente che sta autorizzando un dispositivo durante la fase di interazione dell'utente (vedere Sezione 3.3) e confermare che il dispositivo è in suo possesso. Il server di autorizzazione DOVREBBE visualizzare informazioni sul dispositivo in modo che l'utente possa notare se un client software stava tentando di impersonare un dispositivo hardware.
Per i server di autorizzazione che supportano l'ottimizzazione "verification_uri_complete" discussa nella Sezione 3.3.1, è particolarmente importante confermare che il dispositivo è in possesso dell'utente, poiché l'utente non deve più digitare manualmente il codice visualizzato sul dispositivo. Un suggerimento è visualizzare il codice durante il flusso di autorizzazione e chiedere all'utente di verificare che lo stesso codice sia attualmente visualizzato sul dispositivo che sta configurando.
Il codice utente deve avere una durata sufficiente per essere utilizzabile (consentendo all'utente di recuperare il dispositivo secondario, navigare verso l'URI di verifica, accedere, ecc.) ma dovrebbe essere sufficientemente breve da limitare l'utilizzabilità di un codice ottenuto per phishing. Questo non impedisce a un phisher di presentare un token fresco, in particolare se sta interagendo con l'utente in tempo reale, ma limita la fattibilità dei codici inviati tramite e-mail o messaggio di testo.