criptare password lato client

[rel_style]

Non conosco affatto JavaScript però credo che non posso farne a meno per quello che mi serve.

In pratica vorrei che nel momento in cui un utente scrive i campi user e password in un modulo form per il login, questi vangano inseriti in una 2 variabili anche in chiaro non c'è problema.

Poi ci penso io a prendere la variabile ed effettuare una cifratura. Mi sapete indicare se è possibile farlo?
Io credo di si ma non sono proprio come fare.

[fcaldera]

ma qual è lo scopo della cifratura lato client?

Potresti usare l'MD5

http://pajhome.org.uk/crypt/md5/md5src.html

però essendo un metodo one-way non c'è modo di decodificare la stringa cifrata nella stringa di partenza.

[rel_style]

Ciao fcaldera,
ti spigo brevemente quello che ho in mente riguardo l'autenticazione degli utenti. Praticamente quando l'utente scrive nei campi user e password i propri dati, subito dopo schiccia il tasto submit e invia in rete i dati, e fin qui ci siamo.

Ora (io uso PHP) quindi sul server questi parametri immessi li prendo con l'array globale POST, rispettivamente con:

• $_POST['user']
• $_POST['password']

In questi 2 array ci sono comunque i valori scritti in chiaro; anche se io faccio

• $user=md5($_POST['user']);
• $password=md5($_POST['password']);

l'avrò comunque fatto lato server e non mi serve. Perchè non mi serve?
Non mi serve perchè se si riescono ad intercettare i 2 array prima che arrivino sul server potrebbero essere tranquillamente decifrati permettendo di vedere chiaramente i 2 valori.

Se invece riesco a ottenere le 2 variabili lato client prima che questi schiaccia il submit, io ci applico una funzione personalizzata la quale mi permette di ottenere nei due array globali un valore che non è il reale valore che l'utente ha scritto quindi anche se vengono intercettati i 2 $_POST[] e decifrati vedranno 2 valori che non corrispondono ai reali valori di autenticazione.

Come è possibile che il server riesca a capire se i valori sono esatti?
Semplice, io conosco la funzione personalizzata che ho adottato per cifrare i 2 valori lato client applico la funzione inversa e faccio il normale confronto con i valori che il server conosce.

Faccio un esempio banalissimo per rendere più chiaro il concetto.
la password è uguale a 3
la funzione personalizzata è per esempio elevamento a potenza.
Prima che 3 venga inviato in rete applico la funzione personalizzata ottenendo così il 9. In rete viaggerà il numero 9 non il 3. Arriverà sul server il 9 ci applico la radice quadrata ottenendo la password reale senza che questi abbiamo viaggiato in rete. Ovviamente lo faccio a entrambi i campi.

Ecco perchè volevo capire se quello che scrive l'utente nei 2 campi di autenticazione può essere inserito in 2 varibili diverse prima di schiacciare il bottone SUBMIT.

Resto a disposizione per ulteriori chiarimenti.

[fcaldera]

Faccio un esempio banalissimo per rendere più chiaro il concetto.
la password è uguale a 3
la funzione personalizzata è per esempio elevamento a potenza.
Prima che 3 venga inviato in rete applico la funzione personalizzata ottenendo così il 9. In rete viaggerà il numero 9 non il 3. Arriverà sul server il 9 ci applico la radice quadrata

il che equivale a dire: nella pagina di login ci deve essere un algoritmo poi decrittabile (ovvero non one-way) lato server

Quindi, se un attaccante intercetta il dato e poi entra nella pagina di login in questione, è in grado di risalire al vero valore di login e password poichè l'algoritmo è lato client

A mio parere ti conviene evitare la crittazione lato client e ti suggerisco quest'altra via

1) invia la password in chiaro (ad es. 'pwd')
2) lato server leggi la password e appendi una stringa non banale ad es. 'n6gvb5x03'
3) codifichi in MD5 la stringa così ottenuta (ovvero n6gvb5x03_pwd' e il risultato diventa la password reale che salvi su DB

il meccanismo funziona perchè la password che tu salvi non è l'MD5 della password reale ma una concatenazione di stringhe e l'attaccante non conosce la stringa appesa lato server

[rel_style]

Effettivamente questo è quello che già ha fatto.
Ma pensavo che utlizzando nella pagina di login la protezione del codice html sarebbe più difficile stabile la funzione che inventiamo noi.

La coincidenza comnuque ha voluto che quello che mi hai spigato è proprio quello che ho fatto. Solo che io ho aggiunto un numero non una stringa.

Però è meglio la stringa.

[fcaldera]

Originariamente inviato da rel_style
Ma pensavo che utlizzando nella pagina di login la protezione del codice html sarebbe più difficile stabile la funzione che inventiamo noi.

E' qui che falla il ragionamento
se cripti lato client con una funzione reversibile chiunque può risalire alla password inviata dall'utente semplicemente guardando il codice sorgente della pagina di login

[rel_style]

Hai perfettamente ragione.
Ma il sorgente della pagina si può proteggere no?

Io volevo fare questo in aggiunta al metodo di autenticazione già realizzato come tu lo hai spiegato.

Ma sarebbe superfluo allora?

[fcaldera]

no il sorgente di una pagina non si può proteggere

e cmq come sistema non mi convince molto
con il tuo esempio di prima, se l'utente non ha js attivo e immette 3 come password, il server si aspetta di ricevere un dato risultato da un elevamento a potenza (ovvero 9)

A quel punto l'autenticazione fallisce.