Emailing Tax Returns to Clients

[FEDUKE404]

Follow-up question

Is the potential problem with transmitting a "tax return" or with transmitting Social Security numbers??

Most software now automatically blanks a large portion of any Social Security number on the client copies.

FE

[dtlee]

OK, I have searched around, attended seminars etc. I hear speakers mention that we should/must use some kind of password protection or encryption when emailing a tax return. Of course they are not specific.

I cannot find it anywhere in Circular 230 where it even mentions anything.

Where does it say we must do this and what would be the proper method?

We should all be concerned about this if it is true.

Is there a definitive statment anywhere which absolutely requires us to do this?

I am not certain since I have seldom gotten anyone to cite anything other than, “a class I took” as the source of these requirements. Sometimes I have gotten sales literature from a vendor as a citation for what is required.

From personal research, I believe that these requirements refer to the safeguards rule of the Gramm-Leach-Bliley Act. This act requires that financial institutions design, implement, and maintain safeguards to protect non-public client information. This information includes any information a consumer provides to obtain a financial product or service from the institution, any information about a consumer resulting from any transaction with the institution involving a financial product or service, or any information otherwise obtained about a consumer in connection with providing a financial product or service to that consumer. The act applies to any type of financial institution, which it defines as any entity that is significantly engaged in financial activities. It goes on to state that financial activities include preparing individual tax returns.

My understanding of the Safeguards Rule is that it does not outline specific implementation guidelines for organizations to follow. It appears to require that organizations implement safeguards that are appropriate to their environments and operations when storing (physical or electronic), transmitting (faxing, emailing, mailing, etc.), or disposing of this information.

That is where it starts getting hazy for me. I believe that many course instructors and vendors then extrapolate that certain safeguards are specifically required. If I were recommending safeguards, I would likewise recommend more rather than less. However, in discussions with peers who recommend secure encrypted website portals for transferring data to and from clients, I find many who are not consistent with their implementation of security. Some use these secure sites but never encrypt information in the text of an email. In fact, many who say they use encrypted email are really only encrypting the attachments and passing unencrypted non public information in the body of the email. Some do not use encrypted storage on their PC to protect the data against hackers or repair shop snooping. Some do not encrypt or password protect pdf files on CDs or DVDs they mail to clients. Some do not use certified mail to mail information to clients. I am not advocating using certified mail for everything; just pointing out that there are inconsistencies. Even the IRS routinely uses first class mail and faxes for communicating non public information. Certainly it is easier (and seeming less illegal) to steal large amounts of information electronically than it would be by stealing regular mail.

Personally, I believe that first class mail and faxing are not invalid tools for transmitting client data. I am a little more concerned about sending information (like the date the return was accepted or the amount of the refund) via email, especially in the body of the email. However, this is where it becomes quite murky.

There are dozens of encrypted email services available. Many require both the sender and recipient to subscribe to the same service or install the same software tool in order to read the email. §7216 defines tax return information even more broadly than the Gramm-Leach-Bliley Act defines non public information. If I learn the email address of a client through a tax return engagement, I am forbidden from sharing that information with a third party without prior signed consent. While I believe that putting an address on an envelope or an email does not violate §7216, I am not equally convinced that providing a client’s email address to a vendor who wants my client to install decryption software is equally exempt from the disclosure rules.

I believe we probably should consider using encrypted email communication with clients to document appointments, e-file transmission dates and other nonpublic information although I do not believe this is specifically required by the Gramm-Leach-Bliley Act. However, I think requiring a client to register with a vendor to receive such encrypted email services is not permitted under §7216 since we cannot make our services contingent on them allowing us to share their information with a third party.

Having our own secure portal and encrypted email service would probably be the correct answer to this problem, but barring that, I think we each need to evaluate our own practice and what the risks involved are.

As some have indicated on this forum, it appears that many of the recent rules imposed on preparers are designed to make it financially impractical for a small firm or independent preparer to operate. I have gotten quotes from secured service providers that make the cost of my tax preparation software seem trivial.

I would appreciate the opinions of others, especially anyone who has successfully implemented encrypted email with clients without having it be so complicated that clients become frustrated trying to open them.

[Koss]

E-mail and Encryption

This is something I am keenly interested in, so I'll weigh in with a few comments and observations...

As noted by DMICPA, IRS regulations do not explicitly state that tax professionals must use any type of encryption at all, nor do they prohibit e-mailing tax data to a client.

There are one or two IRS publications which strongly recommend encryption of sensitive taxpayer data by tax professionals and other segments of private industry (i.e., mortgage brokers and others that have legitimate business needs for taxpayer data).

But the official IRS policies and procedures that require encryption are not applicable to tax professionals. These policies apply to transmitters, such as Intuit or Drake, who are sending data directly to the IRS, and to other government agencies, such as state and city tax departments that receive data from the IRS.

With that being said, I agree with Gary2 that the definition of what is adequate security may be a matter of community standards, or industry standards. I highly recommend using some form of encryption, both for data that is stored on hard drives at a tax pro's office, and for data that is sent by e-mail.

I do not know of any federal regulations that require masking of SSNs by tax professionals. The IRS is experimenting with such a requirement for certain issuers of information returns.

The reference to a law in Nevada, posted in this thread much earlier this year, is very interesting. But that law appears to have been repealed. I think it was overreaching.

One post said that PDF encryption may not be sufficient, and suggested that you need a zip utility such as WinZip. I tend to disagree. It is certainly true that many types of PDF encryption do not meet IRS encryption standards. But as I noted earlier, those standards are not applicable to tax professionals; they are meant for government agencies and for entities that are conducting electronic business directly with the IRS.

I use PDF reDirect Pro, which uses 128-bit encryption. IRS standards require 256-bit encryption. I think 128 is adequate if you use complex passwords that cannot be cracked with a dictionary attack or guessed by someone who knows the client. So, for example, the password should not be the client's daughter's name. It also shouldn't be her name followed by her six-digit birthdate.

I am not intimately familiar with the full, professional version of Adobe, but a cursory Google search indicates that the most recent version of Adobe may in fact support 256-bit encryption. If so, this means that you can encrypt a PDF document using government-grade encryption. You don't need to zip the file to achieve that objective.

I generally do not send tax data by e-mail without using encryption. I think it is a good business practice. Too many clients simply do not understand the risk, however small it may appear to be. Too many clients use free e-mail accounts, such as Yahoo, Gmail, and MSN Hotmail. These e-mail services are not secure. The providers do what they can, and they take security seriously. But large clusters of these accounts can and do get compromised, and individual accounts can be hacked if the user doesn't take the right precautions. Sarah Palin's Yahoo account was hacked by a college kid who was able to correctly answer the "secret questions" for password recovery. (I think Yahoo has since changed their password recovery process.)

With that being said...

When it comes to the question of whether encryption is really required for a tax pro who wants to send sensitive data to a client by e-mail...

I stand truly in the middle, with no strong opinion one way or the other.

I stand by my assertion that there is nothing in Circular 230 or in the Internal Revenue Code, or elsewhere in the Treasury Regulations, that specifically applies to tax return preparers. The IRS only makes suggestions and recommendations.

However, there are some other regulatory schemes which arguably apply to us. I think this is an evolving area of the law, that is open to interpretation, and has yet to be tested.

The Federal Trade Commission has developed something called the Financial Privacy and Safeguards Rules, and data security is also addressed in the Gramm-Leach-Bliley Act.

In Protecting Personal Information: A Guide for Business, the FTC writes that

Regular email is not a secure method for sending sensitive data. The better practice is to encrypt any transmission that contains information that could be used by fraudsters or ID thieves.

See page 7 at http://business.ftc.gov/sites/defaul...business_0.pdf

This assertion may not have the force of law. It appears in an FTC publication, and it may be nothing more than an opinion. But it is arguably a legal opinion, expressed in writing, by an administrative agency charged with enforcing certain regulations.

And according to the IRS,

Financial institutions as defined by FTC include professional tax preparers, data processors, their affiliates, and service providers who are significantly engaged in providing financial products or services.

See page 3 of IRS Publication 4557, Safeguarding Taxpayer Data.

So you can begin to connect the dots. There is a mountain of regulatory law that governs financial institutions, and requires encryption, when it comes to electronic processing of payments, such as credit card transactions and electronic check payments. Tax professionals may or may not be subject to this body of regulations. The FTC may think we are financial institutions, but I'm not convinced. I vaguely recall a piece of legislation or regulation that specifically excluded CPAs and attorneys from being considered financial institutions by the FTC. But maybe that exclusion was only in effect for a certain period of time.

Merchants, such as retail stores and restaurants, comply with current privacy laws by swiping credit cards, and not keeping a paper copy of the entire card number. The electronic transmission, of course, is encrypted by the financial institution. Tax professionals comply with most of the applicable regulatory baggage simply by using tax software, which encrypts the data before sending it to the transmitter or host.

But even if you don't offer RALs or RACs, you are still entering your client's RTN and DAN for direct deposit. And you are handling loads of sensitive data in documents such as brokerage statements and 1099s. You start to look a lot like a financial institution when it comes to your responsibility to protect client data.

Whether we are subject to encryption requirements beyond the behavior of our tax software is an open question.

Is your hard drive containing your client data encrypted? If not, what happens if your office is burglarized and the PC is stolen?

The risk of identity theft in that scenario is, in my humble opinion, actually rather low. A PC stolen in a small office burglary is likely to be sold on the black market. Whoever finally gets ahold of it is likely to wipe it clean. Even if they don't, they may not realize what they have. And if they do realize what they have, they may not have the resources to use it for any evil purposes.

But however low the risk may be, the tax pro whose unencrypted PC has been stolen faces a terrible dilemma. If you tell your clients their information has been stolen, they will be worried, and unhappy with you, and you will probably lose some business. But if you don't tell your clients, and the data is used for unlawful purposes and traced back to you, the consequences will be a thousand times worse. Most states now have laws requiring disclosure of data theft. And even if it isn't required, the tax pro could be held liable for the identity theft if it can be shown that it could have been prevented if the data theft had been disclosed to the client.

Much safer to encrypt the hard drive. If the PC is stolen, you should still tell your clients, but you can confidently tell them that the data was encrypted, and that there is virtually no risk.

BMK

[dtlee]

For IRS purposes, it's in the same place where it says you can't leave your office and file cabinets unlocked. In other words, it's not an explicit requirement, but simply proper care versus negligence. Keep in mind that "common practice" can influence what "proper care" really means.

On the other hand, as pointed out earlier in this thread, various states may have stronger requirements.

Publication 4557 includes many suggestions for securing client information. It has a checklist for safeguarding data, but does not say whether any of them are mandatory. It describes them thusly: "The following checklist includes many activities that can be included in an information security program. It can help you put in place security procedures and controls to protect taxpayer information. It is important to consider all the safeguards that are applicable to your business."

[Gary2]

This is something I am keenly interested in, so I'll weigh in with a few comments and observations...

Tremendous post. Thanks for taking the time to write it.

One post said that PDF encryption may not be sufficient, and suggested that you need a zip utility such as WinZip. I tend to disagree. It is certainly true that many types of PDF encryption do not meet IRS encryption standards. But as I noted earlier, those standards are not applicable to tax professionals; they are meant for government agencies and for entities that are conducting electronic business directly with the IRS.

I use PDF reDirect Pro, which uses 128-bit encryption. IRS standards require 256-bit encryption. I think 128 is adequate if you use complex passwords that cannot be cracked with a dictionary attack or guessed by someone who knows the client. So, for example, the password should not be the client's daughter's name. It also shouldn't be her name followed by her six-digit birthdate.

I am not intimately familiar with the full, professional version of Adobe, but a cursory Google search indicates that the most recent version of Adobe may in fact support 256-bit encryption. If so, this means that you can encrypt a PDF document using government-grade encryption. You don't need to zip the file to achieve that objective.

I haven't looked at the current version of Adobe Acrobat (the editing software, not the free Acrobat Reader) to know what's available currently. Historically, the issue with some applications, such as early versions of Acrobat, Quicken, etc. is that they used passwords without providing any encryption. Or if they did, it was trivial encryption easily hacked by an amateur cryptographer. The main purpose of such passwords was to keep the eight year old from reading, or worse, corrupting the parents' records. Or at businesses, to keep mostly honest employees from sneaking a peek at documents that weren't meant for wide distribution. It was never intended to protect the data from malicious attacks by determined, but unskilled people.

Even now, I see Excel spreadsheets that use such passwords to lock fields against changes without hiding the data. Obviously that's not encryption, at least not for confidentiality.

So, if the current version of Adobe Acrobat provides true encryption, then it's time to replace the conventional wisdom that it was worthless with new conventional wisdom, namely make sure you're using a recent version.

[Gary2]

For what it's worth, Massachusetts has a relatively recent data privacy law that applies to all businesses who have private information of their customers. A search for "Massachusetts privacy law" will turn up more than you want (and more than I can sift through right now to find a single, good overview).

[dtlee]

The problem with Adobe is that it attempts, more than most products, to ensure backwards compatibility with earlier products.

Before Adobe Acrobat 9, they did not offer 256-bit AES encryption. For Adobe Acrobat 7, they used 128-bit AES encryption. For Adobe Acrobat 6, it was something called 128-bit RC4. When you have clients who use an older version of Acrobat, you sometimes run into problems. I will share with you this quote from a client using Acrobat Reader 5.0, "I don't know how to change it and my son won't be home from school until May. He is the only one who changes anything on my machine." The more compatible my pdf files are with older versions, the less secure it will be.

I am not a user of WinZip, but the tool I use allows creation of password protected, self-extracting archives using Rijndael AES 256 bit encryption. These archives will open themselves without having to provide software to the clients and prompt the user for a password before allowing access to the file. Thus, I can create a self-extracting archive which will automatically open a pdf file if Adobe Reader is properly installed on the recipient's machine.

[Koss]

Adobe Acrobat Encryption

I don't use Adobe Acrobat. But I find all of this interesting enough that I did a little research.

Adobe Acrobat offers various levels of encryption. As Doug noted, there is an effort to maintain some degree of backward compatibility. The description below applies to Adobe Acrobat and also to the capabilities of Adobe Reader. In this sense, this information is relevant to anyone who uses encrypted PDFs.

Acrobat 3.x and 4.x support only 40-bit RC4 encryption.

Acrobat 5.x and 6.x support 40-bit RC4 and 128-bit RC4.

Acrobat 7.x, 8.x, and 9.x support 40-bit RC4, 128-bit RC4, and 128-bit AES.

AES is considered to be much stronger than RC4.

Adobe X supports 40-bit RC4, 128-bit RC4, 128-bit AES, and 256-bit AES.

256-bit AES is the gold standard. It complies with the requirements of most government agencies, and if sufficiently complex passwords are used, it simply cannot be cracked.

The Adobe technical documentation, to borrow a phrase from the US Tax Court, is not a model of clarity. But it appears that Adobe X can be used "to apply 256-bit AES encryption to Acrobat 8 and 9 documents." Thus, one may infer that a PDF that has been encrypted with 256-bit AES can be opened with Acrobat 8 or Acrobat 9.

But it is clear that 256-bit encryption is not supported by any version of Acrobat earlier than 8. And as Doug noted, this may present issues for less sophisticated clients. Anyone running Adobe Reader 7.x or earlier simply shouldn't be running it. It is no longer supported, and they will eventually encounter compatibility issues that have nothing to do with encryption. But that doesn't help with a client who doesn't get it, or doesn't understand how to download and install the new version. We're talking about clients who barely understand how to save an attachment to an e-mail message. They may save it, and then be unable to figure out where they saved it. When you start talking about what application they need to open the file, you might as well be speaking a foreign language.

But the short answer is that Adobe Acrobat and Adobe Reader, in their most recent versions, do indeed support government-grade 256-bit AES encryption. Adobe Reader 8.x and later can open these encrypted PDFs. You need Adobe Acrobat X, the most recent version, in order to create a PDF that is encrypted with 256-bit AES.

That doesn't address the question of whether lower grades of encryption are suitable for use in a tax practice.

40-bit RC4 is meaningless. Widely available software can be used to crack a 40-bit RC4 password, regardless of how complex it is. It may take a while--like maybe a week or more, in what is known as a brute force attack. The software simply tests every possible encryption key. The underlying mathematics is over my head. But it can be done, and it has been done. The software that does this is totally legal, and the better versions of this software are available for just a few hundred dollars. You don't need IT skills to do this.

128-bit RC4 encryption can be easily cracked with a dictionary attack if the password is too easy. If you use serious passwords, with industry standard criteria such as numbers, letters, and special characters, and a minimum length, then this encryption is much more difficult to crack. Just how vulnerable it is appears to be an open question in the crypto community. The consensus seems to be that when used properly, 128-bit RC4 might be theoretically vulnerable, but that it would take years of trial and error, by high-powered computers, to crack the encryption.

128-bit AES encryption is superior to 128-bit RC4, but is still not considered strong enough for the US government, financial institutions, and the health care industry.

Whether the government standard really means anything is never going to be resolved. Even if Congress or the IRS explicitly mandates that tax pros must use encryption that meets government standards--currently AES-256--some IT pros and mathematicians may still disagree, and argue that other forms of encryption provide adequate security. Sometimes our government does stupid things, and we comply because we want to stay in business, and we don't want to become a test case. That doesn't mean the government is right.

Currently, I don't think anyone in the crypto community has shown any form of 128-bit encryption to be systematically broken. Believe it or not, there are people who do this for a living. Some even do it without getting paid. Grad students write dissertations about this stuff. Somebody, somewhere, is working on it right now.

I don't think 128-bit encryption, when used properly, can be cracked in a reasonable amount of time, even by professional cryptographers with significant resources. But I suppose that depends on your definition of reasonable.

BMK

[dtlee]

Thanks Burton for the detailed information.

I am certain that the information you posted is generally correct, but will share an anomaly. I use Adobe Acrobat 9 on my machines and am attaching a sample file which according to what I can determine, is using AES 256-bit encryption. It was encrypted with Adobe Acrobat 9 Pro Extended Version 9.4.6 and uses the "document open" password "TTB" as well as a "permissions" password. The permissions password is ignored by many products which will allow those products to use the document in ways the document's creator wanted to inhibit.

It is possible that this capability was not available in all versions of Adobe Acrobat 9, but this help page seems to indicate that it was available in the Standard Edition as well and does not indicate a particular release level:

http://help.adobe.com/en_US/Acrobat/9.0/Standard/WS58a04a822e3e50102bd615109794195ff-7d6c.w.html

If you view this in a tool that allows you to view the document properties, you should be able to see that the security Encryption Level is 256-bit AES. I have no way of confirming that they actually achieved this or were simply proclaiming that they used it, but it would be a big negative for Adobe to lie about something like that.

Thanks again for your input.

[Koss]

PDF Passwords

Doug--

Are you saying that because the permissions password doesn't do what it should, i.e., it does not always prevent third-party applications from modifying the document, that you do not trust the security and effectiveness of the open document password?

BMK

[Gary2]

128-bit RC4 encryption can be easily cracked with a dictionary attack if the password is too easy. If you use serious passwords, with industry standard criteria such as numbers, letters, and special characters, and a minimum length, then this encryption is much more difficult to crack.

Any encryption algorithm can be easily cracked with a dictionary attack if the password is too easy. There are other tactics to help defend against dictionary attacks, but 256 bit AES won't protect you if your password is "taxguru" or "1040".

Currently, I don't think anyone in the crypto community has shown any form of 128-bit encryption to be systematically broken. Believe it or not, there are people who do this for a living. Some even do it without getting paid. Grad students write dissertations about this stuff. Somebody, somewhere, is working on it right now.

I don't think 128-bit encryption, when used properly, can be cracked in a reasonable amount of time, even by professional cryptographers with significant resources. But I suppose that depends on your definition of reasonable.

The reason that RC4 has fallen out of favor is that a number of attacks on it have been published. Note that RC4 is designed to use a variable key size, but the underlying algorithm is the same whether the key is 40 bits or 256 bits. I don't know how "published attacks" translates into "how long to break", but I certainly wouldn't make general statements.

[dtlee]

Doug--

Are you saying that because the permissions password doesn't do what it should, i.e., it does not always prevent third-party applications from modifying the document, that you do not trust the security and effectiveness of the open document password?

BMK

Burton,

Not quite. Sorry if that was not clear.

When properly implemented ("properly" by Adobe standards) what the "permissions" password does first of all, is that it prevents a user who has only the "document open" password from removing the password protection from the file. Thus, if you protect a tax return pdf with both passwords and do not provide the client with the permissions password, you have also ensured (to the extent that you are able) that the client cannot store the pdf file in an unprotected mode. The permissions password can also be used to prevent the client from cutting and pasting information from the pdf, from editing it, or even from printing it.

If only the document open password is used, and the client is using Adobe or a full clone, the client would be able to remove password protection and make other changes to it since that password would provide full access to the editing capabilities of the pdf utility the client is using.

My other comment is that I have seen some products which ignore the permissions password and allow editing a document with only the document open password, (even when a permissions password is set). Since Adobe does not appear to have any control over the way their security is implemented by other vendors, it is the permissions password which appears to be easily bypassed by other vendors who have chosen not to comply with it's use.