Se una password è unica, è davvero importante quanto sia "strong"?

Sì, è meno sicuro. Perché se un hacker ottiene una copia del database utente della banca, incluse le password hash, non sono più limitate dalla limitazione o dal blocco dell'interfaccia web e possono eseguire un attacco a forza bruta a piena velocità contro gli hash. Se la banca utilizza un efficiente algoritmo di hashing (che ovviamente non dovrebbero, ma in realtà le banche non hanno tutti una perfetta sicurezza), allora un aggressore potrebbe essere in grado di fare un miliardo di tentativi al secondo. A tale velocità, possono enumerare ogni password di otto lettere contenente una combinazione di cifre, lettere maiuscole e minuscole in due giorni e mezzo.

Praticamente la lunghezza di una password è il fattore più rilevante contro bruteforce + lo scenario di hash offline. Più lunga è la tua password, più tempo ci vorrà per enumerare tutte le possibilità e, di conseguenza, guadagni più tempo e sicurezza.

Anche la "casualità" è importante, ma ciò vale solo per le rainbow-tables / attacchi-dizionario come ha detto koluke. Quindi la casualità può essere irrilevante per casi specifici ma mira a eliminare gli approcci più basilari e quindi a rendere la tecnica della bruteforce un collo di bottiglia.

EDIT: Vorrei aggiungere che trovo anche quelle policy-password come utili per l'accesso pubblico in quanto mi garantiscono come amministratore che tutte le password raggiungono almeno un livello minimo di sicurezza (es. password) e non consente loro di utilizzare come password "password", "sicuro" o "04.04.1997". Di gran lunga non tutte le password che passano le politiche possono essere considerate "sicurezza", ma almeno so che la loro sicurezza non è immaginaria.

Se usi una frase alfanumerica come direful4 , è abbastanza facile indovinare o forzare la tua password. Più strong è una password, più difficile da indovinare o forza bruta nel caso in cui il database dell'account di un sito venga compromesso.

Se il sito della banca che hai menzionato ti consente di archiviare una password non sicura e la banca non riesce a bloccare un account dopo più tentativi di accesso falliti (o il loro database è compromesso), avere una password più strong ti dà più protezione contro chi cerca di crack la password utilizzando le tabelle arcobaleno, la forza bruta o un attacco dizionario.

L'idea con la sicurezza della password (e la sicurezza in generale) consiste nell'avere delle sovrapposizioni nella politica nel caso qualcuno si arrabbi o un attore malintenzionato trovi un modo per eludere una protezione. Questo è noto come approccio alla sicurezza a più livelli. Ad esempio, nessuno si aspetta di essere hackerato, ma nel caso in cui lo siano, disporre di ampi log di accesso aiuta a identificare chi, cosa, quando e dove di un attacco. Allo stesso modo, esegui un software antimalware per prevenire un'infezione da virus, ma dovresti comunque conservare i backup dei dati critici nel caso in cui un pezzo di malware sia in grado di eludere le tue protezioni antimalware.

Se non riutilizzi questa password né alcuna iterazione o variazione di questa password ovunque, direi che non importa che si imponga una policy strong per generarla o meno, a patto che non possa essere brutaforce online ( perché l'applicazione non consente un numero sufficiente di tentativi di accesso non riusciti o perché sarebbe troppo costoso provare molte password online).

L'unico scenario che potrei pensare è:

Diciamo che un utente malintenzionato sia riuscito a ottenere un accesso temporaneo al sistema di destinazione, per qualsiasi motivo, non vuole aggiungere nulla al server in modo che non mantenga l'accesso e non aggiunga alcuna backdoor, qualsiasi cosa ...

Scarica semplicemente il database e decide di non introdursi mai più in questo sistema. (o forse non rilevano mai l'intrusione, ma correggono il loro sistema e lui non può tornare indietro).

Ora se riesce a rompere l'hash o la tua password, può comunque impersonare te su questo sito. Considerando che se la tua password fosse più strong, forse non sarebbe in grado di farlo.

(Sì, lo so che sono passati 2 anni ma mi piacerebbe sapere se ho sbagliato o meno nella mia analisi).

Non dovresti mai fare affidamento sul server per fornire i mezzi per proteggere una password debole. Anche se il server mostra i captcha per impedire a un utente malintenzionato di forzare il brute, è necessario aspettarsi che l'autore dell'attacco sia abbastanza paziente e provare un altro giorno o un'altra ora. Il sito potrebbe anche utilizzare i cookie per verificare se l'autore dell'attacco è lo stesso che non ha valore (può eliminare il cookie). Il server può anche fare affidamento sull'IP: TOR per il salvataggio. Quello che stai proponendo con il tuo approccio unico e non rintracciabile alla fonte è la sicurezza per oscurità e questo approccio è ampiamente disprezzato nel settore sec. Le password non correlate sono buone da proteggere contro John The Ripper che indovina le tecniche, ma tu sei ancora vulnerabile alla forza bruta. Sto pensando alla perdita di celebrità di iCloud. Sono abbastanza sicuro che le password utilizzate dalle celebrità in cui i loro nomi di cani o date di nascita, ma anche con una password alfanumerica di 5 o 6 caratteri, non si aspettavano che Apple fosse così sciatta, senza meccanismi di blocco.

Parola di consiglio: password di grandi dimensioni + password manager = felicità