It is just so awesome to see how nature combines it’s various aspects together to create unimaginable blend of soothing beauty…
See the change of expressions… 🙂
Beautiful Full Moon...
PWDENCRYPT & PWDCOMPARE are two undocumented methods provided by MS SQL Server. PWDENCRYPT generates a hash given a string, and PWDCOMPARE is used to Compare a string with generated hash.
Example:
DECLARE @varPassword NVARCHAR(128)
SELECT @varPassword = ‘Test Encryption’
DECLARE @passwordHash VARBINARY(128)
SELECT @passwordHash = PWDENCRYPT(@varPassword)
PRINT ‘Password: ’ + @varPassword
PRINT ‘Password Hash: ’ + CAST(@passwordHash AS NVARCHAR(128))
DECLARE @chkPassword NVARCHAR(128)
SELECT @chkPassword = ‘Test Encryption’
IF (PWDCOMPARE(@chkPassword, @passwordHash) = 1)
BEGIN
PRINT ‘Match found’
END
ELSE
PRINT ‘Match not found’
These methods work great as far as you are not expecting too much out of them. Let me put down some pros and cons which will help you make your choice regarding whether you should use these methods or not.
Pros:
- Easy to use
- Encryption/Decryption handled directly at SQL level
- Easy to make bulk changes using queries
- In built methods
Cons:
- Case insensitive (now that’s a great problem if you are planning to use it for generating passwords)
- Altering the collation settings does not help make it work consistently
- Undocumented and hence not supported by Microsoft
Summary:
If you are in any way using PWDENCRYPT & PWDCOMPARE, you might want to go back and check for inconsistencies. I would personally recommend handling the encryption at Code level along with case sensitive collation on the SQL side for storing the encrypted values.
Wonder why many a times your ASP.NET website on migration from .NET 1.1 to .NET 2.0 starts giving all sorts of Javascript/AJAX errors? Why things don’t seem to work even when no code changes are made? Why Javascript works on your development environment but not on the production server? The reason behind all these problems is the web.config element ‘xhtmlConformance’.
What happens?
On migration from .NET 1.1 to .NET 2.0, the configuration element <xhtmlConformance mode=”Legacy” /> is automatically added to you web.config file.
There are basically three values xhtmlConformance element can have:
- Legacy (which is similar to how markup was rendered in previous versions of ASP.NET)
- Transitional (XHTMLÂ 1.0 Transitional)
- Strict (XHTMLÂ 1.0 Strict)
Why do the errors surface?
- By default for many .NET 1.0 & .NET 1.1 servers controls, the rendering is not XHTML compliant. ASP.NET 2.0 changed this and by default emits XHTML compliant markup from all controls
- When xhtmlConformance is set to “Legacy” mode, it forces the controls to render in non XHTML compliant markup. What this does is, changes the ClientIDs generated for server controls
- Most of the Javascripts use hardfixed ClientIDs for server controls. When the ClientIDs change, the Javascript is unable to locate the desired object/control & fails
- For using AJAX, XHTML compliance needs to be met and hence this configuration will cause trouble in case you desire to use AJAX
- Most websites have different web.config files for different environment i.e. development/testing/staging/production. In such cases the same code seems to work on one environment but not on the other because of difference in ‘xhtmlConformance’ element configurations
How to resolve these issues?
- Remove ‘xhtmlConformance’ element from you web.conf file
- Check for possible Javascript errors. If NO errors are found – ‘You’re so damn LUCKY!’
- If you face Javascript errors, debug the Javascript, verify the ClientIDs generated on Page and those used by your Javascript. Usually, you will be able to resolve your problems by removing the extra ‘_’ from your Javascript ClientIDs
Hope it helps! 🙂
Suraj Chavda's Blog 
You must be logged in to post a comment.