Impedire l'algoritmo di hashing della password da sovraccaricare la CPU

2

In questi giorni gli algoritmi di hashing della password sono progettati per essere lenti. Mentre impedisce ai berretti neri di indovinare la password (almeno parzialmente), fornisce anche lavoro aggiuntivo per il server.

Posso immaginare che, se qualcuno volesse far funzionare il server estremamente lentamente, potrebbe semplicemente inviare molte richieste di log-in che porteranno a molti calcoli hash delle password, aumentando così drasticamente l'utilizzo della CPU.

Qual è la pratica comune per prevenire tali attacchi? E come si chiama?

    
posta Pijusn 28.07.2013 - 13:24
fonte

4 risposte

5

Il tuo metodo migliore per proteggersi da questo tipo di attacco è implementare una sorta di limite al numero di tentativi di accesso prima che l'account sia bloccato.

Puoi farlo in molti modi, che hanno i loro vantaggi e svantaggi. Come ogni cosa in sicurezza, devi bilanciare pro e contro.

Alcune possibili soluzioni:

Opzione A: numero limite di tentativi di accesso da un indirizzo IP. Tuttavia, gli indirizzi IP sono facilmente falsificati e alcuni strumenti bruteforcing possono cambiare l'IP tra ogni tentativo.

Opzione B: Blocca l'account dopo il numero X di tentativi di accesso non riusciti. Tuttavia, avresti bisogno di un modo per un utente legittimo di sbloccare il loro account.

Opzione C: usa un captcha. Ciò potrebbe essere fastidioso per gli utenti legittimi, ma renderà difficile per un sistema automatico tentare molti accessi.

OWASP ha maggiori dettagli sulla prevenzione di questo tipo di attacco.

    
risposta data 28.07.2013 - 14:36
fonte
3

Si chiama attacco di "fame di risorse", che si applica a qualsiasi situazione in cui il lavoro sulla parte della parte attaccata è maggiore del lavoro richiesto dall'aggressore.

L'hashing è in realtà molto 'economico' rispetto al tempo di esecuzione della ricerca del database per confermarlo.

Ci sono alcune attenuazioni che puoi applicare. Nel caso di un attacco, prima di tutto vuoi aumentare il "costo" per l'aspirante attaccante. I CAPTCHA possono aiutare in questo, ma hanno un impatto negativo sull'accessibilità in generale. Quindi l'opzione migliore è di averli "disattivati" e quindi attivarli in base a un trigger lato server.

Puoi limitare le richieste ma è facile andare in giro. È possibile ritardare e limitare globalmente l'elaborazione di ciascuna richiesta di accesso in modo che ogni IP possa emettere solo una richiesta di accesso alla volta e deve attendere prima che il server inizi ad elaborarlo. Se emettono un'altra richiesta prima che la richiesta sia completata, puoi scaricarla a basso costo. Ma questo ha il lato negativo che è più complesso da implementare e che potrebbe influenzare i client dietro un router NAT. Tutti gli altri sarebbero felici di aspettare un paio di secondi con un dialogo di tipo "please wait" - di nuovo aumenta il costo per l'attaccante in quanto richiedono più risorse da cui attaccare.

Se il tuo sistema può renderti consapevole di un attacco in tempo reale, puoi lavorare con i tuoi host per bloccare o limitare il traffico problematico (ad esempio da regioni che non fornisci o servi) in modo che gli attaccanti in pratica saturino le proprie rotte nei tuoi server o indirizza gli aggressori in vari sinkhole e honeypot.

In fin dei conti si tratta di essere esattamente come qualsiasi altro attacco di tipo Denial of Service distribuito, nel senso che si tratta di gestire il carico. In definitiva, se si tratta di un sistema basato su cloud, potresti voler semplicemente aumentare la capacità (anche se devi essere consapevole dei costi).

In definitiva, la risposta è leggere la sicurezza per comprendere l'intero paesaggio. Dai un'occhiata a Security.SE: se potessi avere un solo libro sulla sicurezza web, quale sarebbe? per i suggerimenti.

    
risposta data 28.07.2013 - 15:24
fonte
0

L'esecuzione dell'hash non è necessariamente lento. È invertire l'hash che è dolorosamente lento. (Questo è necessario solo se hai l'hash e hai bisogno di calcolare la password originale - qualcosa che le tue funzioni di accesso non devono fare).

L'attacco sarebbe chiamato Denial of Service (DoS). La difesa comune è iniziare a ignorare l'indirizzo IP dell'aggressore dopo troppi tentativi di accesso falliti.

    
risposta data 28.07.2013 - 14:36
fonte
0

Tieni traccia degli indirizzi IP e controlla i tentativi di accesso al minuto senza consentire ulteriori tentativi per un po 'oltre la soglia.

    
risposta data 28.07.2013 - 14:42
fonte

Leggi altre domande sui tag