In base al link nginx può leggere gli hash delle password di questi tipi:
crypt (), apr1, SHA1 e amp; SSHA.
Ecco come ho capito come funzionano questi hash e qual è il loro problema:
crypt () scarta tutto dopo il 8. carattere, quindi se la mia password è "12345678UltraSecurePa $$ w0rd" posso accedere con successo digitando "12345678". Non è questo che sconfigge lo scopo di una password lunga (lunga)? Forza brutale attraverso 8 qualsiasi password di carattere sembra essere banale in questi giorni. Non capisco perché la cripta dovrebbe essere più sicura del testo semplice.
apr1 è MD5 ma è rallentato di mille volte . Che è ancora molto debole in questi giorni. Si può trovare rapporti di forzatura bruta tramite > 300.000.000.000 (300 miliardi) hash al secondo con un paio di GPU .
SHA1 non è molto meglio di MD5, è un algoritmo di hashing ottimizzato per essere veloce e quindi vulnerabile agli attacchi di forza bruta. Inoltre non è salato in questo caso.
E l'ultimo metodo è salato SHA1. Questo sembra essere il metodo meno debole per hashing password di autenticazione di base http in nginx. Ma quando qualcuno ruba l'hash, ha anche il sale (il sale è solo codificato in base64), quindi SSHA ha ancora la debolezza di usare algoritmi di hashing veloci per "crittografare" le password.
nginx non può usare bcrypt o PBKDF2.
Per concludere: se voglio che i miei hash auth di base HTTP siano "sicuri" (sicuro significa che è troppo dispendioso il tempo per rompere gli hash) Devo seguire queste regole:
- non utilizzare mai crypt.
- applica le password con almeno 16 caratteri perché questo sembra essere abbastanza lungo contro gli attacchi di forza bruta (ignoriamo solo gli attacchi del dizionario qui per un momento).
E: convincere i ragazzi di nginx che dovrebbero implementare migliori metodi di hashing per l'autenticazione di base HTTP.
C'è un errore nella mia conclusione?