Autenticazione integrata sicura con PHP

[SubnetJO]

Buongiorno a tutti
premetto he sono un principante in PHP.
Sono alle prese con un piccolo progettino che però necessita di autenticazione integrata con Microsoft Active Directory.

Quello che mi preoccupa è l'inserimento delle credenziali.
In un form il campo di tipo password nasconde i caratteri solo a livello cosmetico.
Si potrebbe banalissimamente conservare in chiaro la coppia user/passowrd di tutti coloro che anche solo tentano di autenticarsi alla mia pagina.

Non sono riuscito a trovare granchè su questo argomento e credo che nessuno vorrebbe autenticarsi sulla mia pagina con le proprie credenziali aziendali, senza avere una ragionevole sicurezza che non possano essere rubate.

Premetto che il server PHP/Apache è in visibilità di un Domain Controller.
Vi chiedo:
- esiste un metodo per avere una autenticazione integrata sicura con PHP?

- potreste per favore indicarmi degli articoli sull'argomento?

Grazie a tutti per il vostro aiuto.
JO

[Shores]

Non è molto chiaro che cosa tu voglia ottenere, nè di cosa tu ti stia preoccupando.

Diciamo che in questa situazione entrano in gioco 3 livelli:

Il Browser dell'utente (e quindi html/javascript) che riceve la digitazione di user e pass
Il php che riceve queste informazioni (e sarebbe bene lo facesse tramite una from in method post su https)
Il domain controller che deve decidere se accettare user e password e rispondere al php che l'utente è autenticato.

Per rispondere ai tuoi quesiti: si, gli utenti devono potersi fidare della pagina web su cui digitano le credenziali, ma questo non ha niente a che vedere con come poi queste vengono usate: l'unico modo in cui puoi garantirgli questo è usando una url su un dominio che conoscono ed usando certificati SSL per garantirgli sia che il sito è quello vero sia che la connessione rigorosamente https sarà correttamente criptata.

Detto questo, come poi esegui realmente la verifica delle credenziali sono fatti tuoi; per esempio potresti usare una delle tante librerie LDAP per far parlare php con il domain controller, oppure potresti usare un server web basato su windows e IIS, che ha la possibilità di essere connesso con il DC e quindi richiedere login con le credenziali AD agli utenti web, prima ancora che entri in gioco php.

[SubnetJO]

Buongiorno
Innanzi tutto grazie per la risposta, ma mi sembra di non essermi spiegato bene.

Provo a sintetizzare meglio la domanda: io devo autenticare gli utenti garantendo di non poter conoscere la loro password.
Come � giusto che sia. Si pu� con PHP?

Hai ragionissima se dici che la pagina lato client (html/javascript) � effettivamente un problemone.
Ci vuole un attimo a fare echo in chiaro della password nascosta dai "pallini".
Ma capisco che questa non sia la sede.

In merito al PHP provo a chiarire con un piccolissimo esempio.
Mettiamo che ho il seguente form:


<form name="login" method="post" action="ShowPassword.php">
Insert password: <input name="password" type="password"><br>
<input type="submit" value="submit">
</form>


Il file ShowPassword.php contiene:

<?PHP
echo $_POST["password"];
?>

Quando si preme il pulsante submit, il browser, qualunque esso sia, mi mostrer� in chiaro la password che ho digitato.
Potenzialmente, la password del mio account aziendale, se voglio una autenticazione integrata.
E questo accade sia che usi HTTP o HTTPS ed a prescindere dalla autenticazione su AD che ancora deve avvenire.

La domanda allora pu� diventare:
E' possibile in PHP creare una pagina che non abbia questo problema?

Grazie infinite per il vostro aiuto
JO

[M4V1]

In ogni caso, anche se tu mettessi quell'echo la pass la vedresti solo tu, che avendola appena inserita la conosci già. Non vedo il problema.

[Flaviors200]

La domanda che sorge spontanea leggendo quello che hai scritto è: ma perché dovresti aver bisogno di stampare in una pagina la password in chiaro?

In PHP, ma in generale con qualsiasi linguaggio, le password utente o le fai generare a un sistema o le fai inserire all'utente.

L'operazione successiva è il salvataggio dell'hash della password (non la password in chiaro) nel database, applicando una funzione di hash (le più sicure al momento sono bcrypt o Argon2).

Detto questo non dovresti mai:

1) Salvare le password utente in chiaro!
2) Stamparle a video!
3) Inviarle per email (se lo fai, probabilmente le hai salvate in chiaro). Piuttosto crea un "password dimenticata?" che consente il reset della password.

- esiste un metodo per avere una autenticazione integrata sicura con PHP?

- potreste per favore indicarmi degli articoli sull'argomento?

Settimana scorsa ho pubblicato un piccolo tutorial riguardo la creazione di un form di login in PHP, se vuoi dagli un'occhiata. Non è un sistema completo, è giusto per dare un'idea di quali best practices adottare in casi come questo.

[SubnetJO]

In ogni caso, anche se tu mettessi quell'echo la pass la vedresti solo tu, che avendola appena inserita la conosci già. Non vedo il problema.

Ti prego di scusarmi ma...

il fatto di stampare la password era solo un modo per rendere evidente che la conosco.

Tu inserisci la password che dovresti conoscere solo tu, ed un attimo dopo la conosco anche io (server)

Potrei usarla per accedere alla tua posta elettronica, al tuo storage online, ai tuoi servizi aziendali... tutto
E se cambi la password, alla prima occasione che userai la mia pagina, verrai a consegnarmi la nuova password.

Non so se sono riuscito a rappresentare la circostanza, ma a me questo sembra un problemone di tutta evidenza.

[SubnetJO]

La domanda che sorge spontanea leggendo quello che hai scritto è: ma perché dovresti aver bisogno di stampare in una pagina la password in chiaro?

Era solo un modo per evidenziare che basta che l'utente inserisca la password per renderla nota a che a me (server), in chiaro.

In PHP, ma in generale con qualsiasi linguaggio, le password utente o le fai generare a un sistema o le fai inserire all'utente.

In questo caso, trattandosi di autenticazione integrata con Microsoft Active Directory, la password è quella della utenza aziendale di dominio.
Non posso generarla e neppure posso farla generare all'utente.
In ogni caso comunque, cosa c'entra?
Che io (server) faccia generare la password ad un sistema o la faccia inserire all'utente, non risolve il problema: sarei comunque a conoscenza della password in chiaro.
Comunque venga generata.

L'operazione successiva è il salvataggio dell'hash della password (non la password in chiaro) nel database, applicando una funzione di hash (le più sicure al momento sono bcrypt o Argon2).

Anche questo non credo risolva il problema.
Se posso generare l'hash della password, vuol dire che la password la conosco, in chiaro.
E come faccio a garantire che non me la salvo lato server anche in chiaro?

Detto questo non dovresti mai:

1) Salvare le password utente in chiaro!
2) Stamparle a video!
3) Inviarle per email (se lo fai, probabilmente le hai salvate in chiaro). Piuttosto crea un "password dimenticata?" che consente il reset della password.

Chiaramente non dovrei... ma potrei.
E questo è ovviamente inaccettabile.
Nel caso, certo che non stamparei la password a video e non la manderei via email... per non farmi scoprire che conosco le password di tutti. :-)

Settimana scorsa ho pubblicato un piccolo tutorial riguardo la creazione di un form di login in PHP, se vuoi dagli un'occhiata. Non è un sistema completo, è giusto per dare un'idea di quali best practices adottare in casi come questo.

Articolo interessante, complimenti.

Non credo però risolva questo problema.
Anche tu usi un form, un POST, ed un pulsante submit.
Nel tuo esempio, quando premi il pulsante Accedi del form di login, viene passata al file /php/login.php la variabile $POST_["password"] con la password in chiaro.
Che poi tu non la salvi, o ti salvi l'hash della password, che usi un algoritmo piuttosto che un altro... credo sia del tutto irrilevante.
Non puoi evitare di conoscere la password in chiaro.
Ed è questo il problema che devo risolvere.
Diversamente, non posso proporre una applicazione con autenticazione integrata.

Devo proporre per forza una applicazione con autenticazione interna, autonoma, e chiaramente chiedere comunque la fiducia degli utenti, perché neppure in questo caso potrei garantire di non salvare le password in chiaro.
Almeno però, la esposizione al rischio rimarrebbe circoscritta alla mia applicazione.

Osservazione.
Un esempio potrebbe essere la stessa html.it
Mi pare usi PHP
Come fa HTML.IT a garantire ce non conosce le nostre password in chiaro?

[clasku]

Fai un hash della password in javascript lato client prima del submit e poi hash lato server
la password Vera del cliente non la saprai e non salverai neanche l’hash generato da JavaScript

[Shores]

Mi sa che quello che vuoi ottenere è impossibile...

Nel momento in cui qualcuno digita una password in una maschera, il codice di quella maschera CONOSCE la password, è inevitabile... E non è effettuandone lo hash o altro che garantisci all'utente, che probabilmente nemmeno sa cosa sia uno hash, che non conosci la sua password: tu LA CONOSCI, e scegli di criptarla prima di farci altro, ma l'utente deve, appunto, fidarsi che tu non te la salvi altrove in chiaro.

Detto questo, se pensi che l'utente possa non fidarsi della tua maschera di login, usa l'autenticazione HTTP: così la maschera che raccoglie la password sarà una maschera del browser, e se l'utente non si fida nemmeno del suo browser che ha scelto ed installato lui...

Comunque, se il tuo codice php deve poi occuparsi di effettuare lui l'autenticazione dell'utente, anche se la fai con l'autenticazione HTTP, il codice php conoscerà la tua password in chiaro!

L'unica soluzione in cui il tuo codice html/js/php non conosca MAI la password, è usando l'autenticazione HTTP su IIS su windows, poiché in questo modo sono il browser ed IIS a conoscerla, mentre il tuo codice lato server riceve SOLO un flag che gli indica se l'utente è autenticato o meno.

Un'altra cosa di cui mi raccomando molto è di non usare MAI MD5 o simili funzioni di hash ormai debolissime per qualsiasi cosa inerente la sicurezza... MD5 va bene per generare l'ETag di una pagina, ma nient'altro.

E in ogni caso html.it, come qualsiasi sito che abbia una maschera di login, non garantisce un bel nulla: Quando riempi ed invii la maschera di login, il codice a cui ciò viene inviato su html.it CONOSCE la password, e ne verifica la corrispondenza con lo hash salvato in una tabella.

Ciò che viene garantito è che la password in chiaro sia nota solo nel momento in cui tu la digiti e dev'essere verificata, ma non in nessun'altro momento, e comunque questo solo se html.it fa le cose seriamente.

E' proprio questa la ragione per cui non bisogna MAI riutilizzare una password su più account!

Ma posso chiederti PERCHE' dovresti garantire una cosa simile?

[Shores]

...
Settimana scorsa ho pubblicato un piccolo tutorial riguardo la creazione di un form di login in PHP, se vuoi dagli un'occhiata. Non � un sistema completo, � giusto per dare un'idea di quali best practices adottare in casi come questo.

(Solo per segnalarti alcuni refusi/potenziali problemi del tutorial, peraltro molto ben fatto:

1) Hai un problema di codifica caratteri, le lettere accentate nel codice sono guaste.
2) Nelle form, nel caso in cui un input abbia un name = id, allora la name puo' essere omessa.
3) In fase di connessione al db, attenzione al fatto che $e->getMessage() potrebbe mostrare informazioni riservate
4) Gli script php di registrazione/login danno per assunto che nessuno stia tentando di farli andare in crash, ma sarebbe meglio che non contassero sul fatto che se e' definito _POST["register"/"login"] lo siano anche _POST["username"/"password"]...
5) Meglio evitare di richiedere uno specifico algoritmo di hash a password_hash: se non si indica, la versione di php in uso scegliera' sempre quello piu' forte a disposizione in quella versione, rimanendo comunque in grado di effettuare password_verify anche sugli hash fatti con altri algoritmi e gia' salvati in db.
6) Attenzione ad usare history.back() come link per tornare alla maschera, puo' essere facilmente manipolato; molto meglio un link esplicito a login.html/register.html
7) Attenzione anche al messaggio "Utente gia' in uso": capisco la necessità di indicare l'errore all'utente, ma bisognerebbe allora proteggersi da hammering sulla form di registrazione.
8) Usare session_destroy per eliminare il login e' corretto, ma distrugge tutta la sessione: se nella sessione sono stati memorizzati dati che non necessitavano di un login, come per esempio il contenuto di un carrello acquisti (mai pretendere che per mettere prodotti nel carrello sia necessario fare login, e quindi mai vuotare il carrello se non per diretta richiesta dell'utente) andrebbero persi.
9) In effetti, io comunque porrei dei limiti su cid' che pud' essere usato come username o password: sebbene il tuo codice usando le Prepared sia abbastanza sicuro, io non vorrei comunque trovarmi in db degli utenti come "; DROP TABLE users"!

)