Autenticazione integrata sicura con PHP

[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]

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?

[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"!

)

[Flaviors200]

Ti ringrazio per i suggerimenti Shores. Ti rispondo in basso

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

La codifica dei file è utf8, dovresti aprirli con questa codifica.

2) Nelle form, nel caso in cui un input abbia un name = id, allora la name puo' essere omessa.

In realtà l'id l'avevo messo perché inizialmente il form aveva il tag label, poi l'ho rimosso preferendogli l'attributo placeholder.

3) In fase di connessione al db, attenzione al fatto che $e->getMessage() potrebbe mostrare informazioni riservate

Giusto.

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

Giusto, ho dimenticato un check con isset() su username e password prima di utilizzarli in empty().

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.

OK

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

Giusto. L'ho usato per comodità, di solito redireziono l'utente alla pagina referente impostando un messaggio flash in una variabile di sessione.

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.

Giusto.

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.

Ok, diciamo che si potrebbe omettere e fare solo l'unset delle variabili che interessano, ma per lo scopo del tutorial è ok.

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"!

Per lo username sono daccordo (lo aggiungo nelle conclusioni assieme agli altri suggerimenti), per le password a mio parere non serve in quanto andrà salvato l'hash. Si può aggiungere un controllo sulla robustezza della password. Al momento c'è solo quello sulla lunghezza.

)

[Shores]

Ti ringrazio per i suggerimenti Shores. Ti rispondo in basso

1) Non intendevo nei file da scaricare, ma proprio nella pagina web del tutorial, nei box in cui si vede il codice.

2) In ogni caso, anche se avessi una label, il suo attributo for si riferisce ad un id e non ad una name:

https://developer.mozilla.org/en-US/.../Element/label

quindi avresti potuto fare senza le name comunque.

Ciao!