The other answers already say
No, "roll your own" is rarely a good password storage scheme and yours is no exception.
I'd like to add: It isn't a good scheme for storing/communicating the username either.
You're basically hashing. Nothing wrong with that except:
- You're using a function not designed as a secure hash function. Being a cipher it's surely on the "secure" end of scale but hashing also involves avoiding hash collisions. A cipher isn't typically optimized for having no collision. One-Time Pads are known to be unbreakable, because they have the maximal number of collisions. So a strong cipher makes a poor hash in terms of collisions.
- If you store username and username-encrypted-with-password there are more vulnerabilities:
- In this case, if your database is hacked the attacker doesn't only get
the username encrypted with an unknown password. He also gets the clear text aka. username. So it's a clear text analysis, which for some ciphers is much easier than brute force.
- Hash collisions: The attacker doesn't need to know the password but any that produces the same encryption for a short and given clear text. This might be even easier than clear text analysis.
- If you don't store the username but rely on a single combined transmitted value, there are still drawbacks:
- In this case, you probably didn't consider hash collisions. What about two users, who have the same username? What about two idiots, who have the same username and the same password? What about hash collisions of different usernames and passwords by pure chance (remember: ciphers are not optimized to avoid collisions!)?
- In any case there's the "Pass the hash" attack: An attacker sniffing network communication can simply emulate your application to pass the same data as the user. Did you do anything about that? If not, that's why you shouldn't "roll your own".
Often times the protocol of transmission is as important to security as a strong cryptographic function, independent of hashing vs. encrypting. A bad protocol can expose your function to attacks it's unsuited for, especially "side channel attacks" like "pass the hash" or "man in the middle" that are circumventing the actual crypto-analysis on the side of the attacker.
Your password storage scheme may be prone to such attacks, because you didn't specify, if the username is also stored in clear text. Doing so exposes your scheme to the attacks described above. Not storing it in clear text may require a transmission protocol prone to attacks as described above.
Here are some additional thoughts on transmission protocols in your case, slightly generalized:
If you didn't do anything about the "pass the hash" attack, then your scheme is worse than a whole lot of others. An attacker neither needs to hack your data base nor crack your cipher. He gets what he needs for free by sniffing network traffic.
HTTPS may suffice, although it can be worked around by "man in the middle": Users aren't checking for authentication certificates, are they? An attacker simply opens an unauthenticated but encrypted connection to your user and whatever is expected connection to you.
An additional Challenge-Response scheme may add security. Prior to login the client receives a one-time random string (challenge) that he's required to build into the hash (response). An attacker couldn't reuse a sniffed hash, because the challenge isn't reused either.
But again, no need to "roll you own".