Analogy: As a locksmith, I may (with the customers' permission) keep records of what I've done for them, including the details of their keys. But that puts me at risk of having my own shop broken into and the list stolen (or an Evil Employee doing so) -- in which case the crook could make keys for many houses, and I'd be liable for not having protected this information better.
The solution for keys is to NEVER store they key information in plaintext. Store it encrypted, and never write down the information needed to decode this data. If someone steals the encrypted list, they can't do any damage with it.
Of course, for a computer, "never writing down" would mean it couldn't decode the passwords. But we can solve that problem by creating a system where we don't actually have to decode them. Instead, we take the password the user typed, encode it, and compare the encoded version with the encoded password we stored. If they match, the user typed the right password. There are "codes" (cryptographic hashes) which allow encoding but not decoding, so this can be made respectably secure.
Hashed password lists can still sometimes be cracked, but it is TREMENDOUSLY more expensive to do so -- and as importantly, you can show that you made a reasonable effort to protect the users' data, so your liability is much less.