It depends on the hash function you use. If you use fast hashes like MD5, SHA1-, SHA-3, it is not secure, because they make brute forcing easier.
There is a set of hash functions (called also key stretching or password derivation functions) like PBKDF2, scrypt, Argon2 that require relatively much computation resources (much CPU, much memory) for every hash. Single user notices no difference. But these functions make brute force essentially more expensive than the normal fast hashes. If is quite secure to use these hash functions. If somebody gets access to your database with such hashes, it will be impossible to recover passwords from such hashes.
"Are there any other approaches": Yes. Many.
- Use client certificates issued by you or by your company to authenticate users. Then you don't need any hashes at all.
- Use 2-factor authentication. It can be based on SMS, OTP (one time password), TANs including Photo-TAN. Think of Yubikey or Titan hardware tokens.
- Define user access profile. It is a combination of IP range, device data (laptop, smartphone model etc.), browser data (browser agent, screen resolution, etc.). This is something like Google uses. For Google you don't have to force users to have complex passwords. You don't have to think much of hashing. If you enter correct password from an unknown device or IP, Google requires additional confirmation that it is you.
Important: I suggest you to think if additional approach is adequate to what are you protecting.
What will it cost you or your users if smb. recovers some of the passwords? And what will it cost you to implement other approaches? If the whole purpose of your application is to send customized greeting cards, then hacking such an account doesn't lead to any serious harm and even normal fast hashes like SHA-3 are quite sufficient. But if your application provides access to banking account, you may need serious 2-factor authentication, because the costs in case of recovered password are much higher.