This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(291.2, 11%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Hi,
I would like to hide errorCode from SelfAsserted service response
as per security remediation report from the third party company.
Possible other error codes could be error-codes
You can reproduce this issue with showing these error codes using this demo website authorize with already created account by trying:
For these two above scenarios and many different I would like to have same message without letting the user know what is the error and what is exactly wrong.
Appreciate for any solution :)
Marek
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 17%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGM%3C/text%3E%3C/svg%3E)
@Marek Thank you for reaching out to us, let me research on your query and will revert back.
Is there any option to change value of errorCode to show same value for each request type ? Some predefined value can be.
Hi Marek. I run into this issue long time ago. Unfortunately, for now there is no option to modify errorCode in any way.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(236.8, 42%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Hello, do we have any update on this topic?
I believe is quite a common problem for companies that performs regular security audits.
You can achieve this by using localization and changing the error messages. The concrete localization string ids are listed here, relevant are of type ErrorMessage and begin with "UserMessageIf..."
Once you configure localization with your own messages you will see them:
I know the trick with localization but it does not hide "errorCode" at all and only changes the message. I want to hide/remove "errorCode" from the response for security reason. If errorCode is present in the response then the user can potentially check and search for particular error code over the internet
That is true.
Sorry for misinterpreting your question. The code cannot be hidden/changed/overwritten. Only the error message. In addition, the error code description does not reveal whether the username or password is wrong (AADB2C90052 and AADB2C90054) have identical descriptions. While AADB2C90053 is a little bit more specific, the other two do not say more about the credential.
Although the error code cannot be changed, it does not pose a security risk for your service. The only plausible risk here is the risk of user enumeration. To be successfully exploited, an adversary must already have a list with compromised accounts (from other sites) or potential victims.
Azure AD B2C does have built-in protections against credentials attacks (https://learn.microsoft.com/en-us/azure/active-directory-b2c/threat-management) which prevent brute-force or password spray attacks. It also has built in per-IP address restrictions (https://learn.microsoft.com/en-us/azure/active-directory-b2c/service-limits?pivots=b2c-custom-policy). And last, but not least, there is the Identity Protection combined with Conditional Access (https://learn.microsoft.com/en-us/azure/active-directory-b2c/conditional-access-identity-protection-overview) which will allow you to configure sign-in block in case of suspicious account activity.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
@Anton Staykov I've just hit this as well (as will most/all Microsoft B2C customers who perform a security audit of their authentication process). I have to say, the answer of "it does not pose a security risk to your service" feels rather short sighted - the first step of any potential attack is potentially inferring valid/invalid users of a service. OWASP recommendation is to "...Ensure the application returns consistent generic error messages in response to invalid account name, password or other user credentials entered during the log in process." (See https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account).
Ideally, the following three error codes would all be the same single error code!
| AADB2C90052 | Invalid username or password. | |
|---|---|---|
AADB2C90053 |
A user with the specified credential could not be found. | |
AADB2C90054 |
Invalid username or password. |
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 82%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMP%3C/text%3E%3C/svg%3E)
Can you explain how the protections you listed apply to username enumeration? I have not been able to find any logging or account lockout policies that pertain to testing incorrect usernames, only passwords against an existing account. There is nothing today that I can find the prevents a malicious actor from taking a giant list of compromised credentials, and using this error code difference to determine which usernames exist.
The risk here is if email is allowed for password reset, you are providing an advisory with a second target they can try. If they determine the compromised credentials they have do not work in the service protected by Azure AD B2C but they have confirmed the account does exist, they can now target the emails of a much smaller subset of users.
Having this error code even in the response provides almost no added value since I can configure via custom policy messaging if I want to alert a user if they may have mistyped their email address or not.
I wrote a similar question and got an answer to solve it with a custom OAuth2 error technical profile. I couldn't get it working yet but maybe it inspires you too: https://learn.microsoft.com/en-us/answers/questions/1371411/azure-b2c-should-not-leak-account-existence-on-sig