C'è un modo migliore per avere download sicuri senza il bisogno di un account?

Naviga le tue risposte
3

Il lavoro

Hai il compito di fornire file di grandi dimensioni con dati sensibili a persone esterne alla tua azienda.

Limitazioni e mandati

  1. I destinatari dei dati devono essere avvisati via email
  2. Le dimensioni dei file vietano l'invio dei dati tramite e-mail
  3. Potrebbero esserci decine o centinaia di migliaia di utenti, quindi non è possibile fare account per loro.
  4. Un destinatario potrebbe essere chiunque abbia un indirizzo email.
  5. È necessario che un destinatario sia in grado di utilizzare il link in modo programmatico e scaricare il file in modo da poterlo importare nel proprio software senza interazione umana.
  6. Devi mantenerlo il più sicuro possibile.

Soluzione proposta

Fornirei ai destinatari un collegamento tramite e-mail (TLS protetto) e farebbero semplicemente clic sul collegamento per scaricare il file. Il link conterrebbe un codice di 25 caratteri che consentirebbe loro di accedere al loro file. Se un indirizzo IP (o un indirizzo MAC?) Forniva un codice errato 10 volte, sarebbe stato inserito nella lista nera per 14 giorni per impedire a un attacco di forza bruta di accedere a più file. Il file sarebbe un file zip protetto da password con l'indirizzo email del destinatario come password. I file stessi sarebbero disponibili solo per un determinato periodo di tempo; la scadenza di quel tempo farebbe sì che i file venissero cancellati da un processo di back-end e il codice diventasse disponibile per un altro download (anche se potrebbe non essere mai riutilizzato).

Quindi, con la mia soluzione, uno scenario possibile sarebbe: Mi viene fornito un indirizzo email e ho bisogno di fornire loro un file personalizzato per loro. Creo un file, lo zip con l'indirizzo e-mail del destinatario come password, lo salva nella mia applicazione, la mia applicazione dice che l'URL del file sarà www.test.com/GetFile.aspx?UID=12. e poi ho inviato loro un link.

Ovviamente, se l'e-mail che inviamo con il link è compromessa, anche i file collegati nell'e-mail potrebbero essere compromessi.

C'è un approccio migliore?

    
posta UnhandledExcepSean 18.05.2015 - 22:17
fonte

3 risposte

4

La sicurezza deve essere bilanciata con l'usabilità. La crittografia del file con l'indirizzo e-mail offre solo una piccola quantità di sicurezza aggiuntiva e aggiunge complessità per gli utenti finali.

Bloccare l'utente per 2 settimane dopo solo 10 tentativi falliti è eccessivo. Potrei facilmente vedere qualcuno in un'azienda che prova 10 volte e che non ha successo e che causa loro enormi mal di testa. Un codice generato a caso da 25 caratteri è già sufficientemente protetto, quindi perché preoccuparsi degli attacchi di forza bruta che causeranno solo problemi?

Scadere il collegamento dopo un certo periodo di tempo è soddisfacente e relativamente standard. Ciò significa che compromettere la casella di posta elettronica non compromette il file.

    
risposta data 19.05.2015 - 00:07
fonte
2

Supponendo di avere l'e-mail per l'utente e qualche lato del server segreto puoi fare quanto segue:

  • Crea un token che contiene il file per il download ed è crittografato con il lato segreto del server, cioè solo il server stesso può decodificare il token. Guarda i token JWT per un esempio. Per assicurarsi che lo stesso file non risulti nello stesso token, è possibile aggiungere alcuni dati casuali anche prima della crittografia (nel caso in cui la crittografia stessa non fornisca già un qualche tipo di vettore di inizializzazione casuale). Potrebbe anche essere utile aggiungere un tempo di scadenza per il token. E nel caso in cui il token non sia abbastanza lungo e temi attacchi di forza bruta, aggiungi un po 'più padding casuale al token (prima della crittografia).
  • Invia un link con il token all'utente via email.
  • Se l'utente accede al sito controlla la validità del token (cioè può essere decodificato, HMAC si adatta, non è scaduto) ed estrae il file che l'utente vuole ottenere.
  • Fornisci il file all'utente. Per la protezione contro MITM puoi usare qui https, ma nota che un potenziale aggressore potrebbe aver intercettato il messaggio.

Per una protezione aggiuntiva contro un utente malintenzionato che potrebbe aver intercettato la posta con il token, è possibile richiedere un segreto all'utente nel punto in cui l'utente richiede il download del file o è possibile generare un segreto e mostrarlo all'utente. Il segreto deve essere aggiunto al token e deve essere fornito dall'utente durante il download del file.

    
risposta data 19.05.2015 - 07:57
fonte
1

Idealmente dovresti cifrare il file che vuoi condividere con una chiave simmetrica, firmare il file crittografato con la tua chiave privata, quindi pubblicare il file crittografato in un luogo pubblico (un server web accessibile pubblicamente funzionerebbe). Quindi, quando vuoi inviare a qualcuno il file, devi crittografare la chiave simmetrica del file crittografato con la chiave pubblica dell'utente a cui vuoi inviare il file e inviare via email quella chiave all'utente insieme a un link al file.

L'utente può quindi scaricare il file crittografato, verificare il file utilizzando la chiave pubblica, utilizzare la propria chiave privata per decrittografare la chiave simmetrica che gli ha inviato, quindi utilizzare quella chiave per decodificare il file.

Questo approccio è molto più sicuro di quello che hai suggerito nella tua domanda, poiché non si basa sulla sicurezza dell'account utente dell'utente per mantenere il file privato, e assicura all'utente che il file che hanno scaricato realmente è venuto da te.

    
risposta data 18.05.2015 - 23:21
fonte

Leggi altre domande sui tag

Manutenzione HSM PHP: sono libero da SQL Injection? [duplicare]