Le parole chiave aggiungono sicurezza?

Stai leggendo la proposta leggermente errata. Questo non è inteso come una salvaguardia per rilevare un'intrusione a un sistema già compromesso, ma come mezzo per rilevare il database di un sistema compromesso. Questo è uno scenario completamente diverso, in cui l'utente malintenzionato non avrebbe già avuto accesso al sistema conoscendo la password di qualsiasi utente finale, ma in qualche modo (backup scartato in modo improprio, intrusione fisica, ...) ha messo le mani su un database utente trapelato che memorizza le password con hash.

L'assunto è che l'utente malintenzionato non sappia quale hash forzato da brute corrisponde alla vera password di un singolo utente e potrebbe attivare l'allarme utilizzando invece la password di honeyword. È un metodo abbastanza sano tanto quanto ne ho letto fino ad ora, ma non ho ancora visto alcuna implementazione della vita reale (l'overhead computazionale è sostanziale su un hashing corretto usando algoritmi lenti). È anche leggermente discutibile a causa delle limitate capacità dell'honeypot stesso per prevenire ulteriori tentativi di accesso da parte di altri IP che l'hacker potrebbe utilizzare una volta che l'IP precedente era già nella lista nera (questo è banale da fare a un potenziale aggressore), ma il rilevamento il meccanismo è comunque il suono.

La domanda è, cosa dovrebbe accadere dopo, dopo che tale tentativo è stato rilevato. La soluzione più ovvia è disabilitare l'account utente in questione (quello che l'hacker ha tentato di hackerare), ma cosa succede quando un vero utente inserisce uno di questi honeywords per errore? Queste parole dovrebbero essere sostanzialmente diverse da quello che l'utente stesso ha scelto come password, e ci sono altri vincoli come la posizione in cui il database posiziona la password reale in relazione a quelli di honeyword?

Tuttavia, queste domande potrebbero essere banali per affrontare correttamente, e a buon mercato rispetto a ciò che accadrebbe senza tali salvaguardie. Detto questo, la risposta alla tua domanda è - sì, sicuramente.

La cosa principale che vedo che questo non funziona è che un attaccante intelligente sta rapidamente scoprendo di cosa si tratta se ottengono il DB dump e quindi sanno che devono ottenere la selezione dell'hash valida da un altro server. Aggiunge un altro livello di difficoltà, ma non mi aspetto che un hacker inneschi questo dato che è abbastanza ovvio cosa sta succedendo se hai 50 hash per 1 utente.

È in effetti lo stesso che avere tutte le password memorizzate senza un collegamento all'utente nel DB principale e avere un secondo server che dice al server quale hash della password dovrebbe essere usato ogni volta, anche se c'è probabilmente una maggiore probabilità di falsi in questo caso positivi in quanto le persone possono utilizzare password simili e quindi utilizzare accidentalmente la password di qualcun altro. Cercare più tentativi di password errati per corrispondere con utenti diversi sarebbe un buon modo per capire rapidamente che qualcuno stava cercando di abbinarli e sarebbe un po 'più difficile per l'hacker sapere cosa stava succedendo. (Anche se vedrebbero comunque che il tuo DB principale non collega i nomi utente ai PW e cercherà quelle informazioni.)

• il documento dice che le trappole-password dovrebbero essere più facili da decifrare rispetto a quella reale. Poi:
  • significa anche che se un cracker può ottenere password trap, non dice assolutamente che la vera password sia a rischio;
  • Se inserisco una password di 'qwe123' 'complessità', non è necessario in alcun nuovo metodo prevedere che tale password verrà presto violata, dato che il processo di accesso è disponibile per l'aggressore.
    

Questo metodo sembra enfatizzare il modello di 'sicurezza attraverso l'oscurità' - assicura che le tue password siano al sicuro fino a quando nessuno tenta di craccarle. Prendi anche in considerazione le risorse necessarie per implementare tale schema (Chiunque chieda a Bill di cambiare il modello di sicurezza di Windows?) E rende questo documento un interessante esercizio accademico / pensiero piuttosto che pratico, IMO. E dal modo in cui questa idea compromette la pratica fondamentale del miele - qualsiasi cosa - non rendi la tua produzione più vulnerabile per nessuno scopo.
I network honeynets sono buoni in quanto possono essere completamente isolati dalla produzione, quindi, anche se il vero compromesso si verifica, nessun danno è fatto. Ecco, cosa succede se l'utente malintenzionato compromette tale password prima che possa essere notata? E se questa password di miele a causa di un errore umano durante la configurazione dia un vero accesso a livello utente?

Sì, offre un certo valore di sicurezza.

Questa è una misura di sicurezza che può essere paragonata a CCTV, è un controllo detective e può consentire di prendere provvedimenti prima che le cose sfuggano di mano. Disabilita account / Ripristina password account utente / notifica tempestivamente agli utenti le password riutilizzate.

Avrebbe davvero bisogno dei dati della password, comunque?

Non necessariamente per questo sistema, ma probabilmente tenterà questa combinazione di email / password su altri siti per il riutilizzo della password.