The question is a bit ambiguous, it all depends on whether you need to "scramble" it to then use to:
1) log in to a forum or to a webmail (a vault of the passwords YOU use), or
2) validate that someone logging in to a forum you manage is indeed providing the right password (securely validate users' credentials)
@atom0s' answer is for the situation 2.
Indeed, NEVER do any kind of encryption, as its reversible nature could make you liable for leaking your user's original password data, which would then result in possible reusing them in other forums or other kinds of web credentials, in case you (as a provider of the forum) get hacked and the database is stolen.
I do have some minor remarks to improve the answer, though
While the salt is indeed something you should definitely add, it does not prevent an attacker to try to break each individual password - with dictionary attacks, for instance.
If your database gets stolen, the salts are there as well - you *need* them when doing the validation, to know that *that* salt for that user + abc1 does result in that hash you stored. If you don't keep the salt, you have no way of knowing if the user-provided password will turn into the hash you stored.
Additionally, each user on the database should have his own random salt, so that identical passwords for multiple users result in completely different password hashes.
The way to prevent (or harden) brute forcing is introducing a load factor - a repetition of the number of iterations (MD5, SHA256, whatever) that both the legitimate forum code and also a bruteforcer must execute till it arrives to the final result.
Running an MD5 of a certain input + salt takes X ms. But running it 1 million times, for instance, will take 1 second. If a brute forcer needs to spend 1 second of active CPU to test each possible password, you can see it's much harder to do a brute force or even a dictionary attack.
The downside is that the forum server will take 1s to validate a legitimate user login. A balance must therefore be achieved.
There are lots of details to take into account when trying to design the possible safest way to handle user credentials.
One of many possible guides can be found on this OWASP page: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
The main aspects mentioned there:
- Unique salt for each usage (not even reuse it for multiple passwords of the same user)
- Also add a site-wide key / HMAC that won't get stored on the database and thus *might* not be available if only the DB is stolen
- Introduce a work factor (reduce feasibility of brute force even if all data is stolen)
And above all: design the system assuming all the data will get stolen eventually.
Also, and if you want to laugh a bit, here's a pretty nice article showing what NOT to do: https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/
You can even play crosswords with the user's hashes and password hints