Nascondere password

[GordonFreeman]

Ciao,

in una mia pagina web c'è un form per il login, con metodo di invio POST.
prima del submit cripto la password in SHA1, da una funzione javascript che cattura l'evento OnSubmit

 <script type="text/javascript" src="/sha1.js" ></script>

 <script language="Javascript">
 
  function OnSubmit(){	  
	  var pwd = document.getElementsByName("password");
                  // SHA1 è una funzione definita nello script incluso
	  pwd[0].value = SHA1(pwd[0].value);	  
  }
 
 </script>

<form method="post" enctype="multipart/form-data" onsubmit="OnSubmit()">

 <div>Username:</div>
 <input type="text" name="username" />
 <div>Password:</div>
 <input type="password" name="password"  />
 
 <input type="submit" />

</form>

quindi dal form non viene inviata la pwd in chiaro ma l'hashing SHA1.

E lato server, controllo che questo hashing sia lo stesso di quello nel database (che contiene anch'esso solo gli SHA1 delle pwd).

Supponiamo che , all'invio della password dal form, un man-in-the-middle intercetti lo username , e l'hashing della password, ovvero faccia spoofing.

A questo punto lui può autenticarsi al mio sito senza sapere quale sia la pwd in chiaro, ma avendo solo lo SHA1.

Per farlo basta caricare la pagina di login in modo che nelle variabili POST della richiesta HTTP, ci siano il nome utente e lo SHA1 letti con lo spoofing.

Un modo per farlo (ma non l'unico) :

1) avere Firefox con l'estensione Tamper Data
2) visitare la pagina col form, inserire il nome utente letto con lo spoofing, e una password totalmente a caso
3) cliccare il pulsante di submit del form
4) con tamper data, modificare la password nelle variabili post, sostituendo l'hashing della pwd casuale con l'hashing intercettato con lo spoofing
5) inviare i dati al server

et voilà, l'attaccante è loggato.

Come si fa ad evitare questo?


Forse bisogna usare il protocollo HTTPS? Sono ignorante in materia, ma da quanto ne so bisogna registrarsi ad una certificate authority per creare una firma digitale, e sborsare un sacco di quattrini.
Ci sono soluzioni efficaci ma più economiche ?

[morskott]

mo non vorrei scrivere cavolate, ma se invece del solo hash della pass gli mandi una coppia <t,hash(t|hash(pass)|t)> (dove "|" è concatenazione) e il server sapendo t dal client e hash(pass) dal db calcola pure lui hash(t|hash(pass)|t)? (con t numero random)

[fero86]

studiati come funziona l'autenticazione in HTTP 1.1, pur non essendo basata su crittografia asimmetrica é ugualmente molto sicura (previene anche i replay attacks usando un cosiddetto NONCE, un numeraccio random diverso ogni volta).

per quanto riguarda il certificato, a parte il fatto che credo che sia anche possibile per te autocertificarti ed essere tu stesso la tua CA (chiaramente nessuno ti conosce, quindi gli utenti verrebbero ugualmente messi in guardia da qualunque browser), ma a parte questo esiste una CA gratuita, cacert.org

edit - qua c'é il sito: http://www.cacert.org/

[fero86]

ricordavo di aver avuto necessitá in passato per un progetto universitario in Java di realizzare una procedura di autenticazione sicura analoga a quella di HTTP 1.1, ho ripreso poco fa il progetto e mi sono riletto la relazione; la procedura si svolge come segue:

1. il client invia al server una richiesta di autenticazione;
2. il server risponde generando un numeraccio random da inviare al client (si chiama valore di challenge);
3. il client risponde al valore di challenge inviando a sua volta le seguenti informazioni:
__3a. lo stesso valore di challenge cosi com'é;
__3b. lo username in chiaro;
__3c. l'hash SHA-256 della stringa risultante dalla concatenazione del valore di challenge, dello username e della password;
4. il server legge il valore di challenge inviato dal client in chiaro (3a); se non corrisponde al valore inizialmente inviato dal server l'autenticazione fallisce;
5. il server legge lo username inviato in chiaro dal client (3b) e se nel suo database locale non trova alcun utente con quello username l'autenticazione fallisce;
6. il server legge l'hash inviato dal client (3c) e lo ricalcola in locale utilizzando le informazioni che ha a disposizione: il valore di challenge ce l'ha, lo username ce l'ha perché il client gliel'ha inviato in chiaro e la password ce l'ha nel database; se i due hash non corrispondo l'autenticazione fallisce.

questo sistema impedisce i replay attacks, peró comporta che il server debba memorizzare la password in chiaro.

[GordonFreeman]

Originariamente inviato da fero86

ricordavo di aver avuto necessitá in passato per un progetto universitario in Java di realizzare una procedura di autenticazione sicura analoga a quella di HTTP 1.1, ho ripreso poco fa il progetto e mi sono riletto la relazione; la procedura si svolge come segue:

1. il client invia al server una richiesta di autenticazione;
2. il server risponde generando un numeraccio random da inviare al client (si chiama valore di challenge);
3. il client risponde al valore di challenge inviando a sua volta le seguenti informazioni:
__3a. lo stesso valore di challenge cosi com'é;
__3b. lo username in chiaro;
__3c. l'hash SHA-256 della stringa risultante dalla concatenazione del valore di challenge, dello username e della password;
4. il server legge il valore di challenge inviato dal client in chiaro (3a); se non corrisponde al valore inizialmente inviato dal server l'autenticazione fallisce;
5. il server legge lo username inviato in chiaro dal client (3b) e se nel suo database locale non trova alcun utente con quello username l'autenticazione fallisce;
6. il server legge l'hash inviato dal client (3c) e lo ricalcola in locale utilizzando le informazioni che ha a disposizione: il valore di challenge ce l'ha, lo username ce l'ha perché il client gliel'ha inviato in chiaro e la password ce l'ha nel database; se i due hash non corrispondo l'autenticazione fallisce.

questo sistema impedisce i replay attacks, peró comporta che il server debba memorizzare la password in chiaro.

già è vero, funziona, complimenti
ma la soluzione di morskott ha gli stessi risultati e risparmi un passaggio, ovvero il token può inviarlo il client e basta, no?

comunque ho capito, il tutto si basa sul fatto che l'hashing non è una funzione invertibile, quindi ..

se uno sa qual'è t , e sa che R è il risultato di SHA1(t | SHA1(pass) | t)

non può direttamente calcolare l'inversa di SHA1, cioè SHA1^-1(R) ,
per trovare "t | SHA1(pass) | t" (e quindi , immediatamente, SHA1(pass) )

perchè SHA1^-1 non esiste, quindi deve calcolare tutti i valori SHA1(n) per ogni n e fermarsi quando SHA1(n) = R, ma credo ci metterebbe potenzialmente dei secoli

bene la crittografia mi affascina
mi dispiace non aver scelto quell'esame fra i facoltativi

[GordonFreeman]

Originariamente inviato da morskott

mo non vorrei scrivere cavolate, ma se invece del solo hash della pass gli mandi una coppia <t,hash(t|hash(pass)|t)> (dove "|" è concatenazione) e il server sapendo t dal client e hash(pass) dal db calcola pure lui hash(t|hash(pass)|t)? (con t numero random)

come ho detto sopra, credo tu abbia ragione

però ora supponiamo che un man-in-the-middle

1) intercetti la richiesta iniziale della pagina, da parte del client al server
2) modifichi la risposta del server, in modo che la pagina di login che arriva al client sia uguale a quella originale, ma che non faccia l'hash della password prima del submit del form, cosicchè la password viaggerà in chiaro
3) intercetti la submit del client, e quindi la pwd in chiaro

come la mettiamo?

beh lo so che il passaggio 2 sarebbe ostico, ma credo proprio che sia possibile, da quanto ho letto in giro (non so i dettagli su come si faccia)

[fero86]

il sistema di autenticazione di HTTP 1.1 ti difende dagli intercettatori passivi, ma tu stai parlando di intercettatori attivi, e per quelli ci vuole HTTPS (per evitare lo specifico attacco che descrivi i pacchetti inviati devono essere corredati di hash firmato).

[morskott]

Originariamente inviato da GordonFreeman

come ho detto sopra, credo tu abbia ragione

però ora supponiamo che un man-in-the-middle

1) intercetti la richiesta iniziale della pagina, da parte del client al server
2) modifichi la risposta del server, in modo che la pagina di login che arriva al client sia uguale a quella originale, ma che non faccia l'hash della password prima del submit del form, cosicchè la password viaggerà in chiaro
3) intercetti la submit del client, e quindi la pwd in chiaro

come la mettiamo?

beh lo so che il passaggio 2 sarebbe ostico, ma credo proprio che sia possibile, da quanto ho letto in giro (non so i dettagli su come si faccia)

In questo caso mi pare che non puoi garantire sicurezza in nessun caso, serve SSL per garantire al client di star parlando effettivamente al server a cui crede di parlare.

Una puzzonata ma proprio brutta sarebbe far decidere al client prima del logout una frase o qualcosa da poter rileggere quando effettua un login successivo, ma si deve garantire che solo il client e il server vero ne siano a conoscenza, e che il client se la ricordi!!! E maggiormente che il client faccia il logout senza chiudere direttamente il browser ed è un algoritmo (oltre che non inteligentissimo) user-aware (cioè mentre prima l'utente non sa niente sull'autenticazione adesso è a conoscenza del fatto (può sembrare inutile, ma peggiora l'usabilità)).

[GordonFreeman]

Originariamente inviato da fero86

il sistema di autenticazione di HTTP 1.1 ti difende dagli intercettatori passivi, ma tu stai parlando di intercettatori attivi, e per quelli ci vuole HTTPS (per evitare lo specifico attacco che descrivi i pacchetti inviati devono essere corredati di hash firmato).

ok grazie allora mi studierò un po' HTTPS, o almeno l'autenticazione di HTTP 1.1.

solo una cosa: ma se il client ti manda un valore di challenge, come fai a sapere se è corretto?
in teoria dovresti memorizzarti nel database delle coppie (IP,challenge), ciascuna delle quali create alla richiesta della pagina di login, e con "IP" che sia chiave primaria.

ogni coppia la dovresti cancellare dopo un certo tempo di timeout, altrimenti il db si riempie.

questo tipo di approccio però ha qualche inconveniente:

1) il malintenzionato potrebbe avere lo stesso IP dell'utente, magari perchè si trova nella stessa NAT o perchè ha fatto IP spoofing (cambia l'ip dei pacchetti prima di inviarli)

2) se uno fa IP spoofing come dicevo sopra, potrebbero mandarti continuamente delle richieste di caricamento pagina da tanti IP diversi, ma senza nessun login effettuato, e il tuo db si riempie.
insomma avresti un bel DOS tramite flood.