If your program is set[gu]id, it can never produce a core dump.

If your program is not setid, that there is no way to stop the user running it from looking at its core, at least in vanilla linux. You can always read the password when it's transmitted, or read the memory of the process by attaching a debugger, or watching as it outputs or reads the password. Other users, however, have no way to make it dump core, as they can not send a signal to them.

However, you can prohibit the creation of a core file with the getrlimit syscall (or the ulimit builtin command in a shell, but that would be difficult to use securely in such an application). I don't know of any perl interface for this syscall, but you could call syscall directly, search in CPAN for a module, or write wrapper code yourself.

(There's yet another issue here: if your machine has a swap partition, the memory containing the password can be swapped out, and if someone gains access to the hard disk, he could find the password there. There is a solution for this, the mlock system call, but it would be very hard to use from perl, and it requires setuid root. The best solution against this is not allowing physical access for untrusted people to your hard disk, or, if that's impossible, not using swap partition or using an encrypted swap partition (linux does not have these, but some bsd systems do).)