Posso nascondere quale account nel mio database è l'account di amministratore, quindi un utente malintenzionato non saprà quale hash si incrinerà per primo?

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

La sicurezza attraverso l'offuscamento ha un'efficacia limitata al massimo - per determinare se è adatto, è necessario capire quali minacce si vuole contrastare. Se un attore delle minacce può leggere direttamente il tuo database, quali sono i vantaggi nel nascondere un particolare dettaglio memorizzato?

Se c'è un è vantaggio nell'offuscamento (assicurati di poterlo provare davvero), allora utilizza il tipo di offuscamento che risolve quella minaccia (valori crittografati, origini dati off-line, hashing, ecc. ).

Sono d'accordo con Black Magic che probabilmente non vale la pena farlo, ma se volessi potresti usare 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 tenuto in memoria per eventuali sessioni utente aperte, quindi quelle potrebbero ancora essere vulnerabili all'attaccante.

Ciò significherebbe che avresti le stesse restrizioni del tuo aggressore, supponendo che tu non conosca le password degli utenti. Non si è in grado di leggere lo stato dal DB e, se si desidera modificare lo stato di un utente, è necessario modificarne la password contemporaneamente.

Molti sistemi moderni effettivamente separano il login dell'utente (come si autenticano) dai loro "profili" (permessi), implementati come due o più sistemi discreti. Il tuo server di login 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 server delle applicazioni non viene compromesso, il database di accesso è inutile anche se viene scaricato.

Come ulteriore passaggio, è anche possibile crittografare i dati dell'utente con una chiave dal server di login (memorizzati come parte della sessione), rendendo anche il server delle applicazioni più sicuro. In genere due sistemi sono più difficili da sconfiggere di uno. Tuttavia, se non sei disposto a configurare due server (o cluster), e sembra tutto troppo lavoro, allora probabilmente stai meglio con il tuo attuale design. Semplicemente sapere quali account target non rendono il lavoro più facile; se l'hacker può crearne uno, allora possono crearli tutti con il calcolo parallelo.

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

Anche se è un po 'di sicurezza per oscurità, e ha bisogno di per essere abbinato a buone pratiche come:

• un strong fattore di lavoro su bcrypt
• amministratori con una password complessa
• modi per impedire che l'autore dell'attacco abbia una copia del database in primo luogo

È un buon modo per rallentare un utente malintenzionato in modo tale da modificare la password prima che venga trovata.

Craccare una password non banale (supponendo che tu abbia usato un strong fattore di lavoro) può richiedere alcuni giorni o pochi mesi, quindi è fattibile, ma se non sanno quale account è un valore da hacking, ciò significa che devono hackerare ogni account.

Quindi, a meno che non siano fortunati, o hai nominato un account amministratore "admin", dovranno provare più account, che renderanno i loro costi di almeno un ordine di grandezza più grandi, rendendo l'attaccante o aspetta di più, acquista più potenza o rinunciare.

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

Nota che se hai suggerimenti di qualcuno che è 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à accennato, questo ha impedito all'utente di creare un amministratore utente senza cambiare o almeno chiedendo la sua password.

Se disponibile, la richiesta dell'autenticazione a 2 fattori per gli amministratori sarebbe probabilmente un modo migliore per proteggere gli account admin.

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

come: HereIsMe! 65371 = admin HereIsMe! 65370 = regular

Quindi al login, prova regolarmente prima quindi admin, in questo modo:

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

IMPORTANTE: assicurati che qualcuno non possa modificare l'ultimo carattere della propria password. Ad esempio, assicurati di avere il modulo di registrazione, il modulo per la password dimenticata e il modulo per la modifica della password, aggiungi sempre uno 0 o 1 alla fine della password in base al loro stato reale. Memorizza lo stato in una sessione lato server, preferibile crittografato utilizzando un cookie di sessione lato client.

Ciò rende praticamente impossibile dedurre lo stato dell'amministratore senza infrangere la password con successo.

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

Ci sono molti suggerimenti tecnici interessanti qui, ma bisogna menzionare che anche se li implementate perfettamente questo approccio non ti farà letteralmente guadagnare nulla in caso di intrusione per i seguenti motivi:

• Se qualcuno ha accesso al database (anche se sql injection o qualcosa del genere), è un dato di fatto che possono praticamente fare tutto ciò che vogliono sul tuo server con le autorizzazioni di qualsiasi utente il tuo servizio di database è in esecuzione da molti sistemi di gestione dei database fornire funzionalità per manipolare file e processi in esecuzione 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. Suppongo che il tuo account amministratore sia un utente attivo.
• Se qualcuno ottiene l'accesso agli hash delle password, probabilmente non chiameranno su quali dovrebbero tentare prima. Eseguiranno un bulk cracker per elaborarli tutti in una volta e in ogni passaggio controllerà tutti gli hash nella tabella che stanno elaborando.
• Anche se hai tenuto l'hash della password dell'amministratore in una tabella separata o al di fuori del database completamente, il compromesso degli account con privilegi meno probabili porterà probabilmente a un'escalation dei privilegi, a condizione che l'intrusione non sia stata rilevata da quando l'intruso sarà in grado di impersonare utenti fidati per accedere ad ulteriori 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 delle funzionalità social è molto probabile che esponga già altri modi per identificare gli utenti amministrativi.

Se l'attaccante ha ottenuto l'accesso al database, allora può semplicemente creare il proprio hash bcrypt e sostituire quello nel database. Non c'è bisogno di rompere l'hash.