Crypting UserIdTable

[neoxed]

The module system was never really documented, just a few dated (mostly vague) threads. Even if one managed to write a module, encrypting the UserIdTable would end up being more of a nuisance in the long run.

For example, if the user names were encrypted with symmetric cipher you would need an encryption key. This introduces new problems, where will the key be stored? If the key is defined in the ioFTPD.ini, all the intruder has to do is grab the key along with the UserIdTable to decrypt it. Alternatively, you could have ioFTPD prompt you for the key on start-up, but this destroys the purpose of a daemon (a background task that does not require user interaction).

Now, if one took the time to develop a realistic threat model, encrypting user names would be the least of your worries. Think about all the other points of entry and threats (e.g. uneducated and untrustworthy users).

In my opinion, Harm's idea (using NTFS’s encryption and ACL functionality) is probably sufficient.

[_panic_]

Originally Posted by neoxed

In my opinion, Harm's idea (using NTFS’s encryption and ACL functionality) is probably sufficient.

your point about encrypting the on-disk userfile as being a nuisance (or just futile) are true. i made the mistake of ignoring the advice "just because you can, doesn't mean you should." which does apply in this case.

in fact, you don't even need to attack the encryption itself, as you could use a debugger to watch the calls between ioftpd and the UserModule, which would give you complete access to the information as soon as ioftpd initialized.

regardless, i think the ability to write a UserModule hook, regardless of the utility for this particular case, is good information to have. the example on this thread of ioShareDB being a perfect example of something that would never be in core ioftpd but could still be useful nonetheless.