[jayzee]

Hej,

i ett fält i tabellen lagrar jag lösenord i form av saltad 512bit SHA2. Fältet i fråga är BINARY(64). Nu är det så att vissa lösenord får padding i tabellen och därefter misslyckas. Varför det blir så förstår jag inte alls, SHA2 skall väl alltid vara 512bit (64 byte)??

Ett exempel för lösenordet skafiskafnjakJ]Mw<[j_s4%F0+|JayQHYLd27vrO]UCV~Stz;+H_VtlQwS%o*Vmig_r+K{b&|4|;

PHP-kod:

PHP genererad SHA-2 (hash("sha512" ...))
f2831318c0eb9aa3b78468c61a985c7d76a9d51c8f582863af31a5e919143088068ab25918bbe5f4398d26a08cd808b9297ec6d2167816cf45c22ce43ade4947 


PHP-kod:

MySQL genererad SHA-2 (select sha2(value, 512)):
f2831318c0eb9aa3b78468c61a985c7d76a9d51c8f582863af31a5e919143088068ab25918bbe5f4398d26a08cd808b9297ec6d2167816cf45c22ce43ade4947 


PHP-kod:

SHA-2 som finnes i databasen:
f2831318c0eb9aa3b78468c61a987d76a9d51c8f582863af31a5e919143088068ab25918bbe5f4398d26a08cd808b9297ec6d2167816cf45c22ce43ade494700 


Varför sker detta?

[Conny Westh]

Ursprungligen postat av jayzee

Hej,

i ett fält i tabellen lagrar jag lösenord i form av saltad 512bit SHA2. Fältet i fråga är BINARY(64). Nu är det så att vissa lösenord får padding i tabellen och därefter misslyckas. Varför det blir så förstår jag inte alls, SHA2 skall väl alltid vara 512bit (64 byte)??

Ett exempel för lösenordet skafiskafnjakJ]Mw<[j_s4%F0+|JayQHYLd27vrO]UCV~Stz;+H_VtlQwS%o*Vmig_r+K{b&|4|;

PHP-kod:

PHP genererad SHA-2 (hash("sha512" ...))
f2831318c0eb9aa3b78468c61a985c7d76a9d51c8f582863af31a5e919143088068ab25918bbe5f4398d26a08cd808b9297ec6d2167816cf45c22ce43ade4947 


PHP-kod:

MySQL genererad SHA-2 (select sha2(value, 512)):
f2831318c0eb9aa3b78468c61a985c7d76a9d51c8f582863af31a5e919143088068ab25918bbe5f4398d26a08cd808b9297ec6d2167816cf45c22ce43ade4947 


PHP-kod:

SHA-2 som finnes i databasen:
f2831318c0eb9aa3b78468c61a987d76a9d51c8f582863af31a5e919143088068ab25918bbe5f4398d26a08cd808b9297ec6d2167816cf45c22ce43ade494700 


Varför sker detta?

I de flesta programspråk måste du skilja på binärdata och strängar. Strängar brukar ofta hanteras med att systemet lägger på radslut eller paddar in andra tecken medan binärdata behålls 100% intakt utan tillagda tecken.

Troligen måste du tänka på det i detta sammanhang. Jag vet inte men det är en kvalificerad gissning.

Ett annat problem är om du använder kolumner med fix längd, då måste databasen fylla ut med något tecken och då stämmer inte värdet längre. Typexemplet är många använder CHAR (fyller automatiskt ut värdet så det alltid är exakt antal tecken lagrade) i stället för VARCHAR (semidynamisk längd, man anger en maxstorlek vid definitionen men sedan justeras längden av datat inom denna ram efter behov).

[jayzee]

Stort tack Conny för ditt svar, du är hjälpsam som vanligt.
Det är precis som du säger (och jag misstänkte). Lösenord hanterades som strängar vilket var mindre bra, detta gjorde bla. att citationstecken kunde genereras vilket tog sönder query. Då det enda fördelen med binär approach var att datat tar mindre plats (men det blev jobbigare att jobba med) valde jag istället att göra om fältet till CHAR(128) och lagra som hex, vilket genast gjorde saker en aning lättare