Esiste un modo per archiviare in modo sicuro password non protette?

Question

Esiste un modo per archiviare in modo sicuro password non protette?

#1 da (5 voti)
#2 da (0 voti)

1

Quindi, ovviamente non sto parlando di coppie nome / password qui, ho intenzione di memorizzare le password con due sali e tre hash, ma quello che mi è successo è che se avessi un tavolo dove tenevo le coppie: password crittografata, numero di persone che hanno provato a impostarlo. E prima di impostare una password, l'ho verificato rispetto a quel database, e se più dello 0,01% degli utenti ha provato a usare quella password, viene rifiutato.

Ci sarebbe un modo per archiviare in modo sicuro dati come quello che impedirebbe gli attacchi tramite qualcuno che risolvesse quella tabella e poi forzerebbe il bruto contro la tabella salata?

L'unica cosa che mi viene in mente è usare la password come pad singolo e XOR-it contro l'hash, ma ciò non impedisce nuove tabelle arcobaleno, ma impedisce solo che quelle attuali funzionino.

encryption password-management password-policy

posta Patrick Jeeves 23.06.2015 - 19:08

fonte

2 risposte

0

Fornisci un modo semplice per controllare la password più comune nel tuo database, mi sembra una pratica davvero pessima.

Supponiamo che qualcuno trovi 5 password in questo modo, sa che è in grado di aprire un account 1/200 in meno di cinque tentativi (se riesce a indovinare il nome utente di un altro account).

Se vuoi prevenire un problema, basta semplificare l'attacco con una password comune lasciando che l'attaccante controlli per ogni password nella loro tabella se sarà efficace contro la tua base.

risposta data 24.06.2015 - 09:17

fonte

Leggi altre domande sui tag encryption password-management password-policy

Un amministratore di rete può vedere lo schermo del mio computer se sono connesso alla rete wifi? Come crittografare i pacchetti in rete?

score 5 · Accepted Answer

Qui presumo che il tuo obiettivo sia (come suggerisce @owen) di interrompere l'uso di password comuni (ad esempio password123) utilizzate dalla tua base utente. Questa è generalmente una "brutta cosa" per la sicurezza, poiché vincolerai artificialmente la scelta della password in un modo che è imprevedibile per l'utente.

Se pensi all'esperienza dell'utente finale di questa funzione, potresti fornire loro un messaggio "hey hai scelto una password comune, scegli un'altra"? Se è così, scommetto che la maggior parte degli utenti manterrà un 1 o! alla fine della password e riprovare e / o sentirsi frustrati e andarsene (a seconda del sito), e dato che non hai intenzione di rivelare l'elenco delle password più utilizzate, non c'è modo per l'utente di sapere quali sono / non sono ammessi.

Un approccio migliore potrebbe essere quello di controllare le password in base a un elenco comune, a cui è possibile indicarle e, se scelgono una di queste password, suggeriscono che è una cattiva idea, ma lasciale andare avanti se scelgono di farlo.

Detto questo, supponendo che il tuo obiettivo qui sia come sopra, non avresti bisogno di avere le password associate a specifici account utente che ti serviranno in una lista, quindi non c'è molto sbagliato (nella maggior parte dei casi) con semplicemente memorizzandoli con lo stesso sale e hash, quindi controllando quando aggiungi nuovi utenti. Se un utente malintenzionato compromette tale tabella, tutto ciò che ha (se si rompe gli hash) è un elenco di password utilizzate nel database senza alcun modo diretto per associarle a utenti specifici.

Un altro rischio da considerare se si prende questo approccio è che se il sistema consente agli utenti di auto-registrarsi, un utente malintenzionato potrebbe semplicemente iterare su password comunemente usate per vedere quali sono stati usati dagli utenti in quanto l'applicazione li rifiuterà. ..