sicurezza invio e ricezione dati sensibili web

[cipcip]

salve,
volevo sapere se un sistema che consenta di inviare dati al server per mezzo di una chiave di criptazione puo' garantire la sicurezza dei dati al pari di un certificato ssl.
Mi spiego meglio:

Un sito web fornisce all'utente un algoritmo di criptazione passandoglielo in chiaro e poi lui invia i suoi dati sensibili: carta di credito password ecc...,al server (sito web ) trasformati in base a questo algoritmo.

In questo modo i dati dell'utente viaggino criptati, il mio dubbio deriva dal fatto che l'algoritmo di criptazione viene fornito all'utente senza un certificato ssl quindi in chiaro.

Ha senso una cosa del genere?

Ovvero criptare le informazioni inviate dal client e quelle inviate dal server eccetto che per il momento dell'ivio dell'algoritmo di criptazione?

Esempio banale:

L'utente richiede la pagina di login -> il server serve la pagina di login all'utente con una chiave di criptazione in forma di javascript.
L'utente inserisce la sua password e clicca su accedi -> il javascript si occupa di modificare i dati inseriti in base all'algoritmo di criptazione quindi la password cosi modifica viene inviata al server, che quindi si occupera di decriptarla e fare quello che deve fare


grazie

[Habanero]

ogni algoritmo di crypting necessita di una chiave... non puoi certo passargliela in chiaro!

Non capisco a cosa ti serve tutto questo. HTTPS funziona più che bene ed include tutto quello che serve, compreso lo scambio delle chiavi.

[mark2x]

Qui c'è un articolo che - credo, da quello che ho capito - potrà chiarificarti qualcosa in merito (spero).
L'articolo è mio, in caso di ogni dubbio chiedi pure.

http://php.html.it/articoli/leggi/22...in-ajax-e-php/

[cipcip]

salve il tuo articolo è esattamente quello che faccio io, il problema pero' rimane e cioe' che quello che tu invi al client per mistificare la password viaggia in chiaro, e quindi la mia domanda rimane e cioe:

è sufficiente che le informazioni vengono criptografate a salire sul web con un algoritmo scambiato in chiaro, oppure, poiche' l'algoritmo che il server ti fornisce potrebbe essere intercettato, manda a farsi fottere la sicrezza?

[mark2x]

Cosa intendi per algoritmo scambiato in chiaro? Nessuno scambia algoritmi, ma solo stringhe di "sfida".
L'algoritmo è sempre noto ad entrambe le parti, e questo avviene anche con l'SSL.

Se per algoritmo intendi stringa di sfida, fin tanto che la stringa è lunga e casuale e la password forte, questo tipo di algoritmo è sicuro.
Tuttavia non lo sarà mai quanto una connessione SSL con certificati sia di client che di server, per il semplice fatto che codice ed algoritmi sono stati fatti da geni matematici ed informatici e testati a lungo.

[Habanero]

ora mi è più chiaro quello che vuoi ottenere....

Quello che invii in risposta contiene la password, un segreto che non passa in chiaro.
Attenzione che l'hashing non è un algoritmo di cripting reversibile.

-->challenge: sfida in chiaro inviato dal server
<--response: funzione non reversibile di (challenge+passwordsegreta)

-la conoscenza dell'algoritmo di hashing non reversibile non ti consente di ottenere la password, nemmeno se conosci il respettivo challenge.
-se cerco di forzare una autenticazione otterrò dal server un challenge differente e senza conoscere la password non potrò fornire la risposta corretta.

[mark2x]

Originariamente inviato da Habanero
-se cerco di forzare una autenticazione otterrò dal server un challenge differente e senza conoscere la password non potrò fornire la risposta corretta.

Esattamente: l'unico attacco possibile è di tipo brute force, in cui però gioca un ruolo sfavorevole la possibilità di collisioni dell'MD5.

[cipcip]

allora ti spiego: io faccio cosi


distinguo tre tipologie di dati

1. dati free
2. dati sensibili
3. dati personali

1)i dati free viaggiano senza nerssuna accortezza

2)i dati sensibili viaggiano in questo modo:

invio il salt o sfida come lo chiami tu all'utente + un algoritmo di criptazione casuale a volte md5 a volte shs1 ecc..,
l’utente mi restituiesce criptato(scramble(salt+ criptato(campo)))

il server decodifica la stringa in questo modo:

esegue la decriptazione
descrambla la stringa
elimina il salt
esegue la decriptazione del campo

3) i dati personali viaggiano in questo modo:

l’utente mi restituisce hash(criptato(campo))

il server decodifica la stringa in questo modo:

nel database per ogni dato personale per esempio password ho memorizzato un salt
e l’hash( salt+md5( del dato personale)).

Quindi se l’hash(hash(md5(inviatomi)) + salt) = hash( salt+md5( del dato personale)) memorizzato nel db allora il dato inviatomi è valido

Quando l'utente disabilita il javascript un messaggio l oavvisa che cio che invierà non sarà criptato.

Quindi la mia domanda rimane sempre quella : puo' considerarsi questo meccanismo valido al pari di un ssl, se è carente, in che cosa è carente?

[mark2x]

Allora, il mio metodo va bene per CONFRONTARE password, non per scambiarsi dati (ho capito ora che vuoi anche scambiarti i dati codificati in questo medesimo modo).
MD5 o SHA1 NON sono algoritmi di cifratura, ma di firma e non sono reversibili: dato questo:

criptato(scramble(salt+ criptato(campo))),

questo:

esegue la decriptazione
descrambla la stringa
elimina il salt
esegue la decriptazione del campo

NON lo puoi fare SE "criptato" vuol dire "aver usato MD5 o SHA1"

Semmai (ciò che avevo capito), puoi, una volta verificata la fonte (con uno scambio di password come detto), codificare i dati con un algoritmo a chiave privata. Ovvero "criptato" = "aver usato un algoritmo a chiave privata".

Ma questo alla fine lo fa anche l'SSL.....

[mark2x]

Conclusione: usa l'SSL, che fa tutto ciò che vuoi tu con meno fatica, meglio e prima.