L'approccio standard a questo tipo di problema consiste nel creare un UUID (Universally Unique Identifier) ​​ per ogni immagine. Questo è generalmente un identificatore casuale a 128 bit che puoi assegnare a ciascuna immagine senza alcuna preoccupazione particolare che sarebbe possibile enumerare le immagini tramite un attacco di forza bruta allo spazio dei nomi.

Ad esempio in. NET puoi usare la struttura GUID per questo tipo di scopo. A partire da Windows 2000 ( origine), Guid.NewGuid genera un UUID casuale (versione 4). (Le versioni antiche generavano un versione 1 UUID che rivela la data in cui è stato generato, senza fare nulla per proteggerti dal problema del "numero di fattura".)

Userei semplicemente l'hash delle immagini. Qual è il problema con qualcuno che scopre l'hash che hai usato? Se penso che "questa parte dell'url sembra sha1", scarica il file e ha quello sha1, avevo ragione. Ma questo non mi rende in grado di violare la tua «sicurezza del gatto». Anche se fosse curabile tentare di rompere l'hash per capire l'immagine, non ha senso provarlo invece di scaricarlo semplicemente.

Genera semplicemente un hash crittograficamente sicuro dei dati dell'immagine e usalo come identificatore.

Questo ha due effetti collaterali:

• Le persone possono capire se un'immagine esiste già sul tuo servizio chiedendo un'immagine con quell'hash.
• Le persone non possono caricare immagini duplicate.

Entrambi questi effetti non sono intrinsecamente dannosi. Potrebbero persino tornare utili. Ma se vuoi evitarli, puoi aggiungere a ogni hash immagine un numero pseudocasuale da un generatore di numeri casuali sicuro.

Le collisioni non sono nulla di cui preoccuparsi, comunque. Con una funzione hash come SHA256, le possibilità di una collisione casuale sono così astronomicamente ridotte, sarebbe una sensazione trovarne una.

Il modo standard è semplicemente quello di generare in modo casuale i tuoi URL, utilizzando un generatore di numeri pseudo-casuali crittograficamente sicuro (CSPRNG).

Non c'è bisogno di hashing o simili - usa semplicemente vecchi numeri casuali. Non è necessario che siano GUID (a meno che il database non gestisca i GUID meglio dei semplici numeri per qualche motivo). Presumibilmente il tuo sito ricorda già quale immagine è accessibile a ciascun URL, quindi modificala per gestire URL casuali anziché sequenziali.

Un numero casuale a 128 bit dovrebbe essere abbastanza lungo.

Ricorda di verificare la presenza di URL duplicati durante l'elaborazione di nuove immagini.

Da quello che ho letto nella domanda, nei commenti e in altre risposte, tutto gira intorno alla ricerca di un identificatore univoco per ogni immagine, che non è indovinabile, né fornirebbe informazioni sul numero di immagini e facile da gestire in un database.

Allora, perché non usi solo il timestamp di inserimento (numero di millisecondi dal 1970)? Se c'è una probabilità che due persone inseriscano un'immagine di gatto nello stesso millisecondo, puoi concatenarla con un numero sequenziale corrispondente al numero di inserimenti in quel millisecondo.

In questo modo l'unica cosa che qualcuno in modo aggressivo cercando la tua ultima foto scoprirai che è l'ultima volta che qualcuno ha aggiunto una foto a condizione che tu lasci che un tale idiota faccia quello che sembrerebbe un attacco quotidiano.

Nel frattempo non avresti problemi con le collisioni o il supporto del database.

Soluzione alternativa:

aggiungi metadati agli identificatori di immagine. Esempio:

philipp_20151213_00002.jpg - Seconda immagine pubblicata dall'utente Philipp il 13 dicembre 2015.

Faccio trapelare quei metadati, ma sono solo i dati che un utente può vedere comunque quando si fa clic su quel collegamento (presumo).

Questo non dice a un osservatore quante immagini sono state postate in totale sul tuo servizio, solo sull'attività di quel particolare utente in quel particolare giorno. Se vuoi nascondere anche questo, puoi usare numeri pseudocasuali invece di numeri sequenziali. Le collisioni potrebbero ancora essere possibili quando un singolo utente carica una grande quantità di immagini in un giorno, ma saranno abbastanza rare da poterle gestire semplicemente generando nuovi numeri casuali finché non ne avrai una che non è stata scattata.

Ecco un metodo. Mantieni un CSPRNG a livello di server da 8 byte. Quindi per ogni nuova immagine, genera un altro CSPRNG da 8 byte. Hash questo CSPRNG con il tuo CSPRNG a livello di server (md5 va bene). Quindi XOR gli ultimi 8 byte dell'hash con l'ID immagine (che aumenterà automaticamente da 0 in un database). Il client riceverà una codifica Base64 dell'esclusivo CSPRNG a 8 byte dell'immagine insieme al risultato XOR a 8 byte. Questo sarà l'ID dell'immagine pubblica.

Quando il server riceve l'ID dell'immagine pubblica, eseguirà l'hash dei primi 8 byte dell'ID pubblico insieme agli 8 byte CSPRNG a livello di server. Quindi prenderà gli ultimi 8 byte dell'hash e lo XOR con gli ultimi 8 byte dell'ID pubblico. Il risultato sarebbe l'ID interno privato che può essere indicizzato dal database.

Aggiorna (spiegazione):

Innanzitutto, pre-definire un globale casuale CSPRNG che verrà utilizzato per tutti i calcoli ID (8 byte o 64 bit con 18.446.744.073.709.551.616 combinazioni possibili).

  serverCSPRNG = CSPRNG (8)  

Per creando un nuovo ID pubblico (16 byte) da un ID privato (8 byte), procedi come segue:

  newCSPRNG = CSPRNG (8) hashEnding = last8Bytes (md5 (newCSPRNG + serverCSPRNG)) publicID = newCSPRNG + XOR (hashEnding, privateID)  

Per derivare il privateID da publicID:

  hashEnding = last8Bytes (md5 (first8Bytes (publicID) + serverCSPRNG) ) privateID = XOR (hashEnding, last8Bytes (publicID))  

Per una maggiore sicurezza, un CSPRNG secondario globale (solo server statico) può essere XOR sugli ultimi 8 byte del publicID al fine di proteggerlo completamente dagli attacchi di forza bruta (poiché implementa il modello di sicurezza inhe affitto di un one-time-pad).

Come notato qui: hash, UUID ecc. hanno lo `` svantaggio '' che gli inserimenti di record nel DB in cui questi hash / uuid sono il PK e il PK è raggruppato sono probabilmente molto costosi (definire costoso ...) poiché di solito non sono sequenziali (a meno che non venga utilizzata una funzione specifica come NEWSEQUENTIALID , tuttavia: nota il blocco "importante" su quella pagina: " Se la privacy è un problema, non utilizzare questa funzione. È possibile indovinare il valore del successivo GUID generato ... ").

A parte i suggerimenti qui lo farei considera qualcosa come il fiocco di neve di Twitter ( fuori produzione). Ho scritto una libreria .Net simile ( IdGen); il file readme contiene alcune informazioni su come funziona esattamente. Il vantaggio è che gli ID generati sono ancora (per lo più) sequenziali, non troppo dispendiosi in termini di spazio (64 bit contro UUID a 128 bit / hash) e possono essere utilizzati in un ambiente distribuito (non coordinato) in cui sono presenti diversi host / processi che generano ID senza causare collisioni. E sebbene siano sequenziali, non forniscono molte informazioni sul numero di foto di gatti (o, più in generale, sul numero di "ID utilizzati") in un certo periodo di tempo.

Questo suona come un lavoro per un algoritmo di hashing, giusto?

No, perché come osservi devi preoccuparti delle collisioni. A me sembra un lavoro per una permutazione, cioè un codice a blocchi. Ciò richiede la gestione di una chiave, che è lo svantaggio, ma ti consente di utilizzare la funzione di incremento automatico del database e di non preoccuparti delle collisioni.

La parte difficile è decidere cosa fare con l'IV , e qui hai opzioni. Potresti generarne uno nuovo ogni volta che crei un URL, quindi ci sarà potenzialmente ad es. 2 ^ 128 URL diversi per immagine di gatto. È possibile impostare l'IV per utente o per sessione e memorizzarlo sul lato server come parte del profilo utente / stato della sessione. Potresti persino renderlo per utente ma incluso nell'URL, in modo da poter monitorare chi riesce a rendere virali le immagini.

Un approccio consiste nell'utilizzare hashid.

Hashids è una piccola libreria open source che genera ID brevi, univoci e non sequenziali dai numeri.

Converte numeri come 347 in stringhe come "yr8", o un array di numeri come [27, 986] in "3kTMd".

Puoi anche decodificare quegli ID indietro. Ciò è utile per raggruppare diversi parametri in uno o semplicemente utilizzarli come UID brevi.

Le prestazioni del database non vengono compromesse poiché è possibile continuare a utilizzare internamente ID sequenziali numerici. Nel frattempo i tasti esterni sono opachi.

Ho una soluzione a bassa tecnologia a questo problema. Utilizza semplicemente un servizio di abbreviazione dell'URL o scrivi il tuo.

Fornisce quanto segue:

1. Il tuo URL pubblico non è esposto sui siti di social media.
2. È garantito che i tuoi URL siano casuali e arbitrari.
3. Sei libero di modificare l'implementazione sottostante della denominazione delle risorse e i link esterni continueranno a funzionare.
4. Condivisione più semplice http://catpic.to/i34dhY vs. http://catpictures.com/some-guid-string.
5. L'ID univoco è facilmente indicizzato / cercato.

Se non vuoi fare affidamento su un servizio di terze parti, puoi facilmente eseguire il rollio implementando una funzione biiettiva nella lingua a tua scelta.

• Vorremmo avere un numero sequenziale; altrimenti diventa costoso aggiungere record al database poiché la parte centrale degli indici deve essere aggiornata in un ordine quasi casuale.
• Non vogliamo che il numero si riferisca al numero di gatti caricati.
• Abbiamo bisogno che il numero sia univoco ma solo all'interno del tuo sito web.

Pertanto:

• nextCat è impostato su 0 quando il sito web viene per la prima volta avviato, probabilmente dovrà essere a 64 bit.
• nextCat è incrementato ogni volta che viene aggiunto un gatto e newCat è impostato su true.
• nextCat viene incrementato da un timer casuale che si attiva a una velocità maggiore di quella che ti aspetti che vengano aggiunti gatti. Tuttavia, se newCat è true , l'incremento non viene eseguito per questo timer e newCat è impostato su false .
• A ogni gatto viene anche assegnato un GUID, ma non è mai necessario trovarlo in base al suo GUID
• l'indirizzo web di un gatto è qualcosa.com/cats/catNumber-catGuid
• se quando viene richiesto un gatto il catGuid è sbagliato, viene data la stessa risposta per un catNumber che non si riferisce a un gatto.

(Il timer è fatto per un tempo casuale, in modo che sia difficile dire se due gatti vengono aggiunti tra uno scatto del timer.)

Best practice generale: non esporre mai il PKEY in nessun collegamento web.

Nel tuo database - il tuo PKEY deve essere un BIGINT per la velocità. Anche nel tuo database, considera l'aggiunta di questo campo ... ( public_filename ..se non esiste) alla tua tabella. Il campo public_filename deve essere una stringa guid. Usa una funzione guid per rinominare il file con un nome file univoco al momento del caricamento sul tuo server e popola public_filename con quello.

Il public_filename dovrebbe essere utilizzato per i collegamenti web, non per il PKEY.

Inoltre, consiglio di mantenere un campo nome_file_utente per supportare qualsiasi ricerca forense dall'uploader, se lo consenti. nome_file_utente sarebbe il nome del file originale caricato dall'utente.

Non esporre mai il PKEY in nessun collegamento web - usa sempre una qualche forma di nome_file_pubblica . Utilizza le query del tuo database per de-referenziare public_filename a un PKEY e da lì puoi capire quale file servire dal server.

Un'altra best practice: non sovrascrivere mai un gli utenti vengono caricati automaticamente. Rinomina il campo nome_file_utente con una serializzazione (-001, -002).

È probabile che tu riceva molti file denominati "micio" dallo stesso utente.