Requisito per l'invio di nome utente e password in distinti messaggi di posta elettronica

11

Ho un'applicazione che invia nome utente e password per e-mail (password temporanea casuale, modifica obbligatoria al primo accesso).

Un grande cliente ha questa politica di "non inviare mai nome utente e password nello stesso messaggio" - e richiede una modifica per dividerlo in due messaggi e-mail, uno contenente il nome utente e l'altro con la password.

Capirei se la domanda fosse quella di inviare informazioni utilizzando canali distinti, diciamo, inviare il nome utente via e-mail e password via SMS, perché compromettere entrambi i canali è più difficile. Ma l'invio delle informazioni suddivise in due messaggi sullo stesso canale non ha senso per me: se ritieni che la tua email possa essere compromessa, devi presupporre che l'attaccante sarà in grado di leggere entrambi i messaggi, quindi qual è il punto di fracking?

C'è qualche logica dietro questa politica?

    
posta Paulo Scardine 19.09.2013 - 01:29
fonte

3 risposte

12

Personalmente definirei questo consiglio sulla sicurezza come Cargo Cult Security . Non conosco un exploit che comprometta solo una singola email. Non c'è un link più debole che viene rimosso inviando questo in due e-mail, è solo fastidioso per gli utenti.

Una password o token temporanea passata come parametro GET viene comunemente inviata via email. Non ho mai visto questo processo suddiviso in due e-mail.

Vorrei chiedere all'analista della sicurezza che ha raccomandato questa modifica di fornirti uno scenario specifico in cui ciò migliora la sicurezza.

    
risposta data 19.09.2013 - 01:53
fonte
6

Sembra una casella di controllo in un elenco di controllo.

Non vedo alcuna vera sicurezza se non rendendo forse più difficile per l'utente inoltrare accidentalmente le e-mail entrambe alla stessa terza parte o mailing list. Qualunque cosa abbastanza criptica riguardo le e-mail per separarle l'una dall'altra le renderebbe anche più difficili da usare per l'utente. Inoltre, a meno che l'utente non disponga di una quantità significativa di spam, le due e-mail saranno anche direttamente sequenziali nella posta in arrivo dell'utente indipendentemente da quanto dissimili le e-mail nel contenuto e nell'origine.

Puoi aggirare il problema dell'audit se la tua applicazione ha un sito web - includi solo un URL di creazione di un account one-shot che porta l'utente a una pagina HTTPS per inserire la nuova password.

    
risposta data 19.09.2013 - 02:03
fonte
2

Per la maggior parte, hai ragione sul fatto che la politica ha senso solo quando il secondo messaggio viene inviato fuori banda. Ci sono casi in cui posso pensare a questo vantaggio dividendo la coppia su due e-mail:

  1. Un utente malintenzionato potrebbe essere in grado di utilizzare il nome utente + la password originale per semplificare l'accesso al proprio account tramite l'assistenza clienti. L'email del nome utente può essere archiviata e la password eliminata. Anche se controllano il tuo account email, probabilmente possono semplicemente eseguire una reimpostazione della password.

  2. Fuori nella natura della rete, le rotte che i pacchetti di messaggi viaggiano possono variare in modo significativo. Se quel percorso finisce per attraversare un router meno che reputato, potrebbe registrare la coppia nome utente / password. I messaggi separati possono seguire percorsi separati.

  3. Eavesdroppers, ad esempio quando qualcuno ha controllato la sua e-mail sul WiFi Starbucks. Se non si aprono entrambi, allora c'è meno possibilità che entrambi vengano registrati.

Sì, 2 può essere mitigato in modo significativo attaccando ai servizi che utilizzano esclusivamente HTTPS e 3 è indirizzato completamente da esso.

    
risposta data 19.09.2013 - 02:39
fonte

Leggi altre domande sui tag