I've got a totally theoretical question to you on today - what is the "best" practice for storing passwords? [Best in terms of security and performance]
Usually, especially PHP-Developers tend to store user credentials either in plain text or as hash, using MD5 or SHA1 and their successors. The more clever web developers and software cooks even add some salt to the password before hashing.
Android Developers usually seem to store in plain text, as far as I have seen it until yet, naively relying on the user rights concept of android, even arguing that rooting the devices the user's own fault.
There are lots of different practices out there. Plain text for those applications, where the developers either rely on platform security or want the user to recover their own password. Hashing where developers rely on the integrity of their hashing algorithm, ignoring collision attacks and so on. Salted Hashings where developers read that plain hashing is a bad thing because of rainbow tables. There are even some developers out there who use real cryptography, but usually the key is somewhere recoverable.
My idea was to use AES (or [still not broken] symmetric cryptography in general, like blowfish and so on), crypting the padded password (for hiding the password length) with some salt prefix. The Key would be the users password, which should make it impossible to recover and verifying the password without the password.
I wonder why the usual practice differs from that idea - so where's the fault? The complexity shouldn't be that much high, because there are good implementations of AES out there, even hardware implementations. There are no hash collisions possible on this.
So am I right that no one could use a data dump with those passwords for anything other than bruteforcing? [Of course there are other attacks, which are regardless of the back-end password storage, those are not topic of this question]
May it be that this idea is pretty similar and related to bcrypt, but without multiple iterations?