If you use a one way hash that has been properly salted (i.e., HASH(SALT + password) ), then you should never be able to retrieve forgotten passwords, ever. If you can retrieve a lost password for a user, then you've screwed it up, because if you can recover a lost password, someone who scraped your database can recover a lost password.
The worst, by the way, are web sites which require you to pick a super-secure password (at least 12 characters long, must contain punctuation, both upper and lower case letters, a number character, an Egyptian hieroglyph, and must not match the last 15 passwords used in the past and must be changed ever 30 days)--then stores the password and password history as plain text in the user database. Those are the guys I'd love to murder in cold blood.
Personally I've always liked using some element of a user record attribute as part of the SALT--such as having a UUID associated with each user record that becomes part of the salt for the hash (i.e., HASH(SALT + password + UUID) )--because this means if someone does scrape your database it's computationally a little more difficult to reverse engineer the passwords in the database because even a bunch of people use "123456" as their password, the hashes will be different for each of those users. Of course the UUID must never change or else you'll lock your users out.
I'm also a fan of the POP3 protocol's APOP authentication mechanism, where sending credentials over the 'net requires two transactions: (1) obtaining a unique token for that session, then (2) hashing the password against that token to transmit to the back end. Of course this means you wind up hashing the plain text password *twice*: since you don't have the password on the back end (but its hash) you can only compare against HASH(TOKEN + hashed_password), and on the front end you wind up calculating HASH(TOKEN + HASH(SALT + password + UUID) ). But that requires a lot of work in the client.
Simply sending HASH(SALT + password + UUID) rather than hashing the hash with an additional token means you're subject to a replay attack, where a third party could listen in on the conversation and simply replay the login packet you send to connect to the server.
And while I know a lot of folks claim that all of this is mitigated by using SSH, it doesn't protect against man-in-the-middle attacks, including incidental man-in-the-middle attacks created by certain proxy gateways which use their own certs in order to decrypt HTTP traffic to sniff for viruses or enforce corporate guidelines for acceptable use.
Ultimately security won't stop the most determined hackers; you're not stopping the NSA, for example. But you can stop the script kiddies and disgruntled employees by taking some precautions--such as never storing sensitive information in a database (like credit cards) unencrypted, and using one-way hashes to store passwords.
Oh, and as a footnote: unless you have a Ph.D. in cryptography, don't write your own random functions or hash functions. Yes, I've seen it in the field. Instead, use a cryptographically secure hash function. Heck, even MD-5 is going to be better than anything you try to roll on your own.