Quali sono le implicazioni sulla sicurezza di consentire il checkout degli ospiti utilizzando un indirizzo email associato a un account noto?

Non ti preoccupare se non comunichi nulla agli utenti anonimi. quando l'indirizzo email di un ordine ospite corrisponde a un account esistente, devi procedere come se quell'account non esistesse. La richiesta di accesso dopo aver ricevuto tali informazioni può indicare che l'account esiste.

Guida sempre gli utenti al flusso di lavoro ideale. L'uso di un account stabilito faciliterà il controllo sia per te che per il cliente. La disponibilità dello stato dell'ordine e della cronologia sono spesso utili per motivi non direttamente correlati alla sicurezza. Se il cliente si aspetta la cronologia degli ordini, allora un gentile promemoria per il login è effettivamente utile.

In caso di dubbi, chiedi. Vorrei dare al cliente la possibilità di accedere o effettuare il checkout come ospite come prima opzione dopo aver proceduto al pagamento. Questa opzione dovrebbe essere data prima di chiedere l'identificazione di informazioni come nome, indirizzo o dettagli di pagamento. Potresti incoraggiare gli utenti ad accedere compilando le informazioni di fatturazione / spedizione dal loro account, se tu fossi così inclinato.

Mitiga gli attacchi di forza bruta. Indipendentemente dall'implementazione di un'opzione guest, il tuo processo di recupero degli account registrati non dovrebbe indicare se tale utente / email è registrato. Questo è in qualche modo tangenziale al checkout degli ospiti, ma è correlato poiché gli utenti potrebbero effettuare il checkout come ospiti perché hanno dimenticato le loro credenziali. Personalmente, preferirei reimpostare la mia password e utilizzare le informazioni salvate piuttosto che estrapolare la mia carta di credito.

Ad esempio, chiedi l'indirizzo email associato all'account, quindi visualizza lo stesso messaggio indipendentemente dal fatto che esista un account, ad esempio: "Stiamo cercando nel nostro database un account associato all'indirizzo email [email protected]. Se troviamo un account, invieremo le istruzioni per reimpostare la password a tale indirizzo. Potrebbero essere necessari alcuni minuti. "

L'email può spiegare / collegare il processo di reimpostazione della password a una partita, oppure può consigliare loro di scegliere tra la creazione di un account o il pagamento come ospite in assenza di una corrispondenza. Finché l'esistenza dell'account viene rivelata solo in un'e-mail al proprietario dell'account, non vi è alcun rischio apprezzabile.

Non sono affatto un esperto di tali sistemi, ma mi piacerebbe condividere qualcosa che mi viene in mente con questo approccio, forse sarà di qualche utilità.

A seconda di come questo doppio sistema è implementato, penso che il concetto di anonimato potrebbe potenzialmente prendere piede da questo approccio. Ad esempio, un cliente inserisce un indirizzo email, [email protected] . Ora, tu dici che vuoi che il sistema sia in grado di effettuare il checkout come ospite, anche se [email protected] appartiene a un consumatore esistente. Bene, va bene, ma ciò significa che deve esistere una logica interna che deve riportare questo fatto all'applicazione. Di conseguenza, è possibile che qualcuno "guardando" questa interazione abbia luogo ora deduce che c'è effettivamente un cliente nel tuo database con una tale email, e forse decide di provare e autenticarsi come questo utente. Ovviamente, questo potrebbe non avere importanza, ma forse potrebbe valerne la pena.

Lo scenario ha spiegato che non riesco a vederlo aprendo implicazioni impreviste finché il nuovo sistema è stato distribuito correttamente.

Il punto principale da considerare sarebbe quello che l'UID è che lega gli ordini dei clienti registrati insieme? È probabile che se un cliente esistente non è in grado di effettuare un ordine come ospite con l'indirizzo e-mail con cui è già stato registrato, questo potrebbe evidenziare che l'indirizzo e-mail è l'UID utilizzato, impedendoti di spostarti in avanti con i tuoi piani prima di qualsiasi modifiche.