Dynamics 365 Default Email Token Configuration - Security Breach

Yes, you read it correctly, if you go with default CRM configuration for Email token you might land up in a big soup... and the more delay you do to fix the issue, it will cause you more pain to fix the issue thereafter.

This article is having below sections:

1. Understanding of Token structure
2. Understanding of Issue
3. Security breach scenario
4. Possible solutions

Section 1: Understanding of Token Structure:
As per Microsoft documentation (Link here), below is the Token structure



As can be seen above out of 7 digits, the first digit is a deployment tracking number, second is to identify the user, and third is the actual counter having the count related to the number of emails sent

Below are definitions from Microsoft, referred from the same article above

Deployment base tracking number	Configurable from 0-2,147,483,647. Default value is 0. Can be used as an identifier for a specific instance, organization, or deployment of Microsoft Dynamics 365.
User number digit range	Configurable from 1-9. The default range is three (3) digits. This value determines how many digits to use when Microsoft Dynamics 365 generates the numeric identifier for the Microsoft Dynamics 365 user who generated the email activity.
Incremental message counter digit range	Configurable from 1-9. Default range is three (3) digits. This value determines how many digits to use when Microsoft Dynamics 365 generates the numeric identifier for the email activity (not the individual messages that the activity contains). If you use the default value to generate a token with a three-digit number, it will increment the number through 999, and then restart the number at 000. You can use a larger order of digits to reduce the possibility of assigning duplicate tokens to active email threads.

Section 2: Understanding of Issue:
Based on the above understanding if a user sends more than the 'Incremental message counter digit' value then system will generate duplicate tokens
With default configuration the value is '3' then the maximum value for this field will be '999'. In this case, if a single user sends more than 999 emails, the token will repeat and there will a duplicate token generated in the system.
There might be an argument that how a single user can send more than 999 emails if we consider service accounts and other automated outgoing email accounts this is easily possible.

Section 3: Security Breach Scenario:
Now based on our understanding that system is generating duplicate tokens. If we consider the below scenario.

Step 1: Case Officer sends email on 1st May which has generated a token with CRM:0199001

Step 2: Till 15th of Dec if Case Officer has sent 1000 emails then the same token will be repeated CRM:0199001

Step 3: In the case, at this point customer replies to the email which officer has sent on 1st May then as there are duplicate tokens in the system, this reply of the customer gets associated with the wrong case.

i.e. Customer replied to CAS-001 but reply got associated to CAS-1000, due to duplicate token issue

Security Breach: Now if the data of this email contains sensitive data which only a particular set of people should view and others should not. As this email got wrongly associated whoever is supposed to see this email is not viewing it, rather whoever is not supposed to view it are viewing here is the Issue.

If you can relate this issue then you will understand the impact of the issue on the client which it could potentially have. For example, sensitive data like adult social care or family-related concerns are wrongly associated then it could be a disaster.

Section 4: Possible solutions:

Below two steps should be performed for this issue. 

1. One is to fix the token duplication such that duplicates are not generated.

2. Fix the existing data in the system so that wrongly associated emails are corrected.

2nd step should be taken as per business need, and I will post another article on how this can be achieved. 

For now, the solution to fix the token duplication is to take utmost care while setting up the token number configuration

1. Increase the 'Counter digit range' to a bigger number, probably 6-7 digits so that the repetitive duplicate number duration will be increased.
2. Set the 'User digit range' as per the number of users in your system. If you have more than 1k users then default configuration will not work. you need to set the range to 4 digits.
3. This is most important and will be the key to avoiding this scenario going further. Increment the deployment base tracking number in Token format for every major deployment so that the initial digit gets changed then with the above combination of points 1,2 and 3 there are almost no chances of having a duplicate token issue. 

Hope the issue and resolution steps are clear and helps someone who is searching out for the duplicate token issue. I will try to detail out the solution for cleanup of existing emails in the system in my next blog post.

Take care... Thank you for your time.