[Hibernate/Nhibernate/C#]problemi con md5

[RaouL_BennetH]

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]

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]

Originariamente inviato da gugoXX

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]

Originariamente inviato da banryu79

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]

Originariamente inviato da gugoXX

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]

Originariamente inviato da RaouL_BennetH

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.