Don't store lists of passwords. Store them encrypted. Share a secret between main.cgi and secimage.cgi. Encrypt and store in main; pull and decrypt in secimage.

The project I am working on doesn't want a user to be able to easily copy the password and save it, or just copy and paste it into the login box

The project is an ass. This is half-baked at best. Figure out the security controls that are required, and implement them. "Don't make it easy" is not a control. Presumably what you are trying to do is to require positive action to activate the thing this is password protecting, i.e. to force the user to take the protection of password seriously. Generating a password and then sending it to them is going to have the opposite action.

I would strongly encourage review of the protocols by a security professional.

--woody

EDIT:

Sorry, my tone is bad. One should never call a well meaning project an ass. I work in Fedspace, and recently had an encounter with a web project that went something like this:

Designer: We need a unique identifier. Lets ask the user for their social security number.
Reviewer: You can't do that. People are quite sensitive about social security numbers -- as personally identifiable information, there are significant risks, including federal law, such as the privacy act, which forbids it. In addition, it would support "matching", comparing against other databases, so we'd have to publish it in the federal register, and jump a lot of other hoops.
Designer:Ok, we'll just use their last four digits. They do that with credit cards, so it must be ok.
Reviewer:(strangles self with tie)
Designer:Ah, good, no objections, so lets do that!

Let me restate. Before designing the final solution, determine the actual requirements. Be aware of any unintended consequences of your solution. If your requirement is to 'fool the bots', i.e. to perform a turing test, be aware that this is not easy and that there are no great solutions today. Use of graphical captcha's carries a rather high cost, actually -- in the united states, about one person in ten has a vision defect, with about one in twenty suffering from red/green blindness. Graphical captchas will either disenfranchise large portions of your community or will require deployment of alternative strategies and probably help desk lines.

Well, at least the advice to not store passwords in the clear is sound. :-)

I mean when the user enters the password somewhere you need to verify if his password is correct, so you must have the password stored somewhere.

If you're worried that your database admin might steal the passwords you could try to encrypt the temporary passwords like this:

For each generated password you also create a unique key. Then you encrypt the password with key and store it in the DB, and you send the key to the client (print"<img src='https://www.mysite.com/secure/cgi-bin/secimage.cgi?key=$key'>";).

That way the secret is split into two halves, one is only known in the database and one that is only send the browser (and not stored), so no evil database admin can recover the passwords.

I mean when the user enters the password somewhere you need to verify if his password is correct, so you must have the password stored somewhere.

You don't, actually. You can hash the initial password (with a salt, preferably) and store that. Then to verify the password, take what the user has provided and hash it again (with the same salt) and compare.