alright, i know that normally when hashing a password you should use a strong encryption such as SHA1/2, or something that is considered cryptographically secure. however what if instead of using a strong hash scheme, you use a weak scheme instead?

for example, let's say i take all received passwords(that are hashed on the client side by something like sha-1), then store it as a weakly hashed 32 bit number with something like the DJB2 or SBDM hashing techniques. the concept is that if the database is compromised, the number of potential collisions is so high it makes sifting through the resulting possibility's very large, and the number of possibility's grow the longer the original password was.

obviously this has it's down side's in that higher collisions means it's potentially easier for a person to simply guess an password for an account and maybe get it right, but i was just wondering what some opinions are for this idea, is it absolutely stupid, or has some small merit?

Here's a good overview of the topic: CrackStation - Salted Password Hashing - Doing It Right

The two main properties recommended are to correctly salt each password before hashing, and to use a hash algorithm that is correctly designed to be slow. The first eliminates various pre-computation attacks and similar attempts at efficiency by the attacker, and the second makes any form of brute force attacks incredibly painful.

Using a weak hash might make it hard to guess the correct password, but as you noted, it increases the chances of guessing a workable password. Ultimately, an attacker likely doesn't care about getting the actual password (unless trying to use the same password against different services a single user uses). As long as they can find any password that allows them to be authenticated successfully, they can do stuff.

There is no merit in using a weaker hash function (except in some very exotic, unrelated cases, I remember a scheme that uses a weak hash as a means to prevent MITM attacks on DH). As you've already stated yourself, this only makes the attacker's life a lot easier. If you use a 32-bit hash, there cannot possibly be more than 2³² passwords to check before one comes out as "valid", even if luck is totally against the attacker. That's not even the average case (which would be bad), but the best imaginable case, so this is a desaster. Of course, typical average user passwords still only have a strength of 20-30 bits, even if your hash is 128 bits, but at least you are not giving your keyspace a very small hard limit by design.

Due to the available computional power, the "only correct" way of doing passwords nowaday is to make hashing deliberately slow (rehashing, bcrypt/scrypt, you name it). Alternatively, you might not use hashing at all, but public key cryptography. This avoids the problems of compromising the database alltogether, but it has some different issues (and it's harder to get right, so I would advise you stay with hashing, which is a straightforward, well-established, well-known thing).

But it's really necessary to do something computionally much more intense than "SHA with salt", otherwise, you can almost just as well store plaintext passwords, since the effective security is zero.

If someone stealing your database is something you want to guard against (which is wise!), you must be prepared against an attacker who can literally check billions of hashes per second (a single desktop computer can do several hundred million per second, assume an attacker owns half a dozen computers, plus controls maybe 20 or 30 zombies).

Having a validation scheme that runs much slower (something on the order of several thousand hashes) means of course that you a bit of CPU time at every login, but it also means that your users have days to change their password rather than seconds when your database is stolen. Considering that it could already take a few days before you even notice, this is urgently necessary.

Here's a good overview of the topic: CrackStation - Salted Password Hashing - Doing It Right

This...This was insanely informative, thank you for this link. it's opened my eyes to several creative method of attacks i would never in a million years have considered, and taught me a crap ton, thank you for this link.

The first question is: What kind of attack are you trying to defend against?
The second question is: What methods already exist for defending against that attack?
The third question is: How is this method different, for both good and bad purposes?

For example, if you calculate sha1 on the client, then that means that knowing the sha1 of the password is sufficient to log in -- you don't need to recover the original password, because the only thing the server sees is the sha1. You have effectively just changed the password to be a known 160-bit pattern.

Similarly, if you use hash on the server, then you do that to defend against the risk that the server database leaks. The two kinds of exposure that leads to is making it possible to log in to your service, and using the same password to log in to another service as the same user. Weak hashes allows the attacker to construct a duplicate for logging into your service much easier.