Customising log4j logging for sensitive data

Question

I have a class which contains sensitive information (Credit card info, phone numbers etc).

I want to be able to pass this class to log4j, but have it obscure certain information.

If I have a class UserInformation which has getPhoneNumber, getCreditCardNumber methods, how would I customise log4j or this class so that it will obscure the numbers correctly.

I want the credit card number to be output as xxxx-xxxx-xxxx-1234 and the phone number to be output as xxxx-xxx-xxx given that these would be 1234-1234-1234-1234 and 1234-567-890

Thanks

Answer 1

You could try to implement this by writing a custom log record formatter that obscures those patterns. But I think that is a bit dodgy ... because someone could accidentally or deliberately circumvent this by tweaking the logger configuration files, etc.

I think it would be better idea to do one of the following, depending on how you are assembling the log messages:

• Change the logger calls in your code to assemble the log messages using alternative getter methods on UserInformation that obscure the sensitive fields.
• Change the toString method on UserInformation to obscure the details.

Answer 2

Update: The best option is probably to wrap your real objects in an Obfuscated-ClassName wrapper that implements the same interface but returns obfuscated versions (by delegating to the real object and obfuscating the result) and hand those to the logging system. This only works if you are actually passing in these objects yourself, and not if they are part of an object tree - that might make the whole situation a bit more complex.

old:

Maybe you should just add getPhoneNumberForLogging()/getObfuscatedPhoneNumber() type functions? (Of course you have to take into account that if you hand an object containing this data to another object/process you cannot control access to the 'normal' functions so technically you don't shield the data at all - although it might be possible to make the methods that show sensitive data package local accessible only?)

You could also investigate the call stack on every call and try to figure out if you want to return the full data or the obfuscated version - this will add quite a bit of overhead and might be very tricky to debug.

Answer 3

I'd write an obfuscating formatter for those fields and use that to write to the log file.

I'd also ask why you would continue to use String primitives instead of objects that could encapsulate the appropriate behavior.