I'm putting together a proof-of-concept plugin to obscure .INI directives. Question: Which directives does it make sense to hide? So far I have FirewallPassword, JabberPassword, MailPassword, and ProxyPassword.
Any others?
Any others?
Directives to obfuscate
- Thread starter Charles Dye
- Start date
All "Mail...": MailAddress, MailUser, MailServer; also FTPCFG (though it would be better if that file itself could be encrypted on "home" systems).
I'm guessing your first version will have a hardcoded list of directives to hide. Will it at some point be user-configurable?
For example, (now) I don't care about ProxyPassword and therefore I'd rather not have it obscured, in order to minimize the number of obscured directived.
For example, (now) I don't care about ProxyPassword and therefore I'd rather not have it obscured, in order to minimize the number of obscured directived.
MailPort?
At this point I'm only obscuring directives in the .INI file. I don't have any good ideas for handling the FTP.CFG file. (Keep it on a RAMdrive; unzip or decrypt it in TCSTART if it doesn't exist?)
Hardcoded at this point. I could probably work up some kind of configuration ability if there's a real demand, but right now I'm just trying to make the beast work!
I do not think MailPort is an obfuscand. Likewise, any directive which is not defined, or whose value is an empty string, could be skipped. But how would your obfuscator work with editors? Some directives are not handled by the OPTION dialogs, and must be entered using an editor. Other tricky issues: encoding (ASCII vs. Unicode) of %_ININAME; obfuscands in included .INI files (i.e., files used by the INCLUDE directive)?
Your point about decrypting FTP.CFG when you start TCMD/TCC is still unsafe - unless it is done interactively. Below is a suggestion how it could be done safely and dynamically:
Create new .INI sections for each FTP site, in the manner of the [tab1] [tab2]:
[FTP1]
url=
alias=
username=
password=
directory=
template=
with the username and password entries encrypted. This can be done by your plugin dynamically, using the plain text file specified in the FTPCFG directive when first obfuscating. When TCC is started, the decrypting program could build the FTP.CFG file dynamically, in memory mapped files shared by all TCC instances of the current user in the same manner as aliases and functions. A new command in your plugin could invoke the IDE editor to add, change, or delete FTPCFG entries in that file. It would be the user's responsibility to wipe the original FTP.CFG file, which would no longer be accessed. Of course, eventually this method may be integrated into TCC's internal code.
Your point about decrypting FTP.CFG when you start TCMD/TCC is still unsafe - unless it is done interactively. Below is a suggestion how it could be done safely and dynamically:
Create new .INI sections for each FTP site, in the manner of the [tab1] [tab2]:
[FTP1]
url=
alias=
username=
password=
directory=
template=
with the username and password entries encrypted. This can be done by your plugin dynamically, using the plain text file specified in the FTPCFG directive when first obfuscating. When TCC is started, the decrypting program could build the FTP.CFG file dynamically, in memory mapped files shared by all TCC instances of the current user in the same manner as aliases and functions. A new command in your plugin could invoke the IDE editor to add, change, or delete FTPCFG entries in that file. It would be the user's responsibility to wipe the original FTP.CFG file, which would no longer be accessed. Of course, eventually this method may be integrated into TCC's internal code.
I'm not going to support INCLUDEd files -- way too much code and work for way too few users. (Is that capability even documented anymore?) ASCII vs. Unicode shouldn't be an issue, as passwords are stored as plain old ASCII. And "obfuscand" is definitely my neologism for the month!
Whether or not the INCLUDE directive is documented, it is what allows multiple versions of JPsoft command processors to share most of the nitty-gritty of directives in a single file; another for MAIL directives to be maintained independently. Loading of every known version of 4DOS/4NT/TCC/TCMD successfully handles the directive. However, updating the .INI file using the OPTION dialog will move all directives into %_ININAME, but retain the INCLUDE directive.