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 2 of 2 — ← Prev page 1 [2]

#20101

On Tuesday, November 24, 2015 at 7:09:28 PM UTC+1, Leonardo Serni wrote:
> 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.
> 

Qualche post sotto l'ho riscritto meglio, Eve fa relay fino al
passo 5, poi smette di fare relay, sconnette Alice e manda K a Bob.

> 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 :-)
> 

Infatti, cosa che non mi pareva valere la candela :) se non fosse che...

> Cosa che è fattibile, visto che è stata fatta:
> 
> 	https://github.com/digitalbazaar/forge
> 

... ecco, queste sono le cose che mi mettono paura.
Immagino sia ideato per girare sopra nodejs e non su un client ma, in ogni
caso, mamma mia! :)

Ciao!

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

#20102

On Tue, 24 Nov 2015 11:14:35 -0800 (PST), fmassei@gmail.com wrote:

>> 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.

>Qualche post sotto l'ho riscritto meglio, Eve fa relay fino al
>passo 5, poi smette di fare relay, sconnette Alice e manda K a Bob.

Ah, OK. Session hijacking sotto un altro nome :-)

>> E avremmo reinventato HTTPS :-)

>Infatti, cosa che non mi pareva valere la candela :) se non fosse che...

>> Cosa che è fattibile, visto che è stata fatta:

>> 	https://github.com/digitalbazaar/forge

>... ecco, queste sono le cose che mi mettono paura.
>Immagino sia ideato per girare sopra nodejs e non su un client ma, in ogni
>caso, mamma mia! :)

Non so, non ho avuto il coraggio di guardare :-D

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]

#20096

Il 23/11/2015 21:41, Marco Solinas ha scritto:
> 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.
>

Contribuisco con i miei 2 cent...

ma se la connessione è in chiaro, a quel punto il server ti assegnerà
un cookie di sessione che può essere tranquillamente utilizzato da
qualcun'altro.

L'uso è ovviamente valido durante la sessione di lavoro dell'utente
autenticato, ma esso deve pure ricordarsi di effettuare la 
disconnessione volontariamente, se no, sempre il nostro hacker malevolo
può fare ciò che vuole all'infinito.

Dovresti aggiungere qualche controllo in più non solo in fase di login,
ma questo dipende anche dall'implementazione specifica.

Ciao!

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

#20097

Infatti, anche se non è l'equivalente di avere la password funziona in assenza di lss.

Se però come già detto il server memorizza l'ip del client avere il cookie non ti avvantaggia.

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

#20105

Vi ringrazio tutti per le preziose informazioni.
Il motivo per cui non posso usare HTTPS è che gli script PHP dovranno stare su un server virtuale con EasyPhp e su piattaforma Windows. Ho il mal di testa al solo pensiero di mettere mano al modulo di Apache per implementare SSL. La dimensione del sistema in progettazione (una ventina di pc) e la tipologia dei dati che verranno trattati (nè dati sensibili nè giudiziari) non giustificano a mio parere un simile impegno.
Oltre all'autenticazione mediante userid e password, sfrutterò PHP per filtrare i client in base al loro IP privato. Ovviamente utilizzerò le sessioni (solo su cookie), che verranno sempre rigenerate ad ogni caricamento di pagina.
Quella di inviare al client un challenge random (a proposito: la funzione rand() di PHP è veramente random???) mi pare una soluzione di compromesso accettabile: pensavo di salvarne il valore sulla variabile  $_SESSION["challenge"] e contemporaneamente creare un campo input hidden che la contenga, in modo tale da permettere a javascript di recuperarlo per generarne l'hash e concatenarlo a quello della password. Secondo voi potrebbe andare od è preferibile inviarla su cookie anzichè su input hidden?

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

#20106

Il Wed, 25 Nov 2015 09:14:57 -0800, Marco ha scritto:

> Il motivo per cui non posso usare HTTPS è che gli script PHP dovranno
> stare su un server virtuale con EasyPhp e su piattaforma Windows. 

Allora hai ben altri problemi di sicurezza che far passare le password in 
chiaro.

> Quella di inviare al client un challenge random (a proposito: la
> funzione rand() di PHP è veramente random???) mi pare una soluzione di
> compromesso accettabile: pensavo di salvarne il valore sulla variabile 
> $_SESSION["challenge"] e contemporaneamente creare un campo input hidden
> che la contenga, in modo tale da permettere a javascript di recuperarlo
> per generarne l'hash e concatenarlo a quello della password. Secondo voi
> potrebbe andare od è preferibile inviarla su cookie anzichè su input
> hidden?

Se hai problemi di MITM la sicurezza è zero. Tutto quello che invii al 
client, inclusi il challenge e lo script JS che deve calcolarlo, passa per 
la macchina del MITM, che, dopo aver analizzato il traffico la prima 
volta, ci mette poco a mandare al client una funzione tipo function 
password(psw) { return pwd; } al posto della tua, per poi usare il tuo 
algoritmo sul suo "proxy non trasparente", con doppio vantaggio: raccoglie 
le password in chiaro e diventa invisibile ai tuoi occhi.

Sono pronto a scommettere che impieghi meno a imparare come configurare 
SSL su Windows che a studiare un algoritmo anche solo vagamente sicuro.

Bye.

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

#20109

Scusate per l'OT, ho capito che è inutile tentare di migliorare lo script rimanendo in HTTP. Per favore qualcuno mi sa suggerire la configurazione del file httpd.conf di Apache (vers. 2.4) per SSL? 
Ho già effettuato diverse prove, messo in Listen la porta 443 e decommentato la riga #LoadModule ssl_module modules/mod_ssl.so, ma Apache non si riavvia. 
Poi ho anche decommentato la riga #Include conf/extra/httpd-ssl.conf ed aggiunto, prima della riga #<VirtualHost _default_: 443>: 

SSLMutex predefinita 
 SSLRandomSeed avvio builtin 
 SSLSessionCache  none 
< VirtualHost 127.0.0.1: 443 > 
     SSLEngine  On 
    SSLCertificateFile conf/ssl/site.cert 
     SSLCertificateKeyFile conf/ssl/site.key 
</ VirtualHost> 

ma ancora niente da fare... Apache non si riavvia... 
Qualcuno mi sa dare una mano? Grazie!!!

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web