Devo oscurare le chiavi primarie del database (ID) nel front-end dell'applicazione?

L'unica informazione che potresti sperare di "nascondere" è la sequenza : poiché un database assegnerà i valori delle chiavi primarie a un contatore, le persone che vedono la chiave possono fare un'ipotesi su quando è stato creato l'account utente corrispondente. A parte questo, non ci sono altre informazioni che qualsiasi schema oscuro possa effettivamente nascondere. L'autore dell'attacco sa già che gli utenti distinti sono referenziati tramite chiavi distinte, e questa è l'estensione della semantica della "chiave primaria" del database.

Pertanto, a meno che non si consideri che l'ordine di creazione dell'account è informazioni private che devono essere nascoste, direi che il tuo schema oscuro è inutile.

Un modo semplice sarebbe utilizzare il metodo usato da youtube e da altri siti web. Questo è hashid ( link ).

Con questo metodo puoi dare link come: link mentre fce7db equivale a un numero es: 12

Questo ha il vantaggio delle prestazioni in contrasto con la generazione di un altro hash casuale nel database, perché devi solo tradurlo una volta e poi puoi cercare nel database con la chiave primaria originale come fatto prima.

Per rendere più difficile per gli utenti trovare in modo casuale altri ID, puoi utilizzare un salt segreto per uno e una lunghezza minima per impedire che vengano "forzati brute".

Avendo un dipendente segreto sale possono ancora scambiare gli URL in casi come link .

No. In un modo o nell'altro, è necessario identificare il record specifico con un identificativo univoco nell'URL. Questa può essere la chiave primaria o qualcos'altro. Se è necessario nascondere l'ordine o la sequenza, è possibile utilizzare una seconda colonna con una stringa casuale e univoca come Z2wDKo0ubb1D2VngFh4N.

Se vuoi maggiore sicurezza, usa SSL. Ciò non impedisce tuttavia all'utente di visualizzare l'URL e i parametri, come notato da @eggyal.

Utilizzando SSL, i parametri URL sono crittografati e impediscono l'intercettazione. E sì, sappiamo ormai che SSL è difettoso, non proprio sicuro, ma offre più sicurezza di non usarlo. Ma non usare l'URL per le password! Usa POST per accedere e inviare dati, GET per recuperare informazioni, come sempre.

Vedi link

Motivi per non utilizzare le informazioni segrete in un URL: le richieste DNS probabilmente non sono crittografate (ma come note @tgies nei commenti, la parte richiesta non è inclusa quindi nessun ID qui), cronologia del browser e log del server.

Ho creato alcuni sistemi che fanno o non usano la chiave primaria (o altro identificatore) nell'URL. Il nostro utilizzo è totalmente dipendente dal fattore di danno: ad esempio, per un sito guidato solo dai dati, utilizziamo la chiave primaria nell'URL; non ci interessa se qualcuno passa attraverso i prodotti in sequenza.

Per i sistemi che hanno requisiti di sicurezza, invece di utilizzare un ID prevedibile sequenziale, abbiamo utilizzato uno dei due schemi:

1. Manteniamo le informazioni sulla chiave la sessione del browser. Semplice, diretto e se il nostro server non è sicuro, abbiamo problemi più grandi.
2. Abbiamo generato un numero casuale (e verificato l'univocità) sia quando il record viene creato OPPURE per la sola sessione; e ha usato quel numero casuale all'interno dell'URL.

Buona fortuna,

Larry

Sì, dovresti offuscare quegli ID, dal momento che stai perdendo informazioni.

Se la tua applicazione è perfettamente sicura, l'unica informazione (ab) che gli utenti possono apprendere è un'ipotesi del numero di utenti attraverso l'uso di qualcosa chiamato argomento Doomsday ^‡ . Inoltre, se apprendono gli ID di diversi utenti, sapranno chi si è iscritto per primo e possono indovinare quanto è accaduto. E possono anche fare ipotesi plausibili sugli ID di altri utenti.

Se la tua applicazione è perfettamente sicura.

Se non lo è, e dovresti sempre presumere che potrebbe non esserlo, hai fornito informazioni utili. Se un ID utente era solo un numero casuale, un utente malintenzionato non era in grado di calcolare facilmente un altro ID valido. Con i numeri (per lo più consecutivi) solitamente forniti da una chiave primaria automatica, è banale.

È possibile modificare la chiave primaria o aggiungere una chiave secondaria, se si desidera mantenere la facilità d'uso di piccoli numeri per uso interno. Questa nuova chiave dovrebbe in genere essere un GUID .

^{‡: Ovviamente è un collegamento xkcd.}

Non fornisci informazioni sufficienti sull'applicazione per sapere se dovresti oscurarlo o meno. In quanto tale, questa parte della tua domanda non è responsabile. Tuttavia, se devi chiedere, allora la risposta è probabilmente sì, e anche se non lo è, andare oltre la call of duty offre più protezione dell'alternativa.

Invece di nascondere o oscurare la chiave primaria, considera di cambiarla. Non c'è bisogno che sia sequenziale. Quando crei un nuovo utente, crea un numero casuale a 32 bit, fai una rapida selezione per assicurarti che non sia in uso e usalo come chiave primaria.

Se qualcuno sta modificando un utente, non sarà in grado di ottenere alcuna informazione dal numero dell'utente, e provare i numeri immediatamente adiacenti al numero a cui ha attualmente accesso potrebbe produrre un record inesistente.

Il sovraccarico / l'onere di questo sistema è minimo. Richiede una selezione aggiuntiva durante la creazione dell'account, che è probabilmente rara e non impone alcun overhead overhead aggiuntivo: stai ancora fornendo la chiave primaria nell'URL, quindi le ricerche DB sono ancora veloci, ma la chiave non ha informazioni.