+ Rispondi alla Discussione
Pagina 1 di 2 12 UltimaUltima
Risultati da 1 a 50 di 62

[Tutorial] La Gestione degli utenti in PHP e MySQL

Ultimo Messaggio di webalex il:
  1. #1
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142

    [Tutorial] La Gestione degli utenti in PHP e MySQL

    Cosa è un progetto?

    Concetti Base per un Sistema di Log

    Innanzitutto delineamo le principali caratteristiche dello script:

    1) Comunicazione a connessioni persistenti a MySQL
    2) Utilizzo di sessioni

    Poi, si deve pensare a come deve essere suddiviso:

    1) Registrazione
    2) Log In
    3) Recupero della password
    4) Log Out
    5) Riconoscimento dell'utente
    6) Modifica del profilo

    Però però... Esiste un dilemma!!! le sessioni... su file o nel db???

    Certo, su file è più comodo... Però, come disse il nostro amato Rasmus Lerdorf, << Non c'è niente di più sicuro di un database >>. Spetterà a noi, se vogliamo, implementare questo "optional" mediante la creazione di funzioni.

  2. #2
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    La Gestione Del Database

    La gestione del database è la prima cosa di cui ci si deve occupare, per poi poter sviluppare uno script ottimale. Bisogna quindi preparare una tabella che deve essere composta almeno di questi elementi:

    1) ID dell'utente -> uID
    2) Nome dell'utente -> uNAME
    3) Password dell'utente -> uPWD

    Che costituiranno dei campi che avranno più o meno questa struttura:

    uID -> ID -> INT(20) - Unsigned - NOT NULL - AutoIncrement - Primary
    uNAME -> Nome -> VARCHAR(20) - NOT NULL
    uPWD -> Password -> VARCHAR(20) - NOT NULL

    Noterete che... uID ha l'attributo AutoIncrement e quindi ad ogni inserimento questo campo si aggiornerà incrementadosi di 1. E' di tipo INT, con una lunghezza di 20 e non è nullo. La utilizzeremo come chiave primaria per una ricerca più rapida con SELECT.

    Questa tabella può essere creata facilmente da una query del genere:

    Codice:
    -- Considerando come la tabella verrà chiamata "utenti"
    CREATE TABLE `utenti` &#40;
    
     -- Creiamo in campo per l'ID dell'utente
     `uID` INT&#40; 20 &#41; UNSIGNED NOT NULL AUTO_INCREMENT ,
    
     -- Creiamo il campo per il nome utente
     `uNAME` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Creiamo il campo per la password
     `uPWD` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Stabiliamo come chiave primaria il campo uID
     PRIMARY KEY &#40; `uID` &#41;
    &#41;;
    Naturalmente se vogliamo possiamo anche aggiungere altri dati, tipo:

    1) Email
    2) Numero di casa
    3) Interessi
    5) Professione
    ...
    ...

    Questi ultimi campi li possiamo mettere tranquillamente insieme agli altri 3 sopra descritti, oppure creare una tabella a parte. Se noi vogliamo mettere tutto in una tabella, dovremo creare una tabella di questo tipo:

    uID -> ID -> INT(20) - Unsigned - NOT NULL - AutoIncrement - Primary
    uNAME -> Nome -> VARCHAR(20) - NOT NULL
    uPWD -> Password -> VARCHAR(20) - NOT NULL
    uMAIL -> Email -> VARCHAR(20) - NOT NULL
    uNUM -> Numero telefonico -> VARCHAR(20) - NOT NULL
    uHOBBIES -> Interessi -> TEXT - NOT NULL
    uJOB -> Professione -> VARCHAR(20) - NOT NULL

    Noterete che:
    1) uID ha l'attributo AutoIncrement e quindi ad ogni inserimento questo campo si aggiornerà incrementadosi di 1. E' di tipo INT, con una lunghezza di 20 e non è nullo. La utilizzeremo come chiave primaria per una ricerca più rapida con SELECT.

    2) Tutti gli altri ( ad eccezione di uHOBBIES ) sono VARCHAR ed hanno una lunghezza massima di 20. Anche questi non sono nulli.

    3) uHOBBIES è di tipo TEXT, e quindi prevede del testo di dimensioni più grandi.

    Perciò... La nostra query dovrebbe essere all'incirca così:

    Codice:
    -- Considerando come la tabella verrà chiamata "utenti"
    CREATE TABLE `utenti` &#40;
    
    
     -- Creiamo in campo per l'ID dell'utente
     `uID` INT&#40; 20 &#41; UNSIGNED NOT NULL AUTO_INCREMENT ,
    
     -- Creiamo il campo per il nome utente
     `uNAME` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Creiamo il campo per la password
     `uPWD` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Creiamo il campo per l'Email
     `uMAIL` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Creiamo il campo per il numero telefonico
     `uNUM` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Creiamo il campo per gli interessi
     `uHOBBIES` TEXT NOT NULL ,
    
     -- Creiamo il campo per la professione
     `uJOB` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Stabiliamo come chiave primaria il campo uID
     PRIMARY KEY &#40; `uID` &#41;
    &#41;;
    Ma se invece vogliamo essere più ordinati e creare una tabella a parte per le cose personali dell'utente? Si può, ma dobbiamo aggiungere il campo uID anche in questa tabella per ricollegarci all'altra tabella; ed avremo quindi uno schema così:

    uID -> ID utente -> INT(20) - Unsigned - NOT NULL - Autoincrement - Primary
    uMAIL -> Email -> VARCHAR(20) - NOT NULL
    uNUM -> Numero telefonico -> VARCHAR(20) - NOT NULL
    uHOBBIES -> Interessi -> TEXT - NOT NULL
    uJOB -> Professione -> VARCHAR(20) - NOT NULL

    La nostra tabella si può creare mediante l'utilizzo di una query così:

    Codice:
    -- Considerando come la tabella verrà chiamata "info"
    CREATE TABLE `info` &#40;
    
     -- Creiamo in campo per l'ID dell'utente
     `uID` INT&#40; 20 &#41; UNSIGNED NOT NULL AUTO_INCREMENT ,
    
     -- Creiamo il campo per l'Email
     `uMAIL` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Creiamo il campo per il numero telefonico
     `uNUM` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Creiamo il campo per gli interessi
     `uHOBBIES` TEXT NOT NULL ,
    
     -- Creiamo il campo per la professione
     `uJOB` VARCHAR&#40; 20 &#41; NOT NULL ,
    
     -- Stabiliamo come chiave primaria il campo uID
     PRIMARY KEY &#40; `uID` &#41;
    &#41;;
    Noterete che... uID ha anche qui l'attributo autoincrement che gli permette di mettersi automaticamente alla pari dell'inserimento nell'altra tabella.

    Naturalmente nel caso di una gestione di questo tipo le query che devono essere eseguite sono ben 2 per 'inserimento: una si occuperà di inserire i dati primari dell'utente, l'altra di inserire le informazioni personali. Per ricevere le informazioni l'operazione diventa un pò più complicata, dato che: Prima ci dobbiamo prendere l'ID dell'utente con una SELECT nella tabella "utenti"; Poi facciamo una SELECT nella tabella "info" inserendo l'ID e prendendoci le informazioni di quel determinato utente.

    Ora che il db è stato preparato ci possiamo anche occupare dello script base, al quale spero ci sia una partecipazione di tutti gli utenti, in modo tale da avere più opinioni, più idee e meno lavoro per tutti

    Vi prego di analizzare bene le parti del sistema che volete approfondire e magari aggiornare prima di intervenire.

  3. #3
    User
    Data Registrazione
    Mar 2005
    Messaggi
    503
    ciao pater,

    intervengo per dire la mia sul progetto.

    L'unico appunto che mi viene da fare è sulla divisione in 2 tabelle. Perchè la fai? Come fai notare tu c'è il problema del raddoppio delle query, questo ha anche la spiacevole conseguenza che se malauguratamente la seconda query non va a buon fine (nel caso ad es di un inserimento) avremmo un utente "zoppo" (cioè con solo il record della prima tabella)

    Poi volendo essere pignoli non si rispettano le forme normali, cosa che per praticità si può cmq fare, ma in questo caso non ne vedo i vantaggi

    Altra cosa cosina:

    cosa intendi per "sessioni con file o db" ?


  4. #4
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Lo so per la seconda tabella, l'ho messa solo per dare uno spunto in caso di applicazioni più complicate che la richiessero ( in questo caso non ne vale la pena comunque ). Per le sessioni... Come saprai ci sono 2 tipi di sessioni:

    Quelle su File
    Ovvero quelle che ha integrato PHP dalla versione 4, e memorizza le variabili di sessione in una data cartella col nome di sess_ più una stringa esadecimale di 10 caratteri ( se non mi ricordo male ). Questa Gestione però non viene considerata ottimale, perchè è un pò scadente in termini di sicurezza. Per questo oggi molti preferiscono usare le...

    Sessioni Alternative
    Ovvero quelle che possiamo creare NOI, quindi naturalmente non c'è nessun modulo che le rende disponibili. Queste sessioni alternative vengono chiamate così perchè emulano il vero sistema delle sessioni ma le memorizzano in un DB MySQL. Naturalmente la creazione di una classe semplifica molto la gestione di queste sessioni; anche io ne ho creata una per le mie esigenze, se volete la pubblicherò con un piccolo tutorial su questo tipo di sessioni...

    Quindi ero dubbioso sul sistema di gestione della sessione che vorrete utilizzare...

  5. #5
    User
    Data Registrazione
    Mar 2005
    Messaggi
    503
    non avevo mai approfondito l'argomento in realtà.....


    cmq sembra abbastanza interessante.

    Per quel poco che ho letto, se devi gestirele tu, tanto vale usare il db, xò a quanto pare hai più esperienza in questo campo, quindi a te la scelta!

  6. #6
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    Mi aggrego al progetto....prontissimo a programmare!

    So fare tutta la parte che non comprende le sessioni.

    Di sessioni ne so molto poco!


  7. #7
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Tuonorosso
    Mi aggrego al progetto....prontissimo a programmare!

    So fare tutta la parte che non comprende le sessioni.

    Di sessioni ne so molto poco!

    riki, io ho solo dato le linee guida, ora tocca anche a voi aiutarci!! Sennò che progetto è?

    Grande Tuonorosso, vedi se c'è qualcosa in particolare che intendi sviluppare, vediamo quanti saranno disposti a collaborare!!!

  8. #8
    User
    Data Registrazione
    Mar 2005
    Messaggi
    503
    Citazione Originariamente Scritto da PaTeR
    riki, io ho solo dato le linee guida, ora tocca anche a voi aiutarci!! Sennò che progetto è?
    purtroppo ora non ho assolutamente il tempo quindi mi limito a dare consigli in generale......


    preferisco fare lavorare voi!!

  9. #9
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da riky78

    purtroppo ora non ho assolutamente il tempo quindi mi limito a dare consigli in generale......


    preferisco fare lavorare voi!!

  10. #10
    Banned
    Data Registrazione
    Apr 2005
    Messaggi
    2,073
    Citazione Originariamente Scritto da PaTeR
    Grande Tuonorosso, vedi se c'è qualcosa in particolare che intendi sviluppare, vediamo quanti saranno disposti a collaborare!!!
    Conta pure anche me, solo un paio di giorni per sbrigare due cosette e poi mi dedico anche a questo progetto con quel poco che so.

    Io ho sviluppato su di un sito una cosa del genere, ma è moolto elementare, posso partire da lì per vedere come si può migliorare.


  11. #11
    L'avatar di LowLevel
    Data Registrazione
    Mar 2005
    Località
    Milano
    Messaggi
    1,542
    Citazione Originariamente Scritto da PaTeR
    Naturalmente nel caso di una gestione di questo tipo le query che devono essere eseguite sono ben 2 per 'inserimento: una si occuperà di inserire i dati primari dell'utente, l'altra di inserire le informazioni personali. Per ricevere le informazioni l'operazione diventa un pò più complicata, dato che: Prima ci dobbiamo prendere l'ID dell'utente con una SELECT nella tabella "utenti"; Poi facciamo una SELECT nella tabella "info" inserendo l'ID e prendendoci le informazioni di quel determinato utente.
    Perché due SELECT separate quando si può fare con una sola?

    Aggiungo anche che l'idea di gestire gli ID di sessione col database è ottima, sopratutto per ragioni di sicurezza, tuttavia implementare questa soluzione per poi archiviare in chiaro le password è un po' come sbarrare tutte le finestre di casa lasciando però aperta la porta principale.

    Ben vengano gli ID di sessione nel database, ma la stessa scrupolosità e attenzione alla sicurezza dovrebbe imporre l'esclusione di password in chiaro nel database.

    Inoltre, quando l'utente inserisce la password nel form, come viene inviata la medesima al server? In chiaro? Non si fa!

    E se io scopro in qualche modo l'ID di sessione di un utente e provo a collegarmi al server spedendo quell'ID, come fa il sistema ad evitare di scambiarmi per quell'utente?


    Non vorrei aver equivocato le finalità del progetto. Se si tratta di un semplice script per il riconoscimento degli utenti, allora non è il caso di preoccuparsi. Ma se una maggiore sicurezza rientra nelle caratteristiche che si desidera implementare, allora bisogna pensare ad un bel po' di cose oltre a quelle già citate.

  12. #12
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da LowLevel
    Citazione Originariamente Scritto da PaTeR
    Naturalmente nel caso di una gestione di questo tipo le query che devono essere eseguite sono ben 2 per 'inserimento: una si occuperà di inserire i dati primari dell'utente, l'altra di inserire le informazioni personali. Per ricevere le informazioni l'operazione diventa un pò più complicata, dato che: Prima ci dobbiamo prendere l'ID dell'utente con una SELECT nella tabella "utenti"; Poi facciamo una SELECT nella tabella "info" inserendo l'ID e prendendoci le informazioni di quel determinato utente.
    Perché due SELECT separate quando si può fare con una sola?

    Aggiungo anche che l'idea di gestire gli ID di sessione col database è ottima, sopratutto per ragioni di sicurezza, tuttavia implementare questa soluzione per poi archiviare in chiaro le password è un po' come sbarrare tutte le finestre di casa lasciando però aperta la porta principale.

    Ben vengano gli ID di sessione nel database, ma la stessa scrupolosità e attenzione alla sicurezza dovrebbe imporre l'esclusione di password in chiaro nel database.

    Inoltre, quando l'utente inserisce la password nel form, come viene inviata la medesima al server? In chiaro? Non si fa!

    E se io scopro in qualche modo l'ID di sessione di un utente e provo a collegarmi al server spedendo quell'ID, come fa il sistema ad evitare di scambiarmi per quell'utente?


    Non vorrei aver equivocato le finalità del progetto. Se si tratta di un semplice script per il riconoscimento degli utenti, allora non è il caso di preoccuparsi. Ma se una maggiore sicurezza rientra nelle caratteristiche che si desidera implementare, allora bisogna pensare ad un bel po' di cose oltre a quelle già citate.
    Intendi usare Javascript per codificare la password?

    Comunque fai degli esempi per favore, sinceramente non ci avevo mai pensato a quello che dici tu... Per il momento non ho nessuna idea tranne l'uso di una connessione SSL...

  13. #13
    L'avatar di LowLevel
    Data Registrazione
    Mar 2005
    Località
    Milano
    Messaggi
    1,542
    Intendi usare Javascript per codificare la password?
    Sì. Questo non elimina del tutto il problema ma lo riduce almeno nell'80% dei casi, ad occhio e croce.

    Se vuoi, spiego. Ma ti anticipo che sarò costretto a scrivere un bel po' di roba, per spiegare come funziona (il codice finale sarà invece pochissimo), quindi decidi tu se è il caso di introdurre queste caratteristiche al progetto o se queste spiegazioni lo complicherebbero troppo.

  14. #14
    User L'avatar di linus
    Data Registrazione
    Apr 2005
    Località
    Bergamo
    Messaggi
    125
    Citazione Originariamente Scritto da LowLevel
    E se io scopro in qualche modo l'ID di sessione di un utente e provo a collegarmi al server spedendo quell'ID, come fa il sistema ad evitare di scambiarmi per quell'utente?
    E' un pò difficile fare una cosa del genere, però credo che in questo caso il sistema penserà che tu sei quell'utente per cui avrai accesso.

    Mi sono gia dedicato alla realizzazione dell'autenticazione utente. Però girato e rigirato nell'ID di sessione le password sono in chiaro. Per cui quello che ho fatto io non può essere considerata una soluzione professionale.

  15. #15
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    Citazione Originariamente Scritto da LowLevel
    Perché due SELECT separate quando si può fare con una sola?
    Concordo pienamente anche perchè se fai un semplice schema E-R ti accorgi subito che non ha senso avere 2 tabelle.

    Citazione Originariamente Scritto da LowLevel
    Aggiungo anche che l'idea di gestire gli ID di sessione col database è ottima, sopratutto per ragioni di sicurezza, tuttavia implementare questa soluzione per poi archiviare in chiaro le password è un po' come sbarrare tutte le finestre di casa lasciando però aperta la porta principale.
    Se non sbaglio in MySQL c'è un bel comandino MD5(password) per inserire la pw criptata nel db...

    Citazione Originariamente Scritto da LowLevel
    Inoltre, quando l'utente inserisce la password nel form, come viene inviata la medesima al server? In chiaro? Non si fa!
    Vero vero...

    Citazione Originariamente Scritto da LowLevel
    E se io scopro in qualche modo l'ID di sessione di un utente e provo a collegarmi al server spedendo quell'ID, come fa il sistema ad evitare di scambiarmi per quell'utente?
    mmmm, si potrebbe fare il controllo incrociato ip-sessione.
    Ossia, arrivo, mi loggo, inserisco sessione e ip nel db e poi ad ogni pagina controllo questa coppia...
    sono ?

    Citazione Originariamente Scritto da LowLevel
    Non vorrei aver equivocato le finalità del progetto. Se si tratta di un semplice script per il riconoscimento degli utenti, allora non è il caso di preoccuparsi. Ma se una maggiore sicurezza rientra nelle caratteristiche che si desidera implementare, allora bisogna pensare ad un bel po' di cose oltre a quelle già citate.
    Ovviamente non si vuol fare uno scrippettino scolastico...sarebbe troppo semplice

  16. #16
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    Citazione Originariamente Scritto da LowLevel
    Intendi usare Javascript per codificare la password?
    Se vuoi, spiego. Ma ti anticipo che sarò costretto a scrivere un bel po' di roba, per spiegare come funziona (il codice finale sarà invece pochissimo), quindi decidi tu se è il caso di introdurre queste caratteristiche al progetto o se queste spiegazioni lo complicherebbero troppo.

  17. #17
    L'avatar di LowLevel
    Data Registrazione
    Mar 2005
    Località
    Milano
    Messaggi
    1,542
    Citazione Originariamente Scritto da linus
    Citazione Originariamente Scritto da LowLevel
    E se io scopro in qualche modo l'ID di sessione di un utente e provo a collegarmi al server spedendo quell'ID, come fa il sistema ad evitare di scambiarmi per quell'utente?
    E' un pò difficile fare una cosa del genere
    A seconda dei casi, può rivelarsi facilissimo.

    Ad esempio, molte installazioni si PHP sono configurate in modo da accodare automaticamente ad ogni URL un parametro con l'ID di sessione nel caso in cui l'utente non abbia i cookie attivi.

    Nel momento in cui gli ID di sessione appaiono negli URL, basta seguire un qualsiasi link verso un altro sito con il referer attivo nel browser per far memorizzare nei log del sito di destinazione l'ID usato dall'utente sul sito da cui proviene.


    Concordo pienamente anche perchè se fai un semplice schema E-R ti accorgi subito che non ha senso avere 2 tabelle.
    Io mi riferivo al fatto che si può usare una singola SELECT anche in presenza di due tabelle.


    Se non sbaglio in MySQL c'è un bel comandino MD5(password) per inserire la pw criptata nel db...
    La soluzione passa infatti da algoritmi per il calcolo di checksum, come md5(), ma c'è modo di aumentare ulteriormente la sicurezza facendo qualcosa in più oltre alla semplice memorizzazione dell'md5() della password.


    Ossia, arrivo, mi loggo, inserisco sessione e ip nel db e poi ad ogni pagina controllo questa coppia...
    Infatti si fa così. Ma per coprire anche i casi in cui più utenti siano dietro lo stesso firewall/proxy e presentino quindi lo stesso IP, può essere una buona idea aggiungere qualche controllo sull'user-agent. Ma solo in alcuni casi.


    Ovviamente non si vuol fare uno scrippettino scolastico...sarebbe troppo semplice
    Io sto attendendo un nulla-osta perché è la prima volta che leggo di questi vostri progetti e non ho idea di come funzionino. Cioè, non so se bisogna attenersi alla traccia fornita da PaTeR oppure se può essere ampliata. Per tale ragione, aspetto chiarimenti da PaTeR, che mi pare sia il promotore del progetto.

  18. #18
    User Attivo
    Data Registrazione
    Dec 2004
    Località
    abito sulla luna e ogni volta che mi telefono è un'interrurbana
    Messaggi
    2,413
    in un caso studio si cerca di trovare assieme la soluzione migliore rimanendo in bilico tra la funzionalità del progetto e gli esempi "a scopo didattico".


    la relazione uno a uno tra due tabelle, personalmente, viene usata quando mi trovo a dover interrogare una tabella da più di 20 campi (numero indicativo) dove i campi che effettivamente mi interessano sono pochissimi (2 o 3) ed il numero di record è potenzialmente elevato.

    Per dare un esempio concreto su cui ragionare senza inventarsi un progetto ad hoc per spiegare il concetto, l'anagrafica utenti calza a pennello.

    Se l'anagrafica utenti avesse tutti i campi necessari per memorizzare vita morte e miracoli degli utenti (indirizzi, vari numeri di telefono, vari siti email e chi più ne ha più ne metta) e si raggiunge una dimensione di 30-40 campi per fare semplicemente il login non voglio far girare un tabellone così grande ed in questo caso separo le due tabelle in una striminzita che quindi sarà snella e veloce e l'altra (più grossa e lenta) che verrà interrogata solo quando saranno effettivamente necessarie tutte le info.

    pro e contro:

    pro:
    una maggiore velocità di esecuzione quando faccio il login perchè devo interrogare una tabellina di pochi campi e ben indicizzata (gli indici li vedremo quando analiziamo come fare le tabelle nel dettaglio).

    contro:
    una lentezza leggermente maggiore quando il motore deve estrarre i dati completi del singolo utente in quanto dovrà risolvere un join.


    l'interrogazione nel primo caso sarà:
    select * from utenti where (condizioni)

    nel secondo sarà:
    select (dati che mi interessano) from utenti, utenti_info_aggiuntive where utenti.id = utenti_info_aggiuntive.id_utente where (condizioni)


    pareri?

  19. #19
    L'avatar di LowLevel
    Data Registrazione
    Mar 2005
    Località
    Milano
    Messaggi
    1,542
    Citazione Originariamente Scritto da Tymba
    pareri?
    Sì. Che oltre al motivo indicato da te, la soluzione multi-tabella è generalmente indicata per progetti destinati a possibili ampliamenti.

    Se un sito possiede forum, blog e sondaggi e tutti e tre questi servizi beneficiano dell'autenticazione degli utenti, ha senso creare una tabella con le informazioni generiche e valevoli per tutti i servizi (username, password, IP, ecc.) ed una tabella in più per ciascuno dei servizi esistenti, contenente solo le informazioni-utente relative al servizio al quale la tabella è dedicata.

    Se un domani sarà necessario aggiungere un guestbook o un modulo per spedirsi messaggi privati, ci si limita a creare una nuova tabella per il nuovo servizio, senza toccare nessuna di quelle già esistenti.

    Separare le informazioni relative all'autenticazione da quelle aggiuntive e non essenziali all'autenticazione è sempre una buona idea. Anche perché la tabella con le informazioni per l'autenticazione subisce query continue, anche una ad ogni caricamento di pagina, a seconda dell'implementazione. Meglio che sia piccola, come dicevi tu.

  20. #20
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142

    @ Lowlevel

    @ LowLevel: E' vero che io ho scritto il post, ma il progetto era già stato studiato tra i mods, quindi non seguire solo me, ma anche tutti gli altri mods.

    Io ho solo dato una mano su come realizzare il DB, voi potete seguire quella traccia oppure potete modificarla a vostro piacimento.

    Preferirei che questo progetto avesse anche finalità didattiche, come se fosse una vera pillola, in quanto sarebbe più facile da comprendere e da modificare o estendere. Quindi non sarebbe male se scriveste un pò di righe in più nel vostro post anche per spiegare cosa state facendo e come lo state facendo.

    Per il fatto della password mandata in chiaro, sarebbe una buona cosa se ci spiegassi come fare per mandarla già criptata, perchè ripeto: tutto ciò che può riguardare un sistema di gestioni utenti è meglio inserirlo. E la sicurezza mi sembra rientrare in questi



    Non fatevi venire strane idee su come un moderatore vedrà il vostro messaggio: al massimo vi aiuterà a migliorarlo, di certo non vi

  21. #21
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    http://pajhome.org.uk/crypt/md5/

    E' usato per convertire in MD5 tramite Javascript

  22. #22
    L'avatar di LowLevel
    Data Registrazione
    Mar 2005
    Località
    Milano
    Messaggi
    1,542
    Ok, PaTeR, adesso mi è chiaro. Grazie dei chiarimenti.

    Espongo quello che farei io per migliorare la sicurezza del sistema di autenticazione. Visto che sono ancora allo stadio progettuale, a mio parere è presto per scrivere codice. Penso che sia il caso di farlo solo dopo aver raggiunto un accordo comune sul sistema da implementare, che può variare a seconda del contributo di tutti gli interessati.


    Problema: la password non dovrebbe essere trasmessa in modo tale che un eventuale intercettatore la possa utilizzare per loggarsi.


    Considerazioni: è evidente che limitarsi a criptare la password con un algoritmo come md5() e progettare il sistema in modo che il server accetti dal login dell'utente la password criptata con md5() non serve a nulla, perché se il sistema si accontenta della password criptata con md5() allora è sufficiente che l'intercettatore intercetti la password criptata e la invii al server. In poche parole il livello di sicurezza non è stato aumentato di una virgola rispetto all'uso della password in chiaro. [parlare di criptazione con md5() è improprio, ma sorvoliamo per semplicità]


    Soluzione: la password inserita dall'utente non va trasmessa in nessun modo. Al contrario, è meglio trasmettere un'informazione (che chiameremo "informazione combinata") che si basa sia sulla password inserita dall'utente sia su un valore/stringa casuale, generato dal server ad ogni login e che solo il server conosce. Il calcolo di questo valore combinato spetta a Javascript e viene effettuato prima di spedire i contenuti del form di login.

    Quando l'informazione combinata viene ricevuta dal server, il server controlla se essa è identica a quella che viene fuori combinando la stringa casuale precedentemente generata, che il server deve conoscere, con la password dell'utente, che in teoria dovrebbe essere presente nel database. In altre parole il server fa lo stesso calcolo fatto precedentemente dal Javascript, ma usando la password archiviata invece di quella inserita dall'utente (e che il form non spedisce): se il valore ricevuto e quello calcolato coincidono, allora l'utente ha inserito la giusta password.

    Nasce però il problema che, per effettuare il calcolo, il server deve essere a conoscenza della password dell'utente. Ma memorizzare la password in chiaro nell'archivio non è una buona regola. Pertanto si introduce un livello di criptazione in più in modo che l'informazione combinata venga calcolata (sia dal Javascript che dal server) non combinando il valore casuale con la password in chiaro bensì combinando il valore casuale con un md5() della password. Il server quindi si può accontentare di memorizzare in archivio non la password in chiaro ma il suo md5(), ed il problema è risolto.


    Sicurezza: se l'intercettatore intercetta l'informazione combinata, non se ne fa nulla. Quando l'intercettatore prova a fare il login, il server creerà infatti un valore casuale diverso rispetto a quello generato in precedenza per l'utente. Il server si aspetta di ricevere un'informazione combinata che si basa sul nuovo valore casuale, ma l'intercettatore ha in mano solo un'informazione combinata generata in base ad un precedente valore causale. Quindi gli è impossibile effettuare il login con quello che ha intercettato.


    Implementazione:

    • Al login, il server genera un valore casuale, lo memorizza in una variabile di sessione e lo scrive fisicamente nel codice Javascript contenuto nella pagina, assegnandolo ad una variabile Javascript.
    • Quando l'utente invia il form con i dati, viene chiamata una funzione Javascript che calcola innanzitutto l'md5() della password, e poi l'informazione combinata, ovvero l'md5() del "valore casuale più l'md5() della password".
    • I contenuti del campo della password nel form vengono cancellati e la funzione Javascript assegna l'informazione combinata ad un campo hidden del form.
    • I contenuti del form vengono finalmente inviati al server attraverso il metodo post.
    • L'eventuale intercettatore intercetta il valore combinato, ma non se ne farà nulla.
    • Il server riceve il valore combinato e controlla che sia effettivamente ciò che esce fuori facendo l'md5() del valore casuale (che sta in una variabile di sessione) con l'md5() della password (che sta nel database).
    • Se i valori corrispondono allora l'utente ha inserito la giusta password e il sistema di autenticazione considera l'utente autenticato.



    Note informatiche: che cosa diavolo è questo md5()? md5() è un algoritmo che, partendo da una stringa di byte di qualunque lunghezza, genera una stringa di sedici byte che può essere considerata l'impronta digitale (in gergo chiamata hash o fingerprint) della stringa di partenza.

    L'md5() non è un algoritmo di criptazione che permette di risalire dall'impronta alla stringa originale, perché ad ogni impronta corrispondono infinite stringhe di partenza. In altre parole, non c'è una corrispondenza uno-ad-uno tra stringa di partenza ed impronta bensì una corrispondenza molti-ad-uno, ovvero stringhe di partenza diverse possono generare impronte identiche.

    Nonostante questa limitazione, dovuta al semplice fatto che le combinazioni in sedici byte sono tante ma pur sempre finite, l'algoritmo è stato progettato in modo tale che variazioni minime nella stringa di partenza generino variazioni gigantesche nelle impronte corrispondenti. Quindi non c'è pericolo che l'md5() della password "pippo" sia simile a quello della password "peppo": le impronte delle due stringhe saranno completamente diverse.

    Questo implica che, pur progettando un sistema di autenticazione che archivia non le password ma le impronte md5() delle password, è estremamente improbabile che qualcuno becchi una password che generi lo stesso valore md5() della vera password dell'utente.

  23. #23
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Davvero Ottimo

    Ora non resta che l'implementazione in JS...

  24. #24
    L'avatar di LowLevel
    Data Registrazione
    Mar 2005
    Località
    Milano
    Messaggi
    1,542
    Codice HTML del form di login:

    Codice:
    <form name="login" method="post" action="<? echo $_SERVER&#91;'PHP_SELF'&#93;; ?>" onsubmit="encrypt&#40;&#41;;">
    
    Nome utente&#58;
    <input type="text" name="username">
    
    Parola di accesso&#58;
    <input type="password" name="pw">
    
    <input type="hidden" name="md5ed" value="">
    <input type="hidden" name="login" value="1">
    <input type="submit" value="Accedi">
    
    </form>

    Codice Javascript:

    Codice:
    <script type="text/javascript" src="md5.js"></script>
    <script type="text/javascript">
    <!--
    	function encrypt &#40;&#41; &#123;
    		<? echo "var challengeword = '" . $_SESSION&#91;'challengeword'&#93; . "' ;" ; ?>
    
    		var pw = document.login.pw.value ;
    
    		if &#40;pw&#41; &#123;
    			pw = md5 &#40;pw&#41; ;
    			pw = md5 &#40;pw + challengeword&#41; ;
    			document.login.pw.value = '' ;
    			document.login.md5ed.value = pw ;
    		&#125;
    	&#125;
    // -->
    </script>

    La variabile di sessione challengeword è il valore casuale con cui la password inserita dall'utente viene combinato.

    Può essere generata scrivendo in cima alla pagina un po' di codice PHP, del tipo:

    Codice:
    $_SESSION&#91;'challengeword'&#93; = md5 &#40;mt_rand &#40;&#41;&#41;;
    Ovviamente la sessione deve essere già attiva.

    Chi scrive il codice PHP per il controllo del login? Sempre io?

  25. #25
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Vediamo qualche altro partecipante...

  26. #26
    User Attivo
    Data Registrazione
    Dec 2004
    Località
    abito sulla luna e ogni volta che mi telefono è un'interrurbana
    Messaggi
    2,413
    i miei complimenti
    veramente uno spunto OTTIMO su cui ragionare.
    ho letto con molta attenzione quanto scritto ed ora devo metabolizzare

  27. #27
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Tymba
    i miei complimenti
    veramente uno spunto OTTIMO su cui ragionare.
    ho letto con molta attenzione quanto scritto ed ora devo metabolizzare
    non sei l'unico, appena imparato da lowlevel ho aggiornato il mio sistema di log

  28. #28
    Banned
    Data Registrazione
    Apr 2005
    Messaggi
    2,073
    l' idea di LowLevel è di una praticità ed efficacia disarmanti, non è che mi trovi spesso a gestire l'autenticazione degli utenti, comunque non avevo mai pensato ad usare un metodo simile, quindi intanto subito un bel grazie .

    Adesso mi guardo bene bene il codice e preparo una mia versione del controllo login in PHP.

  29. #29
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da emmebar
    l' idea di LowLevel è di una praticità ed efficacia disarmanti, non è che mi trovi spesso a gestire l'autenticazione degli utenti, comunque non avevo mai pensato ad usare un metodo simile, quindi intanto subito un bel grazie .

    Adesso mi guardo bene bene il codice e preparo una mia versione del controllo login in PHP.
    Poi magari cerca di integralrla qui, così vediamo di curare un'altro aspetto del progetto

  30. #30
    User L'avatar di linus
    Data Registrazione
    Apr 2005
    Località
    Bergamo
    Messaggi
    125
    Fino a ieri il mio bizzarro sistema di autenticazione faceva in modo che le password fossero memorizzate nell' id_sessione in chiaro. Ho risolto 8) (adesso non lo sono più).

    Adesso però devo trovare il modo per non trasmettere più la password utente nel form di login ma bensì quell'informazione combinata di cui si è parlato.

    L'informazione combinata deve tenere conto di due fattori:
    • stringa casuale che solo il server conosce;
      password inserita nel form


    Posso creare una funzione personalizzata (stringa/password) per generare l'informazione combinata? Se ho capito bene la risposta è SI.

    Deve essere obbligatoriamente in javascript la funzione? La risposta è NO se ho capito.

  31. #31
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da linus
    Fino a ieri il mio bizzarro sistema di autenticazione faceva in modo che le password fossero memorizzate nell' id_sessione in chiaro. Ho risolto 8) (adesso non lo sono più).

    Adesso però devo trovare il modo per non trasmettere più la password utente nel form di login ma bensì quell'informazione combinata di cui si è parlato.

    L'informazione combinata deve tenere conto di due fattori:
    • stringa casuale che solo il server conosce;
      password inserita nel form


    Posso creare una funzione personalizzata (stringa/password) per generare l'informazione combinata? Se ho capito bene la risposta è SI.

    Deve essere obbligatoriamente in javascript la funzione? La risposta è NO se ho capito.
    Si, il java script si

  32. #32
    Banned
    Data Registrazione
    Apr 2005
    Messaggi
    2,073
    Citazione Originariamente Scritto da PaTeR
    Poi magari cerca di integralrla qui, così vediamo di curare un'altro aspetto del progetto
    E' esattamante quello che voglio fare .

  33. #33
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    come stiamo procedendo? : 8)

  34. #34
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Tuonorosso
    come stiamo procedendo? : 8)
    Cerchiamo nuovi utenti che possono partecipare!!!

  35. #35
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    ok
    intanto non ci conviene dividerci i compiti noi che già ci siamo?

  36. #36
    Banned
    Data Registrazione
    Apr 2005
    Messaggi
    2,073
    Citazione Originariamente Scritto da Tuonorosso
    come stiamo procedendo? : 8)
    Per il controllo sono un po' indietro, ho avuto una montagna di cose da fare in questi giorni, comunque ci stò lavorando, anche perchè mi serve per un cliente., ma se volete andate pure avanti voi.

  37. #37
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Tuonorosso
    ok
    intanto non ci conviene dividerci i compiti noi che già ci siamo?
    Non sarebbe male...


    Allora ci organizziamo? Per favore scrivete chi è interessato, in fondo è una cosa che servirà a tutti, quindi + siamo meglio è

  38. #38
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    Tuonorosso
    Pater

  39. #39
    Banned
    Data Registrazione
    Apr 2005
    Messaggi
    2,073
    eccomi


    Citazione Originariamente Scritto da Tuonorosso
    Tuonorosso
    Pater
    emmebar

  40. #40
    L'avatar di LowLevel
    Data Registrazione
    Mar 2005
    Località
    Milano
    Messaggi
    1,542
    Tuonorosso
    Pater
    emmebar
    LowLevel

  41. #41

    Data Registrazione
    Jul 2005
    Messaggi
    10
    News?

  42. #42
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Fab G
    News?
    hehe servono utenti volenterosi!

    comuqneu la parte software base non è difficile da fare...
    vuol dire che mi ci dedicherò un pò di più

  43. #43
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    ops...io mi ero dimenticato

  44. #44
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Tuonorosso
    ops...io mi ero dimenticato
    utenti non prendete esempio da questo moderatore!


  45. #45
    Utente Premium L'avatar di Tuonorosso
    Data Registrazione
    Mar 2005
    Località
    Lecco
    Messaggi
    1,997
    Citazione Originariamente Scritto da PaTeR
    utenti non prendete esempio da questo moderatore!

    ehhehe...davvero...a meno che non vogliate diventare mister universo...non imitatemi

  46. #46
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142

    L'hashing delle password -> Perchè?

    Allora ragazzi la questione password è già stata trattata, ma vorrei discutere ora dell'hashing in sè.

    Message-Digest algorithm 5
    Ecco qui il famoso MD5... vi sarete chiesti a che serve qualche volta... no? Ebbene, esso non serve affatto a CRIPTARE una password, bensì a calcolare l'hash di una stringa. Per utilizzarlo PHP mette a disposizione la sua bella funzioncina built-in md5()

    Codice:
    string md5 &#40;
          string str ,
          &#91; bool raw_output &#93;
    &#41;
    In questo prototipo troviamo STR che è la stringa da hashare, e l'opzione booleana RAW_OUTPUT che per default è FALSE. Naturalmente non è possibile risalire alla stringa originale, perchè alcune operazioni dell'algoritmo non sono reversibili ( come la moltiplicazione: 6 è 2*3, ma potrebbe anche essere 1*6 ).

    LA SICUREZZA DI QUESTO ALGORITMO
    La sicurezza di questo algoritmo è alta, ma certamente non è sicurissima: sono infinite ( come tutte le cose ) le stringhe possibili che potrebbero dare come risultato lo stesso hash. Però non preoccupatevi: è molto raro che un lamer le trovi, se non con attacco Brute-Force che tralaltro sarebbe molto dispendioso per lui.

    COME EVITARE GLI ATTACCHI BRUTE-FORCE
    Per evitare attacchi di questo tipo molti siti permettono un massimo di 3 login per uno stesso utente ogni 15 minuti: come il PIN del cellulare... 3 tentativi, allo scadere di questi l'utnte dovrà aspettare 15 minuti ( o quello che volete voi ) prima di tentare un nuovo accesso! Per gestire questo genere di protezione, vi basta controllare i login di un utente ( non interessa manco l'IP ) ed allo scadere dei tre tentativi ( controllati dallo script di accesso che aumenterà i tentativi falliti ) bloccherà i login di quell'utente trascrivendo nel database il timestamp di quell'accesso permettendo allo script del login di calcolare il tempo necesssario per permettere un nuovo accesso. Molti script usano questo metodo, come phpBB e altri forums.

    MD5 in Javascript?
    Ma comunque resta un problema: facciamo passare la password in chiaro??? NOOOO!

    Ora dobbiamo adottare uno stratagemma!

    1) Usare la classe MD5 per javascript
    2) Creare un algoritmo proprio

    Ora vi spiegherò come usare MD5 in Javascript, sistema che comunque in alcuni casi non funzionerà... perciò bisogna decidere se

    1) Obbligare il client ad abilitare js
    2) Metterlo al corrente che il sistema non è sicuro e passare la password in chiaro

    Così dovremo procedere in questo modo:

    Avremo un campo <noscript> che setterà un valore POST in modo tale che esso sarà 'disabled' solo se il js è disattivato

    Codice:
    <noscript><input type='hidden' name='js' value='disabled'></noscript>
    ed un campo <script> che setterà il campo su 'enabled'

    Codice:
    <script lang='javascript'>document.write&#40;"<input type='hidden' name='js' value='enabled'>"&#41;;</script>
    così, sempre in js cripteremo il campo con questo javascript prima che avvenga il passaggio all'altra pagina.

    Lo script lato-server controllerà il valore di 'js' e se sarà su enabled non hasherà il campo della password, se invece è su disabled lo hasherà.

    LINKS UTILI

    http://www.faqs.org/rfcs/rfc1321
    http://pajhome.org.uk/crypt/md5/
    http://en.wikipedia.org/wiki/Brute_force_attack
    http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html

    Conclusioni
    Ci sono tanti modi per criptare una stringa, io vi ho dato informazioni sul metodo più noto... a voi il resto!

    Ciao!

  47. #47
    User
    Data Registrazione
    Dec 2005
    Messaggi
    100
    Pater, è possbile avere la stessa sicurezza con uno script solo di php???
    di java non ne so nulla .

  48. #48
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Albertorrr
    Pater, è possbile avere la stessa sicurezza con uno script solo di php???
    di java non ne so nulla .
    Vedi, il problema è la sicurezza del trasferimento dei dati dal client al server. Col Java possiamo hashare la stringa in anticipo rendendo impossibile la decodifica. ( Con la brute-force sarebbe una sfida... )

  49. #49
    User
    Data Registrazione
    Dec 2005
    Messaggi
    100
    Citazione Originariamente Scritto da PaTeR
    Vedi, il problema è la sicurezza del trasferimento dei dati dal client al server. Col Java possiamo hashare la stringa in anticipo rendendo impossibile la decodifica. ( Con la brute-force sarebbe una sfida... )
    Ho capito, volevo dire anche che in alcuni siti mettono un numero casuale da riscrivere, sai come funziona e se è sicuro???
    L'ho visto anche in quello di MSN quando fai un nuovo account

    Ciao

  50. #50
    User Attivo
    Data Registrazione
    Nov 2004
    Località
    Catania
    Messaggi
    1,142
    Citazione Originariamente Scritto da Albertorrr
    Ho capito, volevo dire anche che in alcuni siti mettono un numero casuale da riscrivere, sai come funziona e se è sicuro???
    L'ho visto anche in quello di MSN quando fai un nuovo account

    Ciao
    Quello serve per non permettere automatizzazioni di registrazioni. E' un'altra cosa... Per avere una sicurezza in più al limite potresti usare SSL...

+ Rispondi alla Discussione
Pagina 1 di 2 12 UltimaUltima

Tag per Questa Discussione

^ Permessi di Scrittura

  • Tu non puoi inviare nuove discussioni
  • Tu non puoi inviare risposte
  • Tu non puoi inviare allegati
  • Tu non puoi modificare i tuoi messaggi
  •  
  • Il codice BB è Attivato
  • Le faccine sono Attivato
  • Il codice [IMG] è Attivato
  • Il codice [VIDEO] è Attivato
  • Il codice HTML è Disattivato
  • Trackbacks Attivato
  • Pingback Attivato
  • Refback Attivato

SEO by vBSEO 3.6.0 PL2 ©2011, Crawlability, Inc.