The disadvantage you mention is less relevant than you think.
The bigger disadvantage to Asymmetric Encryption is that it's quite a bit cheaper than a properly configured Slow Password Hash.
So, you should use a Slow Password Hash. (i.e. BCrypt)
Theoretically, using an Asymmetric encryption routine (where the Private Key is permanently forgotten) is a reasonably secure one-way hash function, but this is not suitable for low-entropy input data (i.e. passwords)
Asymmetric cryptography is usually more expensive than hashing and should therefore require less stretching for the same benefits.
I see that you understand the importance of an expensive hash routine to prevent Brute Force. While Asymmetric Encryption is slower than General Purpose Hash functions (i.e. SHA-2), what you should be using is a Slow Hash function (i.e. BCrypt) which is more expensive than either of the two aforementioned options.
Stronger guarantee on the entered password: there is one and only one password which can be accepted. That is, no collision can be
accepted (contrary to hashing functions) as else the decrypted
password would not be unique.
Modern hash functions have a large enough name-space that collision is not likely to occur in the application's lifetime. Trying to find something even more collision-resistant is pointless.
The main disadvantage I see is that the stored password length is
correlated to actual password length, giving a clue on password
strength. This can be mitigated by introducing a "lengthy" salt to the
password, which will ensure that short password only look as short as
the salt. Long password remain mostly unaffected but that is fine as
they are long but might take space in the database.
The attacker would be able to see how many blocks long the encrypted password may be, but they would not be able to tell any more specifically than that. The vast majority of passwords can be stored in a single block (assuming a strong key size like RSA 1024 or RSA 2048) so this clue would be of limited use to an attacker.
Are there any other disadvantages to this technique?
Asymmetric Cryptography is less expensive than a Slow Password Hash routine such as BCrypt.
Disk space requirements are higher.
"Don't roll your own."
There you have it, you should be using a Slow Password Hash such as
- BCrypt, but be sure to run a quick SHA-2 hash on the input data, so super-long passwords will not be truncated by BCrypt
- PBKDF2 but that is less GPU-resistant
- SCrypt is better than BCrypt if you have a high enough work factor. Otherwise it is worse against GPUs.
- The winner of the Password Hashing Competition may be even better than the aforementioned, but has not yet stood the test of time, so don't use it just yet. It's called Argon2, and has separate Work Factor settings for CPU time and Memory load. (nice!)
Most of these options generate random Salt by default, but do verify whether this is the case!
It is best to include some Pepper (~72 bits of entropy) before the Password prior to hashing. The Pepper can be the same for all your users, but should be stored in a file outside of the database so that component cannot be found via SQL Injection.
Make sure your Work Factor requires about 100ms (with appropriate DoS protection) on your target hardware (knowing that attackers will use faster hardware for Brute force)