1

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 hosted_login_tokens?

(Thank you in advance, from this security.stackexchange newbie.)

Improve this question
3
  • 1
    Noob has some negative implied meaning, beyond how you would normally describe yourself. Newbie is more respectable.
    – 700 Software
    Sep 22, 2016 at 20:29
  • "How should I approach the use of this API" Please clarify how you will be handling the token. Is your application this via email, or is that beyond your control? What application are you designing. If the API is beyond your control, then you should clarify the parts you do control so our advice is applicable to your work.
    – 700 Software
    Sep 22, 2016 at 20:32
  • Thanks, @GeorgeBailey. Made several edits to improve the question.
    – Eric Nguyen
    Sep 22, 2016 at 23:26

1 Answer 1

Reset to default
2

Token as an equivalent of a document

As I understand from your question, the token essentially provides access to all the information typically contained in a customer invoice. This implies that you should approach the security of this token (both in storage and in transit e.g. over email) in the exact same manner as you would the document itself.

If sending that invoice in pdf format over email is acceptable, then sending that token is acceptable as well. If you would only allow downloading such invoices over https but not over http, then the urls with these tokens should also be set https-only. A database containing a lot of these tokens has the same risks as a file storage system containing a lot of historical invoices.

The only token specific risk that comes to mind is guessability - if the tokens are not properly implemented, an attacker would be able to obtain this data without having a proper token by either random guessing or by modifying an existing token. However, it seems that it's not the case for these particular tokens; a simple true random ID from a very large space of possibilities is safe against such attacks.

Improve this answer
1
  • This clarifies a lot! Thanks. I updated the questions with some additional wrinkles, esp that users are able to modify some account information using this token. This is substantially more problematic, so I'd love your opinion there.
    – Eric Nguyen
    Sep 22, 2016 at 23:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .