4

I work on a web application that manages information about transmission setups and processes client transmission statistics to generate billing charges for the services used by these clients.

The team that supports these clients is able to view setup information, including account information and user access controls meet requirements for their production usage of this information.

For testing, data is moved to testing/development environments where the account numbers need to be 'sanitized' or 'transformed' in the best way to avoid the testing/development environments from exposing these account numbers.

I have done work with encrypting data and hashing data and I am looking for suggestions/comments about what are best practices for the 'sanitization/transformation' of these account numbers.

Thanks for any feedback you can provide.

1
  • 5
    As a best practice, you should never use valid accounts on a Dev/QA environment, I suggest you generate fake ones. getcreditcardnumbers.com
    – Kotzu
    Dec 15 '14 at 19:12
1

If you must absolutely use production data in DEV, you may produce a table matching actual account IDs with random ones, then destroy or adequately protect the table after transferring data.

 REAL ID  |  FAKE ID
 --------------------
 0000001  |  3287638
 0000002  |  5917382
 etc.

Beware DEV data may include other information connected to the account number (e.g. an email) allowing a malicious insider to retrieve the account number from public data. Another risk is that malicious insiders try brute-forcing all accounts in production with configurations found in DEV.

1

In addition to the technique Enos mentions, another common technique is to use hashes. For many testing requirements hashes will be sufficient. Couple of gotchas, though:

  • If the space isn't big enough, collisions could cause problems
  • If you have logic that does something like matching account types by the first 4 digits being 0123, then hashing will fail on this type of logic

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.