To store something which allows the server to verify a given password, but does not allow it to rebuild the password; the latter property is desirable, so that consequences of an illegitimate read access to the server database by an attacker remain limited.
So we want a one-way deterministic transform which converts a given password into the verification value. The transform shall be:
- configurably slow, so as to thwart dictionary attacks;
- distinct for every instance, to prevent parallel dictionary attacks, including precomputed tables (that’s what salts are about).
A single invocation of MD5 or SHA-1 fails on both accounts, since these functions are very fast, and not salted. Slowness can be done through nesting many invocations (thousands, possibly millions), and the salt can be injected “somewhere”, although there are good and bad ways to do it. PBKDF2 is a standard transform which does just that, and it is not bad at it (although bcrypt should be somewhat preferable).
However, MD5 and SHA-1 do at least one thing right: they were designed to be one-way. That’s hard to do; it is not even theoretically proven that one-way functions can really exist at all. Cryptographers around the world are currently involved in a competition to design a new, better one-way hash function.
So what your professor seems to recommend is to replace a function designed for one-wayness, with a function which was not designed for one-wayness. It does not correct anything about slowness and salting, but it removes the one good thing about MD5 and SHA-1. Moreover, AES is known to berelatively weak with regards to related-key attacks — that’s not a problem as long as AES is used for what it was meant to, i.e. encryption, but it becomes an important issue when it is subverted into a building block for a one-way hash function. It seems possible to build a secure hash function by reusing parts of the AES design, but it requires substantial reworking (see for instance Whirlpool and ECHO).
So do not use a homemade AES-based password hashing scheme; for that matter, do not use anything which is “homemade”: that’s a recipe for disaster. Security cannot be tested; the only known way to make a secure algorithm is to have hundreds of trained cryptographers look at it closely for a few years. You cannot do that by yourself. Even a lone cryptographer will not risk that.
Hope this helps.