DotNetNuke and FIPS compliance
September 20th, 2012 - Cathal Connolly
Contents
DotNetNuke and FIPS compliance ................................................................................................................ 1
Background ............................................................................................................................................... 2
DotNetNuke .............................................................................................................................................. 2
HMACSHA256 failures........................................................................................................................... 2
MD5CryptoServiceProvider failures...................................................................................................... 2
RC2CryptoServiceProvider failures ....................................................................................................... 4
RijndaelManaged failures ..................................................................................................................... 4
RIPEMD160Managed failures ............................................................................................................... 5
SHA1Managed failures .......................................................................................................................... 5
Third party components ........................................................................................................................... 5
Application settings................................................................................................................................... 5
Further research required......................................................................................................................... 5
Appendix ....................................................................................................................................................... 7
FIPS compliant Algorithms .................................................................................................................... 7
Hash algorithms .................................................................................................................................... 7
Symmetric algorithms (use the same key for encryption and decryption) .......................................... 7
Asymmetric algorithms (use a public key for encryption and a private key for decryption) ............... 7
Algorithms that are not FIPS compliant ................................................................................................ 7
Background
The FIPS-140-2 standard is a U.S. government computer security standard used to accredit cryptographic
modules. This document details the issues with attaining that level of compliance in DotNetNuke based
on the 7.0.0.813 enterprise build (September 20th, 2012)
DotNetNuke
HMACSHA256 failures
Library\Services\ClientCapability\FacebookRequestController.cs – uses the HMACSHA256 algorithm.
This code will have to be removed to be compliant. Another option is to use compliant versions built by
Microsoft’s CLR security team
(https://github.com/DotNetOpenAuth/DotNetOpenAuth/issues/47#issuecomment-1881759) , however
these require machine.config changes so are beyond our ability to resolve without user interaction.
MD5CryptoServiceProvider failures
The following failures exist in the open-core (i.e. affect all versions)
1. Library\Security\PortalSecurity.cs(350):
var hashProvider = new
MD5CryptoServiceProvider();
2. Library\Security\PortalSecurity.cs(417):
var hashProvider = new
MD5CryptoServiceProvider();
3. Library\Services\Analytics\GoogleAnalyticsController.cs(77):
var md5 = new
MD5CryptoServiceProvider();
4. Library\Services\Cache\FBCachingProvider.cs(160):
var md5 = new
MD5CryptoServiceProvider();
5. Library\Services\ModuleCache\FileProvider.cs(55):
var md5 = new
MD5CryptoServiceProvider();
6. Library\Services\OutputCache\OutputCachingProvider.cs(55):
var md5 = new
MD5CryptoServiceProvider();
7. Modules\RazorHost\RazorHelpers\Facebook.cshtml(260):
var md5 =
System.Security.Cryptography.MD5CryptoServiceProvider.Create();
8.
Items 1 & 2 involve the EncryptString and DecryptString functions. As well as being a part of the public
API (meaning that any change may break 3rd party components), they are used in a number of core
locations.



Used to encrypt and decrypt user verification codes – changing the library would mean any
existing unused verification codes would be invalid.
Used to encrypt and decrypt user profile values that use the Secure profile. This was introduced
in 6.0.0 but has not been used in the core to date – however it is a part of the public API
Used to encrypt and decrypt the username and password for connecting to
store.dotnetnuke.com in the “more extensions” function. Changes would invalidate these
details, however the user can re-register as a workaround.
Item 3 - is a piece of code used to determine whether to upgrade the google analytics script. It uses MD5
to create hashes to compare the files. This code could be updated to use a different hashing algorithm
as long as we re-calculate the hash value of the old file.
Item 4 – this uses MD5 to generate “safe” filenames. The code could be safely updated to use a
compliant hashing algorithm.
Item 5 – This is a known issue with a Gemini ticket already logged
(http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=20806&PROJID=2) – The code could be safely
updated to use a compliant hashing algorithm.
Item 6 – As above.
Item 7 – there is no valid fix for this, but as a sample file it can be simply removed from the distribution.
The following failures exist in the paid editions.
1. Professional\Library\LicenseActivation\Common\Cryptographer.cs(291):
hashAlgorithm = new MD5CryptoServiceProvider();
2. Professional\Library\LicenseActivation\Common\Hash.cs(51):
MD5CryptoServiceProvider
hash = null;
3. Professional\Library\LicenseActivation\Common\Hash.cs(54):
hash = new
MD5CryptoServiceProvider();
4. Professional\Library\Providers\ModuleCachingProviders\DatabaseProvider\DatabaseProvider.c
s(27):
var md5 = new MD5CryptoServiceProvider();
5. DotNetNuke.Web\Api\Internal\Auth\DigestAuthentication.cs(34):
private static readonly
MD5 Md5 = new MD5CryptoServiceProvider();
6. Professional\Modules\GoogleAnalyticsPro\Components\GoogleAnalyticsProController.cs(69):
var md5 = new MD5CryptoServiceProvider();
7. Professional\Modules\DocumentLibrary\Components\UrlUtils.cs(140):
var md5 = new
MD5CryptoServiceProvider();
8. Professional\Modules\DocumentLibrary\Components\UrlUtils.cs(151):
var md5 = new
MD5CryptoServiceProvider();
9. Professional\Modules\IntegrityChecker\Components\IntegrityLibrary\HashAlgorithms.cs(94):
return new MD5CryptoServiceProvider();
Items 1,2 and 3 involve a helper class that appears to be for license activation. However within the core,
the only call to it uses RSA (which is compliant) so it appears fine – though it is public API so any change
to it can break a 3rd party extension. However due to the naming, I would want to check to see if the 3rd
party licensing component from bring2mind is expecting to use these libraries and if so if we remove
them whether that will break licensing.
Item 4 – this is the same naming issue as other caching providers and can be resolved in a similar
fashion.
Item 5 – this is new code added with DotNetNuke 7.0. Digest uses MD5 to sign which is not valid
(http://publib.boulder.ibm.com/infocenter/ssp/v3r4/index.jsp?topic=%2Fcom.ibm.help.sspreleasenotes
.doc%2FSSP_FIPSConsiderations.html). It appears SHA1 could be used as an alternative signing
mechanism.
Item 6 – this is the same issue as the google opencore above and can be resolved in the same fashion.
Items 7 & 8 – the document library uses a pair of functions to create tamperproof url’s. This code could
be updated to use a compliant library. It appears the strings are not stored, just generated for use so it
would be possible to resolve this.
Item 9 – this is a library used to compare files and file contents – it appears that removal of the noncompliant methods would be possible, and the code could be updated to use the (slightly slower but
complaint) alternative to resolve.
RC2CryptoServiceProvider failures
Failures in paid editions


Professional\Library\LicenseActivation\Common\Cryptographer.cs(381):
new RC2CryptoServiceProvider();
Professional\Library\LicenseActivation\Common\Cryptographer.cs(463):
new RC2CryptoServiceProvider();
provider =
provider =
Both of these items are similar to before where the cryptographer class is a utility class. Removal of the
non-compliant methods carries the same risk of breaking 3rd party extensions using this API (note: it is
marked as “internal” so the risk is a lot smaller), and care should be taken to ensure it does not break
the licensing solution.
RijndaelManaged failures
The same 2 issues as above exist in the Cryptographer class.
RIPEMD160Managed failures
 Professional\Modules\IntegrityChecker\Components\IntegrityLibrary\HashAlgorithms.cs(92):
return new RIPEMD160Managed();
This is a library used to compare files and file contents – it appears that removal of the non-compliant
methods would be possible, and the code could be updated to use the (slightly slower but complaint)
alternative to resolve.
SHA1Managed failures
 Professional\Modules\IntegrityChecker\Components\IntegrityLibrary\HashAlgorithms.cs(80):
return new SHA1Managed();
This is a library used to compare files and file contents – it appears that removal of the non-compliant
methods would be possible, and the code could be updated to use the (slightly slower but complaint)
alternative to resolve.
Third party components



The client resource management component (originally named client dependency) is not FIPS
compliant. As this is used on every page request since the 6.0.0 release, this makes DotNetNuke
unusable and non-compliant. An issue was logged at
http://clientdependency.codeplex.com/workitem/13194 to resolve this and a fix has been made
(http://clientdependency.codeplex.com/SourceControl/changeset/3645d3d3f37a ) . However as
we have our own “fork” of this code we will need to manually merge this change in. Please note,
I am not 100% convinced that this fix is valid (see “Further research”) and may need amended.
There are no known issues with jQuery or jQueryUI – certain jQuery plugins may utilize MD5
encryption that is not compliant but nothing that is shipped with the product uses these.
Telerik – this library is compliant since Q3 2011 (http://www.telerik.com/help/aspnet-ajax/fipscompatibility.html)
Application settings

By default the viewstate validation algorithm is SHA1 which is non-compliant. However
DotNetNuke ships with 3DES enabled so this is not an issue.
Further research required

A number of articles such as http://stackoverflow.com/questions/3120029/make-asp-net-webapplication-fips-compliant indicate that the presence of references to non-compliant libraries is


sufficient to fail FIPS compliance. This will need to be validated to see if it is true – if it is the fix
for the client dependency framework is not valid (as it offers the choice between libraries
depending on configuration).
We also need to check how the 3rd party licensing solution integrates with DotNetNuke i.e. does
it call the Hash or Cryptographer libraries and if so does it use non-compliant libraries.
.net 4.0 introduces a AllowOnlyFipsAlgorithms property - http://msdn.microsoft.com/enus/library/system.security.cryptography.cryptoconfig.allowonlyfipsalgorithms(v=vs.100).aspx . If
we choose to be FIPS compliant we should set this in the configuration to ensure that noncompliant libraries are not introduced. We will have to check if this is supported at the
web.config level.
Appendix
FIPS compliant Algorithms
Hash algorithms
 HMACSHA1
 MACTripleDES
 SHA1CryptoServiceProvider
Symmetric algorithms (use the same key for encryption and decryption)


DESCryptoServiceProvider
TripleDESCryptoServiceProvider
Asymmetric algorithms (use a public key for encryption and a private key for decryption)


DSACryptoServiceProvider
RSACryptoServiceProvider
Algorithms that are not FIPS compliant










HMACMD5
HMACRIPEMD160
HMACSHA256
HMACSHA384
HMACSHA512
MD5CryptoServiceProvider
RC2CryptoServiceProvider
RijndaelManaged
RIPEMD160Managed
SHA1Managed