Assegnazione di un ID locale a un utente

Question

Assegnazione di un ID locale a un utente

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

0

Sto creando un servizio di sapone in cui gli utenti saranno in grado di interagire tra loro. Avranno una lista di contatti dove le persone possono essere aggiunte. Una delle misure di sicurezza (anche altre sono a posto) prevede l'assegnazione di un ID locale a un contatto.

Per rendere chiaro il processo, immagina il seguente scenario:

$ UserA richiede $ UserB per essere aggiunto all'elenco dei contatti di $ UserA. $ UtenteB accetta e $ UtenteA riceve un ID locale da utilizzare come ID utente riferito al contatto. Il database contiene una tabella denominata USER_MAP (LocalID, UserID).

Due domande:

1) Pensi che questo sia un approccio valido quando si ha a che fare con la sicurezza degli ID utente? Se no, perché? 2) Se lo ritieni valido, puoi suggerire una formula per generare detti ID?

Al momento, l'idea per la formula è: ($ UserA_ID + $ UserB_ID) * ($ UserA_RegDate + $ UserB_RegDate)

Considera RegDates come "numero di giorni dal valore di data 0".

Ogni utente potrebbe avere 1..N id locali a seconda di quanti utenti sono disposti ad aggiungere. Un ID locale è locale per l'utente ma globale nello spazio utente, ad esempio per ogni interazione tra utenti viene utilizzato lo stesso ID locale. Per renderlo più chiaro: se $ UserA richiede di vedere il profilo $ UserB, passerà l'id utente locale che verrà mappato a livello del server all'ID corretto.

Giusto per chiarire: il futuro non significa "da molto tempo, forse, chi lo sa", significa piuttosto: "è programmato, voglio farlo, voglio assicurarmi di avere i miei pezzi pronto e ALLORA lo farò ":) Quindi, non è un" forse "piuttosto solo una questione di QUANDO.

Apparentemente qualcuno ha problemi a comprendere la logica dietro l'approccio di un id locale. Un paio di idee che possono aiutarti a capire perché è una buona idea (secondo me):

Se il tuo ID è locale anziché globale, hai solo l'accesso alle tue risorse / contatti. Utile, ad esempio, per evitare di accedere in modo programmatico a un profilo che non ti è permesso vedere. Ciò con terze parti può essere un problema, specialmente in caso di usi scorretti
Se il tuo ID è locale, puoi usarlo come scorciatoia per i dati locali invece di dover accedere all'account originale. L'elenco dei contatti potrebbe, ad esempio, contenere alcuni dei dati originali che non cambieranno.
Se hai un ID locale è molto più facile "tagliare il filo", perché tutto ciò che devi fare è eliminare uno o due record. Supponi che un utente desideri eliminare un contatto. Tutto quello che dovrò fare è rimuovere al meglio due record, tutti gli altri dati rimarranno intatti e semplicemente filtrato dalle query.

Meglio ora?

Grazie per il tuo tempo!

database security users

posta Andrea Raimondi 13.06.2011 - 10:01

fonte

2 risposte

Leggi altre domande sui tag database security users

ODBC Lic Restrizioni / Bisogno di limiti di limitazione qui sono io pensieri? Cosa suggerisci? Crea il file di intestazione a livello di programmazione

score 1 · Answer 1

A meno che tu non abbia una funzione che richiede questo al momento, la stai sovrascrivendo. Non rendere la tua soluzione più complicata di quanto debba essere. Se arrivi al punto in cui è richiesto, rifatta la tua applicazione per farlo funzionare, ma non cercare di anticipare ciò di cui potresti aver bisogno o non aver bisogno in futuro.

BTW, se hai la capacità di anticipare con successo ciò di cui hai bisogno in futuro, per favore contattami fuori lista. : -)

score 0 · Answer 2

Un approccio migliore alla sicurezza sarebbe semplicemente non consentire a qualcosa come un ID utente di essere un'informazione critica. Come attaccante, i nomi delle tabelle e le query sono più interessanti dei valori chiave.

I dati nella tabella possono essere l'obiettivo finale (forse hai Social Secuirty # nella tabella personale dell'utente o nella cartella clinica del paziente) ma avere l'id utente non dovrebbe farmi avvicinare di più a questo. Tutte le informazioni sensibili devono essere crittografate e la chiave privata non è memorizzata in nessun punto del sistema.

Ciò che è utile per me, l'utente malintenzionato, è scoprire quali delle tue API portano a query che non dispongono di wrapper di sicurezza adeguati. Forse allora potrò promuovere me stesso a un superutente e iniziare a fare chiamate dirette nel DB e sperare di trovare qualcosa di non protetto. Più conosco la tua struttura, più velocemente riesco a farcela. Poi spero solo che tu sia troppo sicuro di me per preoccuparti di proteggere i dati all'interno (ad esempio Sony).