Are you kidding, no hash is secure unless you hash the hash. If you type in "dehasher" in google my website comes up on the first page "global programming syntax" and with my website, sha1, crc23 and crc23b will have a reverse lookup to at least 4 digits. My database is being populated each day with millions of results and will upload the database late November. So currently the database is not publicly viewable but will be soon and I have plans to expand it to a monster database as I have made the database structure efficient for mysql query lookup. So with plans like mine, no hash is secure as long as it follows a standard format. That's why you hash the hash or use a custom hashing function.
SHA256 are Whirlpool are definitely secure. For most applications sha1 and md5 are also secure, though many will recommend using SHA2 and up.
http://en.wikipedia.org/wiki/SHA_hash_functions
You cannot save all the hashes from SHA256 or Whirlpool in a database, or even SHA1.
If you take SHA1 for example, which generates a 160 bit hash, then to store all the possible hashes would require about
:
or in PHP:
$bits = pow(2, 160)*160*2; // ~4.68E+50
(multiplied by 2 since the inputs will take up as much space as the hashes)
You can take away 7 decimal points (8*10^6) in order to get the number of gigs which is around 10^43 Gigs. (10 with 43 zeros)
So it isn't possible to save that amount in a MySQL database. Thus the need for rainbow tables.
If you do the same thing for SHA256 which produces a 256 bit hash like the name suggests then you have to save ~10^72 Gigs.
To add to the problem of storage, you cannot compute all the possible hashes on a single PC due to physical constraints. See:
http://en.wikipedia.org/wiki/Brute_force_attack
under "Theoretical Limits".
Essentially computing all the possible hashes, is a brute force. (Even though you're saving to DB and doing lookups later, the generation of the DB is through brute force). Any hash function that produces more then 128bit hashes will require a considerable amount of parallelized computing to computing even part of the possible hashes. This is why rainbow tables only cover certain characters and not the full ASCII table. Usually a-zA-Z0-9 and a few special characters.
As an example.
The amount of time required to break a 128-bit key is also daunting. Each of the 2128 (340,282,366,920,938,463,463,374,607,431,768,211,456) possibilities must be checked. A device that could check a billion billion keys (1018) per second would still require about 1013 years to exhaust the key space. This is a thousand times longer than the age of the universe, which is about 13,000,000,000 (1.3×1010) years.
AES permits the use of 256-bit keys. Breaking a symmetric 256-bit key by brute force requires 2128 times more computational power than a 128-bit key. A device that could check a billion billion (1018) AES keys per second would require about 3×1051 years to exhaust the 256-bit key space.
http://en.wikipedia.org/wiki/Brute_force_attack
SHA256 is produces 256 bit hashes. So you can compare it to trying to brute force a 256 bit cipher key, which is not possible.
The attacks on hashes are based on problems with the way they are generated. For example, not using a salt, makes the input (the password) a very small range. Thus it will lie within the range covered by a rainbow table.
If a salt is used, but the salt is known to the attacker, then they can create a brute force attack, for which the running time will depend only on the complexity of the password, which is normally not complex.
So the main concern is how to hash passwords securely. I've already cited a few links to resources on the topic in my first post in the thread.
Offline 
But other than that, great way of explaining what I was talking about earlier on. 
Some amazing bits of advise here.
Marked 
