In the case of passwords you can use hashed encryption. What gets stored in the database is a seemingly random string of numbers and letters. When your user logs in you encrypt the value they enter and compare it again and if the encrypted strings match they are let in.
The original hashed value is inaccessible, so it isn't appropriate for most fields. That is where two way salted encryption comes in. A salted encryption can be retrieved from an encrypted field if you have the original encryption string "salt" value used to encrypt it. Then the salt can be saved outside of the database in the php code. Then if someone gets your database they won't be able to decipher the data unless they also get a hold of your salt value. Since getting data from a database and getting data from php are both difficult for a hacker, getting both at once would be more difficult and therefor your data is protected.
The drawback to using a two-way encryption for data is that you can no longer do keyword or partial match searches. Any search would need to be exact match. So really you should only hash passwords and only encrypt fields that contain sensitive enough data that you are ok with the accompanying search restrictions.
In the webassist database I hash the password field and use two way encryption on the email address, phone number, last name, and street address fields. If someone were to get their hands on our database they would only know the first names, city, and state of our users which they couldn't do much with.
There are of course a lot of complications and considerations that you have to use once you start using encryption. For instance you would want to enforce a strict format for phone number if you encrypt it, otherwise it would be impossible to search. I convert all email entries to lower case, again to allow searching more easily. It adds quite a few layers of complexity.