attacchi brutal force e csrf

[Luca Diver]

Ciao,

ho letto che per prevenire attacchi di tipo brutal force, il login utente dovrebbe prevedere il rallentamento volontario della procedura stessa di registrazione e che esistono sistemi di crittografia che già prevedono questa accortezza (tipo il blowfish).

In pratica io cosa devo fare: limitarmi ad usare questo tipo di sistema crittografico o rallentare io stesso il processo di login? (magari con uno sleep() messo da qualche parte)

Altra domanda, per favore.

Per prevenire attacchi di tipo CSRF durante un login, bisognerebbe creare un token casuale, inviarlo all’utente e ricontrollarlo quando l’utente stesso lo invierà insieme a username e password o altri dati richiesti. Il token dovrebbe essere uguale.

Ma un utente malintenzionato non potrebbe prendere questo token (che è inviato in chiaro) e usarlo nel suo tentativo di CSRF per spacciarsi per un “utente vero”?

Non potrei gestire questa situazione creando una variabile di sessione nella pagina login e ricontrollarla nelle varie pagine successive?
Grazie.

[Alhazred]

Ciao,

ho letto che per prevenire attacchi di tipo brutal force, il login utente dovrebbe prevedere il rallentamento volontario della procedura stessa di registrazione e che esistono sistemi di crittografia che già prevedono questa accortezza (tipo il blowfish).
In pratica io cosa devo fare: limitarmi ad usare questo tipo di sistema crittografico o rallentare io stesso il processo di login? (magari con uno sleep() messo da qualche parte)

Qui un'idea di come si evitano tentativi continui.

Per prevenire attacchi di tipo CSRF durante un login, bisognerebbe creare un token casuale, inviarlo all’utente e ricontrollarlo quando l’utente stesso lo invierà insieme a username e password o altri dati richiesti. Il token dovrebbe essere uguale.

Ma un utente malintenzionato non potrebbe prendere questo token (che è inviato in chiaro) e usarlo nel suo tentativo di CSRF per spacciarsi per un “utente vero”?

Se usi una connessione SSL, cosa ormai d'obbligo, i dati non viaggiano in chiaro.

[phelps]

Ciao,

ho letto che per prevenire attacchi di tipo brutal force, il login utente dovrebbe prevedere il rallentamento volontario della procedura stessa di registrazione e che esistono sistemi di crittografia che già prevedono questa accortezza (tipo il blowfish).

In pratica io cosa devo fare: limitarmi ad usare questo tipo di sistema crittografico o rallentare io stesso il processo di login? (magari con uno sleep() messo da qualche parte)

Altra domanda, per favore.

Per prevenire attacchi di tipo CSRF durante un login, bisognerebbe creare un token casuale, inviarlo all’utente e ricontrollarlo quando l’utente stesso lo invierà insieme a username e password o altri dati richiesti. Il token dovrebbe essere uguale.

Ma un utente malintenzionato non potrebbe prendere questo token (che è inviato in chiaro) e usarlo nel suo tentativo di CSRF per spacciarsi per un “utente vero”?

Non potrei gestire questa situazione creando una variabile di sessione nella pagina login e ricontrollarla nelle varie pagine successive?
Grazie.

Nella pagina di login alla variabile $token fai generare un esadecimale tipo = $token = bin2hex(random_bytes(32)); poi lo metti in sessione.
Nel frattempo metti questa variabile $token nel value di in un input nascosto del form.
nella stessa pagina del form potresti fare il controllo POST sui vari campi inviati dal form.. Poi potresti passare i parametri ad un metodo tipo veryUser($username,$password,$token)..In questo metodo fai i controlli sulla mail sulla password e se il token che passi nella funzione è uguale al token che avevi messo in sessione nalla pagina form login.
Se questo metodo ritorna true allora potresti potresti per esempio passare il campo mail validato ad un'ulteriore metodo che lo chiami per esempio findUserByusername($username). Questo metodo non fà altro che fare una query per username dell'username passato.
Se questo ritorna true allora si potresti usare un'lteriore controllo password_verify($password, $user->password) che controlla se la password hash che è nel database è uguale alla password passata nel form via post. Se ritorna true allora fai unset($user->password) e ti instanzi per esempio un metodo $session->login($user) che per esempio in una classe session mette in sessione i dati dell'utente e ritona true.
Ovviamente ho ragionato per oggetti e il metodo è descrittivo però rende l'idea. Cosi sei al sicuro con il csrf.
Per quanto riguarda il brute attack anche io sto studiando come fare

[LucianoS]

nel form, tra i valori da inviare via POST, potrebbe bastare anche un md5/sha1 del session_id() come campo hidden

[Luca Diver]

Grazie a tutti.
E'' possibile sapere quante richieste sono arrivate al server, in un dato lasso di tempo, ad una data pagina del nostro sito?

[Alhazred]

Grazie a tutti.
E'' possibile sapere quante richieste sono arrivate al server, in un dato lasso di tempo, ad una data pagina del nostro sito?

Sì, ma devi mettere su un sistama di log, oppure usare Google Analytics o simili.
I secondi però, per il GDPR, devono essere attivati solo se l'utente acconsente ai cookie di terze parti, quindi potrebbero non dare risultati veritieri, ma una sottostima del traffico.

[Luca Diver]

Riformulo la domanda: è possibile richiedere al server il numero di richieste ricevute, da una data pagina, in un dato lasso di tempo?
Solo il numero di richieste, senza IP o altro.

Vorrei fare far a loro, che hanno mezzi e spazio, il lavoro di tracciamento.
Grazie.