C'è questa web app che ha un database SQLServer e la stringa di connessione che usa per accedere al database non è memorizzata in nessun file di configurazione. Piuttosto, i progettisti hanno deciso che sarebbe stata una buona idea scrivere un algoritmo per generare la password dal codice di licenza del cliente.
Questa è una tecnica comune? È sicuro?
L'impossibilità di cambiare la chiave è il problema principale qui. Se dovesse mai essere compromesso, sarebbe impossibile per il cliente cambiare la password dell'amministratore del database. Direi che è un grosso problema di sicurezza negativo.
Se la stringa di connessione può essere generata dalla chiave di licenza, suppongo che ogni cliente avrà la sua chiave di licenza, risultante in una distinta stringa di connessione per cliente ... quindi in pratica stai dando a ogni cliente un < em> account sul database SQLServer e la sua chiave di licenza è la "password" per questo account. Potrebbe non essere una buona idea, a seconda dei dettagli della tua app Web.
Come commento generico, ciò significa che stai mescolando autenticazione con autorizzazione , che non è una buona idea. La chiave di licenza è authentication : viene utilizzata dal client per dimostrare la propria identità al server. Autorizzazione riguarda la decisione su cosa consentire a un determinato cliente debitamente autenticato. Nella terminologia di Active Directory, la differenza tra autenticazione e autorizzazione è la differenza tra la verifica della password di un utente e la creazione del membro dell'account utente del gruppo "Domain Admins". Autenticazione e autorizzazione sono cose distinte che sono meglio tenere da parte. Nella proposta di licenza-chiave-per-connessione-stringa, si sta utilizzando il codice di licenza per entrambi, che può essere restrittivo.
(Questa distinzione è spesso resa dolorosamente acuta quando si tratta di PKI : tutte le persone che iniziano con PKI provano a qualche punto per gestire diritti di accesso con certificati , e poi inizia la sofferenza.)
Questa è un'idea orribile per almeno due ragioni.
Poiché già menzionato da AJ Henderson , la chiave di licenza non può essere modificata, almeno non senza uno scambio che richiede tempo con l'autore dell'applicazione. Pertanto, se la password del database viene mai compromessa, l'utente malintenzionato può disporre di una giornata campale. Un ex-amministratore insoddisfatto conserverà l'accesso al database.
Non è probabile che una chiave di licenza sia trattata come riservata all'interno di un'organizzazione. È il genere di cose che è normalmente scritto in guide di installazione interne. È anche probabile che venga inserito negli elenchi di asset dal reparto contabilità.
Proteggi finché uno non pubblica pubblicamente che lo sta facendo.
Leggi altre domande sui tag password-policy databases