Combinazione di SCRYPT + un breve crc

Non dovresti scherzare con l'algoritmo come questo. Non riesco a pensare a quale sia l'impatto di questo metodo ma urla insicurezza. Per lo meno, permetterebbe a un aggressore di muoversi a circa 256 volte più velocemente dal momento che CRC è una funzione matematica relativamente semplice e quindi ovviamente più veloce nella parte del database. Sei un po 'di esercizi per la codifica della lavagna lontano da qualcuno che scarica tutte le tue password se ottengono l'accesso al DB.

Invece, emetti un token usando una funzione economica che è a tasso limitato per indirizzo client o prefisso indirizzo client e richiede quel token con nome utente e password. Ciò ti consentirà di valutare il limite della frequenza con cui esegui il costoso processo di verifica della password.

Ho svalutato la risposta di Jeff. Dal punto di vista dell'architettura, è meglio creare alcune funzioni indipendenti di gate keeping legate all'indirizzo del client e che vengono eseguite quando viene richiamato lo schermo di input del login del lato client. Mantenerlo separato dalle routine di autenticazione. Puoi limitare i tassi di prova o i tentativi massimi prima di contrassegnare l'account in qualche modo, e questo non richiede di andare in giro con il nucleo dell'autenticazione.

Le implementazioni crittografiche sono una funzione il collegamento più debole, e CRC non è nemmeno un vero primitivo della crittografia. È piuttosto male in questo senso. L'archiviazione dei checksum CRC crea problemi perché consente a un utente malintenzionato che ottiene il database di utilizzare un processo facilmente parallelo per ridurre il lavoro di attacco a ciascuna password nel database. Mettere il CRC della frase di sale + pass proprio lì con gli hash scrypt finali funziona per un attaccante come una sorta di setaccio. L'utente malintenzionato può eseguire una routine veloce che inizia uno sforzo di forza bruta senza altri oggetti, ma per trovare stringhe che checksum al CRC memorizzato. Solo le stringhe che superano questo passaggio di setaccio devono eseguire il guanto di sfida attraverso l'hashing dello scrypt computing e della memoria intensiva. È ancora più veloce se l'utente malintenzionato esegue dizionari.