Seldom Considered CIAM Attack Vectors
Hiya,
For many CIAM systems, a user can register themselves (self-service registration). In this scenario, you want to ensure that the person who is registering actually is the person they say they are.
This is a difficult problem, because you also want to minimize friction and expense. For example, you could require everyone who signed up online to mail in a copy of their government id before accessing your software application. This may be a viable option for certain types of high value accounts. But for many CIAM systems, a delay of days before a user can access their account will be a non-starter.
One common solution is email verification. This works when the login identifier is email, but if you have another identifier that can be used to send a message, such as a phone number, you can verify those accounts as well.
Verification connects the just created account to an account that is owned by the email owner. While you still don’t know who the person is, with verification you at least can be sure that the ‘dan@example.com’ account is owned by someone who has access to that account.
That adds minimal friction to the typical user, while preventing account takeovers and bot attacks. In some CIAM systems, unverified users can even be automatically deleted after some period of time.
Passwords
Even though passkeys are an up-and-coming solution, passwords are still very very common with CIAM systems. There’s a lot of information about how to manage them, what algorithms should be used to hash them, and how to protect them. I’m partial to the NIST guidelines, myself.
But for all the focus on protecting passwords, there are other CIAM workflows you should consider. There are two other workflows that affect this verification:
login id changes
account recovery
Login Identifier Changes
When the verification of an account is tied to a message sent to a login identifier such as an email address or a phone number, changes to that login identifier need to be treated as a risky operation.
Consier this scenario:
As an attacker, I register for an application with dan@example.com, an email address I control.
I verify my account.
I then change my account identifier to dan@whitehouse.gov.
If the CIAM system doesn’t re-verify the account, then I have a verified account with an email address that probably doesn’t belong to me.
Re-verification on login identifier change should send an email to both the new and the old address. The email to the new address should include a link or code, similar to the initial verification messes. The email to the old address should include the new email address and a message that if this change is not expected, the user’s account may be under attack and to contact customer service immediately.
Re-verifying serves a couple of other purposes:
If someone makes an error in their new email address, re-verification calls that out. If someone meant to change their email address from dan@example.com to dan@gmail.com, but accidentally types in dan@gmial.com, re-verification lets them know. The CIAM system or application will need to let the user know that the new address has not been verified.
It notifies the user of account takeover attempts. If I get an email to dan@example.com saying that my login identifier has been changed to dan@whitehouse.gov, then I know something funny is going on with my account.
Account Recovery
Self-service account recovery is one of the main selling points of CIAM systems. If a user forgets their password, they can reset it by sending an email (or SMS or other message) to another account they control. This is usually the login identifier.
Account recovery messages should not be sent to unverified accounts.
Account recovery can also implement additional security checks, because access to an email inbox may not be enough proof. After all, it is possible for an attacker to take over an email inbox, and then submit account recovery requests for any number of accounts. From this 2008 post:
With [your email account], they have the keys to your forgot password? life. They can quickly go to accounts that you have all over the shop, simulate a forgotten password use case, and now they DO have access to your account info.
Other ways that a CIAM system can help secure account recovery workflows:
invalidate sessions if this is completed, which will alert the attacked user
send messages when the workflow starts, either to the user or a SIEM system
prompt for other information about from the user (a previously captured secret, user behavior only the legitimate user would know such as a previous shipping address or order amount)
require another factor of authentication (MFA) to complete the recovery
Wrapping Up
Self-service registration, when paired with account verification, can help you help your customers while making sure that they are who they say they are. But allowing anyone to make an account on your system opens up subtle attack vectors, so make sure you consider and protect against them.
Dan