On web applications I build I don't hash the passwords. Instead I symmetrically encrypt the username using the user's password and store the result in the password field. I use RijndaelManaged on dotnet.
On login I do it again and check if there is a match.
My question is, how secure is this now when more and more databases are hacked? I do not know at any given time the user's real password. What the hacker would get from db is the username encrypted with an unknown password. With hashing there is the rainbow tables problem, but with this method not.
Knowing the decrypted value already (username) makes it easier to find the password?

What you do really is hashing: you built a hashing function out of a block cipher. Incidentally, "encryption of a known value with the password as key" is how the traditional DES-based crypt scheme for Unix was designed.

On the plus side, your construction includes the user name, which partially provides the effect of a salt: parallel cracking is discouraged because two users using the same password will end up with two distinct hash outputs. "Partially", because upon password change, the user keeps his username, so some form of parallelism is still feasible here; and, perhaps more importantly, the same username may be used in several Web apps (e.g. 'admin'), which makes precomputed tables worthwhile (and the point of the salt is to prevent parallelism, in particular the efficient use of precomputed tables).

On the minus side:


This is a homemade construction. 50 years of research in cryptography have taught us that homemade crypto is very rarely good. In fact, we can "know" that a given algorithm is correct only through years of review by other skilled researchers, and homemade schemes, by definition, never got much of a review.
This is limited. Rijndael is a block cipher that can accept keys up to 256 bits; thus, if you use the password as key, then it must fit within 256 bits. This prevents using so-called "passphrases" which can be strong but easy to memorize passwords by using a lot of space for its entropy (human brains don't like concentrated entropy, but are happy with diluted entropy).
This is way too fast, and this is the biggest immediate problem in your scheme. With a basic PC, an attacker can try a lot of passwords per second, in particular since modern PC have dedicated opcodes for AES. With a quad-core PC, one should be able to try up to about half a billion
of passwords per second. Not many user-chosen password can survive such an onslaught for long.


If you are interested in how password hashing works, then read this. The short answer, though, is still the same: don't use a homemade scheme; use bcrypt.
