Q:

User password as key instead of hashing it

I was reading here on Hashes and Salts and I thought about another method to do user authentication. I need your thoughts on this as I might be overlooking something.
Scenario:
For web application authentication, the general trend is to hash the password appending a random salt, with a strong hash function. The random salt and generated hash gets stored in database. Later, when the user wants to authenticate, the user entered password is hashed again with the stored salt and the generated hash is compared with previously stored hash.
Now about my method:

We store one master secret text (as long as it needs to be) in our database and we use unique salt per user.
Instead of storing password hash, we symmetrically encrypt (hash(master secret + salt)) using user password as key and store this encrypted value in our database.
When user wants to authenticate, this previously stored encrypted value will be decrypted  using user password as a key and we will get a hash(master secret + salt).
This decrypted hash will be compared with newly calculated hash(master secret + salt)
If user enters a wrong password, the decryption will fail and we will get a wrong hash which will fail to compare against hash(master secret + salt)

In this way we are not storing user password in database in any form (plain text, hash, encrypted).
I want to know how this  method compares against our usual method of password hashing.

A:

You do store the "hashed" password. To be precise, you store some data on the server:

A value S (the "salt").
The "master secret" M (which cannot be really secret, since the server stores it "as is" somewhere in its entrails).
E(h(M||S),K): encryption of the hash of the concatenation of M and S, using key K which is derived more or less directly from the user password.

Given these data elements and a potential password P, it is possible to do some computations which result in a boolean result: P is the correct password, or not. That's normal: the server must be able to verify an incoming password, using what the server "knows" only. But if the server can do it, an attacker who got a copy of the server data can do it too. That's unescapable. The stored data elements cannot be directly used to recompute the password, only to verify a given password, so that's one-way.
This is called password hashing. That there is a so-called "master secret" and that an encryption function is internally used are just red herrings; you are simply making a custom password hashing function.

There can be some value in the "master secret" if you actually manage to keep it "secret". The server must know it in order to operate, so it is not really hidden, but you can arrange for it not to be stored in the database, keeping it out of reach of usual SQL injection attacks. It won't do anything against an attacker who obtained a root shell on your server, though.
Using such a "secret" in a password hashing function is called "peppering" and the normal, cryptographer-approved way of doing it is to make the password hashing function a MAC with the "secret" as key.
See this long answer for a primer on password hashing, its concepts, tools and terminology.

