I overlooked the “eval” call in the decoder, and thought it was just unescaping the text.

The original anonymous poster (aaa) was absolutely correct that Paul Gregg’s obfuscation is more powerful than the one in EmailShroud.

I am very sorry, Paul. Thank you for correcting me.

This might be a opportunity to hint that I have been spending some time on EmailShroud 2.0. In response to requests here, increasing the obfuscation level is on the list of priorities [whether I think it is overkill or not :-)]

…Paul Gregg’s obfuscator as an an example, but this is one of many - looks very secure at a glance, but is actually relatively lightly encoded. Because the technique used to encode it is (a) simple and (b) common, I would actually expect it to be cracked by spammers ahead of EmailShroud.

Thanks for the references, however Julian, I would like to counter your assertion about my encoding method. If you decode the javascript you would see that it is not trivial to decode back to the actual email address or link.

For example, I encoded the web address of this page using my routine which produces the following code:
eval(unescape(’%76%61%72%20%73%3D%27%74%68%70%74%2F%3A%77%2F%77%77%73
%2E%6D%6F%74%65%69%68%6B%6E%64%6F%2E%64%6F%63%2F%6D%64%6F%74%64%69%68
%6B%6E%6E%69%2F%67%6D%65%69%61%73%6C%72%68%75%6F%2D%64%6F%77%64%72%72
%70%73%65%2D%73%6C%70%67%75%6E%69%2F%27%3B%76%61%72%20%72%3D%27%27%3B
%66%6F%72%28%76%61%72%20%69%3D%30%3B%69%3C%73%2E%6C%65%6E%67%74%68%3B
%69%2B%2B%2C%69%2B%2B%29%7B%72%3D%72%2B%73%2E%73%75%62%73%74%72%69%6E
%67%28%69%2B%31%2C%69%2B%32%29%2B%73%2E%73%75%62%73%74%72%69%6E%67%28
%69%2C%69%2B%31%29%7D%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%27
%3C%61%20%68%72%65%66%3D%22%27%2B%72%2B%27%22%3E%6C%69%6E%6B%20%74%6F
%20%65%6D%61%69%6C%20%6F%72%20%75%72%6C%3C%2F%61%3E%27%29%3B’))

However, if you actually decode that you will see:
var s=’thpt/:w/wws.moteihkndo.doc/mdotdihknni/gmeiaslrhuo-dowdrrpse-slpgu
ni/’;var r=”;for(var i=0;ilink to email or url’);

I hope you would agree that it certainly wouldn’t be cracked quite as easily as you suggested previously.

Regards,

PG

It appears to be limited to pages being served as strict XHTML - that is the DOCTYPE at the beginning of the web page source is for XHTML 1.0 Strict. It also doesn’t affect Internet Explorer, but does affect Firefox and Opera when JavaScript is turned on

I have a fair idea of the cause, but I haven’t got a clear solution for it yet, and I don’t expect to get a chance to implement a solution for a few months.

In the meantime, if you are bold enough to go for strict XHTML compliance, I apologise and recommend you don’t use EmailShroud 1.0.1.

You can check for yourself what your blog’s theme uses by doing a View Source on one of your blog pages, and looking for the text “XHTML 1.0 Strict” hidden in the DOCTYPE line at the very top. Most people will see the word “Transitional” hidden inside it instead; those people should be fine.

This isn’t a known bug. I just retested it with the latest version of Firefox on Windows, and I am not seeing anything unexpected. I’ve not heard any other complaints from Firefox users either.

Perhaps you could email me more details of the problem (OS, software versions, steps you took) and/or a screenshot of the problem.

Please ensure the Status Bar is turned on (under the View | Status Bar menu.)

Thanks,

Julian

Thanks for your comments. I appreciate that it is important with any software related to security to have people taking a critical look at how it works.

The points that you raise have already been covered above, but let me address them again for clarity.

First, I would warn you that the first example of obfuscation by using escape codes - you use Paul Gregg’s obfuscator as an an example, but this is one of many - looks very secure at a glance, but is actually relatively lightly encoded. Because the technique used to encode it is (a) simple and (b) common, I would actually expect it to be cracked by spammers ahead of EmailShroud. (That said, it is far better than nothing!)

On the other hand, the second Enkoder example seems to be stronger, and I applaud it - I have had it as a reference in the Further Reading section for some months, so it has already provided some inspiration.

As I wrote in the comments above, I did consider the issue that spammers could spend effort to crack EmailShroud:

If EmailShroud became insanely popular, it might start to become worthwhile for a spammer to automate the detection of EmailShroud and decode the addresses.

I did start out with some ambitious plans to encrypt the email address with a randomised secret key to make this even more secure, but I realised I was kidding myself. I will deal with the encumbent problems of overwhelming popularity when (and if) they occur. Until then, the simple obfuscation should be more than sufficient. It’ll also load faster than a full solution.

When the proportion of WordPress blogs that use EmailShroud rises above, say, 0.5%, come right back here for a slower, more secure solution!

While the popularity of EmailShroud has been personally satisfying to me, I don’t think I am close to approaching that sort of level!