It is not encryption, this is hash. And you should not use this method (which is crypt method from the Unix) as it is highly unsafe way. If you want something secure, then check Comeonin with Argon or Bcrypt functions.
If this is already in prod, please think of a way to migrate the data to a more secure system, for example by using user logins to upgrade the hash to a secure version. The current scheme endangers your users.
While I agree with all the previous posts regarding the security of md5crypt, the OP did indicate that this is for compatibility with an existing implementation. Migrating to something better still requires an implementation of the legacy algorithm.
That’s a bit like saying “if you drive carefully you don’t need seatbelts”. Even if it’s technically correct why take the risk at all, especially when more secure alternatives are so readily available?
Here you would need preimage attack, but still using MD5 is poor solution. TBH using any general purpose hash function for storing passwords is poor solution, as these can be easily implemented in FPGA, which mean that just searching for collisions can be made fast, which is undesirable. That is why we have separate set of KDFs to compute the hashes of the passwords - to make such functions memory-dependant.
If I log in with a wrong password that has the same hash value as the (unknown) correct password then I get access to the account. How is this incorrect? The server hashes the password and compares it to the stored hash. So if you can compute a hash collision, your user accounts are unprotected to anyone that has access to the hashed passwords (for example your staff).
You are right, the correct term is preimage attack which is notably more difficult to do than a collision attack. I confused the two attacks.
I just realized that I have long overestimated the risks of MD5 for non-user-generated long passwords It is always good to post on this forum even if it is rubish as you can learn alot from the experts here : )