function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
SFDC DevlSFDC Devl 

Account attachments Encryption and Decryption in SFDC using crypto class

I am looking to encrypt attachments on Account and decrypt to sepcific users. I know how to do the encryption but it is encrypting the attachments on all the objects.

1) how to limit the encryption of attachments to a specific object ?

2) how to decrypt to the users?

3)do I need to develop Visual force page to show the attachments?

4)how to protect the key stored in custom settings?

 

Can someone guide me the process of decryption and show the attachments to some users in SFDC?  Thank you...

Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox

1. Check ParentId.getSObjectType() against Account.SObjectType, and encrypt the file only if this passes.

 

Ex.

 

for(Attachment record: Trigger.new)
    if(record.ParentId.getSObjectType() == Account.SObjectType)
        // Encrypt the body here

2. Since you can't easily decrypt any other way, the easiest solution is to decrypt to a Document object, then have the user download the file. You can store the Document in the user's "Personal Documents" folder to restrict who has access to the document.

 

Ex.

 

Document d = new Document(FolderId=UserInfo.getUserId(), Body=DecryptedAttachment.Body, Name=DecryptedAttachment.Name, ContentType=DecryptedAttachment.ContentType);
    insert d;
// Show a link to have the user download document.

3. As you might imagine from 2, you'll definitely need a Visualforce page to perform the decryption.

 

4. Use a managed package in a developer org, and make sure that the custom settings are "protected." Once you install this package into your org, those settings won't be accessible outside your managed code.

All Answers

sfdcfoxsfdcfox

1. Check ParentId.getSObjectType() against Account.SObjectType, and encrypt the file only if this passes.

 

Ex.

 

for(Attachment record: Trigger.new)
    if(record.ParentId.getSObjectType() == Account.SObjectType)
        // Encrypt the body here

2. Since you can't easily decrypt any other way, the easiest solution is to decrypt to a Document object, then have the user download the file. You can store the Document in the user's "Personal Documents" folder to restrict who has access to the document.

 

Ex.

 

Document d = new Document(FolderId=UserInfo.getUserId(), Body=DecryptedAttachment.Body, Name=DecryptedAttachment.Name, ContentType=DecryptedAttachment.ContentType);
    insert d;
// Show a link to have the user download document.

3. As you might imagine from 2, you'll definitely need a Visualforce page to perform the decryption.

 

4. Use a managed package in a developer org, and make sure that the custom settings are "protected." Once you install this package into your org, those settings won't be accessible outside your managed code.

This was selected as the best answer
SFDC DevlSFDC Devl

Thanks for your response sfdcfox

 

#1 Your code helped in encrypting attachments with a specific object.

 

For #2, We have a requirement not to store the decrypted data in Salesforce.com. If I use Document object, the decrypted data is stored in SFDC which i dont. Is there anyway to download the attachment to the users desktop by providing the link to download on a Visualforce page and the controller should have a logic to decrypt the attachment and save to user's desktop. I am not sure if this is possible.

 

For #4, Since i have to use custom settings to store the key, I should definitely store the key in Salesforce.com. I think i cannot store the key outside of Salesforce. Let me know if there is way.

 

I am new to Encryption/Decryption on attachments. Also my requirement not to store any information(Decrypted attachments, aeskey) in salesforce is making the task difficult i guess. Can you please help? Thank you and appreciate your help.

sfdcfoxsfdcfox

There's no way to emit binary data in salesforce.com's Visualforce. If your attachments are text only, you could indeed allow the contents to be downloaded from a Visualforce page using the content type of the file, removing any need to store the data in salesforce.com. Without some extra work on your part, you'll find that getting that decrypted data to the user in binary form will be a complicated task. I'd imagine a signed Java applet that lets the user download the data to their computer. The suggestion of using a Document is that the data will be accessible only to the user performing the decryption. You might make a background process that periodically deletes these decrypted documents.

 

Using a managed package will keep the data in salesforce.com, but it will be siloed away from the user, so there's no possibility that the key can be intercepted. This is one of the design intents of managed packages, to keep protected code and data out of the hands of people that shouldn't need to directly access the data. Of course, you can store it in a regular custom setting, but this means your key is exposed at minimum to the administrators of the organization, and most likely all users with any access to Setup. I don't see a way of protecting the key universally without a managed package. You don't need to pass a security review though, unless this package will eventually be on the AppExchange.

 

You could store the key externally, and have the server fetch the key using a web service or REST call, if you wanted to. Your security would only be as secure as the remote server, though, and may affect your users' loading time. You could also embed the key inside the source code, but doing this also means you'd want a managed package to avoid exposure. Perhaps you could take a look at https://wiki.developerforce.com/page/Secure_Coding_Storing_Secrets for more information on storing secrets.

 

Alternatively, you could encrypt natively in salesforce.com, and only allow decryption on a remote server. This would let you emit the headers necessary for downloading binary data. Again, security is complicated by this approach, but it's not impossible.

SFDC DevlSFDC Devl

Thank you very much. I will have to do some research. But your above solution to store the decrypted files on documents folder and storing the key using managed packages is definitely helpful for those who dont have the requirement (not to store the key in salesforce and decrypt the file to user's desktop) as mine and hence I am marking it as solved. Thank you again.