Si tratta di un design danneggiato perché un GUID non dovrebbe essere segreto, ma da quello che ho capito fornisce accesso identico a inserire il nome utente e la password sul sito web.
In teoria il design è solido. Proteggi il GUID come se fosse la password dell'utente e il caso chiuso.
In pratica questo introduce molti problemi.
Esempio: inizio a lavorare in azienda oggi. Mi è stato detto di scrivere una funzione di ricerca in modo da poter trovare altri utenti tramite l'indirizzo email. Probabilmente codificherei i risultati della ricerca come una pagina che mostra un elenco di link ai profili, che contiene qualcosa come <a href="/user/${user.id}">${user.name}</a> . Dopo aver verificato quali colonne utilizzare, scopro che il campo id è chiamato guid e il campo nome è chiamato fullName . Lo metto alla prova. Funziona. Spingo il codice.
Senza rendermene conto, ho appena fatto trapelare il GUID dell'utente, che in pratica fornisce l'accesso completo all'account. Ora puoi dirottare qualsiasi account di cui conosco l'indirizzo email.
In questo momento il programmatore può avere costantemente in mente che sapere il GUID fornisce l'accesso completo all'account, ma in pochi mesi non sarà più qualcosa a cui pensi molto. Poiché è, presumo, l'unico modo unico per indicare un account, è necessario utilizzarlo in molti luoghi. Soprattutto per l'interazione con l'utente, questo potrebbe essere un problema (forse gli utenti possono creare società o gruppi, condividere cartelle, chiamarlo).
Un modo migliore sarebbe separare l'identificazione e l'autenticazione. Il GUID identifica un utente mentre un token di sicurezza autentica un utente. Questo completa le parti di Identificazione, Autenticazione e Autorizzazione (IAA) di un sistema di sicurezza: il sistema decide l'Autorizzazione basata sull'Identificazione dopo aver verificato l'Autenticazione. Ecco perché, oltre alle password, abbiamo anche bisogno di compilare un nome utente sui siti Web. Usare l'una o l'altra è generalmente una cattiva idea.
Tutte le posizioni in cui è attualmente utilizzato il GUID devono essere sostituite con i token di sicurezza appena generati. Ad esempio una richiesta potrebbe essere simile a questa: /API/2.0/doAction?GUID=${user.guid}&token=${some_security_token} . Tieni presente che questi token devono essere completamente randomizzati (probabilità di indovinare che deve essere circa 1 in 2 ^ 128 ).
Ci sono molti modi per generare questi token di sicurezza. Molti siti Web generano sessioni, ma è anche possibile utilizzare un campo di database aggiuntivo. Ogni volta che vengono effettuate chiamate API, l'utente viene autenticato da questo campo casuale. Il campo dovrebbe essere chiamato qualcosa che chiarisca che non dovrebbe essere conosciuto dagli altri.
Di nuovo, in teoria non fa davvero una grande differenza nella progettazione del sistema se si usa un GUID casuale o un altro campo generato a caso per l'autenticazione, ma in pratica penso che prevenga un sacco di grossi errori di sicurezza, specialmente quando il sito ha un qualche tipo di interazione con l'utente (ma anche in caso contrario, ad esempio una funzionalità di reimpostazione della password potrebbe esporre accidentalmente il GUID dopo aver inserito un nome utente o un indirizzo e-mail). Riduce semplicemente il numero di possibilità di attacco.