Friday, May 17, 2013

Why is my InfoPath form failling to publish as a Site Content Type in SharePoint 2007/2010?

First of all, this assumes you have a form in InfoPath (any version older than 2013, I haven't tested that one), and that you want to publish that form into a SharePoint site as a Content Type.  This is advantageous to the site, because that form can be reused as much as you want in the Site Collection (although they work only so well in Content Type Hubs, the reason being the template XSN file crosses the Site Collection barrier, which is generally a no-no).

BUT:  You need to be careful how you document your content type in the Description box in InfoPath.  Here is where the Office team messed up:  They don't do any encoding or sanitizing of the text in that box before sending it off to the Webs web service in SharePoint (Webs.asmx).  As a result, any XML tags, or HTML tags, or hell, ANY stray double quotes (") or greater-than/less-than symbols (<) (>), will make their way into the call, and gum up the whole works.

The reason this fails is the call to the Webs.asmx service is SOAP, which is pure XML, and the description is sent as an Attribute, not as a text node value.

Here's the real rub, though: if you DO happen to have illegal characters in there, InfoPath won't error out.  Instead it will successfully publish the form to the site, but then prompt for credentials over and over and over again for the web service.  If you're foolish enough to continue clicking Ok you'll eventually lock out your AD account in the process.  When you click Cancel, it will say "Creating the site content type failed."  That's it.  No help at all.  What it should say, instead of prompting at all is "SOAP error" or "400: Bad Request" which is what is actually happening in the background.

What it took to find this little sucker was installing Fiddler on the local machine and watching the traffic going out to the website.  I was seeing HTTP 400 errors when the web calls were being made, and in looking at the RAW SOAP XML request to the service, that's where I saw the Description attribute, and it was invalid, thanks to double quotes in my description.

I lost 4 hours to this error, and had to drag in a sys-admin to help me figure out Fiddler to see the raw data.  I hope this helps someone else...

Friday, May 10, 2013

Friends don't let friends use RC4 (UPDATED: EVER!)

And there are a myriad of reasons why.  Despite its great speed and small footprint, its simplicity also leaves it wide open to faults and attacks.  So it's no longer recommended for any new implementations, and existing implementations should stop using it.

UPDATED SEPT 17 2013:  Looks like the official recommendations are coming down now for that to happen after all these NSA revelations.  And it gets worse.

But here's the rub.  It was so widespread during the early days of many Internet and Wireless protocols (and is STILL used), you actually CAN'T get rid of it entirely, and you can't improve upon it without breaking compatibility with older systems.

This is probably the most frustrating aspect of ALL crypto-systems:  Something that is great one day, can be (probably) broken in a short time frame (5-10 years or less), but is SO great, that it gets put into EVERYTHING before all hell breaks loose, and the industry as a whole is slow to adopt new tactics and algorithms, leaving the rest of us with "Swiss cheese security."

Take DES, as an example.  It was developed a long time ago when computers were still HUGE, and desktop computing hadn't really happened yet.  It was quickly broken as home computers became more and more powerful in the late 80's, and as cryptanalysts developed new techniques for getting algorithms to give up their secrets (quite literally) through careful bit manipulation and extensive comparison of inputs and outputs, it became clear that a new algorithm was needed.

In the move to get rid of DES, it was so prevalent, that the best anybody could do at the time (since DES was an adopted NIST FIPS standard) was to simply implement it 3 times in succession with a longer overall key (once forward, once backward, once again forward, each with a different, usually independent, piece of the overall key).  Thus "Triple DES" or "3DES" was born.  Hardly any new hardware required, and very little new software, just use what you have 3 times.

This was... ok... except it was later determined that the process of having the center transformation reversed caused some of the bits in the key to "not matter."  Instead of 168 bits of security, you basically only get 112.  Bummer.

And NIST calls it, effectively, 80.  Double bummer.

And with modern hardware, a single DES key can be broken by brute-force in a matter of minutes or hours.  Triple bummer. (see what I did there?)

Then came AES, which was chosen after a long competition held by NIST with some of the best crypto minds in the world (it was adopted in 2002 officially after an exhaustive process starting in 1997).  It's only just now starting to show cracks (in 2011 or 2012, I can't find the original article, someone figured out that in the 256 bit version, the key expansion schedule had some peculiar behavior that COULD someday lead to an attack).

AES is now one of the most adopted algorithms in software*, because it's free, open source, and actually required for many US Government processes. (*I'm making an educated guess here based on my own experience.)  It's even found its way into some Intel CPU architectures as a stand-alone Arithmetic Logic Unit (ALU), right alongside all the other key parts of the CPU.  Try changing that out in all the PC's in the world if it were ever broken!  UPDATE Another CPU was announced recently!  I just don't have the link handy, but many have Tweeted about it.

But I'm getting away from the plot...

RC4 was one of those algorithms that emerged and showed great promise due to its great speed and small memory footprint (less than 280 bytes in memory).  It was so fast, in fact, that it was adopted when the first short-range, wireless connectivity standards were being implemented (remember 802.11a and WEP?).  It does, however, still require a license (as of the time of writing this article) from RSA, the original developer.

The trouble is, by the time all the faults were discovered, 802.11a and all of its children were already in VERY widespread use.  The idea of forcing manufactures and software vendors to change hundreds of thousands of devices (many of which had no way to "flash" new programs) was completely out of the question.  New standards, which overcame SOME of the flaws, were later adopted (enter WPA, WPA2Personal/Enterprise), but the damage had already been done.

RC4 is dead!  Long live RC4!

Yup, it's still out there, in use, in production, and it shouldn't be... but I digress.

One thing I will say, though, is that for quick-and-dirty encryption (read weak and probably easily cracked), its speed is largely unmatched.  So even I dipped my toes in the water with a way to try and improve it, but I seriously doubt my way is any better than the last attemptsNope ANY use of RC4 at this point is crap!  Just don't do it!

But, if you need to use something small and lightweight... *wince* I can't recommend anything else that fits the same memory/code footprint *wince*. I would normally say use BlowFish, TwoFish, or even ThreeFish, but... *shrug* for this discussion, we're going "cheap"...

UPDATE:  Yeah, I'm essentially striking this from the record.  Even this "improvement" is just polishing a turd.  JUST DON'T USE RC4!!!!

For starters, don't use the standard version in your final implementation (and not at all if you don't obtain a license from RSA; remember, this algorithm is still under their control).  Do this instead:

DISCLAIMER:  USE AT YOUR OWN RISK, AND ONLY AFTER OBTAINING KNOWLEDGE OF THE LOCAL LAWS AND REGULATIONS OF YOUR JURISDICTION.  AUTHOR MAINTAINS NO WARRANTY OF ANY KIND NOR OF ANY SOUNDNESS, VIABILITY, SECURITY, OR TRUSTWORTHINESS OF THIS CONCEPT!  READER IS CAUTIONED AGAINST USING STRANGE ALGORITHMS FROM STRANGERS WITHOUT PRIOR CONSENT OF AN ADULT.  YOU ARE ON YOUR OWN, AND AUTHOR ACCEPTS NO RESPONSIBILITY FOR WHAT YOU DECIDE TO DO WITH YOUR LIFE.

Start with the standard version, just to build up the base, but remember that its flaws are numerous, and mostly surround the starting state, and the first 1000 bytes or so of output.  From the standard, deviate with the following:

1.  Input key is passed through [RIPEMD-160] hash first before the state is initialized.
    (any decent hash will do, just stay away from MD5 and SHA-1; you don't need to go to
     full SHA-512, or Skein, or Blake, or Keccak or anything like that, this is quick-
     and-dirty after-all, right? Use all the bits that are output from the hash)
2.  Initialization is increased from 1 pass through the state buffer to 3

    (basically, increase from 256 key-based swaps to 768).
3.  First 4096 bytes of stream output (without salt) are dropped.

    (this hides the initial state sufficiently enough*, and costs very little in
     processor time)
4.  A salt is added to all final output bytes. 
    (a) The salt is defined as a [RIPEMD-160] HMAC buffer (keyed by *original* input key)

        of the state as defined by steps 1-3 above.  
        (again, any hash in HMAC mode will work here, but use the same as the one above,
         less code that way)
    (b) A single persisted byte 'R' determines the index from the salt buffer to be used

        next, and is initialized to 0 after steps 3 and 4(a).
    (c) The salt byte at index 'R' is XOR'd with the next stream output byte, which is

        obtained from the RC4 algorithm as normal.  'R' is then incremented, modulus the
        length of salt buffer.
    (d) Repeat step (c) as needed.

DISCLAIMER:  USE AT YOUR OWN RISK, AND ONLY AFTER OBTAINING KNOWLEDGE OF THE LOCAL LAWS AND REGULATIONS OF YOUR JURISDICTION.  AUTHOR MAINTAINS NO WARRANTY OF ANY KIND NOR OF ANY SOUNDNESS, VIABILITY, SECURITY, OR TRUSTWORTHINESS OF THIS CONCEPT!  READER IS CAUTIONED AGAINST USING STRANGE ALGORITHMS FROM STRANGERS WITHOUT PRIOR CONSENT OF AN ADULT.  YOU ARE ON YOUR OWN, AND AUTHOR ACCEPTS NO RESPONSIBILITY FOR WHAT YOU DECIDE TO DO WITH YOUR LIFE.  THERE I SAID IT TWICE!  NOW YOU HAVE NO EXCUSE!