Posso rallentare un attacco di forza bruta codificando i dati di input della password?

Question

Posso rallentare un attacco di forza bruta codificando i dati di input della password?

#1 da (6 voti)
#2 da (4 voti)
#3 da (1 voti)

3

Sto costruendo un modulo di accesso php con solo username & password come $ _POST dati. Ma prima di inviare il modulo, una funzione JS check() baserà64_encode sull'input password , quindi alla fine sottoporrà il modulo in questo modo: (la funzione base64_enc personalizzata è un po 'più avanzata rispetto a una codifica base64)

function check() {
   var pwd = $_get_by_id('loginPw').value;
   $_get_by_id('loginPw').value = base64_enc(pwd);
   $_get_by_id('loginFrm').submit();
}

Ovviamente, oltre a ciò, so che abbiamo un sacco di cose di sicurezza per prevenire la forza bruta (id di sessione, token csrf, captcha, divieto di tempo ...).

Ma mi chiedo se, a questo punto, questo semplice trucco javascript potrebbe rallentare un attacco? (Anche l'autore dell'attacco deve generare un'altra versione elaborata dei suoi dizionari)

Ad esempio se hydra tool può elaborare ogni riga di wordlist prima di eseguire un thread (con una versione del codice shell di ciò che abbiamo nel controllo javascript () fn)

cryptography brute-force hydra

posta The-Vinh VO 21.04.2017 - 19:37

fonte

3 risposte

4

No, questa idea non rallenta l'aggressore, perché la password codificata è la password-- è il valore che un client HTTP deve accedere al sistema. La password originale è quasi casuale a quel punto. Invece, l'hacker rivolgerà la sua attenzione per iterare attraverso le stringhe Base64 invece delle password, e l'entropia totale sarà esattamente la stessa. Inoltre, se l'hacker ha un dizionario di password, è banale generare un dizionario di stringhe Base64 comprendente la stessa lista esatta.

Tuttavia, non è una pessima idea rallentare un aggressore chiedendogli di risolvere un problema complesso. CAPTCHA è l'esempio più comune: gli strumenti degli hacker possono capire come risolvere un CAPTCHA, ma richiede un po 'di CPU e ridurrà il numero di tentativi di forza bruta al secondo. La risoluzione di qualsiasi problema complesso farebbe lo stesso, ad es. se oltre a inviare la password, lo script doveva anche indovinare il valore di un hash (basato su un valore casuale e non correlato) fornito dal server. Ma vorresti mantenere questo meccanismo completamente separato dalla password.

risposta data 21.04.2017 - 20:20

fonte

1

Non cambierà nulla all'attaccante. Non avrà nemmeno bisogno di aggiornare i suoi dizionari.

L'attacco genera password e le invia a una funzione che eseguirà la richiesta HTTP. L'utente malintenzionato deve selezionare l'URL target, denominare i parametri. La codifica della password in quella funzione non è lenta. Sono ordini di grandezza più veloci della richiesta HTTP e l'impatto sulla dimensione della richiesta sarà così piccolo da non avere alcun effetto.

risposta data 21.04.2017 - 19:47

fonte

Leggi altre domande sui tag cryptography brute-force hydra

Come decodificare questo carico utile dell'hacker? Quali attacchi sono possibili se riesci a racimolare un elenco di utenti?

score 6 · Accepted Answer

Can I slow down a brute force attack by encoding password input data?

Sì, puoi rallentare artificialmente un attacco a forza bruta facendo eseguire al client un'attività costosa per ogni tentativo di accesso. Questo concetto è chiamato prova di lavoro . È un approccio ben noto per combattere lo spam di massa e tecnicamente potresti anche applicarlo ai sistemi di autenticazione sul web.

Tuttavia , la tua proposta concreta non si qualificherebbe come protocollo di prova di lavoro. Questo perché base64 non è affatto costoso e richiede una quantità di lavoro uguale per il client da generare come per il server da verificare. Inoltre, un utente malintenzionato può riutilizzare le password codificate tutte le volte che vogliono senza doverle ricalcolare, ad es. per attaccare altri account.

Per un'implementazione real-of-work, potresti ad es. costruisci uno schema challenge-response e chiedi all'utente di eseguire costosi calcoli hash su ogni tentativo di accesso. La sfida potrebbe essere di invertire parzialmente un hash: fornisci una sequenza casuale e sfidi l'utente a generare un hash SHA-256 che termina con quella stessa sequenza. Aumentare la lunghezza della sequenza richiede esponenzialmente più calcoli hash da parte del client ma verificare i risultati è sempre solo un confronto tra stringhe.

Il progetto "proof-of-work-login" è uno dei pochi in realtà esempi che ho trovato che riprendono l'idea di usare un POW per i login. (Non posso comunque commentare la qualità dell'implementazione). Dalla descrizione:

A client side SHA256 hash must be calculated before allowing a login. This limits bruteforce login attacks in environments where you can't ban by IP like Hidden Services.

Tuttavia, dovresti tenere a mente che per le applicazioni web esistono strumenti più semplici per bloccare gli attacchi a forza bruta come i CAPTCHA, limitando i tentativi di accesso per account, gli indirizzi in blacklist, ecc.