-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make pre-authorized code flow optional? #60
Comments
This would likely be countered by client attestation, however client attestation is probably not required but recommended? |
I agree with Kristina and I think in the high assurance profile there is no place for pre-auth code flow. Furthermore, as it is mentioned in the OIDF workshop for the eIDAS expert group the pre-auth code flow is usable for scenarios that demand a lower level of security, and seems strange to me to see it in HAIP. We already shared our concerns regarding the usage of this flow here. |
Is this an issue with pre-authz code or cross device in general? I'm asking since cross device could be done with authz code flow, too. Not sure, however, this is more secure in any way. |
I agree that in the case of cross-device flow, the same attack vector is applicable for the authz code flow as well. However, in the case of the same device flow, another big problem with the pre-auth code flow is PIN phishing, while in the case of authz code flow is not applicable and we have PKCE to avoid the code injection/replay attacks. In the case of cross-device, the best we can do is integration available BCPs in the cross-device draft. |
I have checked back with Fabian. My conclusion: this issue always exists, if there is state from before the credential offer that is conveyed into the issuance process. So even if the authz code is used, if it is used in conjunction with |
@paulbastian I would like to point out that wallet attestation does not prevent the attack on the pre-authorized code flow, because the attacker can use an unmodified wallet on a device under his control to exchange the pre-authorized code for a credential. |
@fabian-hk do you think that attack won't work with authorization code and |
Let us clarify what exactly we are talking about here. The attack I discovered during my formal security analysis assumes the following things:
After selecting the malicious app, the attacker can also ask for the user pin, which is not suspicious because the wallet is supposed to do that. |
I fully agree that pre-authorized code flow should be optional in the HAIP here the motivations |
During the OAuth Security Workshop, Fabian's formal analysis highlighted that it is very hard to ensure the pre-auth code gets into the intended wallet. even when the PIN is used, if the QRcode with pre-auth code is scanned by a malicious wallet, chances are high that the user will type in the correct PIN received via a separate channel in the malicious wallet.
At the same time, I am reluctant to remove this flow, because it is important for the issuance when user authentication is done in-person in the government office.
The text was updated successfully, but these errors were encountered: