What's wrong with the KIS principle to store application settings in an INI file? The risk that someone is tampering with the INI file is an often heard reason for not using them. Not being able to store private or secret information another one.
Both issues are solved with the introduced TEncryptedIniFile class. It descends from TMemIniFile and is as such a drop-in replacement and will deal only in app memory with decrypted data. In the file itself, the data is at all times encrypted. To build TEncryptedIniFile, we internally use AES 256bit encryption offered by the TAESEncryption class in TMS Cryptography Pack.
The code to use TEncryptedIniFile becomes something like:
const aeskey = 'anijd54dee1c3e87e1de1d6e4d4e1de3'; var mi: TEncryptedIniFile; begin try mi := TEncryptedIniFile.Create('.settings.cfg', aeskey); try FTPUserNameEdit.Text := mi.ReadString('FTP','USER',''); FTPPasswordNameEdit.Text := mi.ReadString('FTP','PWD',''); FTPPortSpin.Value := mi.ReadInteger('FTP','PORT',21); mi.WriteDateTime('SETTINGS','LASTUSE',Now); mi.UpdateFile; finally mi.Free; end; except ShowMessage('Error in encrypted file. Someone tampered with the file?'); end; end;Of course, the weakness now is that the AES key is in the EXE file and as such, it won't stop seasoned hackers to extract it from the EXE and use it directly to decrypt/encrypt the settings file and tamper with it this way. Extra steps could be taken to use an AES key that is a combination of a unique machine ID and a part that is encrypted with a Ed25519 generated public key and decrypt the encrypted part of the AES key on the fly in the app with the Ed25519 private key and then use it in combination with the machine ID to encrypt/decrypt the INI file. That should make the effort to hack the settings file already a lot more difficult.
To start using this TEncryptedIniFile you can get TMS Cryptography Pack and you can download the TEncryptedIniFile class source here.