jiebi/CodeConvo huggingface dataset:
user authentication using asymmetric cryptography that can be invoked from a web browser or native client.  Version 2.2 of the FIDO Client to Authenticator Protocol (CTAP) supports a new cross-device <del> authentication protocol, called "hybrid", which enables an external device, such as a phone or tablet, to be used as a roaming </del> <ins> authentication protocol, called "hybrid transports", which enables an external device, such as a phone or tablet, to be used as a roaming </ins> authenticator for signing into the primary device, such as a personal computer.  This is commonly called FIDO Cross-Device Authentication <del> (CDA). </del> <ins> (CDA).  CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms. </ins> When a user wants to authenticate using their mobile device (authenticator) for the first time, they need to link their authenticator to their main device.  This is done using a scan of a QR code.  When the authenticator scans the QR code, the device sends an encrypted BLE advertisement containing keying material and a <del> tunnel ID.  The main device and authenticator both establish connections to the web service, and the normal CTAP protocol exchange occurs. </del> <ins> tunnel ID.  The main device (CTAP client) and authenticator both establish connections to the web service, and the normal CTAP protocol exchange occurs. </ins> If the user chooses to keep their authenticator linked with the main device, the QR code link step is not necessary for subsequent use.
6.2.3.3. <del> Both the Consumption Device and the authenticator require BLE support.  The Consumption Device must support both FIDO2/WebAuthn, specifically CTAP 2.2 with hybrid transport CTAP22Draft.  The mobile phone must support CTAP 2.2 or greater to be used as a cross-device authenticator. </del> <ins> Both the Consumption Device and the authenticator require BLE support and access to the internet.  The Consumption Device must support both FIDO2/WebAuthn, specifically CTAP 2.2 with hybrid transports CTAP22Draft.  The device serving as the FIDO authenticator must support CTAP 2.2 or later to be used as a cross-device authenticator. </ins> 6.2.3.4.
FIDO2/WebAuthn SHOULD be used for cross-device authentication scenarios whenever the devices are capable of doing so and a suitable <del> FIDO credential is not available on the consumption device.  It MAY </del> <ins> FIDO credential is not available on the Consumption Device.  It MAY </ins> be used as an authentication method with the Authorization Code Grant <del> RFC6749 and PKCE RFC7663, to grant authorization to an Consumption Device (e.g., smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/ WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device Authorization Grant RFC8628. </del> <ins> RFC6749 and PKCE RFC7663, to grant authorization to a Consumption Device (e.g., smart TV or interactive whiteboard) using a device serving as the FIDO authenticator (e.g. a mobile phone) for authentication.  This combination of FIDO2/WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device Authorization Grant RFC8628. </ins> 6.2.4.
Authorization Code Grant as defined in RFC6749 are more appropriate. If a protocol supports both same-device and cross-device modes (e.g., OpenID.SIOPV2), the cross-device mode SHOULD not be used for same- <del> device scenarios.  If an implementor decides to use a cross-device protocol or a protocol with a cross-device mode in a same-device scenario, the mitigations recommended in this document SHOULD be implemented to reduce the risks that the unauthenticated channel is exploited. </del> <ins> device scenarios.  An authorization server MAY choose to block cross- device protocols used in same-device scenarios if it detects that the same device is used.  An authorization Server may use techniques such as device fingerprinting, network address or other techniques to detect if a cross-device protocol is being used on the same device. If an implementor decides to use a cross-device protocol or a protocol with a cross-device mode in a same-device scenario, the mitigations recommended in this document SHOULD be implemented to reduce the risks that the unauthenticated channel is exploited. </ins> 6.
Attackers exploit the unauthenticated channel by changing the context of the user code or QR code and then sending a message to a user <del> (e-mail, text, instant messaging etc).  By deploying content filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine- tune content filtering solutions to detect artefacts like QR codes or user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authorization to access restricted resources. </del> <ins> (e-mail, text messaging, instant messaging or other communication mechanisms).  By deploying content filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine-tune content filtering solutions to detect artefacts like QR codes or user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authorization to access restricted resources. </ins> Some scenarios may require legitimate re-transmission of user, QR and authorization data (e.g., retries).  To prevent the disruption of
limited number of messages with the same QR or user codes to be transmitted before interrupting the delivery of those messages. Content filtering may also be fragmented across multiple <del> communications systems and channels (e-mail, messaging, text etc), </del> <ins> communications systems and communication channels (e-mail, text messaging, instant messaging or other communication mechanisms), </ins> making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems.
5.2.2.1. <del> A standard under development as part of the Financial-grade API (FAPI) family of standards that allows a device or service (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user does not scan a QR code or obtain a user code from the initiating device. </del> <ins> Client Initiated Back-Channel Authentication (CIBA) CIBA: A standard developed in the OpenID Foundation that allows a device or service (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user does not scan a QR code or obtain a user code from the initiating device, but is instead contacted by the OpenID Provider to complete the authentication using a push notification, e-mail, text message or any other suitable mechanism. </ins> 5.2.2.2.
5.1.13. <ins> Use cross device authentication after a successful phishing resistant authentication.  The unauthenticated channel between the initiating and authenticating device allows attackers to obtain a QR code.  When the QR Code is presented after a successful phishing resistant authentication, this prevents the attack from being initiated. Scenario A user would like to verify an identity on a web application using an identity stored on a separate mobile device in a phishing resistant way.  Using verifiable credentials from a secure and trusted wallet and presenting this to a trusted verifier service would be an example of this.  The flow is initialized using a QR Code created inside a secure session on the target service after a phishing resistant authentication.  The verifier could validate the identity from the authenticated session where the QR Code is presented, and the identity sent in the verifiable credential. 5.1.14. </ins> The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or reduce the impact or remediate an attack if it succeeds.  When
of the credentials and after completing the onboarding process, their account is activated. <ins> 2.7. An employee is signed into an application on their personal computer and wants to bootstrap the mobile application on their mobile phone. The employee initiates the cross-device flow and is shown a QR code in their application.  The employee launches the mobile application on their phone and scans the QR code which results in the user being signed into the application on the mobile phone. </ins> 3. The benefits of cross-device flows is compelling and is seeing
3.7. <ins> An attacker creates a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach.  They ask employees to send them the QR code typically used to transfer a session.  The employee, eager to assist, initiates the process to transfer a session.  They authenticate and obtain a QR code and then send the QR code to the attacker.  The attacker scans the QR code with their mobile phone and access the users data and resources. </ins> 3.8. In all of the attack scenarios listed above, a user is tricked or
5.1.14. <del> Use cross device authentication after a successful phishing resistant authentication.  The unauthenticated channel between the initiating and authenticating device allows attackers to obtain a QR code.  When the QR Code is presented after a successful phishing resistant authentication, this prevents the attack from being initiated. Scenario A user would like to verify an identity on a web application using an identity stored on a separate mobile device in a phishing resistant way.  Using verifiable credentials from a secure and trusted wallet and presenting this to a trusted verifier service would be an example of this.  The flow is initialized using a QR Code created inside a secure session on the target service after a phishing resistant authentication.  The verifier could validate the identity from the authenticated session where the QR Code is presented, and the identity sent in the verifiable credential. </del> <ins> By requiring a user to authenticate on the initiating device with a phishing resistant authentication method before initiating a cross- device flow, the server can prevent an attacker from initiating a cross-device flow and obtaining QR codes or user codes.  This prevents the attacker from obtaining a QR code or user code that they can use to mislead an unsuspecting user.  This requires that the initiating device has sufficient input capabilities to support a phishing resistant authentication mechanism.  Note that this does not prevent the attacks described in Example B5: Illicit Network Join [4] and Example B7: Illicit Session Transfer [5] and it is recommended that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [6] and Example A7: Transfer a session [7]. </ins> 5.1.15.
displays a message to the attacker with instructions on how to access their account. <ins> 3.7. In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding with the attacker, the security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on his device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to trick proximity checks. This document therefore only considers scenarios where a user does not collude with an attacker. </ins> 4. Cross-device flows that are subject to the attacks described earlier,
2.1. <del> An example of a cross-device flow that relies on the user copying information from the Initiating Device to the Authorization Device is shown below: The Device Authorization Grant (RFC8628) follows this pattern. </del> <ins> The Device Authorization Grant (RFC8628)is an example of a cross- device flow that relies on the user copying information from the Initiating Device to the Authorization Device.  The figure below shows a typical example of this flow: </ins> 2.2. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization on the user's authorization device via the backchannel. </del> <ins> The Client Initiated Backchannel Authentication CIBA transfers the session on the backchannel with the Authroization Server to request authorization on the Authroization Device.  The figure below shows an example of this flow. </ins> The Authorization Server may use a variety of mechanisms to request user authorization, including a push notification to a dedicated app on a mobile phone, or sending a text message with a link to an endpoint where the user can authenticate and authorize an action. The Client Initiated Backchannel Authentication CIBA follows this pattern. 2.3. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization request via the backchannel. </del> <ins> Examples of the user-transferred authorization data pattern includes flows in which the Initiating Device requests the Authorization Server to send a one time access code (e.g. as a text message or e-mail) to the Authorization Device.  Once the Authroization Device receives the code, the user enters it on the Initiating Device.  The Initiatng Device presents it back to the Authroization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </ins> The Authorization Server may choose to authenticate the user before sending the access code.  The access code may be delivered as a text
3.1. A common action in cross-device flows is to present the user with a <del> QR code or a user code on the initiating device (e.g., Smart TV) which is then scanned or entered on the authorization device (the </del> <ins> QR code or a user code on the Initiating Device (e.g., Smart TV) which is then scanned or entered on the Authorization Device (the </ins> mobile phone).  When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being displayed in the place or context intended by the service provider. <del> It is up to the user's judgment to decide on whether they can trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the initiating device (smart TV) and the device on which the authentication/ authorization will take place (the mobile phone). </del> <ins> It is up to the user to decide whether they should trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the Initiating Device (e.g., smart TV) and the Authorizing Device (e.g., the mobile phone). </ins> Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by initiating the authorization flows).  They then use social engineering techniques to change the context in which authorization is requested to trick end-users to scan the QR code or enter it on <del> their mobile devices.  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </del> <ins> their Authorization Device (e.g., mobile phone).  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </ins> 3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del> <ins> In the backchannel transferred session pattern, the client requests the authorization server to authenticate the user and obtain </ins> authorization for an action.  This may happen as a result of user <del> interaction with the initiating device, but may also be triggered without the users direct interaction with the initiating device, </del> <ins> interaction with the Initiating Device, but may also be triggered without the users direct interaction with the Initiating Device, </ins> resulting in an authorization request presented to the user without context of why or who triggered the request.
[3] #Content Filtering <del> [4] #Example B1: Illicit access to a video streaming service (User Transferred Pattern) </del> <ins> [4] #Example B1: Illicit access to a video streaming service (User- Transferred Session Data Pattern) </ins> [5] #Example B4: Illicit Transaction Authorization (Client Transferred Pattern) <del> [6] #Example B5: Illicit Network Join (Hybrid Pattern) </del> <ins> [6] #Example B5: Illicit Network Join (User-Transferred Authorization Data Pattern) </ins> <del> [7] #Example B7: Illicit session transfer (Hybrid Pattern) </del> <ins> [7] #Example B7: Illicit session transfer (User-Transferred Authorization Data Pattern) </ins> <del> [8] #Example A5: Add a device to a network (Hybrid) </del> <ins> [8] #Example A5: Add a device to a network (User-Transferred Authorization Data Pattern) </ins> <del> [9] #Example A7: Transfer a session (Hybrid) </del> <ins> [9] #Example A7: Transfer a session (User-Transferred Authorization Data Pattern) </ins>
2.2. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization on the user's authorization device via the backchannel. </del> <ins> The Client Initiated Backchannel Authentication CIBA transfers the session on the backchannel with the Authroization Server to request authorization on the Authroization Device.  The figure below shows an example of this flow. </ins> The Authorization Server may use a variety of mechanisms to request user authorization, including a push notification to a dedicated app on a mobile phone, or sending a text message with a link to an endpoint where the user can authenticate and authorize an action. The Client Initiated Backchannel Authentication CIBA follows this pattern.
3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del> <ins> In the backchannel transferred session pattern, the client requests the authorization server to authenticate the user and obtain </ins> authorization for an action.  This may happen as a result of user <del> interaction with the initiating device, but may also be triggered without the users direct interaction with the initiating device, </del> <ins> interaction with the Initiating Device, but may also be triggered without the users direct interaction with the Initiating Device, </ins> resulting in an authorization request presented to the user without context of why or who triggered the request.
techniques to prime the user for an authorization request and thereby trick them into granting authorization.  The social engineering techniques range in sophistication from messages misrepresenting the <del> reason for receiving an authorization request to triggering a large </del> <ins> reason for receiving an authorization request, to triggering a large </ins> volume of requests at an inconvenient time for the user, in the hope that the user will grant authorization to make the requests stop. The figure below shows an example of such an attack.
that this is the third time that they have been notified and their last opportunity to prevent deletion of their work files.  One or more employees respond by following the URL, entering the code and <del> performing multi-factor authentication.  Once these employees authorized access, the attacker obtains access and refresh tokens from the authorization server and uses it to access the users files, perform lateral attacks to obtain access to other information and continuously refresh the session by requesting new access tokens. These tokens may be exfiltrated and sold to third parties. </del> <ins> performing multi-factor authentication.  Throughout the authentication experience, the user is interacting with a trusted user experience, re-enforcing the legitimacy of the request.  Once these employees authorized access, the attacker obtains access and refresh tokens from the authorization server and uses it to access the users files, perform lateral attacks to obtain access to other information and continuously refresh the session by requesting new access tokens.  These tokens may be exfiltrated and sold to third parties. </ins> 3.4.3.
protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated Backchannel Authentication (CIBA) provides an alternative, provided <del> that there is a channel through which the authorizations server can </del> <ins> that there is a channel through which the authorization server can </ins> contact the end user.  Examples of such a channel include device push notifications, e-mail or text messages which the user can access from their device.  If CIBA is used, additional mitigations to enforce
These flows are increasingly popular and typically involve using a mobile phone to scan a QR code or enter a user code displayed on an <del> initiating device (e.g., Smart TV, Kiosk, Personal Computer etc). </del> <ins> Initiating Device (e.g., Smart TV, Kiosk, Personal Computer etc). </ins> The channel between the Initiating Device and the Authorization Device is unauthenticated and relies on the user's judgment to decide whether to trust a QR code, user code, or the authorization request pushed to their authorization device. <del> Several publications have emerged in the public domain (Exploit1, Exploit2, Exploit3, Exploit4, Exploit5, Exploit6), describing how the unauthenticated channel can be exploited using social engineering techniques borrowed from phishing.  Unlike traditional phishing attacks, these attacks don't harvest credentials.  Instead, they skip the step of collecting credentials by persuading users to grant authorization using their Authorization Devices. </del> <ins> Cross-Device Consent Phishing (CDCP) attacks exploit the unauthenticated channel between the Initiating Device and Authorization Device using social engineering techniques to to gain unauthorized access to the victims data.  Several publications have emerged in the public domain (Exploit1, Exploit2, Exploit3, Exploit4, Exploit5, Exploit6), describing how the unauthenticated channel can be exploited using social engineering techniques borrowed from phishing.  Unlike traditional phishing attacks, these attacks don't harvest credentials.  Instead, they skip the step of collecting credentials by persuading users to grant authorization using their Authorization Devices. </ins> Once the user grants authorization, the attacker has access to the user's resources and in some cases is able to collect access and
Attackers exploit cross-device flows by initiating an authorization flow on the Initiating Device and then use social engineering techniques to change the context in which the request is presented to <del> the user in order to trick them into granting authorization on the </del> <ins> the user in order to convince them to grant authorization on the </ins> Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating Device and the Authorizing Device is unauthenticated.  These attacks <del> are also known as illicit consent grant attacks. </del> <ins> are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.