[MySQL] Blob o file system?

[Fayble]

Ciao a tutti!

Devo organizzare i documenti di un cliente utilizzando una applicazione web.
Si tratta di documenti riservati quindi devo evitare che questi possano essere raggiunti digitando una URL pubblica (es: http://www.miosito.it/area-riservata/docs/file.pdf).

Non posso pubblicare sopra la root pubblica (il server non è di proprietà).
Potrei utilizzare un file htaccess nella cartella /docs per evitare accessi diretti:

<Files ~ ".+">
Order allow,deny
Deny from all
Satisfy All
</Files>

Questa soluzione garantisce un livello di sicurezza elevato?
Oppure è preferibile utilizzare il tipo di dato BLOB e inserire quindi i documenti su database.

Il costo della seconda soluzione è in genere maggiore (lo spazio su DB costa più di quello web), invece l'efficienza in lettura dovrebbe essere a vantaggio della prima soluzione.

Insomma, i pro e i contro sembrano esserci per entrambe le soluzioni.

Cosa ne pensate?

Ciao!

[deleted_29]

codifica semplicemente il nome del file con l'hash del file stesso (es. con whirlpool o sha512).
htaccess non fa male (in aggiunta).
non andrei di blob, sono sempre un casino da gestire in mysql (soprattutto se son grandi, ovvero piu' di 1MB circa)

---
in casi simili al tuo dò un'applicazione lato-client specifica che decripta i file che tengo criptati sul server.

[Fayble]

Grazie per la risposta.
Non so se rinominare utilizzando un hash possa bastare. Potrebbero comunque sniffare le URL dei files se non si è in https e raggiungerli.

Criptare i files potrebbe essere un'altra soluzione, le password per il decrypt potrebbero stare su DB. Anche raggiungendo l'URL il documento sarebbe illeggibile (anche se il file htaccess ci sarà), quindi solo un attacco al DB rivelerebbe i documenti, mentre un attacco al file system non avrebbe conseguenze. Giusto? Ma fare crypt in upload e decrypt in apertura è una operazione efficiente?

Ciao!

[deleted_29]

Originariamente inviato da Fayble
Grazie per la risposta.
Non so se rinominare utilizzando un hash possa bastare. Potrebbero comunque sniffare le URL dei files se non si è in https e raggiungerli.

E come "dovrebbero" fare, così giusto per curiosità?

Criptare i files potrebbe essere un'altra soluzione...Ma fare crypt in upload e decrypt in apertura è una operazione efficiente?

e perchè non dovrebbe esserlo?

[Fayble]

E come "dovrebbero" fare, così giusto per curiosità?

Volevo dire questo: se non si usa htaccess e si rinomina il file utilizzando un algoritmo di hash, se si intercetta l'URL del file, questo diviene comunque raggiungibile, quindi leggibile:
http://www.miosito.it/area-riservata...4j23n3kj42.pdf

O mi sono perso qualcosa?

e perchè non dovrebbe esserlo?

Me lo stavo infatti chiedendo. Ogni lettura / download del file comunque deve fare prima un decrypt.

Credo utilizzerò:
http://www.php.net/manual/en/functio...pt-encrypt.php
http://www.php.net/manual/en/functio...pt-decrypt.php

Ciao!

[deleted_29]

Originariamente inviato da Fayble
Volevo dire questo: se non si usa htaccess e si rinomina il file utilizzando un algoritmo di hash, se si intercetta l'URL del file, questo diviene comunque raggiungibile, quindi leggibile:
http://www.miosito.it/area-riservata...4j23n3kj42.pdf

O mi sono perso qualcosa?

ma COME dovresti (o potresti) intercettare l'URL?
Voglio dire "se avessi l'url allora potresti".
Ma come fai a prenderla?

Me lo stavo infatti chiedendo. Ogni lettura / download del file comunque deve fare prima un decrypt.

non uso php, non ti so dire.

EDIT: ho guardato, quelle son funzioni per stringhe, non per file

posso dirti però, a titolo informativo, che sulla mia macchina (ho fatto il test or ora) througput di codifica-decodifica twofish è nell'ordine di 700MB al secondo, immagina quanto può incidere su un caricamento-scaricamento da internet

[Fayble]

ma COME dovresti (o potresti) intercettare l'URL?
Voglio dire "se avessi l'url allora potresti".
Ma come fai a prenderla?

Non so se le URL o gli headers della richiesta HTTP possono essere sniffate da un "man-in-the-middle". Se la risposta è si, allora è possibile.

EDIT: ho guardato, quelle son funzioni per stringhe, non per file

Ho testato con successo encrypt e decrypt di file pdf, docx, jpg. Farò altre prove per essere sicuro della correttezza logica dello script, che posto nel caso in cui qualcuno fosse interessato all'argomento o volesse testarlo (anche se la discussione sembra essere "virata" su PHP).

$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$key = "This is a very secret key";
$file = base64_encode(file_get_contents('doc.docx'));
$cryptfile = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $file, MCRYPT_MODE_ECB, $iv);
$handle = fopen('docenc.docx', 'w');
fwrite($handle, $cryptfile);
fclose($nhandle);
$file = file_get_contents('docenc.docx');
$decryptfile = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $file, MCRYPT_MODE_ECB, $iv);
$handle = fopen('docdec.docx', 'w');
fwrite($handle, base64_decode($decryptfile));
fclose($handle); 

posso dirti però, a titolo informativo, che sulla mia macchina (ho fatto il test or ora) througput di codifica-decodifica twofish è nell'ordine di 700MB al secondo, immagina quanto può incidere su un caricamento-scaricamento da internet

Grazie mille per il test effettuato!

Ciao!

[deleted_29]

Originariamente inviato da Fayble
Non so se le URL o gli headers della richiesta HTTP possono essere sniffate da un "man-in-the-middle". Se la risposta è si, allora è possibile.

Non offenderti... ma la domanda è... come fai a fare il man-in-the-middle?
Se parliamo di attività reali, nel mondo reale, fare una cosa del genere prevede un ARP poisioning direttamente dal provider o (cosa mooolto più facile) direttamente il coinvolgimento di quest'ultimo (molto più raro del provider internet).
Ossia "se sono in grado di mettere le mie luride manine sul server... altro che man-in-the-middle"

Ho testato con successo encrypt e decrypt di file pdf, docx, jpg....

Te lo sconsiglio, codificando in base64 aumenti di un buon 30% la dimensione.
In pratica fai una sorta di "emailona".
Normalmente, nelle mie applicazioni, faccio esattamente il contrario.
Prima calcolo l'hash del file; lo comprimo, lo cripto, lo rinomino con l'hash, sicchè sulla macchina remota non c'è nulla di "identificativo", compreso soprattutto il nome del file (per ragioni di privacy).
Esempio "elenco_fatture_del_2010_del_cliente.xls" non è proprio l'ideale, anche ammesso che il file sia cifrato.

Lato-client l'operazione inversa porta ad un file cui puoi ricalcolare l'hash e verificarlo col nome del file; se è diverso la password è sbagliata.

------
Alternativa (dipende dai casi), per la conservazione "sicura".
Hash, zippatura file originale+hash; criptazione; hash criptato; rinominazione criptato.

In questo caso puoi verificare sia il download che la decriptazione e
(se puoi amministrare il server) ti basta lanciare ogni tanto un ricalcolo degli hash e confronto coi nomi dei file (è un banale script) per essere sicuro che non siano stati alterati (cosa utile soprattutto per i backup).

Questo richiede più "intelligenza" lato applicazione (qui parliamo di programmi ad hoc, non certo di paginette javascript o simil)
------


E, sempre in quest'ottica, se sei "veramente" paranoico puoi incapsulare il flusso dentro un contenitore simil-BMP (praticamente una steganografia dei poveri), bastano pochissimi header aggiunti.

Lo scopo è quello di non "far incazzare" certi provider che non hostano volentieri file "strani" per abbonamenti a basso costo (non so quale sia il tuo caso).

[Fayble]

Non offenderti... ma la domanda è... come fai a fare il man-in-the-middle? Se parliamo di attività reali, nel mondo reale, fare una cosa del genere prevede un ARP poisioning direttamente dal provider o (cosa mooolto più facile) direttamente il coinvolgimento di quest'ultimo (molto più raro del provider internet). Ossia "se sono in grado di mettere le mie luride manine sul server... altro che man-in-the-middle"

Ok, molto difficile ma non impossibile. Comunque il dettaglio tecnico di come si fa l'attacco non lo conosco e non lo approfondisco neppure. Nel senso che non la vedo dal punto di vista dell'attaccante (sarebbe quasi impossibile approfondire nel dettaglio tutte le tecniche di attacco), ma da quello applicativo. Il punto è: "cosa" e "quanto" posso fare lato applicazione per evitare "tipologie" di attacco, seppure molto remote?

Te lo sconsiglio, codificando in base64 aumenti di un buon 30% la dimensione.

Consiglio accettato, comprimo poi cripto. Riposto il codice:

$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$key = "This is a very secret key";
$file = gzcompress(file_get_contents('pdf.pdf'));
$cryptfile = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $file, MCRYPT_MODE_ECB, $iv);
$handle = fopen('pdfenc.pdf', 'w');
fwrite($handle, $cryptfile);
fclose($nhandle);
$file = file_get_contents('pdfenc.pdf');
$decryptfile = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $file, MCRYPT_MODE_ECB, $iv);
$handle = fopen('pdfdec.pdf', 'w');
fwrite($handle, gzuncompress($decryptfile));
fclose($handle); 

Grazie per le altre dritte, ma credo che il meccanismo compressione + crypt sia più che sufficiente.
Rinominerò utilizzando un numero che sarà l'identificativo della tipologia di file nella cartella della persona: /docs/243/12.pdf => 243 id della persona, 12 tipologia del file.

Molte grazie per l'ottimo contributo.

Ciao!

[deleted_29]

Originariamente inviato da Fayble
Ok, molto difficile ma non impossibile. Comunque il dettaglio tecnico di come si fa l'attacco non lo conosco e non lo approfondisco neppure. Nel senso che non la vedo dal punto di vista dell'attaccante (sarebbe quasi impossibile approfondire nel dettaglio tutte le tecniche di attacco), ma da quello applicativo. Il punto è: "cosa" e "quanto" posso fare lato applicazione per evitare "tipologie" di attacco, seppure molto remote?

mi occupo professionalmente proprio di fare queste cose da un paio di lustri.
bisogna essere realistici su cosa devi fare, perchè spesso si ricade nelle "leggende metropolitane" (sniffing delle URL ad esempio).
La risposta alla tua domanda te l'ho già data: criptazione simmetrica con password che non transita mai su internet (questa è una PSK a tutti gli effetti, con tutti i problemi del caso. Ma se la password è consegnata con un canale trustato la robustezza è pressochè assoluta)

Grazie per le altre dritte, ma credo che il meccanismo compressione + crypt sia più che sufficiente.
Rinominerò utilizzando un numero che sarà l'identificativo della tipologia di file nella cartella della persona: /docs/243/12.pdf => 243 id della persona, 12 tipologia del file.

Non ha un gran senso.
Anzi diciamo pure nessuno, visto che rende immediato scrivere uno spider che wgetti tutti i file.
Te lo scrivo con Excel (!), notepad (!) e wget in non più di 2 minuti.
---
Si chiama "difesa in profondità": adotta meccanismi multipli che rendano difficile per chiunque "sfondare".
Se ti affidi ad un unico meccanismo, e questo fallisce, che fai? (risposta: come i giapponesi a fukushima)

PS perchè ECB? A 'sto punto meglio CBC