locked
Masking the SSN number and Display it like XXX-XX-1111 in the field of the CRM Form RRS feed

  • Question

  • Hello CRM Guru's,

    I have to mask the SSN number and display the value as XXX-XX-1111 in the field.

    I need a JScript as a webresource to do that, if anyone has the Jscript available, can please share with me here.

    I need the same functionality in other fields like Credit Card number and some other ID's like insurance ID and other.

    If anyone can share that would be great help.

    Thanks.


    Puneet Joshi

    Friday, March 30, 2012 3:19 PM

All replies

  • Hi,

    You can use the following code:

    var FlexAccount = Xrm.Page.data.entity.attributes.get("new_flexaccountnumber").getValue();
        
        var expression = /\d{1}/g; 
        var NewFlexAccount1 = FlexAccount.substring(0,12).replace(expression,"X");
        var NewFlexAccount2 = FlexAccount.substring(13,FlexAccount.length);
    
        Xrm.Page.data.entity.attributes.get("new_flexaccountnumber").setValue(NewFlexAccount1+NewFlexAccount2);
    

    Where:

    • FlexAccount is your initial value (ex: 123-12-1111).
    • NewFlexAccount1 = The part of the FlexAccount that will be replace by the "X". (First 12 characters of the FlexAccount).
    • NewFlexAccount2 = The part of the FlexAccount that will not be replaced by the "X". (Rest of the characters of the FlexAccount).

    If you don't want the value to be saved in the DB, you can make the fields as read only, or use the setSubmitMode("never") method on each of the field.

    Hope it helps.

    Friday, March 30, 2012 11:55 PM
  • Keep in mind using an OnLoad form script to change how the number is displayed will only provide a minimal amount of protection to sensitive data.

    • During a slow page load the full number may be able to read the original value before it finishes loading
    • If you encounter a JavaScript error on the form your script may not hide the data
    • The unencrypted data will still be available to users through an advanced find

    Ideally you would not store the full SS number or Credit Card information in a database without encrypting the data. But the problem you will run into with CRM is trying to encrypt the field and keeping it searchable. You would have to go outside the box (like a plugin that encrypts that data and a custom SSRS report that lets you search using the full number against the encypted value) to get something that secured the data and kept it searchable. Hopefully some built in field encryption for Credit Cards and Social Security numbers will be built into CRM in the future.

    Of course the simplest thing is to just have the a field that is last 4 digits instead of the whole number.

    I have added a feature request for Confidential Fields. Please vote it up if you would like to see a native feature for handling credit card and social security fields.

    https://connect.microsoft.com/dynamicssuggestions/feedback/details/734816/confidential-information-fields

    Saturday, March 31, 2012 4:48 AM
  • I have added a feature request for Confidential Fields. Please vote it up if you would like to see a native feature for handling credit card and social security fields.

    https://connect.microsoft.com/dynamicssuggestions/feedback/details/734816/confidential-information-fields

    How about splitting the field into two parts (for SSN, that would be first-5 and last-4), and using Field-Level Security to secure each part in the required ways?

    Thanks,
    David


    Monday, April 2, 2012 8:11 PM
  • Chris,

    I was trying to understand the other point of Advanced Find:

    If i do not mark the field as searchable in the Attributes properties, that field will be never searchable (not in Quick Find and Advanced Find). Is it something doable and could be a possible solution.

    And i like the idea of David to split the fields into two parts (for SSN, that would be first-5 and last-4), what could be the implications you can forsee.

    Please provide feedback.


    Puneet Joshi

    Tuesday, April 3, 2012 2:26 AM
  •  

    The problem with the advanced find is that the searchable option does the opposite of what you probably would want for a field like a SSN. If a any user already has the full SSN it should be fine for them to search for records using it, but you would not want to display the full SSN to them if they don't have it. Turning Searchable to no will prevent the user from filtering or searching on that field, however, they can still add the column to their view or advanced find results to show them the value of that field.

    I think Davids solution might be the best solution without doing a lot of custom programing.

    The risk threats that would still remain is that field level security does not protect the database. So anyone with the appropriate SQL access could walk off with all of the SS numbers and customer information. Also it's not great that a user with field level access to both of the fields could do search which would show a long list of SSNs along with other personal information.

    Monday, April 9, 2012 5:40 PM
  •  

    Also it's not great that a user with field level access to both of the fields could do search which would show a long list of SSNs along with other personal information.

    In that case, why don't you also use Record-level security?  That should help restrict which records are displayed to a given user.  I believe you can configure this on a per-user and per-team basis, from memory.

    As for SQL access, I don't know what you can do about that aside from encrypting the data itself.  Or, preferably, hiring administrators who you can trust. :-)

    Thanks!
    David

    • Proposed as answer by David Nidorf Thursday, April 12, 2012 12:55 AM
    Tuesday, April 10, 2012 12:45 AM