Well, I notice that there's a few misconceptions here... First of, one must know that Encryption and Hashing are NOT the same. A basic description of each:
- Encryption: using an algorithm to encode a set of data into a result that is as variable-length as the input, that can keep it secure until it is decoding using the same key that was used to encode it.
- Hashing: using an algorithm to convert an input set of data into a FIXED-LENGTH output, that is, by design, NOT reverse-engineerable. It is impossible to accurately decode a hash to get the original input.
Now, while data that needs to be retrieved (DRM-secured media, "saved" passwords in a password manager, secured data) encryption is what will need to be used.
On the flip side is hashing, which is used on password databases, or at least those that aren't a complete joke. (yes, many major sites still store passwords in plaintext) This adds a layer of security to the users' passwords: if a hacker manages to steal the database (or part of it) it merely makes the brute-force attack POSSIBLE, as they now can just set up their own system to check passwords by entering in repeated, different combinations to see if they match. Otherwise, they'd be limited by the "lock-out" mechanism most log-in routines have, where typically 3 wrong passwords in succession will prevent further log-in attempts for a while. (such as 15 minutes here)
Now, for added security, many hashes are "salted;" that is, a "salt" is an extra value that is added to the input (that is, your password) before it is hashed. This makes the brute-force attack much more difficult, as now stealing the database is insufficient, as that only tells the hash result of the password+salt, which leaves the hackers having to guess BOTH all combinations of password AND salt. So if, say, your password is "The Elder Scrolls V: Skyrim", while the MD5 hash (the most common, if hardly the best, hashing algorithm) will be "462eec40be7229f6e8ac7928a247703b", if the passwords are salted, it won't show up like that, and hence that database entry could mean ANYTHING.
Also, do remember that just because you're one user out of millions doesn't mean that you're going to be safe against them deciding to pick YOU to hack; hackers who try at this tend to not "pick individuals," but attempt to simply see how many of those accounts they can crack at once. Hence they often don't brute force, but rather start by using something like a "rainbow table." In short, they have a file with, say, "the top 1,000 passwords," all in their pre-hashed version. They then simply do a cross-check with the stolen database; as a general rule, a large number of people will be using these "most popular" passwords. (it's what makes them the most popular, after all) If 10% of a 10,000,000 database use the top 1,000, that's a full million accounts cracked without having to brute-force a thing. This is why you're told to make sure your passwords are unique. Of course, nothing is 100% secure: the downside of a hashing algorithm is the logical trade-off for being reverse-engineerable: multiple source passwords could yield the same end result... And if your password might be very obscure, there's no guarantee that the end-result hash will match that of one of those "most popular passwords." This is why you STILL change your password in situations like these.
Now, as for ENCRYPTED data... It actually tends to be less secure than hashed passwords, and ESPECIALLY salted and hashed passwords. So yes, all the more reason to be cautious.