Sto parlando di questa password - 23##24$$25%%26
e di quelli simili composti da caratteri speciali che appaiono in uno schema, che gli utenti in questi giorni usano molto.
Al lavoro (società finanziaria) stavo creando un elenco di password errate che gli utenti non dovrebbero poter scegliere, che coinvolgono determinati cicli o pattern, e il tipo di cui sopra mostra quel tratto di contenere numeri consecutivi che racchiudono caratteri speciali (ripetute certe volte, qui due volte).
Solo per curiosità, l'ho verificato su un sito molto conosciuto (sulla sua pagina di accesso), e ha dichiarato che ci sarebbero voluti secoli per rompere.
Alcuni altri esempi nell'elenco che richiederebbero anni per rompere, ma sono molto vulnerabili:
1!2@3#4$5%6^
%codice%
2@3#4$5%6^7&
Ora, rimango confuso con la lista, dovrei contrassegnare questi particolari tipi di password come vulnerabili e non consentire agli utenti di farli, anche se impiegano molto tempo per interrompere?
Nota 1 - Stiamo considerando questi vulnerabili come molti utenti (e, quindi, più password simili) stanno seguendo questa tendenza per ricordare facilmente le cose.
Nota 2 - Siamo confusi perché i membri della sicurezza stanno aumentando l'entropia, ciò che stanno ignorando è una maggiore ordine di hash simili nel database
Sorse un attrito tra ragazzi su dove disegnare una linea, definendo quale password essere consentita o non consentita.
Modifiche:
-
Di questo sito di cui sto parlando, ma che non nominerò, su cui ho provato la password è praticamente noto a tutti gli hacker etici / non etici, quasi tutti gli utenti qui su Stack Exchange e molte grandi / piccole aziende ( come usano i suoi servizi).
-
Non memorizziamo le password in testo semplice . Utilizziamo un algoritmo di hashing piacevole, non preparato in casa.
Un incidente ci ha portato a rivedere le nostre norme sulle password e abbiamo creato un database separatoa!b@c#d$e%f^
su una macchina diversa, in cui abbiamo archiviato semplicemente_hashed_newly_created password utente (niente sale, niente, solo hashed_password) senza memorizzare who_created, when_created details. Lo abbiamo fatto solo per un breve periodo. Anche la modifica della password è stata inserita in questo database. Mentre, nel nostro database originaledb-2
sat secure_salted_passwords.
Abbiamo continuato a creare una listadb-1
di password vulnerabili con hash, seguendo un pattern, e siamo rimasti divertiti quando abbiamo trovatoL
&L
- abbiamo visto più gruppi di password simili, con determinati modelli.db-2
eL
sono stati successivamente cancellati dai sistemi. -
db-2
è stato mantenuto su un computer altamente sicuro ed è sicuro, non fornirà qui i dettagli esatti. Siamo consapevoli che anche le intercapedini o le prese elettriche non sono sicure. Siadb-2
chedb-2
sono stati distrutti. -
Non preoccuparti delle password pubblicate qui, dato che abbiamo già condotto il nostro piccolo esperimento e tutte quelle serie specifiche di utenti sono state create per reimpostare le password (ovviamente una nuova password diversa da quella precedente). Questa è la ragione, sono venuto qui pubblicando alcuni campioni.
E, ho già commentato qui in precedenza, che ho pubblicato un campione di password dalla logica del generatore che ha creato un elenco molto grande di password hash, che possono essere o non essere inL
. Ancora una volta, poiché tutti quegli utenti hanno una nuova password, quindi non preoccuparti, tutto è sicuro e protetto. -
Dal momento che so che il generatore funziona, ho testato alcuni esempi di password su un sito Web e ci siamo confusi su quali sono consentiti o non autorizzati, su quali criteri.
Grazie mille per le tue risposte, accetta la mia gratitudine. Sulla base delle risposte, per il momento abbiamo rinviato qualsiasi tipo di restrizione da porre sulla scelta della password.