Hashing + sicurezza in quanto riguarda un sito di condivisione di file teorico

Question

Hashing + sicurezza in quanto riguarda un sito di condivisione di file teorico

#1 da (1 voti)
#2 da (1 voti)

0

In questi giorni è possibile hash un file sul lato client, inviare l'hash al server e fare in modo che il server verifichi se quel file è già caricato. Se lo è, possiamo saltare il caricamento del file e farlo sembrare caricare quasi istantaneamente all'utente. Questo può anche risparmiare un sacco di larghezza di banda per un sito di grandi dimensioni.

Ciò ha tuttavia alcune importanti implicazioni sulla sicurezza.

Se l'utente è intelligente, può utilizzare queste informazioni per determinare quali file sono già presenti sul server, inclusi documenti illegali o riservati
Può produrre milioni di hash finti, inviarli al server e sperare in una collisione per accedere a documenti casuali
C'è una collisione legittima ma non intenzionale in cui gli hash sono uguali, ma il file è in realtà diverso

La mia domanda è: ne vale la pena? Possiamo mitigare alcuni o tutti questi problemi? Come?

security theory hashing

posta mpen 21.05.2014 - 22:29

fonte

2 risposte

Leggi altre domande sui tag security theory hashing

inserire metodi nella classe base che non ha senso / farvi parte [chiuso] Tipo persistente in Java - dovrei usare le bandiere?

score 1 · Answer 1

Certo, se sospetti che un certo file illecito si trovi sul server, puoi caricarne un'altra copia e dedurne che è lì. Ma dedurre non è una prova in un tribunale; dovresti comunque ottenere il permesso al proprietario del repo per rivelare quali documenti sono o non sono presenti nei loro sistemi, altrimenti potresti o non potresti convincere un tribunale che in realtà hanno quel file. E tu stesso stai caricando deliberatamente lo stesso file potresti indebolire il tuo caso - se lo metti volentieri su un servizio di archiviazione su Internet, quanto può essere segreto o prezioso?
Poiché gli hash vengono utilizzati solo internamente dal provider di archiviazione, non vedo come un utente che invia valori hash possa compromettere o, in effetti, ottenere qualcosa.
Le popolari funzioni di hash sono abbastanza buone che non è una preoccupazione. Molti di loro sono rotti rispetto a un attaccante intelligente e capace che cerca attivamente per generare collisioni di hash, ad es. condurre un attacco di compleanno. Ma due file che diverse persone generano e caricano sono ancora estremamente improbabili da contrastare - improbabile come in "dovresti preoccuparti di un meteorite che colpisce il data center".

score 1 · Answer 2

Questo è un approccio sbagliato. E io credo che Dropbox sia stato arrestato qualche tempo fa.

L'approccio funzionerebbe se:

I file non sono criptati sul server e semplicemente copi il file senza un upload (il che significa che chiunque può vederne il contenuto)
Usi una chiave di crittografia condivisa per tutti i file e semplicemente copi i file senza un upload (il che significa che puoi vedere il contenuto)
Le chiavi di crittografia vengono archiviate sul server per consentire di decrittografare e crittografare nuovamente i file quando si esegue tale copia (ovvero è possibile visualizzarne il contenuto).

Ciascuna di queste opzioni, IMO, rappresenta un serio problema di privacy. Se vuoi che sia sicuro e privato, ti consigliamo di ottenere un codice per utente che non archivi e / o esegui la crittografia sul lato client.