Newsgroup: it.comp.sicurezza.varie
Titolo: Basic Authenticatio

Ciao raga ho un dubbio, holetto in giro che l'autenticazione di tipo basic 
permette l'invio di nome utente e password codificate in base64 a sua volta 
volendo utilizzare il metodo di protezione htaccess di Apache (utilizzando 
a sua volta una autenticazione di tipo basic) ovvero:
.htaccess
AuthUserFile /www/htdocs/secure/.htpasswd
AuthGroupFile /dev/null
AuthName "Directory Protetta"
AuthType Basic
<Limit GET>
require valid-user
</Limit> 
il seguente metodo è di tipo plain-text ovvero che username e password 
vengono inviati in sempolice formato testo, non criptato.
La mia domanda è allora, ma se ilmetodo Htaccess utilizza un'autenticazione 
di tipo Basic i dati vengono inviati codificati o no?
Non mi è chiaro quando i dati vengono inviati codificati e quando no?
Suggerimenti


:Provate a guardare gli ingredienti del famoso Labello che si usa per
:le labbra screpolate: Butirrospermum Parkii (sperma di maiale).

Per mandare i dati criptati, devi usare SSL, non HTTP.
Dimenticavo: questo se per "dati" intendi la pagina HTML. Se intendi i
dati di login (username+password), allora correggasi:
:Per mandare i dati criptati, devi usare Digest, non Basic.
...e l'autenticazione Digest funziona anche via HTTP, naturalmente.
A dire la verita' c'e' un bug implementativo in IE, non so se e' stato
gia' risolto oppure no. Ma non costituisce un gran problema.


 Ma non costituisce un gran problema.
Eh, beh.
-- 
Per non dimenticare:
http://snipurl.com/SdC_ed_il_vino
Le sigarette a volte danno buoni consigli:
http://snipurl.com/sigarette

ed a quelli che usavano IE no.
Il bug mi pare colpisse solo le sottodirectory, se usi un root URI non ti
da' problemi. Questa e' la fix veloce :-)
Con Apache 2.0.51 c'e' un'altra fix altrettanto veloce:
	Using Digest Authentication with MSIE:
	BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On 
...ma e' bacata, serve la 2.0.52 :-)
Una fix alternativa pubblicata Altrove per Apache 1.3: dove in
mod_auth_digest c'e'
           /* check that query matches */
            || (d_uri.query != r_uri.query
                && (!d_uri.query || !r_uri.query
                    || strcmp(d_uri.query, r_uri.query)))
            ) {
            ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
                          "Digest: uri mismatch - <%s> does not match "
                          "request-uri <%s>", resp->uri,
resp->raw_request_uri);
            return BAD_REQUEST;
        }
    }
si aggiunge un controllo bovino
        {
                        const char *UserAgent;
                        UserAgent=ap_table_get(r->headers_in,
"User-Agent");
                        if ((NULL == UserAgent)
                        ||
                        (strstr(UserAgent, " MSIE ") == NULL)
			{
		            ap_log_rerror(APLOG_MARK,
APLOG_NOERRNO|APLOG_ERR, r,
                          "Digest: uri mismatch - <%s> does not match "
                          "request-uri <%s>", resp->uri,
resp->raw_request_uri);
            return BAD_REQUEST;
			}
         }
Solito disclaimer: "as is", ecc. ecc..
Da qualche parte, ho anche la fix per PHP, che vagamente ricordo essere
stata molto piu' semplice (e ha l'effetto collaterale di poter usare le
sessioni senza usare ne' cookies, ne' trans-sid).


 da' problemi. Questa e' la fix veloce :-)
Preziosissimo come sempre. ;)
Grazie e ciao.
