Domanda:
Due password per un account
Lexu
2016-01-25 17:52:44 UTC
view on stackexchange narkive permalink

Sarebbe una buona idea se avessi un account che richiederebbe due password diverse?

Ad esempio, i tuoi dati di accesso erano:

  email: example @ gmail .compassword 1: P4 $$ w0rd1password 2: HereIsMySecondPassword  

Ora quando l'utente accede al mio sito gli viene richiesto di inserire entrambe le password. Sarebbe un'idea migliore di una sola password più forte ? L'utente può scegliere due password che può ricordare più facilmente di una forte.

Considera quanti utenti avranno `password2` =` password1` (o, se esplicitamente proibito, `password2` =` password1` + `2`)
Basta impedire che siano uguali e che non possano contenersi a vicenda.
O che le password devono essere una certa% diverse in cima alle idee di @gab06's.
Un tipo di nome utente ha lo stesso effetto. I nomi utente per la mia banca, ad esempio, sono qualcosa come (parte del nome) (parte del cognome) (numero casuale). Quindi, se il mio nome è Jonathan Smith, il nome utente potrebbe essere jonatsmi022 o jonsmit840. Ciò renderebbe più difficile un attacco di forza bruta poiché l'attaccante avrebbe bisogno di trovare o indovinare sia il nome utente che la password.
Obbligatorio (correlato) xkcd ... https://xkcd.com/936/. Smettila di renderlo eccessivamente complesso .. consenti solo password più lunghe .. aiuterebbe più di tutte queste regole (eccessivamente) complesse;) (che incoraggiano le persone a scrivere le cose, compromettendo comunque tutte quelle regole)
Domanda correlata con buone risposte - [http://security.stackexchange.com/q/82005/52297”(http://security.stackexchange.com/q/82005/52297)
Microsoft ha provato questo con il suo hash LANMAN. Non ha funzionato così bene per loro, ed è in effetti ancora in vigore per Windows <8 per impostazione predefinita e Windows 8 per preferenza. Non sono sicuro circa 10.
Quando l'ho letto per la prima volta, ho pensato che descrivesse l'autenticazione a due o due fattori. Come i codici di lancio nucleare che richiedono a più attori di inserire i propri codici segreti per verificare un lancio, o accedere a GMail, che è leggermente più difficile.
Dieci risposte:
#1
+91
Matthew
2016-01-25 17:59:17 UTC
view on stackexchange narkive permalink

Non proprio. È essenzialmente una password, con la pressione del tasto Invio come un carattere.

Aggiunge complessità al processo di accesso, che in genere non è una buona cosa (gli utenti sceglierebbero probabilmente una buona password e una veloce per digitare la password). Non dimenticare la regola di @ AviD: "La sicurezza a scapito dell'usabilità, va a scapito della sicurezza"

A seconda di come le password sono state memorizzate, diminuirebbero leggermente la capacità degli aggressori di forzare gli account , poiché un utente malintenzionato dovrebbe rompere entrambe le parti. Dubito però che questo bilanci il problema dell'usabilità.

A seconda di come viene implementato, l'aggressore potrebbe essere in grado di rompere le due parti separatamente. Il sistema dovrebbe richiedere entrambe le password anche se la prima fosse sbagliata, altrimenti la seconda richiesta di password rivelerebbe che la prima password è stata indovinata correttamente. In questo caso, la divisione in due password * migliorerebbe * la capacità degli aggressori di forzare gli account.
Un buon esempio del mondo reale di ciò che suggerisce @MontyHarder può essere visto con la [vulnerabilità nota dei PIN WPS] (https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup#Online_brute-force_attack). E, anche se implementi la limitazione della velocità, probabilmente stai ancora archiviando le due parti separatamente nel tuo database, il che aumenta il rischio se l'aggressore ottiene l'accesso al database.
@MontyHarder "Il sistema dovrebbe richiedere entrambe le password anche se la prima fosse sbagliata" IN UN MOMENTO COSTANTE DI TEMPO.
@Bob: Un esempio migliore potrebbe essere [LM hash] (https://en.wikipedia.org/wiki/LM_hash) - è un algoritmo di hashing delle password che ha anche lo stesso problema.
@Aron Un periodo di tempo costante o tale che eventuali variazioni nel tempo siano ortogonali al fatto che la prima password sia stata inserita correttamente, per evitare la fuga di informazioni sulla validità della prima password. Ma stavo iniziando a rimanere senza spazio per esprimere il mio punto e ho deciso di omettere quella parte.
Non c'è modo che possa essere * più * difficile da attaccare di una singola password combinata di lunghezza e complessità equivalenti. Più facile è possibile, come scrive @MontyHarder.
#2
+30
pri
2016-01-25 18:06:35 UTC
view on stackexchange narkive permalink

Ho visto siti bancari in cui un utente è tenuto a rispondere a 2 domande di sicurezza (scelte a caso da una serie di 5 domande prestabilite, al momento della creazione dell'account).

Il punto è che se una password può essere compromessa (sia sul fronte dell'utente che a causa di scappatoie del sito), quante probabilità ci sono che la seconda password rimanga al sicuro? Se il sito web può utilizzare un algoritmo di crittografia migliore per una delle password, perché non utilizzarlo per una singola password?

Immagino che un'opzione migliore sia, l'utente può concatenare le 2 password per creare una password molto più forte . Ad esempio, l'impostazione di 2 password "aBcD" e "eFgH" può essere violata in pochi minuti (o ore), ma una password come "aBcDeFgH" richiederebbe molto più tempo per essere interrotta da un hash.

Esattamente quello. Una buona password è molto meglio di due password deboli.
Non è esattamente quello che è successo con WPS che lo ha reso così famigerato: le prime quattro cifre sono state valutate indipendentemente dalle ultime quattro?
Che ne dici di hashing aBcD con seed di eFgH?
@ardaozkal La maggior parte delle volte, l'hashing seminato è solo "hash (pass + seed)". Quindi l'hashing "aBcD" con seed "eFgH" sarebbe, nella maggior parte dei sistemi, lo stesso hashing "aBcDeFgH" tranne che meno sicuro perché l'hacker può scegliere il proprio seed, rendendo così più facili le tabelle arcobaleno.
#3
+23
Ben
2016-01-25 22:32:28 UTC
view on stackexchange narkive permalink

Uno svantaggio non ancora menzionato nelle altre risposte è che un tale schema probabilmente sconfiggerà alcuni popolari gestori di password.

Dato che dovresti incoraggiare i tuoi utenti a utilizzare i gestori di password, in modo che possano utilizzare lunghe sequenze di caratteri completamente casuali come password, questa è probabilmente una cattiva idea.

#4
+6
supercat
2016-01-25 23:12:30 UTC
view on stackexchange narkive permalink

Un tale sistema potrebbe avere qualche vantaggio se (1) le due password fossero scelte indipendentemente e (2) la politica di blocco per i tentativi errati sulla seconda password fosse più rigorosa di quella per la prima.

Avere una politica di blocco abbastanza rigida per i tentativi di password errate può migliorare notevolmente la resistenza agli attacchi di forza bruta, ma facilita anche notevolmente gli attacchi di negazione del servizio. Se un account viene bloccato per 30 minuti dopo tre tentativi di password errata, chiunque conosca l'ID account può rendere molto difficile l'accesso a un utente legittimo inviando tre falsi tentativi di accesso ogni 30 minuti.

Se è presente una password in due parti e il blocco è applicabile solo ai tentativi di ingresso in cui la prima password è corretta, allora sarebbe necessario violare la prima password per condurre anche un attacco di negazione del servizio. Inoltre, la ricerca nello spazio della chiave per la seconda password sarebbe molto più lenta rispetto alla prima. Inoltre, mentre la notifica a un titolare di account di password primarie errate ripetute produrrebbe molti falsi allarmi per cui il titolare dell'account non potrebbe fare nulla, notificare al titolare dell'account password errate dell'account secondario potrebbe essere molto più utile. Se Adam Baker riceve una notifica che è stato effettuato un tentativo di accedere al suo account con una password primaria corretta ma una password secondaria errata e Adam stesso non era responsabile per quel tentativo di accesso, saprà che la sua password principale è stata violata e potrebbe essere in grado di farlo. per agire prima che il truffatore possa violare la seconda password.

#5
+4
GdD
2016-01-25 18:00:26 UTC
view on stackexchange narkive permalink

L'utilizzo di 2 password non è migliore di una password poiché i problemi principali con le password non vengono risolti. 2 password non annulleranno i key-logger né impediranno ai cracker di recuperare con successo le password utilizzando le tabelle arcobaleno. Inoltre, 2 password sono più difficili da ricordare per le persone di una.

#6
+3
March Ho
2016-01-26 10:51:00 UTC
view on stackexchange narkive permalink

Un ulteriore punto debole di questo sistema di password è che rende il sistema molto più vulnerabile all'hash cracking a forza bruta con tecniche come tabelle arcobaleno. Ciò potrebbe accadere se il database dell'hash delle password fosse trapelato in qualche modo.

Se un utente malintenzionato ha ottenuto l'accesso al database delle password con hash, le due password dovrebbero essere archiviate separatamente come due hash (dal momento che le memorizzano insieme impedisce il confronto diretto di ogni password). Ciò quindi riduce notevolmente l'entropia di ogni hash, consentendo a un utente malintenzionato di decifrare facilmente entrambi gli hash molto più velocemente di quanto sarebbe necessario per decifrare un singolo hash delle password concatenate.

Se le due password hanno la stessa lunghezza e vengono estratte dallo stesso pool, il tempo impiegato per decifrare due hash in isolamento richiede metà del tempo esponenziale (cioè se il cracking dell'intero hash richiede 1.000.000.000.000 di tentativi, bastano solo 1.000.000 di tentativi per decifrare ogni sotto-hash).

Un buon caso di studio è l ' hash NTLM utilizzato in Windows XP e versioni precedenti, che presenta un difetto di progettazione molto simile al sistema di password menzionato. Una password relativamente complessa viene suddivisa e archiviata in due hash separati, il che rende l'intera password notevolmente più debole.

Anche i computer di 10 anni fa potevano facilmente crackare la stragrande maggioranza degli hash NTLM in pochi giorni senza usare le tabelle arcobaleno, e con le tabelle il cracking è quasi istantaneo.

enter image description here

#7
+3
Eugene Ryabtsev
2016-01-26 11:19:09 UTC
view on stackexchange narkive permalink

L'ho visto fare con la seconda password (1) utilizzata non per accedere, ma per eseguire un'azione importante all'interno dell'account, ad es. una transazione monetaria; (2) di tipo diverso dalla prima password, ad es. la prima password è testo costante, la seconda password proviene da 1 time pad o messaggio SMS. Utilizzato in questo modo, sembrava una buona idea.

Questo potrebbe essere utilizzato per accedere, se l'account contiene dati altamente sensibili e l'accesso non viene utilizzato spesso, ma in questo modo sembra già che non lo sia che buona idea.

Utilizzare una password di testo costante per accedere e un'altra password di testo costante per eseguire azioni importanti potrebbe avere un senso in alcune circostanze, ma molto meno che con una -time password secondaria.

L'uso di due password di testo costanti solo per accedere offre pochissimi vantaggi rispetto a una password più lunga, e presenta anche alcuni grossi svantaggi, come per le altre risposte.

#8
+2
TheHidden
2016-01-25 18:06:25 UTC
view on stackexchange narkive permalink

Un metodo comune utilizzato dalle banche è un numero pin e una password. quindi vengono richiesti caratteri casuali in ordine casuale, ad es. inserisci il numero 3 1 2 del tuo numero pin e inserisci i caratteri 3 9 5 della tua password ... questo rende più difficile per i keylogger ottenere qualsiasi informazione ma questo richiede un metodo di 2 password per garantire che gli attacchi casuali non possano avvenire, insieme a un fail2ban , rispettivamente.

quindi la risposta è no, non è una cattiva idea ma niente è una cattiva idea, è l'implementazione che lo rende grande o un errore.

Alcune idee sono cattive idee, non sono solo le implementazioni che possono fare schifo, ad es. WPS.
@domen haha ​​ok forse sono un po 'ottimista
Questa è una cattiva idea. Essere in grado di confrontare parti di una password implica l'archiviazione della password lato server non sicura.
@NeilSmithline implica ma non definisce. Penso che quando molte banche lo fanno, le grandi banche sono sicuro che probabilmente è sicuro, ma potrei sbagliarmi e il mio denaro potrebbe scomparire da un giorno all'altro. un sacco di organizzazioni governative e di detenzione di denaro utilizzano questo metodo, non è nuovo né unico ma in realtà provato e testato.
#9
-1
user 5150
2016-01-26 06:06:24 UTC
view on stackexchange narkive permalink

Nessuno dei due è completamente a prova di errore perché di solito chi cerca di accedere all'account ha altri mezzi per ottenere la password creata dall'utente e quindi dare loro l'accesso alla password di autenticazione in due passaggi che francamente è abbastanza facile da ottenere perché utilizza un telefono di backup o email alternativa con questo detto credo che una password più lunga con caratteri casuali diversi da lettere e numeri

#10
-2
Will Salazar
2016-01-26 03:28:52 UTC
view on stackexchange narkive permalink

Le aziende chiamano l'accordo "autenticazione a due fattori", ma si riduce ad avere una password che crei per te stesso e un'altra password che ottieni da qualche altra parte. Questo è l'equivalente per computer della sicurezza fornita da una cassetta di sicurezza: la tua chiave da sola non può aprire la scatola, e nemmeno la chiave della banca può farlo; entrambe le parti devono utilizzare entrambe le chiavi contemporaneamente.

Questa non è un'autenticazione a due fattori.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...