[MySql]Come si gestisce una tabella user e password?

[RaouL_BennetH]

Ciao a tutti :)

Come da titolo, mi trovo in questa situazione:

Al db mysql in oggetto, devono poter accedere diversi utenti da diversi punti non intranet e con indirizzi ip che possono variare, escluderei quindi il GRANT.

Adesso, se volessi creare una tabella id, user, password all'interno del db, avrei queste domande:

1) E' fattibile?
2) Come si cripta il campo password?

Grazie.

RaouL.

[thehuge]

1) E' fattibile?
Certamente. Un esempio potrebbe essere:
CREATE TABLE login (
id INTEGER PRIMARY_KEY,
user VARCHAR(255) NOT NULL,
password VARCHAR(255) NOT NULL

);
2) Come si cripta il campo password?
Le funzioni (sintassi MySQL) più utilizzate sono password() (http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html#function_password) e md5() (http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html#function_md5). In alternativa puoi usare le funzioni di encrypting del linguaggio di programmazione che si interfaccia con il DB.

[Xfight]

Spero di non andare OT, però può essere interessante :

dato che sia password(), sia md5(), sia sha1() sono one-way ( cripti e non puoi più recuperare la pass ), mi domandavo come fanno certi gestori a fare il classico form "dammi un po' di dati e ti diremo la pass".

Si dovrebbe utilizzare un algoritmo di criptazione a chiave oppure si tengono salvate le pass in chiaro da qualche altra parte :confused: ?

Argh, ho visto ora che ci sono le funzioni AES e DES.. ma allora non è meglio usare AES ? ( spero di non aver detto una caxxata ^^ )

Ciau

[thehuge]

dato che sia password(), sia md5(), sia sha1() sono one-way ( cripti e non puoi più recuperare la pass ), mi domandavo come fanno certi gestori a fare il classico form "dammi un po' di dati e ti diremo la pass".

Si dovrebbe utilizzare un algoritmo di criptazione a chiave oppure si tengono salvate le pass in chiaro da qualche altra parte :confused: ?


Generalmente viene memorizzata solo la versione criptata della password.
Quei gestori che forniscono una password se vengono inseriti alcuni dati corretti (solitamente la risposta ad una "domanda segreta"), in realtà forniscono una nuova password (a volte temporanea), modificando quella corrente dell'utente.
Poi sarà cura dell'utente stesso modificarla di nuovo (magari reinserendo quella precedentemente scelta).


Argh, ho visto ora che ci sono le funzioni AES e DES.. ma allora non è meglio usare AES ? ( spero di non aver detto una caxxata ^^ )


A meno di casi particolari è meglio non usare forme di crittografia reversibili, sia per una questione di sicurezza, sia per poter dare la garanzia all'utente che nessuno (nemmeno l'amministratore del DB) possa spacciarsi per lui.

[RaouL_BennetH]

Grazie per le risposte.

Non ho ancora capito però come funziona il tutto:

1)Creo il database

2)Non creo privilegi di nessun tipo

3)Creo la tabella con user e pass

....

Quando l'utente si collega, se non ha come prima cosa i privilegi a livello di grant, come fa a loggarsi su una tabella di un db dove non ha privilegi?

[thehuge]

Quando l'utente si collega, se non ha come prima cosa i privilegi a livello di grant, come fa a loggarsi su una tabella di un db dove non ha privilegi?

L'utente del DB che esegue le query sarà sempre lo stesso (di solito un utente apposito con il permesso di eseguire solo SELECT e, se serve, INSERT, UPDATE e/o DELETE).
Tramite questo utente (che solo l'amministratore conosce), esegui tutte le query necessarie; tra le quali anche la verifica del login per gli utenti finali.

Edit:
In pratica gli utenti finali saranno utenti dell'applicazione, non del DBMS.

[RaouL_BennetH]

L'utente del DB che esegue le query sarà sempre lo stesso (di solito un utente apposito con il permesso di eseguire solo SELECT e, se serve, INSERT, UPDATE e/o DELETE).
Tramite questo utente (che solo l'amministratore conosce), esegui tutte le query necessarie; tra le quali anche la verifica del login per gli utenti finali.

Edit:
In pratica gli utenti finali saranno utenti dell'applicazione, non del DBMS.

ah.. ecco.. quindi quello che cercavo di fare è praticamente inutile.

Cioè:

Devo dare un grant (anche se ad un solo utente) senza restrizioni. Questo perchè l'utente non si collegherà sempre dalla stessa macchina, quindi, il suo ip può cambiare in qualunque momento..

Devo quindi fare:



GRANT tipoPrivilegio ON mioDb.* to utente identified by 'password'
//senza quindi specificare l'host


Sinceramente.. non la trovo una cosa molto pratica se non una complicazione inutile garantire l'accesso a livello di applicazione e non di db. Un domani che cambio applicazione per accedere sempre allo stesso db, in pratica devo riscrivere il metodo di autenticazione in base al linguaggio scelto...

Non ci sono altre soluzioni?

Grazie mille :)

RaouL.

[thehuge]

Devo dare un grant (anche se ad un solo utente) senza restrizioni. Questo perchè l'utente non si collegherà sempre dalla stessa macchina, quindi, il suo ip può cambiare in qualunque momento..


No. Anzi: dipende.

Se l'applicazione è eseguita da un server (PHP, Servlet Java, ASP, CGI, e molti altri) puoi tranquillamente permettere l'accesso solo dall'IP del server.

Altrimenti (Applet Java, JavaScript, e qualunque cosa venga eseguita dal client) è proprio così.


Sinceramente.. non la trovo una cosa molto pratica se non una complicazione inutile garantire l'accesso a livello di applicazione e non di db. Un domani che cambio applicazione per accedere sempre allo stesso db, in pratica devo riscrivere il metodo di autenticazione in base al linguaggio scelto...

Non ci sono altre soluzioni?


Certo. Puoi creare un utente del DBMS per ogni utente finale, però il problema resta lo stesso: non puoi restringerli a seconda dell'IP dell'utente.
In più si aggiunge almeno un problema: i permessi così creati valgono solo per il DB, non per la tua applicazione (se dovesse modificare i comportamenti a seconda dell'utente); quindi dovresti verificarli tramite il DB ad ogni azione da compiere.

Edit:
E comunque dovresti avere almeno un utente amministratore che si occupi della gestione degli utenti finali (con permessi di GRANT... non molto sicuri da esporre ad una applicazione).