Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20081 > unrolled thread

Evitare di inviare via POST i dati di login in chiaro

Back to article view | Back to it.comp.www.php

Contents

  Evitare di inviare via POST i dati di login in chiaro Marco Solinas <marcosol@tiscali.it> - 2015-11-23 12:41 -0800
    Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-23 13:10 -0800
    Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-23 13:12 -0800
    Re: Evitare di inviare via POST i dati di login in chiaro Alessandro Pellizzari <shuriken@amiran.it> - 2015-11-23 21:55 +0000
      Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 02:18 -0800
    Re: Evitare di inviare via POST i dati di login in chiaro Leonardo Serni <lserni@gmail.com> - 2015-11-24 00:17 +0100
      Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 02:34 -0800
        Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 04:02 -0800
          Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 04:14 -0800
            Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 04:19 -0800
              Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 04:21 -0800
                Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 04:31 -0800
                  Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 04:54 -0800
                    Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 06:46 -0800
                      Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 07:11 -0800
                        Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 07:56 -0800
                          Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 08:17 -0800
                            Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 12:18 -0800
                              Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 12:41 -0800
        Re: Evitare di inviare via POST i dati di login in chiaro Leonardo Serni <lserni@gmail.com> - 2015-11-24 19:09 +0100
          Re: Evitare di inviare via POST i dati di login in chiaro fmassei@gmail.com - 2015-11-24 11:14 -0800
            Re: Evitare di inviare via POST i dati di login in chiaro Leonardo Serni <lserni@gmail.com> - 2015-11-24 20:33 +0100
    Re: Evitare di inviare via POST i dati di login in chiaro KVM <kvm@nome.it> - 2015-11-24 16:14 +0100
      Re: Evitare di inviare via POST i dati di login in chiaro fmigliori <fmigliori@gmail.com> - 2015-11-24 07:39 -0800
    Re: Evitare di inviare via POST i dati di login in chiaro Marco <marcosol@tiscali.it> - 2015-11-25 09:14 -0800
      Re: Evitare di inviare via POST i dati di login in chiaro Alessandro Pellizzari <shuriken@amiran.it> - 2015-11-25 20:04 +0000
    Re: Evitare di inviare via POST i dati di login in chiaro Marco <marcosol@tiscali.it> - 2015-11-27 01:48 -0800

Page 1 of 2  [1] 2  Next page →

#20081 — Evitare di inviare via POST i dati di login in chiaro

Salve a tutti. Sono nuovo in questo gruppo.
Sto realizzando un cms che necessita di una procedura di autenticazione in avvio, mediante userid e password. Il tutto su area intranet.
Non posso utilizzare il protocollo https.
Per quanto riguarda le password intendo memorizzare nel db l'hash sha512 delle stesse e basare l'autenticazione sul confronto dei relativi valori di hash.
Il mio dubbio è questo: per ragioni di sicurezza sarebbe meglio strutturare il form con del codice javascript, in modo tale che l'hashing della password inserita dall'utente avvenga lato client, e venga quindi inviato alla pagina di autenticazione (php), con metodo post, soltanto il valore hash? Oppure si può lasciare viaggiare in chiaro il valore del campo input relativo alla password, affidando infine a php il compito di generare l'hash per il confronto con quello contenuto nel db?
Con il primo sistema, però, renderei visibile ad un utente accorto l'algoritmo di hashing utilizzato (basterebbe aprire e leggere il file javascript); con il secondo sistema dovrei far circolare la password in chiaro fra il client ed il server, con tutti i rischi che ciò potrebbe comportare.
Mi interessa capire bene le implicazioni ed i rischi per la sicurezza conseguenti all'uno ed all'altro sistema, a prescindere da altre questioni come l'uso dei salt o hmac.

[toc] | [next] | [standalone]

#20082

On Monday, November 23, 2015 at 9:41:57 PM UTC+1, Marco wrote:
> Salve a tutti. Sono nuovo in questo gruppo.

Ciao :)

> Sto realizzando un cms che necessita di una procedura di autenticazione in
> avvio, mediante userid e password. Il tutto su area intranet.
> Non posso utilizzare il protocollo https.

Perché mai? Genera un certificato self-signed e sei a posto: specialmente
su intranet, puoi aggiungere in tutti i client il certificato stesso, così
da non avere messaggi "strani" che possano confondere gli utenti.

> Per quanto riguarda le password intendo memorizzare nel db l'hash sha512
> delle stesse e basare l'autenticazione sul confronto dei relativi valori
> di hash.

PHP, dalla 5.5 in poi (e ci sono script di compatibilità per le versioni
precedenti) ha una funzione apposita per la generazione degli hash delle
password: password_hash. Usa quella!
Non solo ti garantisce che, in fronte ad un update futuro, la funzione
sottostante sarà aggiornata in base agli standard di sicurezza più
accettati, ma ti elimina soprattutto un sacco di errori che è possibile
fare quando si gestiscono funzioni crittografiche a mano.

> Il mio dubbio è questo: per ragioni di sicurezza sarebbe meglio strutturare
> il form con del codice javascript, in modo tale che l'hashing della password
> inserita dall'utente avvenga lato client, e venga quindi inviato alla pagina
> di autenticazione (php), con metodo post, soltanto il valore hash? Oppure si
> può lasciare viaggiare in chiaro il valore del campo input relativo alla
> password, affidando infine a php il compito di generare l'hash per il
> confronto con quello contenuto nel db?

Se non trasmetti in HTTPS, tutto quello che viaggia sul cavo è in chiaro.

> Con il primo sistema, però, renderei visibile ad un utente accorto
> l'algoritmo di hashing utilizzato (basterebbe aprire e leggere il file
> javascript); con il secondo sistema dovrei far circolare la password in
> chiaro fra il client ed il server, con tutti i rischi che ciò potrebbe
> comportare.

Le due cose sono, a livello di sicurezza, equivalenti.

> Mi interessa capire bene le implicazioni ed i rischi per la sicurezza
> conseguenti all'uno ed all'altro sistema, a prescindere da altre questioni
> come l'uso dei salt o hmac.

Utilizza HTTPS.
Oppure solo HTTP, fai viaggiare solo cose in chiaro, e sposta il problema
a chi/come si può connettere alla intranet: se il sistema gira in un ufficio,
su tre PC più un server, collegati in LAN, e senza accesso a internet o a
periferiche esterne (il che, considerando l'uso di chiavette USB, è difficile
da garantire), allora non c'è nessun problema.

Ciao!

[toc] | [prev] | [next] | [standalone]

#20083

>Con il primo sistema, però, renderei visibile ad un utente accorto l'algoritmo di hashing utilizzato (basterebbe aprire e leggere il file javascript); con il secondo sistema dovrei far circolare la password in chiaro fra il client ed il server, con tutti i rischi che ciò potrebbe comportare. 

Anche vedendo e modificando lo script non ottiene nessun vantaggio, forse il limite è che non puoi usare il sale per le password nel db.

[toc] | [prev] | [next] | [standalone]

#20084

Il Mon, 23 Nov 2015 12:41:55 -0800, Marco Solinas ha scritto:

> con il secondo sistema dovrei far circolare la password in
> chiaro fra il client ed il server, con tutti i rischi che ciò potrebbe
> comportare.

Farlo circolare in chiaro o crittato è la stessa cosa.
Se qualcuno intercetta quel valore, non deve fare altro che rimandarlo 
uguale al tuo server, e lui lo autentica.

Tanto vale dire agli utenti di usare password non banali (che è quello che 
dovrebbero fare).

L'unico modo è https, ma visto che hai detto che non puoi usarlo, non 
farti troppe pare mentali e manda la password in chiaro.

Bye.

[toc] | [prev] | [next] | [standalone]

#20086

Il giorno lunedì 23 novembre 2015 22:55:06 UTC+1, Alessandro Pellizzari ha scritto:
> Il Mon, 23 Nov 2015 12:41:55 -0800, Marco Solinas ha scritto:
> 
> > con il secondo sistema dovrei far circolare la password in
> > chiaro fra il client ed il server, con tutti i rischi che ciò potrebbe
> > comportare.
> 
> Farlo circolare in chiaro o crittato è la stessa cosa.
> Se qualcuno intercetta quel valore, non deve fare altro che rimandarlo 
> uguale al tuo server, e lui lo autentica.

Do per scontato troppe cose. Se al login passi il sale (casuale per ogni richiesta di login) a quel punto vedere il traffico iniziale non ti serve, certo che criptare la password non equivale a proteggere il traffico, ma questo era chiaro fin da subito e vedere lo script non aiuta.

[toc] | [prev] | [next] | [standalone]

#20085

On Mon, 23 Nov 2015 12:41:55 -0800 (PST), Marco Solinas <marcosol@tiscali.it>
wrote:

>Per quanto riguarda le password intendo memorizzare nel db l'hash sha512 delle stesse e basare l'autenticazione sul confronto dei relativi valori di hash.
>Il mio dubbio è questo: per ragioni di sicurezza sarebbe meglio strutturare il form con del codice javascript, in modo tale che l'hashing della password inserita dall'utente avvenga lato client, e venga quindi inviato alla pagina di autenticazione (php), con metodo post, soltanto il valore hash? Oppure si può lasciare viaggiare in
chiaro il valore del campo input relativo alla password, affidando infine a php il compito di generare l'hash per il confronto con quello contenuto nel db?

Tecnicamente non c'è differenza. Per essere autenticato tu devi mandare un
blob di bit. Se uno lo intercetta può rimandarlo uguale, e che sia la pass
in chiaro o uno SHA-65536 non cambierà le cose.

C'e' la differenza che la password dell'utente (che magari usa anche per i
rimanenti siti) non viene catturata mentre viaggia.

Per evitare i replay attack, puoi usare una cosa javascript che fa così:

	- il server invia una challenge veramente random C
	- il client legge dall'utente la password P
	- effettua uno SHA-512 (in javascript) ottenendo H
	- effettua uno SHA-512 di H concatenato C ottenendo K
	- invia K

	- il server riceve K, conosce SHA512(P), verifica se
	  SHA512(SHA512(P) concatenato H) è davvero K

Questo sistema è vulnerabile a una cattura del database. Però:

a) La password originaria, magari usata da altri siti, non è rivelata
b) Se un attaccante mette le mani sul DB, è probabile che abbia accesso a
   tutto il server, e modificare il codice per introdurre una backdoor in
   grado di bypassare del tutto l'autenticazione è relativamente facile.

Leonardo

-- 

Now suppose -just suppose- I could show you a way to
manufacture a wall that would do the same job... but
was only one inch thick.

[toc] | [prev] | [next] | [standalone]

#20087

On Tuesday, November 24, 2015 at 12:17:18 AM UTC+1, Leonardo Serni wrote:
> Tecnicamente non c'è differenza. Per essere autenticato tu devi mandare un
> blob di bit. Se uno lo intercetta può rimandarlo uguale, e che sia la pass
> in chiaro o uno SHA-65536 non cambierà le cose.
> 
> C'e' la differenza che la password dell'utente (che magari usa anche per i
> rimanenti siti) non viene catturata mentre viaggia.
> 
> Per evitare i replay attack, puoi usare una cosa javascript che fa così:
> 
> 	- il server invia una challenge veramente random C
> 	- il client legge dall'utente la password P
> 	- effettua uno SHA-512 (in javascript) ottenendo H
> 	- effettua uno SHA-512 di H concatenato C ottenendo K
> 	- invia K
> 
> 	- il server riceve K, conosce SHA512(P), verifica se
> 	  SHA512(SHA512(P) concatenato H) è davvero K
> 
> Questo sistema è vulnerabile a una cattura del database. Però:
> 
> a) La password originaria, magari usata da altri siti, non è rivelata
> b) Se un attaccante mette le mani sul DB, è probabile che abbia accesso a
>    tutto il server, e modificare il codice per introdurre una backdoor in
>    grado di bypassare del tutto l'autenticazione è relativamente facile.
> 

Questo sistema è vulnerabile a un MITM, nel passo 5.

Ciao!

[toc] | [prev] | [next] | [standalone]

#20088

Questo sistema è vulnerabile a un MITM, nel passo 5. 

>         - invia K ?

Spiegati che mi interessa

[toc] | [prev] | [next] | [standalone]

#20089

On Tuesday, November 24, 2015 at 1:02:10 PM UTC+1, fmigliori wrote:
> Questo sistema è vulnerabile a un MITM, nel passo 5. 
> 
> >         - invia K ?
> 
> Spiegati che mi interessa

Se sei nel mezzo tra client e server, leggi e fai passare tutto fino a quel
punto. Una volta intercettato K, mandi al client un 503 e la K al server
la mandi te.

Ciao!

[toc] | [prev] | [next] | [standalone]

#20090

Il giorno martedì 24 novembre 2015 13:14:06 UTC+1, fma...@gmail.com ha scritto:
> On Tuesday, November 24, 2015 at 1:02:10 PM UTC+1, fmigliori wrote:
> > Questo sistema è vulnerabile a un MITM, nel passo 5. 
> > 
> > >         - invia K ?
> > 
> > Spiegati che mi interessa
> 
> Se sei nel mezzo tra client e server, leggi e fai passare tutto fino a quel
> punto. Una volta intercettato K, mandi al client un 503 e la K al server
> la mandi te.
> 
> Ciao!

Se il client usa te come proxy, ma se avete ip diversi...

[toc] | [prev] | [next] | [standalone]

#20091

On Tuesday, November 24, 2015 at 1:19:08 PM UTC+1, fmigliori wrote:
> Il giorno martedì 24 novembre 2015 13:14:06 UTC+1, fma...@gmail.com ha scritto:
> > On Tuesday, November 24, 2015 at 1:02:10 PM UTC+1, fmigliori wrote:
> > > Questo sistema è vulnerabile a un MITM, nel passo 5. 
> > > 
> > > >         - invia K ?
> > > 
> > > Spiegati che mi interessa
> > 
> > Se sei nel mezzo tra client e server, leggi e fai passare tutto fino a quel
> > punto. Una volta intercettato K, mandi al client un 503 e la K al server
> > la mandi te.
> > 
> > Ciao!
> 
> Se il client usa te come proxy, ma se avete ip diversi...

Nel tuo algoritmo non c'era nessun controllo sull'IP :)

Ciao!

[toc] | [prev] | [next] | [standalone]

#20092

Il giorno martedì 24 novembre 2015 13:21:17 UTC+1, fma...@gmail.com ha scritto:
> On Tuesday, November 24, 2015 at 1:19:08 PM UTC+1, fmigliori wrote:
> > Il giorno martedì 24 novembre 2015 13:14:06 UTC+1, fma...@gmail.com ha scritto:
> > > On Tuesday, November 24, 2015 at 1:02:10 PM UTC+1, fmigliori wrote:
> > > > Questo sistema è vulnerabile a un MITM, nel passo 5. 
> > > > 
> > > > >         - invia K ?
> > > > 
> > > > Spiegati che mi interessa
> > > 
> > > Se sei nel mezzo tra client e server, leggi e fai passare tutto fino a quel
> > > punto. Una volta intercettato K, mandi al client un 503 e la K al server
> > > la mandi te.
> > > 
> > > Ciao!
> > 
> > Se il client usa te come proxy, ma se avete ip diversi...
> 
> Nel tuo algoritmo non c'era nessun controllo sull'IP :)
> 
> Ciao!

Quindi sei d'accordo nel considerare il sistema come robusto

[toc] | [prev] | [next] | [standalone]

#20093

On Tuesday, November 24, 2015 at 1:31:23 PM UTC+1, fmigliori wrote:
> Quindi sei d'accordo nel considerare il sistema come robusto

No, visto che il problema del MITM rimane pari pari. Se il server controlla
anche l'IP, si fa relay fin dal primo messaggio.

L'unico modo per avere un sistema "robusto" per questa strada sarebbe
reimplementarsi tutto il sistema di TLS sopra HTTP, il che è semplicemente
follia! :)

Ciao!

[toc] | [prev] | [next] | [standalone]

#20094

Il giorno martedì 24 novembre 2015 13:54:18 UTC+1, fma...@gmail.com ha scritto:
> On Tuesday, November 24, 2015 at 1:31:23 PM UTC+1, fmigliori wrote:
> > Quindi sei d'accordo nel considerare il sistema come robusto
> 
> No, visto che il problema del MITM rimane pari pari. Se il server controlla
> anche l'IP, si fa relay fin dal primo messaggio.
> 
> L'unico modo per avere un sistema "robusto" per questa strada sarebbe
> reimplementarsi tutto il sistema di TLS sopra HTTP, il che è semplicemente
> follia! :)
> 
> Ciao!

Come già avevo accennato: il proxy. Però devi modificare la configurazione dei client, a quel punto con un bel keylogger fai prima e questo non è propriamente un mtm che legge il traffico. O del dns se lo usano. Senza considerare che l'utente non può accedere, quindi ben visibile, e poi lasci tracce nella configurazione del proxy che indica il server malevolo. Ed è mono uso.

Se non potessi usare ssl questo è il sistema che molto probabilmente adotterei.

Mentre te preferiresti andare scoperto, senza accorgersi di nulla violabile com'è con un banale sniffer.

[toc] | [prev] | [next] | [standalone]

#20095

On Tuesday, November 24, 2015 at 3:46:35 PM UTC+1, fmigliori wrote:
> Il giorno martedì 24 novembre 2015 13:54:18 UTC+1, fma...@gmail.com ha scritto:
> > On Tuesday, November 24, 2015 at 1:31:23 PM UTC+1, fmigliori wrote:
> > > Quindi sei d'accordo nel considerare il sistema come robusto
> > 
> > No, visto che il problema del MITM rimane pari pari. Se il server controlla
> > anche l'IP, si fa relay fin dal primo messaggio.
> > 
> > L'unico modo per avere un sistema "robusto" per questa strada sarebbe
> > reimplementarsi tutto il sistema di TLS sopra HTTP, il che è semplicemente
> > follia! :)
> > 
> > Ciao!
> 
> Come già avevo accennato: il proxy. Però devi modificare la configurazione
> dei client, a quel punto con un bel keylogger fai prima e questo non è
> propriamente un mtm che legge il traffico. O del dns se lo usano. Senza
> considerare che l'utente non può accedere, quindi ben visibile, e poi lasci
> tracce nella configurazione del proxy che indica il server malevolo. Ed è
> mono uso.
> 

Mica il proxy è l'unico modo di mettersi in mezzo ad una comunicazione,
qualsiasi nodo tra il client e il server è buono, a partire dal router
del client fino allo switch del server. Sulla rete locale non c'è neppure
bisogno di toccare nulla, basta un ARP poisoning.

> Se non potessi usare ssl questo è il sistema che molto probabilmente
> adotterei.
> 

Io mi chiederei quali sono questi motivi per cui non posso usare SSL, che
sinceramente non li capisco.

Altrimenti io non userei nulla, tutto in chiaro, altrimenti tanta fatica per
pochi benefici.

> Mentre te preferiresti andare scoperto, senza accorgersi di nulla violabile
> com'è con un banale sniffer.

Come sopra, chi sa usare uno sniffer sa anche fare spoofing.

Ciao!

[toc] | [prev] | [next] | [standalone]

#20098

Il giorno martedì 24 novembre 2015 16:11:43 UTC+1, fma...@gmail.com ha scritto:

> Mica il proxy è l'unico modo di mettersi in mezzo ad una comunicazione,
> qualsiasi nodo tra il client e il server è buono, a partire dal router
> del client fino allo switch del server. Sulla rete locale non c'è neppure
> bisogno di toccare nulla, basta un ARP poisoning.

Con l'arp poisoning ho letto pacchetti che non erano diretti a me (prove eeeh), ma un intero relay che si attiva solo per il momento che il tizio si logga? Senza che perda i servizi di rete? Oppure un arp poisoning del server, che così nessuno entra. Impercettibile.


Prima di craccare router, mi lavorerei il server stesso e a quel punto l'ssl ti aiuta ben poco. Dopodiché passerei al livello 8 della scala osi e torturerei il tizio. Ma forse stiamo esagerando. Nessuno ha affermato che il sistema possa risolvere la mancanza di ssl, di sicuro è una sicurezza in più in quanto per essere scavalcato richiede delle signore compentenze.

> > Se non potessi usare ssl questo è il sistema che molto probabilmente
> > adotterei.
> > 
> 
> Io mi chiederei quali sono questi motivi per cui non posso usare SSL, che
> sinceramente non li capisco.

Boh? Avrà un server http leggero. Di sicuro è che ti difendi male senza ssl.

 

[toc] | [prev] | [next] | [standalone]

#20099

On Tuesday, November 24, 2015 at 4:56:21 PM UTC+1, fmigliori wrote:
> Il giorno martedì 24 novembre 2015 16:11:43 UTC+1, fma...@gmail.com ha scritto:
> 
> > Mica il proxy è l'unico modo di mettersi in mezzo ad una comunicazione,
> > qualsiasi nodo tra il client e il server è buono, a partire dal router
> > del client fino allo switch del server. Sulla rete locale non c'è neppure
> > bisogno di toccare nulla, basta un ARP poisoning.
> 
> Con l'arp poisoning ho letto pacchetti che non erano diretti a me (prove
> eeeh), ma un intero relay che si attiva solo per il momento che il tizio
> si logga? Senza che perda i servizi di rete?

Non ci siamo capiti. Se sono sulla rete locale, faccio spoofing per fare in
modo che la macchina target usi la mia come router invece del router "vero".
A quel punto posso fare relay dei suoi pacchetti.

> Oppure un arp poisoning del server, che così nessuno entra. Impercettibile.

Perché "nessuno entra"?

> Prima di craccare router, mi lavorerei il server stesso e a quel punto
> l'ssl ti aiuta ben poco.

Non serve "craccare" né il router né il server.

Ma, voglio dì, di modi ce ne sono un milione! Se invece di una LAN c'è
un wireless, metti vicino un hotspot aperto controllato da te, prima o poi
il router cade e le macchine si connettono al tuo.
Per ogni situazione possibile si possono inventare centinaia di modi!

> Dopodiché passerei al livello 8 della scala osi e torturerei il tizio.

eheheh - questo però potrebbe essere un buon punto per dare software non
sicuro: "se tutto fosse troppo sicuro, un attaccante sarebbe costretto a
venire qui di persona a picchiarvi, così invece fa tutto sulla rete" :)

> Ma forse stiamo esagerando.

Sì, direi :)

> Boh? Avrà un server http leggero.

Esiste un webserver che fa girare PHP ma non supporta SSL? :) Forse
boa+php in cgi, però sarebbe una configurazione un po' strana!

> Di sicuro è che ti difendi male senza ssl.

Infatti, questo è il succo di tutto il discorso

Ciao!

[toc] | [prev] | [next] | [standalone]

#20103

Il giorno martedì 24 novembre 2015 17:17:04 UTC+1, fma...@gmail.com ha scritto:
> On Tuesday, November 24, 2015 at 4:56:21 PM UTC+1, fmigliori wrote:
> > Il giorno martedì 24 novembre 2015 16:11:43 UTC+1, fma...@gmail.com ha scritto:
> > 
> > > Mica il proxy è l'unico modo di mettersi in mezzo ad una comunicazione,
> > > qualsiasi nodo tra il client e il server è buono, a partire dal router
> > > del client fino allo switch del server. Sulla rete locale non c'è neppure
> > > bisogno di toccare nulla, basta un ARP poisoning.
> > 
> > Con l'arp poisoning ho letto pacchetti che non erano diretti a me (prove
> > eeeh), ma un intero relay che si attiva solo per il momento che il tizio
> > si logga? Senza che perda i servizi di rete?
> 
> Non ci siamo capiti. Se sono sulla rete locale, faccio spoofing per fare in
> modo che la macchina target usi la mia come router invece del router "vero".

Ma questo pezzo l'ho scritto io o lo hai scritto te?

>mettersi in mezzo ad una comunicazione, qualsiasi nodo tra il client e il server è buono, a partire dal router

Il router internet (ma anche fosse solo border)? ti metti a nattare te al posto suo? con un ip spooffato, all'intera rete aziendale.


Son convinto che non lo hai mai fatto, altrimenti ti vengo a stringere la mano anche lavorassi in Islanda, ma poi me lo fai vedere.


> A quel punto posso fare relay dei suoi pacchetti.

a mo di proxy

> 
> > Oppure un arp poisoning del server, che così nessuno entra. Impercettibile.
> 
> Perché "nessuno entra"?


server ip 192.168.1.2 mac address xx:xx:xx:xx:xx:xx

hai drogato la rete con falsi pacchetti arp

falso ip server 192.168.1.3 mac address yy:yy:yy:yy:yy:yy

e ora come ti colleghi al server? Quali pacchetti arrivano a al vero server?

Che poi con gli hub era semplice, ma con gli switch di adesso ti viene a bussare il sistemista appena premi enter.

> > Prima di craccare router, mi lavorerei il server stesso e a quel punto
> > l'ssl ti aiuta ben poco.
> 
> Non serve "craccare" né il router né il server.
> 
> Ma, voglio dì, di modi ce ne sono un milione! Se invece di una LAN c'è
> un wireless, metti vicino un hotspot aperto controllato da te, prima o poi
> il router cade e le macchine si connettono al tuo.
> Per ogni situazione possibile si possono inventare centinaia di modi!
> 
> > Dopodiché passerei al livello 8 della scala osi e torturerei il tizio.
> 
> eheheh - questo però potrebbe essere un buon punto per dare software non
> sicuro: "se tutto fosse troppo sicuro, un attaccante sarebbe costretto a
> venire qui di persona a picchiarvi, così invece fa tutto sulla rete" :)


Questa poi! Sei te che vuoi il software insicuro perché tanto ci sono milioni di modi di craccare, tutti i nodi, rete wireless... Ma ti leggi quando scrivi? E' a te che fa fatica scrivere 6 righe di php e due in js perché se non posso avere il massimo della sicurezza (ssl) tanto vale mandare tutto in chiaro! 

Ma magari ti ho frainteso, credo che ci stiamo impastando

> Esiste un webserver che fa girare PHP ma non supporta SSL? :) Forse
> boa+php in cgi, però sarebbe una configurazione un po' strana!

Di web server scritti nei linguaggi più improbabili ce ne sono una marea, ma io non ci perderei molto tempo visto che per installare i più solidi ci si mette 3 minuti.

> > Di sicuro è che ti difendi male senza ssl.
> 
> Infatti, questo è il succo di tutto il discorso

Meno male che qui siam d'accordo!! :)

Visto l'interesse di Marco - che nel frattempo son convinto abbia imparato a farsi i certificati autofirmati - direi che potremmo anche fermarci. Sempre se sei d'accordo :p

[toc] | [prev] | [next] | [standalone]

#20104

On Tuesday, November 24, 2015 at 9:18:48 PM UTC+1, fmigliori wrote:
> <big snip>
> Son convinto che non lo hai mai fatto, altrimenti ti vengo a stringere
> la mano anche lavorassi in Islanda, ma poi me lo fai vedere.
> <big snip>

Networking e/o sicurezza non è il mio campo, ma di questo genere ho visto
con i miei occhi fare cose anche peggiori (o migliori, se vuoi). Se è per
questo ho anche visto direttamente raggirare lo SSL, con chi si ricorda più
il nome di uno strano bug (non che nella storia delle varie implementazioni
di SSL ce ne siano stati pochi, ma tant'è), per cui immaginerai quanta
sicurezza mi può dare, a sensazione, un sistema homemade.

Per quello che mi riguarda, specialmente visto che di reti ne so più di
teoria che di pratica, se una cosa è teoricamente possibile la considero
possibile anche praticamente.

Anche per quanto riguarda la crittografia, le procedure crittografiche
sono famose per il fatto che un solo passaggio sbagliato fa "crollare"
tutto. Io, sinceramente, non mi ci metto: c'è gente esperta anche in quel
campo, io mi fido.

Sì, insomma, ad ognuno il lavoro suo :)

> > > Di sicuro è che ti difendi male senza ssl.
> > 
> > Infatti, questo è il succo di tutto il discorso
> 
> Meno male che qui siam d'accordo!! :)
> 
> Visto l'interesse di Marco - che nel frattempo son convinto abbia imparato
> a farsi i certificati autofirmati - direi che potremmo anche fermarci.
> Sempre se sei d'accordo :p
>

Sìsì, anche perché alla fine stiamo dicendo la stessa cosa :)

Ciao!

[toc] | [prev] | [next] | [standalone]

#20100

On Tue, 24 Nov 2015 02:34:13 -0800 (PST), fmassei@gmail.com wrote:

>> 	- il server invia una challenge veramente random C
>> 	- il client legge dall'utente la password P
>> 	- effettua uno SHA-512 (in javascript) ottenendo H
>> 	- effettua uno SHA-512 di H concatenato C ottenendo K
>> 	- invia K

>Questo sistema è vulnerabile a un MITM, nel passo 5.

Uhm, non ho capito. La nostra Eve può mettere le mani su C e su
SHA(H|C)... o non ho capito un apascio?

In che modo riesce a ri-autenticarsi sul server? La volta dopo,
ricevera' un nuovo C' e non sarà in grado di generare SHA(H|C')
perché non ha H e SHA è supposto non invertibile.

Certamente può fare session hijacking, ma questo può farlo dato
che è su HTTP.

L'unico modo per impedirlo sarebbe usare una funzione simile su
ogni pacchetto trasferito fra client e server, usando magari un
algoritmo P/P per negoziare una chiave simmetrica di cifratura.

E avremmo reinventato HTTPS :-)

Cosa che è fattibile, visto che è stata fatta:

	https://github.com/digitalbazaar/forge

Leonardo

-- 

Now suppose -just suppose- I could show you a way to
manufacture a wall that would do the same job... but
was only one inch thick.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web