Domanda:
Abbiamo davvero bisogno di una password lunga e complicata per i siti web?
drpexe
2014-11-05 18:16:06 UTC
view on stackexchange narkive permalink

La maggior parte dei siti web che gestiscono informazioni importanti (Gmail, ad esempio) ha una sorta di protezione dalla forza bruta. A volte, se provi più di X volte, l'account verrà bloccato o almeno ti darà un captcha da risolvere.

Attualmente tutti gli esperti di sicurezza continuano a dire la stessa cosa: crea password lunghe, con caratteri misti, ad alta entropia . Questo ha molto senso se pensi a una chiave RSA oa qualcosa che potrebbe essere decrittografato offline, ma è davvero importante quando parliamo di password di account online?

Ad esempio, creiamo una password per Gmail utilizzando solo 6 lettere dell'alfabeto inglese. Questo è circa 26 ^ 6 = 309 milioni di combinazioni. Se consideriamo che possiamo testare 1 password al secondo (che penso sia più veloce di quanto possiamo effettivamente, se prendi in considerazione i captcha di Gmail), avremo bisogno fino a 10 anni per rompere e 5 anni in media.

Punti da considerare:

  • Se utilizzi la stessa password su un sito web diverso, un altro sito web potrebbe essere violato e la tua password potrebbe essere esposta. Presumo che la password sia univoca. Utilizzato solo con Gmail.
  • Se qualcuno riesce a prendere il database, potrebbe forzare l'hash della tua password offline. Presumo che il sito web utilizzi almeno un hash salato (molto improbabile che l'hacker tenti di violare tutte le password) e / o è molto improbabile che il database venga violato (è un presupposto equo con Gmail)
  • Inoltre presumo che la tua password non sia una parola del dizionario o qualcosa di facile da indovinare. Ciò dovrebbe escludere la forza bruta di più account (ad es. Testare la stessa password comune su più account).

È lecito ritenere che non abbiamo bisogno di una password molto lunga per i siti web come non appena seguiamo le altre misure di sicurezza? Se suggeriamo alle persone di utilizzare una password lunga solo perché normalmente non seguono gli altri consigli di sicurezza (utilizzare la stessa password su tutti gli account, ecc.). Non stiamo davvero cercando di risolvere i sintomi e non la causa?

PS: alcune altre domande riguardano quasi la stessa cosa, ma le risposte considerano sempre che la persona utilizza la stessa password su tutti i siti Web o che il database del sito Web viene facilmente rubato.

Cosa consideri più a lungo? Nel tuo esempio, l'utilizzo di una password alfanumerica lunga 8 caratteri rende impossibile un attacco di forza bruta online. Ma questo non è sempre un probabile attacco.
Considero lungo qualsiasi cosa> 6 caratteri. Molto tempo fa, quando Gmail, all'avvio di Google, richiedeva di avere una password> = 6, dopo un po 'di tempo l'hanno aumentata a> = 8
Mentre è vero che Gmail ha alcune buone misure di sicurezza in atto, è anche vero che sono un grosso bersaglio per le persone malvagie e sono probabilmente sotto qualche forma di attacco ogni giorno. Penso che i gestori di password siano la strada da percorrere fino a quando qualcuno non troverà un modo per avere password facili da ricordare ma difficili da decifrare (collegamento XKCD obbligatorio: http://xkcd.com/936/). Solo perché un sito o un servizio sembra avere buone contromisure in atto non significa che non verranno violati o subiranno errori di sistema (o umani). O, naturalmente, sabotaggio.
Non c'è una buona risposta. Sfortunatamente, le password casuali (ad esempio, "pl3sqzjwAb") tendono ad essere difficili da ricordare e digitare. La maggior parte delle persone sarebbe probabilmente più felice con le "passphrase", ma molti siti non le consentono, per vari motivi, buoni e cattivi.
È per se il database viene violato
Potresti essere in grado di digitare solo una password al secondo, ma il software potrebbe essere scritto per farlo molto più velocemente. Più lunga è la password, maggiore sarà il tempo di CPU (e / o) necessario per decifrare una password.
`Attualmente tutti gli esperti di sicurezza continuano a dire la stessa cosa: crea password lunghe, con caratteri misti e ad alta entropia` [citazione necessaria]
Come esempio di vita reale, il PIN sulla tua carta di credito o VISA ha solo 9999 combinazioni possibili e hai 3 tentativi. Quante volte la tua carta è stata disabilitata senza preavviso e sostituita a causa di una violazione della sicurezza interna della banca o di un caso in cui _non erano del tutto sicuri_ se qualcuno avesse rubato i dati dell'account di circa centomila persone (incluso tutto ciò che serve per creare un carta, ma escluso PIN)? Per me, questo è successo 5 volte negli ultimi 10 anni, quindi in media una volta ogni 24 mesi ... ora presumo che il sito web medio abbia una sicurezza inferiore con meno controlli rispetto a una banca.
@Damon è un po 'diverso. 1) Ci sono solo 10 combinazioni possibili per ogni numero in quattro posizioni. L '"hacker" ha bisogno solo di un massimo di 10.000 tentativi per indovinare quel PIN. Con una password è molto, molto di più perché se un utente usa solo l'alfabeto, ci sono 26 possibilità diverse in ogni luogo. Quindi considera le lettere maiuscole e le lettere minuscole e quel numero raddoppia. Quindi aggiungi i numeri che aggiungeranno altre 10 possibili ipotesi a ciascuna posizione. Il lasso di tempo per "hackerare" la password è molto, molto più lungo di quanto non lo sia per il PIN di una carta, semplicemente perché ci sono più opzioni possibili.
Inoltre, potrei sedermi con un pezzo di carta e una penna, con te seduto dall'altra parte del tavolo rispetto a me, e indovinare il tuo PIN entro un'ora semplicemente utilizzando il processo di eliminazione. È così che questi "hacker" ottengono così facilmente e spesso i PIN delle persone.
Sarebbe interessante vedere un'analisi credibile di quante esposizioni / penetrazioni effettive sono dovute a password deboli, rispetto a tutti gli altri buchi nella sicurezza. Non è chiaro che le penetrazioni di milioni di clienti in Target, Home Depot e altri siano dovute in qualche modo a password deboli.
Dodici risposte:
#1
+36
R15
2014-11-05 19:30:54 UTC
view on stackexchange narkive permalink

Quanto segue in realtà non rende giustizia, ma in sintesi ...

In un mondo ideale no, le password complicate non dovrebbero essere richieste per le risorse online.

Ma , in quel mondo ideale dipendiamo dagli amministratori del sistema per rafforzare i sistemi per impedire l'accesso non autorizzato al "file delle password", quanto segue minimizzerà il rischio:

  • Configura in modo sicuro l'infrastruttura;
  • Applicare tempestivamente le patch;
  • Avere una qualche forma di monitoraggio per identificare una compromissione in caso di uno scenario di exploit zero-day (in modo che agli utenti possa essere "detto" di cambiare le proprie password );
  • Avere e seguire metodologie di programmazione / sviluppo "sicure";
  • Assumere solo persone affidabili.

La combinazione completa delle quali è improbabile per molti siti.

I punti deboli nell'elenco precedente possono provocare exploit che consentono di aggirare completamente le password, ma indipendentemente dalla natura di un exploit riuscito, è una scommessa sicura che , dopo aver guadagnato accesso non autorizzato a un sistema, gli aggressori tenteranno di esfiltrare il file della password e successivamente di forzarlo per favorire la successiva compromissione di altri sistemi (sfruttando il riciclaggio delle password).

Quindi, sebbene non vi sia alcuna garanzia che un forte (er ) la password impedirà tutto ciò che è dannoso, può aiutare a mitigare i punti deboli nelle soluzioni dei fornitori (noti o meno).

A scanso di equivoci, dipendiamo anche dal fornitore di servizi per fare quanto segue :

  • Applica hashing e salting alle password;
  • Assicurati che la password non venga mai scambiata in testo non crittografato.

Immagino che per la maggior parte degli utenti finali la decisione sulla complessità e la lunghezza della password dipenderà dalle informazioni a cui il sito (e quindi la password) dà accesso.

Il mio consiglio è: se si tratta di qualcosa di importante, usa una password complessa in modo che, in caso di compromissione del sistema, le password di altre persone vengano probabilmente scoperte per prime. Ma se qualcosa di banale e la comodità è più importante, rischia una password più debole, ma accetta che un hack potrebbe portare alla perdita di accesso all'account e / o al rilascio di informazioni dall'account.

Per Molti proprietari di siti sospetto che la decisione di richiedere password complesse sia una combinazione di FUD e il desiderio di ridurre al minimo l'impatto di un errore critico dei controlli aumentando la quantità di tempo per le password a forza bruta, dando così più tempo per rettificare e ridurre al minimo l'utente effettivo compromissione dell'account (sebbene se un utente malintenzionato ha accesso agli hash delle password, probabilmente ha un accesso al sistema sufficiente per compromettere il sistema in altri modi).

Hai dimenticato "nessun programmatore commette mai un errore".
L'unica risposta finora che affronta effettivamente la questione di lasciare che i servizi si occupino della protezione del cliente.
@MichaelKjörling Sento un pizzico di ironia? Ma sì, d'accordo e aggiornato. Grazie.
@R15 Solo un pizzico di ironia. Il semplice fatto è che qualsiasi errore da parte di un programmatore nella parte sbagliata del codice può portare a punti deboli sfruttabili, ed è tutt'altro che certo che anche con la revisione del codice tali errori vengono colti prima che qualcuno riesca a sfruttarli e si trasformi in un grosso problema. Non è richiesta alcuna malizia da parte degli sviluppatori.
Mi spiace, non vedo il motivo della maggior parte dei pericoli: nella maggior parte di essi una password più lunga non sarebbe d'aiuto in alcun modo. Se ho un'unica password breve solo per GMAIL, l'unico svantaggio di una password lunga è un attacco di forza bruta offline. E la maggior parte dei tuoi scenari molto probabilmente comprometterà l'account senza bisogno di una password o fornirà la password in chiaro ... Gli scenari in cui solo l'hash viene rubato silenziosamente per un attacco al dizionario offline sono solo una frazione ...
1 e 2 potrebbero compromettere l'account in qualsiasi modo. 3 senza hashing la lunghezza della password è irrilevante (e il salting è standard per i grandi siti) 4. Testo in chiaro = lunghezza irrilevante 5. Zero day = cambia la tua PW = lunghezza irrilevante 6 & 7 = in qualsiasi modo ... Fornisci solo scenari di attacco generali - la domanda è in quale percentuale una password lunga ti aiuterebbe a mitigarla?
@Falco la mia intenzione originale dell'elenco era di illustrare le nostre dipendenze dal fornitore di servizi e non volevo vincolarlo a `` solo '' il lato della password delle cose nel caso in cui qualcuno lo raccolga in futuro e lo usi come elenco di spunta per configurazione di un servizio. Modificherò la risposta per renderla più specifica (anche se non sono completamente d'accordo con la tua analisi).
In un mondo davvero ideale non avremmo bisogno di password o misure di sicurezza. ;)
#2
+33
DaniloNC
2014-11-05 18:36:42 UTC
view on stackexchange narkive permalink

La raccomandazione per la password lunga è di proteggere le password dall'essere violate se qualcuno ha accesso all'hash di quella password.

Strumenti come hashcat possono facilmente (usando gpu) testare gli hash 93800M c / s md5

Come utente di solito non sai come fa il sito a memorizzare la tua password, quindi è meglio usare una password lunga per mitigare questi attacchi.

Si spera che qualunque sito utilizzi non memorizzi le password in testo normale, sarebbe molto brutto e illustri la necessità di utilizzare password diverse.
Pensando in questo modo possiamo presumere che non abbiamo bisogno di una password lunga per servizi come gmail. Poiché è molto improbabile che il loro DB venga violato e anche se lo è, è più improbabile che qualcuno prenda di mira il tuo nome utente. È giusto? o forse questa ipotesi è troppo ottimistica?
@drpexe Ma poi di nuovo, le persone avrebbero potuto dire lo stesso di LinkedIn.
-1
@drpexe Non puoi presumere che Gmail (o qualsiasi altro provider) non verrà violato. Infatti, [Google _è_ stato violato in precedenza] (https://en.wikipedia.org/wiki/Operation_Aurora).
@drpexe Ricevi email di spam? Quindi un bot da qualche parte prende di mira il tuo nome utente.
@Jonathan Se il server memorizza la password come testo normale, una password più complessa difficilmente aiuterà. Tuttavia, se il server utilizza un hash della password scadente (come ad esempio l'applicazione di MD5 alla password e nient'altro), puoi rimanere al sicuro utilizzando una password complessa.
@kasperd Buon punto. Stavo parlando di non riutilizzare la tua stessa password su molti account. Se un sito lo memorizza in testo normale, è molto probabile che venga compromesso e gli hacker possono utilizzarlo per accedere agli altri account.
@drpexe: Le precedenti istanze di hacking prendono di mira il database. Quindi il nome utente e l'hash della password di tutti (non la password in testo normale) diventano noti e scaricabili da tutti su Internet. Da quel database i cracker quindi prendono di mira il nome utente di tutti per aumentare le loro possibilità di ottenere almeno un account violato (o quanti più account possibile). Perché non dovrebbero? Tu e la maggior parte delle altre persone probabilmente controllate il conto bancario online tramite Gmail. L'obiettivo non è Gmail. L'obiettivo è il tuo conto bancario che ti consente di reimpostare la password tramite Gmail.
@slebetman se la tua banca ti consente di reimpostare la tua password bancaria utilizzando solo la posta elettronica, è meglio ** iniziare a cercare immediatamente un'altra banca **. normalmente è necessario verificare il reset su un altro canale (via telefono o anche di persona)
@törzsmókus: La maggior parte ma non Paypal. Capisco che paypal non è una banca ma accetta denaro da te e gestisce denaro che le persone ti danno. Svolgono tutte le funzioni di base di una banca e necessitano solo della posta elettronica per il controllo. Immagina di avere il controllo dell'account paypal di un venditore ebay impegnato.
@slebetman: hai fatto un punto valido, sebbene anche Paypal offra l'autenticazione a due fattori.
#3
+31
Xander
2014-11-05 20:37:07 UTC
view on stackexchange narkive permalink

Scegliere buone password è difficile. Gli esseri umani e il nostro debole per i modelli semplicemente non sono molto bravi. Moltiplicalo per le dozzine di account che accumuliamo nel tempo, e questa è la radice del problema.

Quindi sì, l'eliminazione di password errate e il riutilizzo delle password può risolvere il problema della creazione di destinazioni flessibili, ma non risolve il problema alla radice del mantenimento di tutti quegli account e password, che è ciò che porta al cattivo password e riutilizzo delle password in primo luogo. Quindi, è bene dire "basta seguire buone politiche di sicurezza delle password" e sarai al sicuro, ma senza affrontare il problema della gestione dell'account non hai risolto nulla.

Allora, qual è la risposta? Usa un gestore di password. Questo risolve il problema. Quando scarichi la creazione della password e il problema di gestione su uno strumento progettato specificamente per quello scopo, ottieni password complesse per impostazione predefinita e non è mai necessario riutilizzare una password di nuovo. Non è una soluzione perfetta (niente lo è) ma è la migliore che abbiamo al momento e rende discutibili le questioni di complessità e lunghezza della password, perché quando non sei tu a dover creare e ricordare la password, non ti interessa più quanto è complesso e lungo, solo che viene generato con abbastanza entropia da renderlo forte, e un gestore di password ti dà questo.

Non sono sicuro che tu abbia capito tutto. Perché qualcuno dovrebbe usare un gestore di password se può semplicemente creare, per ogni sito web diverso, una password di 6 caratteri facile da ricordare?
@drpexe Allora hai fallito il requisito di sicurezza "facile da indovinare" che hai messo in atto. Non c'è abbastanza entropia nelle password "facili da ricordare" a sei caratteri perché siano forti. Soprattutto una volta che inizi a parlare di diverse dozzine a cento o più.
Per gli attacchi offline sì, ma per gli attacchi online no. Sono d'accordo che anche una password di 6 caratteri è difficile da ricordare se ne hai a tonnellate, ma questo non è vero per tutti
@drpexe Certo, non sto dicendo che non potrebbe funzionare per nessuno ... Certamente potrebbe. Non è solo un'ottima soluzione generale al problema.
Sono d'accordo con la prima parte, ma un gestore di password non risolve davvero nulla.
Questo non sembra davvero rispondere alla domanda principale.
@Lilienthal Sto principalmente sottolineando che la premessa di base della proposta è viziata, rendendo le specifiche irrilevanti.
Più esplicitamente, il problema è che può sembrare facile ricordare dozzine di password di 6 caratteri. Ma ricordare anche dieci password di 6 caratteri * a piena entropia * è impossibile che un essere umano ne soffra. Suggerirei di notare questo nella tua risposta, poiché è ciò che l'OP sta effettivamente proponendo e non dici esplicitamente che è qui che la domanda è imperfetta.
@Xander: Qual è la differenza tra usare un gestore di password e riutilizzare la stessa password ovunque e scriverle tutte su post-it * (tranne che nel primo caso devi fidarti di una terza parte) *?
#4
+11
Stan Rogers
2014-11-06 18:46:29 UTC
view on stackexchange narkive permalink

Le uniche sane ipotesi per gli sviluppatori web che utilizzano l'autenticazione con password locale sono:

  1. che i loro utenti useranno la stessa password per tutto ;

  2. che il sito è già stato compromesso, anche se non hanno ancora finito di scriverlo; e

  3. ci sarà una responsabilità legale molto costosa associata alle conseguenze di tale compromissione.

(Tieni presente che Non sto insinuando, né sto suggerendo, che tutti - o anche qualsiasi - gli sviluppatori web siano sani di mente o sappiano abbastanza di ciò che stanno facendo per rendersi conto che ciò che stanno facendo sarebbe folle se sapessero cosa stanno facendo. Gli hash semplici, sia semplici che salati, sono abbastanza vicini dal punto di vista computazionale al testo normale da non far nulla di questi tempi, eppure si trova ancora testo normale, MD5 non salato, ecc. sul Web nei cosiddetti "tutorial" che le persone copiano e incollano in produzione su server ovunque.)

Queste supposizioni significano che anche se gestisco un sito con un'applicazione estremamente locale dedicata a consentire alle persone di elencare consigli per prelibatezze per criceti senza glutine organiche, ruspanti e coltivate localmente, devo trattare la tua password come se erano i tuoi account PayPal, eBay ed e-mail tutti insieme (perché ci sono buone probabilità che lo sia effettivamente). E questo significa che per proteggere il mio dietro piuttosto prezioso, devo prendere almeno alcuni passaggi minimi per proteggere il tuo prezioso dietro, che ti piaccia o no. Idealmente, ciò significa rendere la tua password qualcosa che non può essere banalmente forzato (usando un sale cripto-casuale e una costosa funzione di derivazione della chiave) e mettere un limite inferiore assoluto al conteggio dei caratteri (idealmente senza limite superiore, entro limiti ragionevoli ), pur permettendoti di usare qualcosa che è facile da ricordare (niente di tutto ciò "deve usare almeno un carattere accentato, un emoji e un hiragana" senza senso). In altre parole, consentirti di utilizzare una password molto breve espone le mie natiche personali a pericoli ingiustificati, quindi non aspettarti che lo permetta. E questo se il mio sito non custodisce alcun segreto eccetto la tua password. Se ci sono dati personali effettivi associati a te di cui sono responsabile, aspettati la mia paranoia sul tuo conto per aumentare notevolmente.

#5
+5
Taemyr
2014-11-06 21:04:23 UTC
view on stackexchange narkive permalink

Ci sono problemi con un paio di supposizioni.

309 milioni sono un numero ridicolmente piccolo se c'è un attacco offline. E in un attacco offline, anche con un buon sale, l'attaccante cercherà per primo il frutto basso. Cioè. trova le password che si trovano nel dizionario, quindi le password brevi, quindi altre password semplici. Tuttavia, quanto sia un problema è discutibile: ci sono buone possibilità che un utente malintenzionato con accesso al database delle password abbia accesso anche a qualsiasi altra cosa stia cercando. - Ciò presuppone che non sia in corso il riutilizzo della password.

309 milioni sono, come noti, uno spazio di ricerca troppo grande per la forza bruta in un attacco online. Tuttavia le tue supposizioni che portano a questo numero sono dubbie. Noi come specie siamo notoriamente poveri in due compiti rilevanti; venire con sequenze autenticamente casuali e ricordare sequenze casuali. Ciò significa che la tua entropia è notevolmente inferiore se hai selezionato una password di 6 caratteri. Questo può essere evitato se utilizzi un gestore di password o un'utilità simile, ma in tal caso potresti anche optare per una password più lunga per proteggerti dagli attacchi offline.

In conclusione; ottenere una buona entropia nella password dipende dal carattere entropia pr e dalla lunghezza della password. - Se hai una buona entropia per carattere puoi accettare una password più breve. Tuttavia, questo è un approccio poco adatto alla maggior parte degli esseri umani, poiché ricordiamo stringhe più lunghe con un'entropia inferiore per carattere meglio di stringhe più corte con un'entropia elevata per carattere. Siamo anche capaci di generare stringhe casuali e il consiglio che citi è per le persone che non utilizzano gestori di password per generare password.

#6
+5
Falco
2014-11-07 19:39:53 UTC
view on stackexchange narkive permalink

Usare una password complessa per un singolo sito sicuro è come usare una serratura speciale sulla porta del tuo appartamento, che fa sì che l'apertura della porta richieda più tempo e ti protegga meglio dall'1% di tutti i ladri

La maggior parte delle risposte si occupa di tutti i tipi di scenari di attacco, che potrebbero compromettere la tua password, ma per decidere se una password più piccola (6 caratteri) è sufficiente se la usi solo su 1 singolo sito con una sicurezza ragionevole, dobbiamo solo confronta un singolo numero:

Quanti attacchi funzionano significativamente meglio su una password debole che su una password complessa?

Se la protezione dalla forza bruta online è sufficientemente forte (una premessa nella domanda ) l'unico scenario di attacco rilevante è il brute-forcing offline. In tutti gli altri scenari di attacco (lettura della password in chiaro, furto di sessione, ingegneria sociale, phishing, falsificazione dell'utente) la complessità della password non ha alcun ruolo (se non è una password standard)

Allora come la maggior parte degli attacchi al tuo account o a Gmail utilizzerà probabilmente una forzatura bruta offline fattibile della tua password? Probabilmente quasi nessuno. La forzatura bruta funzionerà solo con una versione hash o crittografata della tua password. In qualsiasi altro luogo la tua password è in testo normale (quindi la complessità è irrilevante) o non è affatto rilevante (ad es. Session-id, accesso diretto da un insider al server di archiviazione della posta)

Le uniche istanze in cui la tua password è crittografati o hash sono 1. hash salato nel database e 2. trasferimento della password tramite HTTPS

  1. hash salato nel database Se l'hacker ha avuto accesso al database in cui tutti gli utenti- le password vengono memorizzate (probabilmente uno dei migliori punti protetti nell'infrastruttura) ma non è stato possibile accedere ad altri servizi (come un ID di sessione attivo o l'accesso diretto all'account) Quindi un attacco offline contro il tuo hash salato con un attacco di forza bruta maneggerebbe rapidamente la tua password.

  2. Trasferimento HTTP Molto improbabile perché l'attaccante dovrebbe forzare brutemente il tuo flusso HTTPS per isolare la tua password, quindi la lunghezza della password molto probabilmente non ha molta importanza.

Quindi l'unico scenario in quale password lunga ti protegge effettivamente è se qualcuno ha accesso all'archivio dati (probabilmente) più sicuro dell'infrastruttura senza che nessuno se ne accorga e senza accesso sufficiente per ottenere un accesso più facile al tuo account. Direi che questo scenario è davvero improbabile, perché nel vasto numero di vulnerabilità e attacchi contro il tuo account, questo è solo un tipo di attacco improbabile.

È così improbabile che sia successo almeno 7 volte l'anno scorso a grandi aziende. Ecco un elenco di [violazioni principali] (https://haveibeenpwned.com/PwnedWebsites). Potresti notare che GMail è in quella lista. Sebbene costituisca una piccola parte di tutti gli attacchi, quando si verifica espone milioni di password. Se guardi quanto è probabile che una determinata persona abbia un account su un sito violato, le probabilità sono in realtà piuttosto buone. Tale elenco include yahoo, adobe, gmail e snapchat. Penso che le probabilità siano abbastanza buone che a una determinata persona sia stata violata la password negli ultimi due anni.
@Tyrsius in quei casi avere una password "complessa" farebbe la differenza? Col passare del tempo, sono più propenso a credere che la password più sicura ... sia quella che non esiste.
@prusswan Sì, avere una password complessa ti dà più tempo prima che la password possa essere determinata. Ciò consente di modificare la password sul sito violato. Più è complesso, più tempo hai. Una complessità sufficiente combinata con un metodo di hashing della password appropriato (come bCrypt) renderà tutto così difficile che probabilmente non sarà terminato prima che l'attaccante si arrenda. Il punto è che le probabilità sono che questo * sta per * accadere a te, ed è meglio essere preparati con una password difficile da decifrare. Ancora meglio se la password è univoca e il cracking esporrà solo l'account violato.
@Tyrsius non ci sono prove che Gmail sia stato violato. Se segui la discussione sull '"elenco Gmail" non ci sono prove che gli hash pw siano stati effettivamente rubati e la maggior parte delle persone indica che gli accessi provengono probabilmente da xtube o altri siti ...
@Falco Buono a sapersi. Penso che il mio punto sia ancora valido: sebbene questi attacchi siano meno frequenti, quando * accadono * si traducono in centinaia di migliaia, a volte milioni, di credenziali violate. Invece di guardare alla frequenza degli attacchi, dovremmo guardare al numero di persone colpite ogni anno. Fornisce un'indicazione molto migliore della probabilità che tu sia colpito da questo tipo di attacchi.
#7
+4
James_1x0
2014-11-06 20:33:07 UTC
view on stackexchange narkive permalink

La mia risposta è semplicemente sì. Non puoi presumere che i siti utilizzino metodi di hashing salato. Ad esempio, MD5 viene ancora utilizzato in natura e le persone pensano che sia perfettamente accettabile.

Ma con un meccanismo di hashing fortemente salato, non c'è modo che qualcuno possa accedere alla password effettiva, anche se lo è un passaggio di caratteri bassi. Soprattutto se il tuo server è adeguatamente protetto e la tua API prende le dovute precauzioni per gli attacchi di forza bruta.

#8
+4
Mark
2014-11-07 22:23:20 UTC
view on stackexchange narkive permalink

Sebbene sia più sicuro creare password complicate, consiglio sempre di renderle facili allo stesso tempo e di avere anche un'unicità per sito web. L'unico modo in cui questa potrebbe essere una vulnerabilità è se cadi in una truffa di phishing, motivo per cui è importante avere più modi per recuperare il tuo indirizzo email, perché la tua email è il tuo modo per recuperare altri account.

Ecco le regole che uso personalmente:

  • Almeno 8 o 10 caratteri, preferibilmente 12 o più
  • Usa qualcosa che significhi qualcosa per te
  • Le abbreviazioni o l'uso di un numero invece di una lettera possono essere facili ma efficaci
  • Se vuoi, puoi usare un prefisso o un suffisso per mantenere le password univoche

Quindi per esempio: ThisIsMyPassword14si

Utilizza: lettere maiuscole, numeri e il suffisso si per lo scambio di stack e ha un anno di qualcosa che significa qualcosa di personale. Questo tipo di password di solito viene sempre visualizzato come una password complessa.

Esistono anche più servizi che ti consentono di accedere utilizzando un altro servizio basato su token. Penso che questa sia una grande idea, perché puoi disconnetterti ogni volta che vuoi rimuovere qualsiasi accesso e non hai bisogno di una password per ogni singolo servizio (supponendo che gli sviluppatori abbiano progettato il processo correttamente). TUTTAVIA, devi essere di più fai attenzione alla password di quel servizio e disponi di più opzioni di ripristino nel caso in cui la perdi per qualsiasi motivo.

Penso che Google stia andando nella giusta direzione qui, avendo più opzioni di ripristino e 2- autenticazione dei fattori. Il problema è che quasi tutto può essere falsificato se non presti attenzione alla pagina effettiva che richiede le tue informazioni.

Si spera che in futuro ci sarà un dispositivo su di te, come un telefono cellulare, che può fungere da autorizzazione di sicurezza per i servizi web. Le app sono controllate dal distributore, quindi avere un'app per piattaforma per ottenere la richiesta di accesso e chiedere il tuo permesso sarà il modo giusto per gestirla in futuro, quindi non dobbiamo preoccuparci di questa password individuale per tutto senza senso.

... un giorno ...

#9
+2
dibble
2014-11-06 12:06:43 UTC
view on stackexchange narkive permalink

Non dimentichiamo che qualcuno non ha bisogno di forzare un bersaglio. Possono provare la stessa password con molti obiettivi, rendendo vulnerabili gli utenti con le password più comuni.

Funziona solo se l'utente ha una password come "123456" o qualcosa di molto comune.
@drpexe sopravvaluti la diligenza degli utenti: http://stricture-group.com/files/adobe-top100.txt
#10
+2
Irving Poe
2014-11-08 16:36:10 UTC
view on stackexchange narkive permalink

Hai dimenticato l'attacco fisico locale! Una password lunga e complessa rende molto meno probabile che il rilevamento delle spalle abbia successo. Anche se qualcuno fissa la mia tastiera, non otterrà le mie password a meno che non sia Rainman. (Non può commentare)

#11
+2
Shai
2014-11-09 11:15:21 UTC
view on stackexchange narkive permalink

Quando si utilizza un affidabile sistema di autenticazione a due fattori, è ragionevole utilizzare una password meno sicura. È comunque meglio utilizzare una password complessa generata da un generatore di password utilizzando lettere maiuscole e minuscole, numeri e simboli.

Ma le persone che non distribuiranno una password così sicura; nel caso di un servizio che offre l'autenticazione a due fattori, queste persone possono sentirsi ragionevolmente sicure.

#12
-6
Amaresh Pattanayak
2014-11-06 14:36:55 UTC
view on stackexchange narkive permalink

Non puoi proteggere la tua password utilizzando combinazioni su larga scala, per questo devi criptare la tua password. Alcuni algoritmi di criptazione comuni sono md5, SHA-1, SHA-256 stc, ma non è ancora sicuro al 100%. L'attaccante può decrittografare la tua password utilizzando strumenti come hash cat con GPU elevata, come menzionato sopra.

Quindi in un guscio di noce nessun algoritmo è sicuro al 100%, ma puoi generare un meccanismo di password forte usando sali con crypt esistenti algos. Ecco alcuni famosi algoritmi di cripta.

http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions

l'hashing non è la stessa cosa della crittografia


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...