On Mon, 19 Jul 1999 15:28:17 +0200, Patrick Schoenbach
>>Don't you think crypt() would be pretty damn useless for passwords
>>if it was possible to decrypt the string?
>>The only way to "decrypt" it is to encrypt all possible character
>>combinations and compare it with the original crypted string until
>>you have a match.
>Ok, agreed. But how can I solve the following problem: I want to write a
>mail biff that can handle the IMAP protocol, and I want to store the
>account data in a config file in the home directory. The password has to
>be submitted in plaintext to the IMAP daemon, but I do not like storing
>the password in plaintext in the config file. So, what could I do?
You are screwed, because the poor security of IMAP is a weak link in
the security. You say you don't like storing a plaintext password in
the file, but what about the fact that it is transmitted to IMAP
in plain text? A password is more likely to be stolen from the network
wire than from a protected file.
About all you can do is store the password in a file that is owned by the user
who is running the biff-like program, and is properly secured.
This is what fetchmail does. Passwords to POP or IMAP accounts
are stored in plaintext in a file called .fetchmailrc in the user's
home directory. This file is given 0600 permissions.
Speaking of which, are you sure you couldn't use fetchmail for what you are
trying to do and save yourself the hassle of reinventing the wheel? fetchmail
can poll remote mail accounts, and bring the mail down to the local account.
The ordinary mail notification mechanisms can then kick in.
Another thing you can do is ask for the password when your biff-like program is
run, and then retain it in memory. The user would have to do this each time he
or she wants to run the program, but at least the password wouldn't be in a
file. Fetchmail can do this too; you aren't required to store passwords in the