This little error seems to poke its ugly little head in several different areas around the .NET world. In my little corner of this world, SharePoint, and more specifically custom authentication with my Hybrid Provider, this error almost brought my portal to its knees. I've finally gotten enough of a grasp on one of the causes of this error; even if this doesn't match your situation, hopefully my description will point you in the right direction.

The problem is encryption. Among all the different types of encryption, the crux of it revolves around a public key and a private key pair. The public key is out there in the open, and when combined with the private key, which is hidden away, can unlock the cipher, just like in the Da Vinci Code. In my work, encryption is used to securely store my SQL SharePoint user's passwords.

The SQL Membership Provider takes care of all the details, to such an extent that when I first started seeing this error, I had no idea where to dig. The way it works is that ASP.NET web.config files can contain an element called a machine key. The entire element looks like this:

(Most of the really long keys are omitted.)

This is essentially the public key in the encryption paradigm. Whenever any data is encrypted using a particular key, only that key can again be used to decrypt it. If a different key is present at "decryption time," you'll get the error: "Padding in valid and cannot be removed." Unfortunately, it's not worded better, for example, "The data you are attempting to decrypt was encrypted with a different machine key."

If that were thrown at you, you'd know exactly what to do! Now, again, I'm not an expert here; perhaps this error message covers more than just machine key problems, or encryption is only part of the issue. Regardless, let me outline what happened to me, and hopefully it'll save you from making the same mistake.

I have hundreds of SQL users in my Hybrid Provider's database. When we first launched the site, it was on a VM. Since our virtual environment is more designed for development and test servers rather than production, we decided to de-virtualize (realize?) our SharePoint farm. So we spun up a brand-spankin' new Windows Server 2008 box, migrated SharePoint, moved our Hybrid Provider database over, fired that puppy up, and logged in as a SQL user.

Padding is invalid and cannot be removed.

Padding!? What the hell is padding? And what can't it be removed from?? Well, after further investigation, I noticed that I could create new SQL users with no problem. Also, once an old user's password was reset, it worked just fine. Hmm. It seemed as though passwords from the old users directly migrated over didn't work. Hmm again. Then it hit me: the machine key! This is a new machine, so it was a new machine key, so decryption of the old passwords is failing!

All I had to do was then copy and paste the machine key from the old web.config into the new, and everything started working. So this is the warning to everyone using FBA (forms-based authentication) that encrypts users' passwords in your ASP.NET application (SharePoint or otherwise): your web.config contains (or inherits) the public key used across the board for decryption. When you move your encrypted data and your private key (internally part of the SQL Membership Provider – all that SALT stuff), you must bring the same public key along with it! Have fun!