Pagina 2 di 2 primaprima 1 2
Visualizzazione dei risultati da 11 a 18 su 18
  1. #11
    In primo luogo, GRAZIE

    Hai centrato il problema e credo anche la risposta: è impossibile

    Di conseguenza, necessariamente tutti i siti web conoscono la tua password (compreso html.it), e semplicemente "ti devi fidare" che non la conservino.
    (ed è per questo che non bisogna mai usare la stessa password)

    In realtà la soluzione globale ed "elegante" a questo problema ci sarebbe: Microsoft ADFS.
    Purtroppo però la infrastruttura dove mi devo autenticare non l'ha implementata e certamente non lo fa ad hoc per me.


    Correttissima anche l'idea di IIS per cercare sfruttare la integrazione con Windows, infatti è già in cantiere.
    Vediamo se riusciamo a superare il problema in qualche modo.
    In effetti, io provengo più dal "mondo MS" e mi sono rivolto ad Apache + PHP perchè volevo una soluzione completamente "platform independent", qualcosa che non girasse necessariamente solo sotto Windows + IIS e funzionasse con certezza anche su un telefonino.
    Mi sa che dovrò rinunciare, vedremo cosa tiriamo fuori... :-)


    L'obbiettivo finale, sintetizzando al massimo, è lanciare (lato server) dei programmi e principalmente degli script powershell.
    Chiaramente non tutti coloro che si imbattono nella mia pagina devono poterli lanciare.
    Chi è autorizzato a lanciare quegli script?
    Naturalmente, come è prassi molto comune, la risposta è: tutti gli utenti appartenenti ad un gruppo di Active Directory.
    Di conseguenza, le persone che devono accedere alla pagina si autenticano ad essa con le credenziali aziendali, alle quali è legato praticamente tutto, posta elettronica, cloud storage, intranet, cartelle di rete, telefono... tutto.


    E' per questo motivo che è mandatorio il poter garantire che la mia pagina non possa conoscere le credenziali di dominio degli utenti.
    Diversamente, io per primo non scriverei mai la mia password in quel box.

    GRAZIE infinite, a tutti, per il vostro aiuto
    JO

  2. #12
    In primo luogo, GRAZIE
    Hai centrato il problema e credo anche la risposta: è impossibile
    Di conseguenza, necessariamente tutti i siti web conoscono la tua password (compreso html.it), e semplicemente "ti devi fidare" che non la conservino.
    (ed è per questo che non bisogna mai usare la stessa password)

    In realtà la soluzione globale ed "elegante" a questo problema ci sarebbe: Microsoft ADFS.
    Purtroppo però la infrastruttura dove mi devo autenticare non l'ha implementata e certametne non lo fa ad hoc per me.

    Correttissima anche l'idea di IIS per cercare sfruttare la integrazione con Windows, infatti è già in cantiere.
    Vediamo se riusciamo a superare il problema in qualche modo.
    In effetti, io provengo più dal "mondo MS" e mi sono rivolto ad Apache + PHP perchè volevo una soluzione completamente "platform indipendent", qualcosa che non girasse necessariamente solo sotto Windows + IIS e funzionasse con certezza anche su un telefonino.
    Mi sa che dovrò rinunciare, vedremo cosa tiriamo fuori... :-)

    L'obbiettivo finale, sintetizzando al massimo, è lanciare (lato server) dei programmi e principalmente degli script powershell.
    Chiaramente non tutti coloro che si imbattono nella mia pagina devono poterli lanciare.
    Chi è autorizzato a lanciare quegli script?
    Naturamente, come è prassi molto comune, la risposta è: tutti gli utenti appartenti ad un gruppo di Active Directory.
    Di conseguenza, le persone che devono accedere alla pagina si autenticano ad essa con le credenziali aziendali, alle quali è legato praticamente tutto, posta elettronica, cloud storage, intranet, cartelle di rete, telefono... tutto.

    E' per questo motivo che è mandatorio il poter garantire che la mia pagina non possa conoscere le credenziali di dominio degli utenti.
    Diversamente, io per primo non scriverei mai la mia password in quel box.

    GRAZIE infinite, a tutti, per il vostro aiuto
    JO

  3. #13
    In primo luogo, GRAZIE
    Hai centrato il problema e credo anche la risposta: è impossibile
    Di conseguenza, necessariamente tutti i siti web conoscono la tua password (compreso html.it), e semplicemente "ti devi fidare" che non la conservino.
    (ed è per questo che non bisogna mai usare la stessa password)
    In realtà la soluzione globale ed "elegante" a questo problema ci sarebbe: Microsoft ADFS.
    Purtroppo però la infrastruttura dove mi devo autenticare non l'ha implementata e certametne non lo fa ad hoc per me.
    Correttissima anche l'idea di IIS per cercare sfruttare la integrazione con Windows, infatti è già in cantiere.
    Vediamo se riusciamo a superare il problema in qualche modo.
    In effetti, io provengo più dal "mondo MS" e mi sono rivolto ad Apache + PHP perchè volevo una soluzione completamente "platform indipendent", qualcosa che non girasse necessariamente solo sotto Windows + IIS e funzionasse con certezza anche su un telefonino.
    Mi sa che dovrò rinunciare, vedremo cosa tiriamo fuori... :-)
    L'obbiettivo finale, sintetizzando al massimo, è lanciare (lato server) dei programmi e principalmente degli script powershell.
    Chiaramente non tutti coloro che si imbattono nella mia pagina devono poterli lanciare.
    Chi è autorizzato a lanciare quegli script?
    Naturamente, come è prassi molto comune, la risposta è: tutti gli utenti appartenti ad un gruppo di Active Directory.
    Di conseguenza, le persone che devono accedere alla pagina si autenticano ad essa con le credenziali aziendali, alle quali è legato praticamente tutto, posta elettronica, cloud storage, intranet, cartelle di rete, telefono... tutto.
    E' per questo motivo che è mandatorio il poter garantire che la mia pagina non possa conoscere le credenziali di dominio degli utenti.
    Diversamente, io per primo non scriverei mai la mia password in quel box.
    GRAZIE infinite, a tutti, per il vostro aiuto
    JO

  4. #14
    Utente di HTML.it
    Registrato dal
    Jan 2019
    residenza
    Sicilia
    Messaggi
    86
    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.



    Dici? Dunque stai affermando che salvare la password hashata oppure in chiaro non fa differenza


    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.
    Non puoi evitare di conoscere la password in chiaro.
    Quando un utente si registra io non conosco la sua password, anche se la stampassi a video (in questo caso la vede solo lui). L'unico modo è salvarla in chiaro nel DB o farsela mandare per email.

    Mi sfugge comunque il problema che ti poni. Quando ad esempio scrivi

    neppure in questo caso potrei garantire di non salvare le password in chiaro.
    ritorniamo al punto di partenza...

    Se il sistema lo gestisci tu e hai cattive intenzioni, con le password ci fai quello che vuoi, con tutti i rischi che ne seguono.

    Ma tu non sei un utente malintenzionato, dunque adotterai le migliori pratiche per garantire la sicurezza dell'applicazione.

  5. #15
    Utente di HTML.it
    Registrato dal
    Jan 2019
    residenza
    Sicilia
    Messaggi
    86
    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.

    Dici? Dunque stai affermando che salvare la password hashata oppure in chiaro non fa differenza


    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.
    Non puoi evitare di conoscere la password in chiaro.
    Quando un utente si registra io non conosco la sua password, anche se la stampassi a video (in questo caso la vede solo lui). L'unico modo è salvarla in chiaro nel DB o farsela mandare per email.

    Mi sfugge comunque il problema che ti poni. Quando ad esempio scrivi

    neppure in questo caso potrei garantire di non salvare le password in chiaro.
    ritorniamo al punto di partenza...

    Se il sistema lo gestisci tu e hai cattive intenzioni, con le password ci fai quello che vuoi, con tutti i rischi che ne seguono.

    Ma tu non sei un utente malintenzionato, dunque adotterai le migliori pratiche per garantire la sicurezza dell'applicazione.

  6. #16
    In primo luogo, GRAZIE
    Hai centrato il problema e credo anche la risposta: è impossibile
    Di conseguenza, necessariamente tutti i siti web conoscono la tua password (compreso html.it), e semplicemente "ti devi fidare" che non la conservino.
    (ed è per questo che non bisogna mai usare la stessa password)

    In realtà la soluzione globale ed "elegante" a questo problema ci sarebbe: Microsoft ADFS.
    Purtroppo però la infrastruttura dove mi devo autenticare non l'ha implementata e certametne non lo fa ad hoc per me.

    Correttissima anche l'idea di IIS per cercare sfruttare la integrazione con Windows, infatti è già in cantiere.
    Vediamo se riusciamo a superare il problema in qualche modo.
    In effetti, io provengo più dal "mondo MS" e mi sono rivolto ad Apache + PHP perchè volevo una soluzione completamente "platform indipendent", qualcosa che non girasse necessariamente solo sotto Windows + IIS e funzionasse con certezza anche su un telefonino.
    Mi sa che dovrò rinunciare, vedremo cosa tiriamo fuori... :-)

    L'obbiettivo finale, sintetizzando al massimo, è lanciare (lato server) dei programmi e principalmente degli script powershell.
    Chiaramente non tutti coloro che si imbattono nella mia pagina devono poterli lanciare.
    Chi è autorizzato a lanciare quegli script?
    Naturamente, come è prassi molto comune, la risposta è: tutti gli utenti appartenti ad un gruppo di Active Directory.
    Di conseguenza, le persone che devono accedere alla pagina si autenticano ad essa con le credenziali aziendali, alle quali è legato praticamente tutto, posta elettronica, cloud storage, intranet, cartelle di rete, telefono... tutto.

    E' per questo motivo che è mandatorio il poter garantire che la mia pagina non possa conoscere le credenziali di dominio degli utenti.
    Diversamente, io per primo non scriverei mai la mia password in quel box.

    GRAZIE infinite, a tutti, per il vostro aiuto
    JO

  7. #17
    Utente di HTML.it
    Registrato dal
    Jan 2019
    residenza
    Sicilia
    Messaggi
    86
    Ti ringrazio per i suggerimenti Shores. Ti rispondo in basso

    Quote Originariamente inviata da Shores Visualizza il messaggio
    (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.

    )
    Ultima modifica di Flaviors200; 07-10-2019 a 18:21

  8. #18
    Quote Originariamente inviata da Flaviors200 Visualizza il messaggio
    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!
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.