PDA

View Full Version : [Hibernate/Nhibernate/C#]problemi con md5


RaouL_BennetH
20-05-2009, 14:06
Ciao a tutti :)

Ho un form di login dove la password che viene inserita deve ovviamente essere confrontata con la password inserita sul database con l'algoritmo md5.


la funzione che fa questo l'ho scritta così:



private void TestAuth()
{
using(ISession session = DBFactory.OpenSession())
{
using(ITransaction tx = session.BeginTransaction())
{

try
{
Operatore operatore = (Operatore)session.CreateQuery("from Operatore o where o.UserName = :userName AND o.Password = ").UniqueResult();
//blablacode...
tx.Commit();
}
//etc..



il problema mi si presenta appunto dopo 'AND'.

In rete non sono riuscito a trovare qualcosa di comprensibile per me.


Grazie a tutti :)

RaouL.

gugoXX
20-05-2009, 14:11
Ti consiglio di trattare i digest e gli hash (MD5, SHA1, MD6, etc.) come stringhe (uppercase per convenzione) nel database, e non come binari.

banryu79
20-05-2009, 14:16
Ti consiglio di trattare i digest e gli hash (MD5, SHA1, MD6, etc.) come stringhe (uppercase per convenzione) nel database, e non come binari.
Perchè?
[scusate l'intrusione, e il relativo OT]

@EDIT:
Grazie della risposta gugoXX.

gugoXX
20-05-2009, 14:27
Perchè?
[scusate l'intrusione, e il relativo OT]

Solo per semplicita' di scrittura delle query e di passaggio di parametri sia in input che in output.

Lo scotto da pagare e' qualcosa di piu' del raddoppio dello spazio per quei campi (un byte viene codificato in 2 caratteri quando stringa, e le stringhe hanno tipicamente un po' do overhead costante in quasi tutti i database)

Inoltre ci sono casi di motori in cui non e' possibile dichiarare indici sui campi binari, che sarebbero invece utili in molte query che coinvolgono le tabelle dove gli hash sono stati memorizzati, quindi ricerche tipo
WHERE hash =....
potrebbero risultare penalizzate.

RaouL_BennetH
20-05-2009, 14:35
Ti consiglio di trattare i digest e gli hash (MD5, SHA1, MD6, etc.) come stringhe (uppercase per convenzione) nel database, e non come binari.

Ciao gugoXX :)

Credo che inconsciamente abbia fatto come da te suggerito dato che la tabella sul db l'ho fatta così:


table Operatori:

id_operatore int (pk)
userName varchar(20)
password text
ruolo varchar(5)



per l'inserimento dei dati, avendolo fatto direttamente dal db ho fatto così:



INSERT INTO Operatori(userName, password, ruolo)
VALUES('raoul', md5('raoulsecret'), 'ULN01');



Ad ogni modo, ho trovato un esempio dal quale sono partito per passare questa 'palla' a C# e non a nhibernate mediante l'assembly System.Security.Cryptography e l'utilizzo del service provider MD5.

Può andare bene lo stesso?

Grazie :)

RaouL.

gugoXX
20-05-2009, 14:43
Ciao gugoXX :)

Credo che inconsciamente abbia fatto come da te suggerito dato che la tabella sul db l'ho fatta così:
...
Ad ogni modo, ho trovato un esempio dal quale sono partito per passare questa 'palla' a C# e non a nhibernate mediante l'assembly System.Security.Cryptography e l'utilizzo del service provider MD5.

Può andare bene lo stesso?

Grazie :)

RaouL.

Secondo me hai fatto bene delegare i calcoli degli hash al C#.
Possono esserci problemi di architettura in presenza di comunicazioni verso DB non blindate, per le quali occorrerebbe studiare qualcosa di diverso, ma funzionalmente va comunque bene e se non stai facendo qualcosa di sensibile va bene.