Perché i siti web moderni insistono ancora sui requisiti archaic di username / password? [duplicare]

Nessuna ragione particolare. È arbitrario quanto "la tua password non può essere più lunga di 8 caratteri" . Sono programmatori o proprietari di prodotti che non sanno cosa stanno facendo.

Lì può essere un motivo legacy per questo, quando il sistema di autenticazione è collegato ad un sistema di credenziali che ha avuto alcune limitazioni per ragioni storiche (qualcosa come un'implementazione crypt() molto vecchia che salta tutta la password inserire dopo l'ottavo carattere come menzionato qui ), ma data la grande maggioranza delle applicazioni (web) è costruita sulla parte superiore del costume i sistemi di autenticazione e le credenziali sono memorizzati in database relazionali, questo non dovrebbe essere un problema al giorno d'oggi.

Fondamentalmente lo stesso motivo per cui l'iniezione SQL è ancora così comune - persone che non conoscono meglio la progettazione e la costruzione di sistemi.

Proprio come con SQL injection, ci sono eccezioni occasionali, nel caso di SQL injection semplici bug o strumenti legacy, nel caso di username / password compatibili con altri sistemi. Ma il 99,99% delle volte è semplicemente "non sapeva di meglio".

Un motivo per spingere per OpenId (login google o facebook), è quello di rendere un sistema semplice e facilmente comprensibile come predefinito che tutti conoscono.

Oltre alla ragione storica dello spazio su disco (sì, c'era un tempo in cui lo spazio su disco era importante!), c'è sempre il problema di codifica / escape. Quando si affrontano caratteri e spazi speciali, è necessario assicurarsi che siano debitamente fuoriusciti (per prevenire attacchi di iniezione) e codificati (per assicurarsi che la password funzioni effettivamente alla fine). Al giorno d'oggi, il supporto degli strumenti per questo è buono; le migliori pratiche sono conosciute e diffuse. Ai tempi, escludendo tutti i personaggi speciali rendeva la vita tremendamente più facile. Nota che "più facile" significa quasi sempre "meno sicuro" ...

Alla fine, ci sono due ragioni per tali restrizioni in una moderna applicazione:

1. L'app dipende da alcuni sistemi legacy con queste restrizioni.
2. Qualcuno ha scelto la "facile uscita".

Si riassume in: A qualcuno non importava abbastanza per la sicurezza. Perché altrimenti la banca continuerà a funzionare con i sistemi di banking online con password a 4 cifre (!) A lunghezza fissa?

Come le altre risposte dichiarate, motivo legacy.

La maggior parte dei framework web può sfuggire ora e gestirla.

Avevo un collaboratore che non sapeva nulla di istruzioni preparate e così ha codificato una regex javascript che avrebbe solo controllato alcuni caratteri illegali e si lamentava di ciò.

Quindi potrebbe anche essere la mancanza di conoscenza del programmatore ...

I limiti dei caratteri sono molto probabilmente perché è un modo più semplice per limitare l'iniezione SQL e la superficie di attacco XSS. La corretta escaping dovrebbe essere una soluzione più completa e la maggior parte dei framework moderni la supportano, ma dato che i dati possono essere elaborati da diversi sistemi scritti da diversi sviluppatori in diversi ambienti, è difficile garantire che tutto venga eseguito correttamente ogni volta e nessuno abbia mai commesso un errore o ha preso una scorciatoia. È molto più semplice ridurre il set di caratteri a un sottoinsieme sicuro e prevedibile quando possibile.

Con le password anche se non c'è molta giustificazione, dal momento che le password non dovrebbero mai essere memorizzate o visualizzate così come sono. L'unica ragione per cui riesco a limitare il set di caratteri è quella di gestire varie codifiche e bug che potrebbero verificarsi quando sviluppatori o browser non li gestiscono correttamente. All'interno del set di caratteri ASCII standard, non c'è assolutamente alcun motivo per non accettare alcuna stringa come password.

I was signing up for a website last night, and once again was greeted with the fact that my username cannot contain certain characters (including spaces)

Molti siti web usano i nomi utente come chiavi per cercare i record in un database, e tradizionalmente le chiavi non hanno spazi. Per quanto riguarda i personaggi speciali che possono essere una vasta gamma di motivi per cui sono esclusi. I proprietari del sito potrebbero semplicemente non desiderare che le persone abbiano chiamato $%@#$% come utente.

Passwords that are phrases have higher entropy and are harder to crack than simple letter/number substitution:

Questa è una prospettiva di pregiudizio dal tuo punto di vista, e tieni presente che le password non sono cracked ma i siti Web sono incrinati.

Le password di forma lunga basate su frasi rendono effettivamente più facile decrittografare un algoritmo di hashing, quindi una breve password contenente caratteri, caratteri e numeri superiori e inferiori. La ragione è che il linguaggio umano usa molte meno lettere dell'alfabeto per la maggior parte delle frasi. Ciò consente a un hacker di restringere l'ambito del proprio attacco a un hash. Se sanno che tutte le password sono 8 caratteri, ma contengono una gamma possibile di 255 caratteri diversi da quella che è una gamma enorme di possibili hash.

L'attacco più comune su un sito web non proviene da quel sito web . Viene dalla debolezza nel altro sito web. Se eseguo l'hacking nel sito ABC e ottengo un elenco di e-mail e password non trattate, posso utilizzare tale elenco per attaccare altri siti Web.

Prima che un hacker utilizzi il suo elenco su siti web popolari come Facebook, Twitter o Google. Puliranno quell'elenco attaccando i siti più piccoli per vedere quali idioti hanno riutilizzato le loro password. Una volta che hanno un elenco pulito, le probabilità sono che la persona abbia riutilizzato la password su un sito Web principale.

Spesso questi siti Web vengono attaccati senza che l'aggressore venga mai notato, perché hanno camminato correttamente usando un'autenticazione valida.

Quindi non riutilizzare mai la tua password. Usa sempre uno generato a caso e interrompi l'uso di frasi.

Use A Password Vault

Non penso che importi troppo - indipendentemente da cosa consentiamo all'utente finale - continueranno a utilizzare password come 123456 e password.