Secure website password storage

I've seen a number of posts about using salts and hashes to create secure versions of passwords that can be stored in a database.

However, one question is puzzling me and I can't see a problem so I thought I'd post the question here and see if other people can point out any flaws in the idea.

My basic idea is to generate a public/private key pair and then destroy the private key. My limited understanding of public/private key cryptography is that if I don't have the private key then decrypting a message encrypted with a public key is "mathematically improbable".

I would use the public key to encrypt a password and then store the encrypted version 开发者_运维百科in the database. When someone attempts to login, I simply encrypt the password using the public key and see if it matches the stored one?

Is there some horrible flaw in this idea? Would salts and hashes be somehow more secure?

The issue with this approach is that unlike a hash function, the output of the encryption function is generally nondeterministic: you can encrypt the same payload with the same public key twice, and the encryption algorithm would produce entirely different ciphertexts each time. RSA encryption, for instance, incorporates random padding into the input to defend against certain classes of attack.

In contrast, the output of cryptographic hashes is deterministic, which accounts for being use in problems such as password storage where this property is is needed.

you've effectively described the hash part -- consider the situation where two individuals share the same password -- with your basic approach, the stored values would be the same. So, if you discover the hashing algorithm and dictionary attack it you can generate a password -> hashed value table and instantly look up a possible password for each individual.

After all, if a hacker got your table, they probably got your code, too...