And stored in a database, which for authentication purposes would need to be able to convert said "encrypted" data into plain text for any customer service representative, the billing systems, etc. The key has to be something that's widely accessible, or goes through a proxy.
Assuming that they are using widespread password encryption practices (i.e. only storing a salted, hashed version of the password) then they never convert the encrypted data back into plain text for authentication. Instead, they salt/hash the password that the user has entered using cryptographically strong but publicly known algorithms (no secret keys) and compare the result to what is in the database. Brute-force or dictionary attacks can be used against this, but there is no such thing as a decryption key that can reverse a hash operation.
Either way, it's highly unlikely the "encryption" scheme is much more sophisticated than a single XOR operation. Decrypting that field for a substantial portion of the database SELECT statements would be a huge overhead.
I disagree that their encryption scheme would be unsophisticated for the reasons you provide. Applications do not typically examine the password field on a substantial portion of database calls. Applications do typically use strong cryptography during authentication calls and the overhead is not prohibitive. If they are using XOR to encrypt passwords, it is not for technical reasons.