Salted hash

salt skal ind i sha1 !

du bør nok bruge sha256 eller sha512 fremfor sha1, når du alligevel skal igang med at skifte.

Det må være overflødigt at lave salt på så kompleks en måde.

64 eller 128 tilfældige bit. Og der er ikke behov for specielt super tilfældige tal.

MD5 bør være bandlyst. Men jeg mener faktisk ikke at der findes komplette rainbow tables for MD5 endnu.

Som jeg ser det, er mit salt inde i sha1? I substr encrypter jeg det.
Er det ikke nok at gøre det sådan?

Jeg startede faktisk med at bruge hash(); funktionen, så jeg evt. kunne bruge sha256, men af en eller anden årsag, kan jeg ikke få det til at virke på mit webhotel, så dem har jeg lige hevet fat i, og De undersøger sagen. Så indtil videre står den vidst bare på sha1. Kunne måske bruge crypt();, men kan bedre lide den anden.

Det har jeg også tænkt lidt på. Nu lavede jeg det på denne måde, fordi den bliver rimelig kompleks, men det er nok unødvendigt at gøre sådan og den bruger bare ekstra tid og resourcer på det. 1 salt vil typisk også være nok formentlig? Men et salt bør være unikt hver gang ikke?

Jeg havde faktisk tænkt på at kompleksificere systemet yderligere ved at hash'e saltet i 1 slags algoritme og så hash'e det hash'ede salt yderligere i en anden algoritme. Så det "krypterede blev krypteret". Men det er nok totalt overkill, og ved ikke om det ville virke i det hele taget.

Nope, der er ingen komplette rainbow tables endnu :)
Men det er desværre nok bare et spørgsmål om tid.

$nyt_kodeord = $salt1 . sha1($string) . $salt2;

hasher ikke salt.

$nyt_kodeord = sha1($salt1 . $string . $salt2);

hasher salt.

Salt skal opbevares i databasen sammen med det hashed password, så en hacker vil kende det.

Eneste krav er at det skal være så tilfældigt at det ikke findes i nogle forudberegnede tabeller.

Er det ikke nok at hashe det 1 gang oppe i substringen og så lægge dem sammen bagefter? Så bliver det måske ikke en korrekt "sha1 bit værdi"? Så er der ingen grund til at hash'e den deroppe, hvis jeg vælger at gøre det til sidst i funktionen. I og med at jeg så hasher til sidst nu, har jeg 2 variabler indeholdende saltet som raw input. Er det et muligt sikkerhedsbrud? (så bør man måske beholde hash i subtr også) (jeg ved godt at det bare et et password, så der er grænser for hvor sikkert det skal være), men det er meget sjovt at rode med og gøre det "uigennemtrængeligt".

Og jeps, salt skal naturligvis gemmes i databasen, for ellers vil personen aldrig kunne logge ind igen, eftersom det er unikt.

Men blev faktisk i tvivl nu. Skal salt gemmes alene som hash eller plain text? Det burde vel være hashed, da ellers det jo lige er til at se, hvad der der er tillagt kodeordet. Og man må formode, at hvis en person kan få fat i det hashede password fra databasen, så kan han også få fat i saltet.

Hvis du gemmer slat af hash kan du ikke bruge det til noget. Du skal jo bruge salt når du skal checke hash af password.

$nyt_kodeord = $salt1 . sha1($string) . $salt2;

er værdiløst.

Den onde hacker fjerner bare $salt1 og $salt2 og slår du det der er tilbage op i en tabel over hash af kendte ord og sammensaetninger.

Kan godt se problemet i at hashe på den måde. Som du siger, så kan personen bare skille det ad, og så er det egentlig ikke meget værd længere.

Jeg tror der er nogenlunde styr på det så. Ellers kan jeg bare vende tilbage jo. Smid du bare et svar, og tak for responsen :-)

svar