Quanto è difficile rompere la porzione di sale dell'hash

Question

Quanto è difficile rompere la porzione di sale dell'hash

#1 da (3 voti)

0

Scrivo un'applicazione mobile e ho bisogno di autenticare gli utenti contro il server. Il lato del server è scritto in PHP. Non posso usare i cookie per memorizzare SID (Session ID), quindi ho deciso di inviarlo ad ogni richiesta usando il metodo GET.

In seguito, ho deciso che l'invio dello stesso SID ogni volta non è abbastanza sicuro, quindi ho deciso di utilizzare una nuova stringa ad ogni richiesta. Server e Client mobile hanno memorizzato la stessa stringa casuale (chiamiamola salt ). Alla fine di ogni richiesta, il server invia una stringa casuale al client mobile e alla richiesta successiva, il client mobile invia al server la versione con hash di salt + stringa casuale . Il server crea l'hash da salt + stringa casuale e lo confronta con quello ricevuto dal client mobile per autorizzarlo.

Ora la mia domanda è:

Se ci sarebbe un attacco man-in-the-middle, quanto sarebbe difficile spezzare l'hash e trovare la porzione salata di hash?
Come potrei renderlo più difficile? (ad esempio, non utilizzando la formula salt + stringa casuale , ma salt_1st_half + stringa casuale + salt_2nd_half o stringa di hashing più volte in base alla lunghezza del nome utente o di altri "trucchi")

PS: ho intenzione di utilizzare la funzione crypt di php con l'algoritmo blowfish sul server

Modifica

I decided that sending the same SID everytime is not secure enough

Perché? Perché trasferirò alcuni dati utente sensibili (posizione effettiva, ..), e chiunque vorrebbe catturare SID potrebbe cambiare questi dati, o usare il SID corrente per fingere di essere qualcun altro e potrebbe ottenere altri dati sensibili dall'applicazione (e non sarebbe Non ci sono errori di bug o di applicazione, perché un utente regolare con quel SID avrebbe accesso a questi dati). Questo è il motivo per cui ho deciso di cambiare SID dopo ogni richiesta e aggiungere alcuni calcoli e la convalida di SID.

password-cracking blowfish

posta Buksy 17.09.2013 - 23:02

fonte

1 risposta

Leggi altre domande sui tag password-cracking blowfish

Cosa significa "Hash of a malware"? Quali sono i motivi per cui questo codice di iniezione SQL non funziona? [duplicare]

score 3 · Accepted Answer

Se la tua "stringa casuale" è in realtà una "stringa casuale", allora nessuno dei tuoi trucchi può fare qualcosa di buono. Del resto, il sale non migliorerà le cose. Né l'uso di bcrypt (ciò che PHP chiama "crypt with Blowfish").

In effetti, tutti i giochi con sali e iterazioni sono solo modi per far fronte alla debolezza intrinseca delle password . Le password sono deboli. Non possono aiutare a essere deboli: si adattano a una mente umana. Quindi, fintanto che gli utenti umani sono, per esempio, umani , dobbiamo occuparci delle password, e dato che le password possono essere (per la maggior parte degli utenti umani) forzate, dobbiamo applicare "trucchi" che rendono l'attacco Più strong. I due trucchi principali sono la lentezza (rendendo la funzione hash intrinsecamente costosa attraverso molte iterazioni) e i sali (per prevenire attacchi paralleli e precomputazioni). Ho scritto molto sull'argomento lì .

Tuttavia, se si hanno stringhe casuali tra un computer e un altro computer (gli smartphone sono computer), quindi nessun essere umano, quindi nessun problema. Un arto sufficientemente lungo e sufficientemente casuale sconfigge la forza bruta per la sua pura casualità. Sali e lentezza non portano alcuna sicurezza aggiuntiva: non può essere forza bruta, punto.

(Oppure, detto altrimenti, se la tua stringa casuale può essere bruta forzata, allora lo stai facendo molto male.)

Tutto si riduce a questa tua frase:

Later on, I decided that sending the same SID everytime is not secure enough

Perché?

Semplicemente, perché? Perché non dovrebbe essere "abbastanza sicuro"?

Potrebbero esserci ragioni buone e razionali. Ma non puoi fare nulla di valore, nel campo della sicurezza, se non ti prendi il tempo per pensare a i tuoi requisiti . Definisci la tua sicurezza: i tuoi obiettivi, gli obiettivi dell'attaccante, i poteri dell'attaccante, le risorse in gioco ...

In ogni caso, se le comunicazioni tra l'applicazione e il server richiedono qualsiasi tipo di riservatezza, integrità o autenticità (suppongo che questo sia il caso, dal momento che ti occupi dell'autenticazione), non c'è modo di sfuggire: usa SSL (noto anche come "HTTPS"). Nessun SSL, nessuna sicurezza reale. Ma con SSL, le cose vanno bene. Puoi inviare la tua "stringa casuale" (che in realtà è un cookie di sessione personalizzato) così com'è, non verrà intercettata da terze parti, attiva o passiva.