In particolare, sono curioso di hosted_login_token di Recurly.com, descritto qui: link
Fondamentalmente, è un token che consente di essere archiviato in chiaro e persino inviato via e-mail con fatture e notifiche dei clienti. È unico per cliente, ma non scade mai. È anche incorporato nel link che gli utenti utilizzano per accedere a queste pagine ospitate, quindi ovunque l'URL potrebbe essere raccolto (SSL aiuta con questo, sì?) Potrebbe essere una vulnerabilità.
Le interfacce utente che fornisce l'accesso per contenere:
- PII utente, come nome, indirizzo e numero di telefono,
- Informazioni di pagamento occultate, ad es. 43XX-XXXX-XXXX-1234 per un CC # (senza CVV),
- Dati della fattura su ciò che il cliente ha acquistato.
Da un lato, ci sono molti dati da raccogliere se, ad esempio, abbiamo memorizzato i token e siamo stati compromessi o un relay di posta elettronica da qualche parte è stato compromesso. D'altra parte, questo è tutti i dati che vengono regolarmente inviati via posta ordinaria ogni giorno.
Ancora più preoccupante, queste interfacce utente possono anche essere configurate per consentire agli utenti di aggiornare (ma, ancora una volta, non visualizzare) le loro informazioni di pagamento o di annullare le loro iscrizioni.
Vorremo utilizzarlo per fornire ai nostri clienti l'accesso alle pagine di amministrazione di fatturazione self-service in hosting con tutte le funzionalità di cui sopra. Gli forniremo l'accesso incorporando un collegamento (contenente il token) a queste UI dietro il nostro login, sul nostro dominio. Tutte le pagine del nostro sito contenenti il token verrebbero pubblicate su HTTPS.
Come dovrei gestire questi hosted_login_token s?
(Grazie in anticipo, da questo newbie security.stackexchange.)