Et login som krypterer i både PHP og Javascript? Hvorfor? Hvad bruger du til det i Javascript siden du ikke kan sætte iterationer og længde, eftersom SHA ikke er indbygget i Javascript? Er det Node eller browser-Javascript?
Jeg forstår stadig ikke hvorfor du vil kryptere noget i Javascript.
Password-hashing sker i backenden. Det er teoretisk muligt at gøre det i frontend, men jeg har aldrig nogensinde hørt om nogen der gjorde det.
Normalt vil du bare sende passwordet råt (end-to-end kryptering står SSL for) til din backend, der så hasher det (og lad være med at bruge SHA, det har ikke været sikkert længe. Brug password_hash() funktionen med bcrypt) og putter det i databasen. Når du logger ind, sender du det igen råt og bruger password_verify() til at tjekke med det i databasen.
Det første er én person der stiller et upopulært spørgsmål på SO, det andet er et modul beregnet til NodeJS, som er Javascript på serveren. Det giver ingen mening at bruge det sammen med PHP.
Så er der nogle andre sider der viser som proof-of-concept at det kan lade sig gøre, ja, men det betyder ikke at nogen bruger det til passwords. Især ikke fordi SHA som sagt ikke er sikkert og ikke bør bruges til det.
Læser du det samme link som mig? For alle i den tråd siger netop at SHA er designet til at være hurtigt mens bcrypt er designet til at være langsomt, hvilket netop er hvad du vil have i en password-hashing algoritme. Jo langsommere jo bedre.
Og det andet link... Hvis du kigger på det, eller bare på URL'en, vil du se det netop er et Node modul. NPM står for Node Package Manager. Node er Javascript på serveren. Du bruger ikke Node og PHP sammen, da de udfylder samme formål. Node og browser-Javascript er samme sprog men overhovedet ikke samme ting ellers. Det du snakker om at bruge er browser-Javascript.
Men hvordan skulle jeg give dig et link på, at der ikke er nogen der hasher i frontenden? Jeg kan kun sige at i mine 12 år som professionel udvikler og tid som sikkerhedsansvarlig for store websites, har jeg aldrig set det gjort.
"SHA-2 family of hashes was designed to be fast. BCrypt was designed to be slow. Both are considered robust. With enough rounds or work-factor, either one can take longer than the other, but I would lean towards the one that was designed to be slow. (if server load is an issue, the Work Factor is adjustable)" Jeg ser ikke dette som et "OMG, ur stoopid if you use sha". Mere som et "Ja, brug sha, vil du vil. Men bcrypt er nok det bedre valg." :)
Ah, fair nok - jeg er ikke til bloatede frameworks, så det smuttede lige. ;)
Haha, ej, det var så heller ikke var jeg forventede. :D Sjovt som man kan tale lidt forbi hinanden. :p Det jeg hintede efter, var en sammenligning viser giver dig ret. ;) Men hvis du aldrig har hørt/set det, så bliver det naturligvis svært! :D Mit udgangspunkt er nemlig omvendt - jeg lærte først at bruge det i javascript, før jeg fandt ud af at php havde en brugbar mulighed. :)
Altså, du bliver nok ikke hacket hvis du bruger SHA. Men når der nu findes noget bedre, hvorfor så bruge det.
Node er ikke et framework. Overhovedet ikke. Det har som sagt slet intet med almindeligt Javascript i browseren at gøre.
Hvis du gerne vil gøre det på den måde, så kan du da godt gøre eksperimentet. Så længe det er hashing og du genererer dit salt løbende, så det ikke kan findes i koden, så ser jeg ikke det store problem i det, andet end at det er mere besværligt. Men det normale er altså at gøre begge dele på serveren. Uanset om du der bruger Node, PHP, eller noget helt andet.
Fair nok, så tror jeg ikke vi behøver rode mere rundt i det. ;p
Naturligvis generes saltet løbende. :D Andet ville at være HELT væk - hvis du spørger mig. :)
Og så tror jeg, at jeg anbefalingen og skrotter JS delen - og dermed sover bedre. :)
Synes godt om
1 synes godt om dette
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.