Not Opting for a Least Common Denominator Solution

No doubt you've realized that different versions of Windows provide different data protection technologies. Generally speaking, the new versions of the operating system provide better data security by way of ACLs, cryptographic services, and high-level data protection capabilities. However, what if your application must run on Windows NT 4 and later, yet you want your application to provide the best possible security for client data on the newer operating systems? You could always use what's available in Windows NT 4, but, as you've read, Windows 2000 offers more capability than Windows NT 4 through the data protection API. The best way to take advantage of what the operating system has to offer is to call the functions indirectly, using run-time dynamic linking rather than load-time dynamic linking, and to wrap the calls in wrapper functions to isolate the code from the operating system. For example, the following code snippet works in Windows NT and Windows 2000 and later, and it has the logic to use DPAPI on Windows 2000 and LSA secrets on Windows NT 4:

//signature for CryptProtectData typedef BOOL (WINAPI CALLBACK* CPD) (DATA_BLOB*,LPCWSTR,DATA_BLOB*, PVOID,CRYPTPROTECT_PROMPTSTRUCT*,DWORD,DATA_BLOB*); //signature for CryptUnprotectData typedef BOOL (WINAPI CALLBACK* CUD) (DATA_BLOB*,LPWSTR,DATA_BLOB*, PVOID,CRYPTPROTECT_PROMPTSTRUCT*,DWORD,DATA_BLOB*); HRESULT EncryptData(LPCTSTR szPlaintext) { HRESULT hr = S_OK; HMODULE hMod = LoadLibrary(_T("crypt32.dll")); if (!hMod) return HRESULT_FROM_WIN32(GetLastError()); CPD cpd = (CPD)GetProcAddress(hMod,_T("CryptProtectData")); if (cpd) { //call DPAPI using (cpd)(args); //store result in ACLd registry location } else { //call LSA Secrets API } FreeLibrary(hMod); return hr; }