/ Forside / Teknologi / Udvikling / ASP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
ASP
#NavnPoint
smorch 9259
Harlekin 1866
molokyle 1040
Steffanst.. 758
gandalf 657
smilly 564
gibson 560
cumano 530
MouseKeep.. 480
10  Random 410
kryptering af info i cookies
Fra : Christian M. Nielsen


Dato : 09-12-05 18:55

Hej.

Jeg har overvejet noget kryptering af brugerens password i forbindelse med
auto login, men er lidt i tvivl om hvordan jeg skal gribe det an.

MD5 vil være oplagt, da det er eenvejs kryptering samt kan laves uden
komponenter installeret på serveren. Jeg kender ikke så meget til hverken
MD5 eller andre former, så jeg vil gerne høre om andres erfaringer med dette
emne.

Så vidt jeg kan forstå, så gemmer man hash værdien af brugernavn i databasen
når brugeren oprettes. Ved login sammenlignes hashværdien af det indtastede
password med det gemte i databasen. Er dette korrekt forstået?
I tilfælde af at brugeren glemmer sit password, hvordan hash'er man så
baglæns ud fra den værdi der er gemt i databasen?

Hvis I har et link til en forklaring, så er det fint.

Go' weekend.

--

Mvh / Regards
-=< Christian >=-
What capital has 164 letters in its name? See my web page to find out.
http://www.cmnielsen.dk
The scary thing about looking for truth is that you might find it.



 
 
Brian B. Christensen (09-12-2005)
Kommentar
Fra : Brian B. Christensen


Dato : 09-12-05 19:02

On Fri, 9 Dec 2005 18:54:42 +0100, "Christian M. Nielsen"
<look.for.it@my.webpage> wrote:

>Hvis I har et link til en forklaring, så er det fint.

http://www.asp-faq.dk/article/?id=52

Mvh. Brian
--
Dagens afstemning: "Vil du helst have tæv med et bat, høre på Hannibal Hildorf eller få en Vaginal akupressur af Søren Ventegodt?"

Christian M. Nielsen (09-12-2005)
Kommentar
Fra : Christian M. Nielsen


Dato : 09-12-05 20:25

"Brian B. Christensen" <nej@denneemailerikkedenrigtige.dk> skrev i en
meddelelse news:8khjp1dtbl3qmpccbgsjpa8kdh17g5bmbk@4ax.com...

>>Hvis I har et link til en forklaring, så er det fint.
>
> http://www.asp-faq.dk/article/?id=52


Ok, så havde jeg forstået fremgangsmåden korrekt.

Hvad gør man i tilfælde af brugeren glemmer sit password?

--

Mvh / Regards
-=< Christian >=-
What capital has 164 letters in its name? See my web page to find out.
http://www.cmnielsen.dk
The scary thing about looking for truth is that you might find it.



Adam Ellesøe (09-12-2005)
Kommentar
Fra : Adam Ellesøe


Dato : 09-12-05 20:32

> Hvad gør man i tilfælde af brugeren glemmer sit password?
Så generer siden et nyt, og dette sendes til brugeren.. (dette skal man dog
selv prog.) Eller også gemmer man både det krypterede og det ikke krypterede
i db'en. Derved kan din cookie være krypteret og du kan gå "tilbage"...
eller du hacker krypteringsnøglen...



Christian M. Nielsen (09-12-2005)
Kommentar
Fra : Christian M. Nielsen


Dato : 09-12-05 20:37


"Adam Ellesøe" <adam_ellesoe@hotmail.com> skrev i en meddelelse
news:4399db97$0$15793$14726298@news.sunsite.dk...
>> Hvad gør man i tilfælde af brugeren glemmer sit password?
> Så generer siden et nyt, og dette sendes til brugeren.. (dette skal man
> dog selv prog.)

Det var også min umiddelbare tanke!

> Eller også gemmer man både det krypterede og det ikke krypterede i db'en.
> Derved kan din cookie være krypteret og du kan gå "tilbage"...

Ville egentligt helst undgå at gemme det i ren tekst i databasen, men på den
anden side, skam man også se på hvor stor sikkerhed der kræves på siden

> eller du hacker krypteringsnøglen...

Eller finder ud af en algoritme der kan forudsige lottotallene og glemmer
alt om programmering fremover

Go' weekend
--

Mvh / Regards
-=< Christian >=-
What capital has 164 letters in its name? See my web page to find out.
http://www.cmnielsen.dk
The scary thing about looking for truth is that you might find it.



Adam Ellesøe (09-12-2005)
Kommentar
Fra : Adam Ellesøe


Dato : 09-12-05 20:47

> Eller finder ud af en algoritme der kan forudsige lottotallene og glemmer
> alt om programmering fremover
Så sender du lige en kopi, ik??

> Go' weekend
I lige måde, og god Jul

--
MVH
Adam G. Ellesøe



Jens Gyldenkærne Cla~ (09-12-2005)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 09-12-05 23:34

Adam Ellesøe skrev:

>> Hvad gør man i tilfælde af brugeren glemmer sit password?

> Så generer siden et nyt, og dette sendes til brugeren.. (dette
> skal man dog selv prog.)

Netop.

> Eller også gemmer man både det krypterede og det ikke krypterede
> i db'en.

Nej! Grunden til at man gemmer en hashværdi af adgangskoden i
stedet for selve adgangskoden, er for at øge sikkerheden mod
misbrug. Hvis den originale adgangskode gemmes i databasen, er der
ikke nogen grund til at anvende en hashet værdi.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

Adam Ellesøe (09-12-2005)
Kommentar
Fra : Adam Ellesøe


Dato : 09-12-05 23:58


> Nej! Grunden til at man gemmer en hashværdi af adgangskoden i
> stedet for selve adgangskoden, er for at øge sikkerheden mod
> misbrug.

Problemet var at man ikke skulle kunne se koden i cookien....

> Hvis den originale adgangskode gemmes i databasen, er der
> ikke nogen grund til at anvende en hashet værdi.
Hvor nemt er det at få adgang til de oplysninger i databasen??
--
MVH
Adam G. Ellesøe



Jens Gyldenkærne Cla~ (10-12-2005)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 10-12-05 00:08

Adam Ellesøe skrev:

>> Hvis den originale adgangskode gemmes i databasen, er der
>> ikke nogen grund til at anvende en hashet værdi.

> Hvor nemt er det at få adgang til de oplysninger i databasen??

Serveren kan blive hacket, personer med adgang til databasen kan
misbruge deres adgang, ...

Alene mistanken om at en adgangskode er sluppet ud fra et system,
kan være problematisk. Hvis en adgangskode er blevet misbrugt, vil
man kigge på hvem der har haft mulighed for at få fat i den. Folk
der har adgang til systemet kan dermed blive mistænkeliggjort - og
det kan være svært at mane mistanken i jorden.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

Jørn Andersen (11-12-2005)
Kommentar
Fra : Jørn Andersen


Dato : 11-12-05 17:04

On Sat, 10 Dec 2005 00:08:17 +0100, Jens Gyldenkærne Clausen
<jens@gyros.invalid> wrote:

>Adam Ellesøe skrev:
>
>>> Hvis den originale adgangskode gemmes i databasen, er der
>>> ikke nogen grund til at anvende en hashet værdi.
>
>> Hvor nemt er det at få adgang til de oplysninger i databasen??
>
>Serveren kan blive hacket, personer med adgang til databasen kan
>misbruge deres adgang, ...
>
>Alene mistanken om at en adgangskode er sluppet ud fra et system,
>kan være problematisk. Hvis en adgangskode er blevet misbrugt, vil
>man kigge på hvem der har haft mulighed for at få fat i den. Folk
>der har adgang til systemet kan dermed blive mistænkeliggjort - og
>det kan være svært at mane mistanken i jorden.

Jeg er helt enig - det er den bedste beskyttelse af programmører og
systemfolk, at de simpelthen ikke *kan* se adgangskoden.

Og man skal lige huske på, at folk jo generelt ikke overholder de mest
grundlæggende simple password-regler, fx at man kun må bruge det samme
password ét sted. Mange gange har folk det samme pasword (eller måske
2 eller 3 forskellige) til alt fra netbank, netværkslogin på
arbejdspladsen, bilen osv. - og så alle disse underlige steder, hvor
man skal have et password for at komme ind på banale websteder af
enhver slags. Så man skal som programmør ikke kun tænke på sin egen
(måske lille og banale) applikation, men også på at denne applikation
kan være genvejen til de mere dyre ting.

Så: Altid hashing af adgangskoder!

Og hvis folk selv kan få et nyt password, hvis de har glemt det, skal
det
a) kun kunne sendes til en i forvejen oplyst og bekræftet mailadresse
og (eler anden lignende sikkerhed)
b) kun være et midlertidigt password, hvor man tvinges til at ændre
password ved første login.

Det sidste gøres nemmest ved at tildele det en oprettelsesdato, som er
længere tilbage end den "timeout" man bruger til at tvinge folk til at
skifte password med faste mellemrum. Hvis man fx tvinger folk til at
skifte password hver 3. måned (meget almindeligt), kunne det
midlertidige password fx have en oprettelsesdato der er et år bagud.

Mvh. Jørn

--
Jørn Andersen,
Brønshøj

Jesper Stocholm (12-12-2005)
Kommentar
Fra : Jesper Stocholm


Dato : 12-12-05 09:34

"Christian M. Nielsen" <look.for.it@my.webpage> wrote in
news:4399c4b1$0$67256$157c6196@dreader2.cybercity.dk:

> Hej.
>
> Jeg har overvejet noget kryptering af brugerens password i forbindelse
> med auto login, men er lidt i tvivl om hvordan jeg skal gribe det an.
>
> MD5 vil være oplagt, da det er eenvejs kryptering samt kan laves uden
> komponenter installeret på serveren. Jeg kender ikke så meget til
> hverken MD5 eller andre former, så jeg vil gerne høre om andres
> erfaringer med dette emne.

Jeg vil blot lige gøre opmærksom på, at MD5 ikke er en
krypteringsfunktion, men en hash-funktion. Jeg ville ikke selv anvende
MD5 som hash-funktion, da det efterhånden er trivielt at bryde den (finde
kollisioner). I stedet kan anvendes fx SHA1, der er noget mere "sikker".

Vær også opmærksom på, at du aldrig må gemme en simpel hash-værdi af et
password i din database. Du skal altid lave hash-værdien som en hemmelig
nøgle + password, også kaldet en "initialiseringsvektor".

Dvs:

Hemmelig nøgle: 6e9b8a2d
Password: mypassword

Værdi gemt i database = SHA1(6e9b8a2dmypassword).

Grunden til dette er, at det ofte vil være trivielt ud fra en database
med SHA1-udgaver af passwords at finde de oprindelige passwords (ordbogs-
angreb).

Når du skal gemme en værdi på klienten til auto-login, så skal du være
sikker på, at en "ond" klient ikke selv kan lave sådan en værdi. En
løsning på dette kunne være:

Lav en tekststreng som

initialiseringsvektor + email (eller brugerid) + hash(password)


('+' er her string-sammensætning, dvs Abe + Tjans = AbeTjans)


Denne værdi laver du en hashværdi af og gemmer på klienten og i databasen
for den enkelte bruger. Når en bruger kommer ind på din side, så henter
du teksten fra din database, laver samme udregning og sammenligner. Hvis
der er succes, så logger du ind for brugeren.

Eks:

hash(mypassword) = 0af519e4

initialiseringsvektor = 6e9b8a2d

6e9b8a2d0c + crap@foo.bar + 0af519e4 = 6e9b8a2d0ccrap@foo.bar0af519e4

(*)
hash(6e9b8a2d0ccrap@foo.bar0af519e4) = e8b01ad3

Denne værdi gemmes i cookie samt i db for bruger

Når bruger kommer tilbage slås op i db og der hentes

hemmelig vektor (denne skal ikke gemmes i db)
email
hash(password)

Nu udregnes (*) igen og sammenlignes med værdi i cookie.

Pointen er, at da klienten ikke kender din hemmelige vektor, så kan hun
heller ikke lave værdien, der gemmes i cookie - selv ikke hvis hun havde
opsnappet en eller andens password.



--
Jesper Stocholm
http://stocholm.dk

Findes din kiosk på nettet? Se http://ekiosk.dk

Christian M. Nielsen (17-12-2005)
Kommentar
Fra : Christian M. Nielsen


Dato : 17-12-05 11:15


"Jesper Stocholm" <j@stocholm.invalid> skrev i en meddelelse
news:Xns972A616385C98stocholmdk@62.243.74.162...
> Eks:
>
> hash(mypassword) = 0af519e4
>
> initialiseringsvektor = 6e9b8a2d
>
> 6e9b8a2d0c + crap@foo.bar + 0af519e4 = 6e9b8a2d0ccrap@foo.bar0af519e4
>
> (*)
> hash(6e9b8a2d0ccrap@foo.bar0af519e4) = e8b01ad3
>
> Denne værdi gemmes i cookie samt i db for bruger
>
> Når bruger kommer tilbage slås op i db og der hentes
>
> hemmelig vektor (denne skal ikke gemmes i db)
> email
> hash(password)
>
> Nu udregnes (*) igen og sammenlignes med værdi i cookie.
>
> Pointen er, at da klienten ikke kender din hemmelige vektor, så kan hun
> heller ikke lave værdien, der gemmes i cookie - selv ikke hvis hun havde
> opsnappet en eller andens password.


Tak for et godt forklaret eksempel. Det er hermed taget til efterretning.

Men når man bruger initialiseringsvektor, så er MD5 vel lige så godt som
SHA1 ??
--

Mvh / Regards
-=< Christian >=-
What capital has 164 letters in its name? See my web page to find out.
http://www.cmnielsen.dk
The scary thing about looking for truth is that you might find it.



Jesper Stocholm (19-12-2005)
Kommentar
Fra : Jesper Stocholm


Dato : 19-12-05 16:26

"Christian M. Nielsen" <look.for.it@my.webpage> wrote in news:43a3e4ff$0
$78283$157c6196@dreader1.cybercity.dk:

> Tak for et godt forklaret eksempel. Det er hermed taget til
> efterretning.
>
> Men når man bruger initialiseringsvektor, så er MD5 vel lige så godt
> som SHA1 ??

Nej. Anvendelse af initialiseringsvektor har bla. til formål at undgå
muligheden for at lave ordbogsangreb på dine hash-værdier. MD5 er et
dårligt valg, da algoritmen ikke længere anses for (helt) sikker ... og det
er ikke i samme grad tilfældet med SHA1. Du kan evt anvende SHA1-256, der
giver 256bits "sikkerhed".

Hvis du kigger på eksempelkoden i [0], så er der et link til sitet, hvor
jeg selv fandt SAH1-koden. Så vidt jeg husker, så er der også en udgave til
SHA256.

[0] http://asp.stocholm.dk/hash/

--
Jesper Stocholm
http://stocholm.dk

Findes din kiosk på nettet? Se http://ekiosk.dk

Christian M. Nielsen (19-12-2005)
Kommentar
Fra : Christian M. Nielsen


Dato : 19-12-05 20:26


"Jesper Stocholm" <j@stocholm.invalid> skrev i en meddelelse
news:Xns9731A6F81730Fstocholmdk@62.243.74.162...

> Hvis du kigger på eksempelkoden i [0], så er der et link til sitet, hvor
> jeg selv fandt SAH1-koden. Så vidt jeg husker, så er der også en udgave
> til
> SHA256.
>
> [0] http://asp.stocholm.dk/hash/


Jeg kigger på det, tak for linket
--

Mvh / Regards
-=< Christian >=-
What capital has 164 letters in its name? See my web page to find out.
http://www.cmnielsen.dk
The scary thing about looking for truth is that you might find it.



Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408938
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste