Direi che questo è un po 'troppo problematico considerando quello che ne ottieni. Penso che quando l'attaccante ha accesso al database hai problemi molto più grandi. Offuscare lo stato di amministratore di un utente costerà all'aggressore solo un po 'di tempo in più, ma un APT (Advanced Persistent Threat) probabilmente non sarebbe scoraggiato da questo fatto.

La sicurezza attraverso l'offuscamento ha un'efficacia limitata nella migliore delle ipotesi: per determinare se è adatta, è necessario capire quali minacce si desidera contrastare. Se un attore di minacce può leggere direttamente il tuo database, che vantaggio c'è nel nascondere un particolare dettaglio memorizzato?

Se è un vantaggio nell'offuscamento (assicurati di poterlo davvero provare), utilizza il tipo di offuscamento che affronta tale minaccia (valori crittografati, fonti di dati offline, hashing, ecc.).

Concordo con Black Magic sul fatto che probabilmente non vale la pena farlo, ma se lo desideri potresti utilizzare una funzione di derivazione della chiave per creare una chiave di crittografia basata sulla password e utilizzarla per crittografare il contenuto della colonna Stato.

Potenzialmente lo stato dovrebbe essere mantenuto in memoria per tutte le sessioni utente aperte, in modo che queste potrebbero essere ancora vulnerabili all'attaccante.

Ciò significherebbe hanno le stesse restrizioni del tuo aggressore, supponendo che tu non conosca le password degli utenti. Non saresti in grado di leggere lo stato dal DB e se volessi cambiare lo stato di un utente dovresti cambiare la sua password allo stesso tempo.

Molti sistemi moderni in realtà separano il login dell'utente (come si autenticano) dai loro "profili" (i permessi che hanno), implementati come due o più sistemi discreti. Il tuo server di accesso potrebbe avere solo un GUID, un nome utente con hash e una password con hash; in caso di accesso riuscito, trasferire la sessione al server delle applicazioni. Finché il tuo server delle applicazioni non è compromesso, il database di accesso è inutile anche se viene scaricato.

Come passaggio aggiuntivo, potresti anche crittografare i dati dell'utente con una chiave dal server di accesso (archiviato come parte della sessione), rendendo anche più sicuro il server delle applicazioni. Due sistemi sono in genere più difficili da sconfiggere di uno. Tuttavia, se non sei disposto a configurare due server (o cluster) e tutto sembra troppo lavoro, probabilmente stai comunque meglio con il tuo progetto attuale. Sapere semplicemente quali account scegliere come target non semplifica il lavoro; se l'aggressore riesce a decifrarne uno, può decifrarli tutti con il calcolo parallelo.

Il suggerimento di PlasmaHH era di: "anteporre una lettera alla password quando viene hash (in realtà più lettere, era un" id gruppo ") e fare in modo che il meccanismo di autenticazione provi tutte le combinazioni."

Sebbene sia in qualche modo la sicurezza per oscurità e deve essere associato a buone pratiche come:

• un forte fattore di lavoro su bcrypt
• amministratori che hanno una password complessa
• modi per impedire che l'attaccante abbia una copia del database in primo luogo

È un buon modo per rallentare un attaccante abbastanza in modo che la password viene cambiata prima che venga trovata.

Il crack di una password non banale (supponendo che tu abbia utilizzato un fattore di lavoro forte) può richiedere da alcuni giorni ad alcuni mesi, quindi è fattibile, ma se non lo fanno Non so quale account vale la pena hackerare, gli impone di hackerare ogni account.

Quindi, a meno che non siano fortunati o tu abbia chiamato un account amministratore "admin", dovranno provare più account, che fanno i loro costi almeno un ordine di mag nitude più grande, facendo in modo che l'attaccante attenda di più, acquisti più potere o si arrenda.

In conclusione, non è inutile, in quanto è un deterrente economico che non disturba l'utente.

Nota che se hai suggerimenti che qualcuno sia un amministratore, come un post di qualcun altro modificato da loro (se solo gli amministratori possono farlo), mascherare il loro stato nel db è inutile.

Come altri hanno già detto, questo ha dei trucchi come impedirti di rendere un utente amministratore senza cambiare o almeno chiedere la sua password.

Se disponibile, richiedere l'autenticazione a 2 fattori per gli amministratori sarebbe probabilmente una soluzione migliore modo per proteggere gli account amministratore.

Sì, è possibile. Basta aggiungere lo stato di amministratore come parte della password.

come: HereIsMe! 65371 = adminHereIsMe! 65370 = regular

Quindi all'accesso, prova prima con regolare quindi admin, in questo modo:

  if (sha512 ($ password. "0") eq $ hash) {funzioni utente blabla} else {if (sha512 ($ password. "1") eq $ hash) {blabla admin functions} else {show password errata message}}  

IMPORTANTE: assicurati che qualcuno non possa modificare il proprio ultimo carattere della propria password. Ad esempio, assicurati che il modulo di registrazione, il modulo della password dimenticata e il modulo di modifica della password, aggiungano sempre uno 0 o 1 alla fine della password a seconda del loro stato reale. cookie di sessione laterale.

Ciò rende praticamente impossibile dedurre lo stato di amministratore senza decifrare con successo la password.

Se il database lo supporta, configura un server di autenticazione LDAP o simile, quindi le credenziali non verranno archiviate localmente.

Ci sono diversi suggerimenti tecnici interessanti qui, ma va detto che anche se li implementate perfettamente questo approccio non vi farà letteralmente guadagnare nulla in caso di intrusione per i seguenti motivi:

• Se qualcuno ha accesso al database (tramite sql injection o qualcosa del genere), è un dato di fatto che può fare praticamente tutto ciò che vuole sul tuo server con le autorizzazioni di qualsiasi utente con cui è in esecuzione il tuo servizio di database poiché la maggior parte dei sistemi di gestione del database forniscono funzionalità per manipolare file ed eseguire processi sul proprio host. Ciò significa che l'intruso può modificare le tue pagine web o l'elaborazione lato server per acquisire password in chiaro durante l'accesso e ottenere rapidamente password non crittografate per i tuoi utenti attivi. Presumo che il tuo account amministratore sia un utente attivo.
• Se qualcuno ottiene l'accesso agli hash delle tue password, probabilmente non accederà a quelli che dovrebbero tentare di crackare per primi. Eseguiranno semplicemente un cracker di massa per elaborarli tutti in una volta e in ogni passaggio controllerà tutti gli hash nella tabella che stanno elaborando.
• Anche se hai mantenuto l'hash della tua password amministratore in una tabella separata o completamente al di fuori del database, la compromissione di account meno privilegiati porterà probabilmente a un'escalation dei privilegi fintanto che l'intrusione non viene rilevata poiché l'intruso sarà in grado di impersonare utenti fidati per ottenere accesso a più informazioni (utilizzando un account moderatore per parlare con l'amministratore e avviare il furto di cookie o altre attività dannose, ad esempio).
• Se il tuo sito ha funzionalità social, è molto probabile che esponga già altri modi per identificare gli utenti amministrativi.

Se l'attaccante ha ottenuto l'accesso al database, può semplicemente creare il proprio hash bcrypt e sostituire quello nel database. Non è necessario decifrare l'hash.