Specifically, I'm curious about Recurly.com's
hosted_login_token, described here: https://docs.recurly.com/docs/hosted-account-management
Basically, it's a token that they allow to be stored in cleartext and even emailed with customer invoices and notifications. It's unique per customer, but never expires. It's also embedded in the link that users use to access these hosted pages, so anywhere the URL might be collected (SSL helps with this, yes?) could be a vulnerability.
The UIs it provides access to contain:
- User PII, like name, address, and phone number,
- Obfuscated payment info, e.g. 43XX-XXXX-XXXX-1234 for a CC# (no CVV),
- Invoice data about what the customer has purchased.
On the one hand, that's a lot of data to gather if, say, we stored the tokens and were compromised or an email relay somewhere were compromised. On the other hand, this is all data that's regularly sent out via snail mail every day.
More troublingly, these UIs can also be configured to allow users to update (but, again, not view) their payment information, or cancel their subscriptions.
We would like to use it to provide our customers access to hosted, self-service billing admin pages with all of the above features. We'd provide them access by embedding a link (containing the token) to these UIs behind our own login, on our domain. All pages on our site containing the token would be served over HTTPS.
How should I handle these
(Thank you in advance, from this security.stackexchange newbie.)