It's better to use Windows' DPAPI. It's much more secure than using other methods:
- CryptProtectData / CryptProtectMemory
- CryptUnprotectData / CryptUnprotectMemory
CryptProtectMemory / CryptUnprotectMemory offer more flexibility:
- CRYPTPROTECTMEMORY_SAME_PROCESS: only your process can decrypt your data
- CRYPTPROTECTMEMORY_CROSS_PROCESS: any process can dectypt your data
- CRYPTPROTECTMEMORY_SAME_LOGON: only processes running with the same user and in the same session can decrypt data
Pros:
- No need to have a key - Windows do it for you
- Granular control: per process / per session / per login / per machine
- CryptProtectData exists in Windows 2000 and newer
- DPAPI Windows is more secure than using "security" related code written from you, me and the people that believe Random() returns absolutely random number :) In fact Microsoft has decades of experience in the security field, having the most attacked OS ever :o)
Cons:
- In the case of CRYPTPROTECTMEMORY_SAME_PROCESS One* can just inject a new thread in your process and this thread can decrypt your data
- If someone reset user's password (not change) you will be unable to decrypt your data
- In the case of CRYPTPROTECTMEMORY_SAME_LOGON: if the user* run hacked process it can decrypt your data
- If you use CRYPTPROTECT_LOCAL_MACHINE - every user* on that machine can decrypt the data. This is why it's not recommended to save passwords in .RDP files
- Known issues
Note: "every user" is a user who has tools or skills to use DPAPI
Anyway - you have a choice.
Note that @David-Heffernan is right - anything stored on the computer can be decrypted - reading it from memory, injecting threads in your process etc.
On the other hand ... why don't we make cracker's life harder? :)
Rule of thumb: clear all buffers that contain sensitive data after using them. This doesn't make things super safe, but decreases the possibility your memory to contain sensitive data.
Of course this doesn't solve the other major problem: how other Delphi components handle the sensitive data you pass to them :)
Security Library by JEDI has object oriented approach to DPAPI. Also JEDI project contains translated windows headers for DPAPI (JWA IIRC)
UPDATE: Here's sample code that uses DPAPI (using JEDI API):
Uses SysUtils, jwaWinCrypt, jwaWinBase, jwaWinType;
function dpApiProtectData(var fpDataIn: tBytes): tBytes;
var
dataIn, // Input buffer (clear-text/data)
dataOut: DATA_BLOB; // Output buffer (encrypted)
begin
// Initializing variables
dataOut.cbData := 0;
dataOut.pbData := nil;
dataIn.cbData := length(fpDataIn); // How much data (in bytes) we want to encrypt
dataIn.pbData := @fpDataIn[0]; // Pointer to the data itself - the address of the first element of the input byte array
if not CryptProtectData(@dataIn, nil, nil, nil, nil, 0, @dataOut) then
RaiseLastOSError; // Bad things happen sometimes
// Copy the encrypted bytes to RESULT variable
setLength(result, dataOut.cbData);
move(dataOut.pbData^, result[0], dataOut.cbData);
LocalFree(HLOCAL(dataOut.pbData)); // http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
// fillChar(fpDataIn[0], length(fpDataIn), #0); // Eventually erase input buffer i.e. not to leave sensitive data in memory
end;
function dpApiUnprotectData(fpDataIn: tBytes): tBytes;
var
dataIn, // Input buffer (clear-text/data)
dataOut: DATA_BLOB; // Output buffer (encrypted)
begin
dataOut.cbData := 0;
dataOut.pbData := nil;
dataIn.cbData := length(fpDataIn);
dataIn.pbData := @fpDataIn[0];
if not CryptUnprotectData(
@dataIn,
nil,
nil,
nil,
nil,
0, // Possible flags: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261%28v=vs.85%29.aspx
// 0 (zero) means only the user that encrypted the data will be able to decrypt it
@dataOut
) then
RaiseLastOSError;
setLength(result, dataOut.cbData); // Copy decrypted bytes in the RESULT variable
move(dataOut.pbData^, result[0], dataOut.cbData);
LocalFree(HLOCAL(dataOut.pbData)); // http://msdn.microsoft.com/en-us/library/windows/desktop/aa380882%28v=vs.85%29.aspx
end;
procedure testDpApi;
var
bytesClearTextIn, // Holds input bytes
bytesClearTextOut, // Holds output bytes
bytesEncrypted: tBytes; // Holds the resulting encrypted bytes
strIn, strOut: string; // Input / Output strings
begin
// *** ENCRYPT STRING TO BYTE ARRAY
strIn := 'Some Secret Data Here';
// Copy string contents to bytesClearTextIn
// NB: this works for STRING type only!!! (AnsiString / UnicodeString)
setLength(bytesClearTextIn, length(strIn) * sizeOf(char));
move(strIn[1], bytesClearTextIn[0], length(strIn) * sizeOf(char));
bytesEncrypted := dpApiProtectData(bytesClearTextIn); // Encrypt data
// *** DECRYPT BYTE ARRAY TO STRING
bytesClearTextOut := dpApiUnprotectData(bytesEncrypted); // Decrypt data
// Copy decrypted bytes (bytesClearTextOut) to the output string variable
// NB: this works for STRING type only!!! (AnsiString / UnicodeString)
setLength(strOut, length(bytesClearTextOut) div sizeOf(char));
move(bytesClearTextOut[0], strOut[1], length(bytesClearTextOut));
assert(strOut = strIn, 'Boom!'); // Boom should never booom :)
end;
Notes:
- The example is lightweight version of using CryptProtectData / CryptUnprotectData;
- Encryption is byte oriented so it's easier to use tBytes (tBytes = array of byte);
- If input and output string are UTF8String, then remove "* sizeOf(char)", because UTF8String's char is 1 byte only
- The use of CryptProtectMemory / CryptUnProtectMemory is similar