---

Jeg har lavet en form til brugeroprettelse.
Brugeren indtaster brugernavn og adgangskode efter eget valg.
Jeg vil nu gerne have at brugeren bekræfter adgangskoden for at
undgå fejltastninger.
Hvordan klarer jeg den?

Med venlig hilsen

Michael Tillgaard

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP ???
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Michael Tillgaard wrote:
> Jeg vil nu gerne have at brugeren bekræfter adgangskoden for at
> undgå fejltastninger.
> Hvordan klarer jeg den?

Du laver bare endnu et passwordfelt, og så sammenligner du de to
passwords på den side du submitter til.

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

On Fri, 18 Oct 2002 01:18:35 +0200, "Jakob Møbjerg Nielsen"
<jakob@dataloger.dk> wrote:

>Michael Tillgaard wrote:
>> Jeg vil nu gerne have at brugeren bekræfter adgangskoden for at
>> undgå fejltastninger.
>> Hvordan klarer jeg den?
>
>Du laver bare endnu et passwordfelt, og så sammenligner du de to
>passwords på den side du submitter til.

Desuden vil jeg anbefale, at du (Michael) er forholdsvis grundig med
at validere password, fx checke, at det kun indeholder tal og
bogstaver (evt. at det *både* indeholder tal og bogstaver), at det har
en vis længde, evt. at det er forskelligt fra tidligere password etc.

Det hele afhænger selvfølgelig noget af, hvilken sammenhæng det skal
bruges i.

Desuden, som det ofte er blevet diskuteret her i gruppen, er det en
god idé at gemme password i "krypteret" (hashet) form i databasen -
også selv om det måske ikke er adgangen til Fort Knox og
Nationalbanken, vi snakker om.
Årsagen er den simple, at folk ofte (*meget* ofte) bruger samme
passwords til en lang række ting. Ved at hashe værdien, kan du
friholde dig selv fra mistanke om at have brugt andres passwords.

Jesper Stocholm har en udmærket MD5-hash-funktion til ASP på sin side,
som jeg har brugt med glæde:
<URL: http://asp.stocholm.dk/>
Ideen er den simple, at værdier hashes, inden de gemmes i databasen,
og sammenligningen med indtastet pw sker på de hashede værdier.

Good luck!

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

---

Jørn Andersen skrev:

[SNIP]
> Desuden, som det ofte er blevet diskuteret her i gruppen, er det en
> god idé at gemme password i "krypteret" (hashet) form i databasen -
> også selv om det måske ikke er adgangen til Fort Knox og
> Nationalbanken, vi snakker om.
> Årsagen er den simple, at folk ofte (*meget* ofte) bruger samme
> passwords til en lang række ting. Ved at hashe værdien, kan du
> friholde dig selv fra mistanke om at have brugt andres passwords.
>
> Jesper Stocholm har en udmærket MD5-hash-funktion til ASP på sin side,
> som jeg har brugt med glæde:
> <URL: http://asp.stocholm.dk/>

Jeg hentede den komponent han har lavet, men jeg aner ikke hvordan man
bruger sådan noget. Fik at vide, at det ikke er muligt, at hash'e koder i
det VB vi har adgang til i asp, så jeg bliver nødt til at lære hvordan man
bruger hans komponent. Efter du sagde, at du har brugt det, tænkte jeg, at
jeg ligeså godt kunne sprøge dig som ham =) For at det ikke kun skal handle
om mig, kunne du måske forklare Michael Tillgaard og jeg, hvordan man
anvender komponenten. Man kan ikke være andet bekendt end at hash'e folks
koder, så jeg bliver nødt til det.

Tak
__
Flemming Jensen

---

On Fri, 18 Oct 2002 14:40:02 +0200, "Flemming Jensen"
<CyberOrc@tiscali.dk> wrote:

>> Jesper Stocholm har en udmærket MD5-hash-funktion til ASP på sin side,
>> som jeg har brugt med glæde:
>> <URL: http://asp.stocholm.dk/>
>
>Jeg hentede den komponent han har lavet,

Strengt taget er det ikke en komponent, men "blot" et script. :)

>men jeg aner ikke hvordan man bruger sådan noget.

Hvis du har gemt filen som md5.asp, så includer du den på de sider,
hvor den skal bruges:
<!--#include file="md5.asp"-->

hvorefter den kan anvendes som enhver anden funktion. Hvis du fx har
et nyt pw (strPwNew), som skal hashes, inden det skal gemmes, så fx:

strPwNewMd5 = md5(strPwNew)

>Efter du sagde, at du har brugt det, tænkte jeg, at
>jeg ligeså godt kunne sprøge dig som ham =)

Det er et åbent forum, så alle kan jo svare

>Man kan ikke være andet bekendt end at hash'e folks
>koder, så jeg bliver nødt til det.

Enig - og det er altså ret enkelt, så der er ikke engang nogen
fornuftig grund til at lade være ...

Good luck!

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

---

Jørn Andersen wrote :

> On Fri, 18 Oct 2002 14:40:02 +0200, "Flemming Jensen"
> <CyberOrc@tiscali.dk> wrote:
>
>>> Jesper Stocholm har en udmærket MD5-hash-funktion til ASP på sin
>>> side,
>>
>>Jeg hentede den komponent han har lavet,
>
> Strengt taget er det ikke en komponent, men "blot" et script. :)

og strengt taget er det ikke mig, der har lavet den. Jeg har blot lagt
den må mit domæne til download. Jeg synes nemlig, at det er nemmere at
huske på http://asp.stocholm.dk end www.frez.co.uk/gfgfy/ ... eller hvad
det end er den oprindelige adresse hedder.

> Hvis du har gemt filen som md5.asp, så includer du den på de sider,
> hvor den skal bruges:
> <!--#include file="md5.asp"-->
>
> hvorefter den kan anvendes som enhver anden funktion. Hvis du fx har
> et nyt pw (strPwNew), som skal hashes, inden det skal gemmes, så fx:
>
> strPwNewMd5 = md5(strPwNew)
>
>>Man kan ikke være andet bekendt end at hash'e folks
>>koder, så jeg bliver nødt til det.
>
> Enig - og det er altså ret enkelt, så der er ikke engang nogen
> fornuftig grund til at lade være ...

præcist !

Og jeg vil godt i løbet af "kort" tid lave et "working" example på
anvendelsen af den, som man kan downloade. Så kan det køres og man kan
bruge det til at lege lidt med det.



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

Jørn Andersen skrev:

> Hvis du har gemt filen som md5.asp, så includer du den på de sider,
> hvor den skal bruges:
> <!--#include file="md5.asp"-->
>
> hvorefter den kan anvendes som enhver anden funktion. Hvis du fx har
> et nyt pw (strPwNew), som skal hashes, inden det skal gemmes, så fx:
>
> strPwNewMd5 = md5(strPwNew)
>

Nu føler jeg mig dum! Det du nævner der er jo nok det letteste man kan komme
ud fra. Jeg har helt sikker fået et forkert link til Jepser Stocholms side,
for jeg endte med at ligge nogle mystiske filer ned, i blandt nogle dll
filer og ingen asp filer. Det var der den gik gal. Men når det bare er på
denne måde, er det jo www.let.dk =) Jeg går i gang med det sammen, så kan
ingen hænge mig op på noget ang. deres koder.

Tak

__
Flemming Jensen

---

Nu jeg hentet koden og den er jo også lavet i VB, altså ingen dumme dll
filer eller andet, som jeg troede :) Jeg har bare et par spørgsmål. Jeg går
ud fra den er lavet af folk i England, så kan den håndterer koder med æøå?
Og kan du fortælle mig erfaringer med den? Kan det lade sig gøre at
konveterer tilbage til "klartekst", eller er den 100% sikker?

Tak
__
Flemming Jensen

---

On Fri, 18 Oct 2002 18:11:03 +0200, "Flemming Jensen"
<CyberOrc@tiscali.dk> wrote:

[MD5]
>Nu jeg hentet koden og den er jo også lavet i VB, altså ingen dumme dll
>filer eller andet, som jeg troede :) Jeg har bare et par spørgsmål. Jeg går
>ud fra den er lavet af folk i England, så kan den håndterer koder med æøå?

Det havde jeg faktisk ikke prøvet, men en hurtig test viser, at æøå
kører OK.
Perosnligt ville jeg nok begrænse passwords til a-z + A-Z + 0-9, men
det er sikkert nok en smags sag.
Bare lidt surt at sidde ved en eller anden US-PC og ikke lige kunne
huske ASCII-koden for æøå

>Og kan du fortælle mig erfaringer med den? Kan det lade sig gøre at
>konveterer tilbage til "klartekst", eller er den 100% sikker?

Der er aldrig noget, der er 100% sikkert. Alt kan brydes, spørgsmålet
er kun, hvor mange kræfter, der skal bruges på det. Men algoritmen
skulle være stærk nok til, at du skal have ret så tillokkende værdier
bag koden for at få nogen til at bruge kræfter på det.

Desuden handler sikkerhed jo ofte om helt andre ting end hvor stærke
krypterings-algoritmer, man bruger - nemlig om det *samlede* billede
af det, man vil sikre.

Men den del er nok mere Jespers hjemmebane end min.

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

---

Jørn Andersen skrev:

> Det havde jeg faktisk ikke prøvet, men en hurtig test viser, at æøå
> kører OK.
> Perosnligt ville jeg nok begrænse passwords til a-z + A-Z + 0-9, men
> det er sikkert nok en smags sag.
> Bare lidt surt at sidde ved en eller anden US-PC og ikke lige kunne
> huske ASCII-koden for æøå

Så må brugeren lade være med at vælge æøå i hans password :)

> Der er aldrig noget, der er 100% sikkert. Alt kan brydes, spørgsmålet
> er kun, hvor mange kræfter, der skal bruges på det. Men algoritmen
> skulle være stærk nok til, at du skal have ret så tillokkende værdier
> bag koden for at få nogen til at bruge kræfter på det.

Det er jo så sandt som det er sagt. Men der er ingen der får fat i databasen
hvor koderne er i, så det er jo ligegyldig om folk _kan_ bryde koderne.

__
Flemming Jensen

---

Flemming Jensen wrote :

> Jørn Andersen skrev:
>> Der er aldrig noget, der er 100% sikkert. Alt kan brydes, spørgsmålet
>> er kun, hvor mange kræfter, der skal bruges på det. Men algoritmen
>> skulle være stærk nok til, at du skal have ret så tillokkende værdier
>> bag koden for at få nogen til at bruge kræfter på det.
>
> Det er jo så sandt som det er sagt.

> Men der er ingen der får fat i
> databasen hvor koderne er i

pas på med at antage dette - det kan være farligt :)

>, så det er jo ligegyldig om folk _kan_
> bryde koderne.

det er jo aldrig ligegyldigt, om nogen kan bryde koderne - hvilket
"nogen" altid kan. Det interessante er, om der er nogen der gider have
besværet ved at bryde ind i dit system - hvis det eneste man er at få to
gratis billed-SMS'er.

Sikkerhedsbetragtninger er _altid_ et trade-off imellem omkostningerne
ved øget sikkerhed og det "forventede" pres på servicen.



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

Jesper Stocholm skrev:

>>Det er jo så sandt som det er sagt. Men der er ingen der får fat i
>>databasen
>>hvor koderne er i, så det er jo ligegyldig om folk _kan_ bryde >>koderne.

> pas på med at antage dette - det kan være farligt :)

Nå', det var ikke ment som en opfordring til en eller anden hacker om at
prøve. Jeg mente blot, at det jo i dette tilfælde er ligegyldigt, da
databasen ikke ligger sammen med siderne på serveren. Det var jo noget andet
hvis man smed en hashed værdi i en query til en anden side, hvor man jo så
sagtens kunne se den hashede kode.

__
Flemming Jensen

---

On Fri, 18 Oct 2002 20:36:00 +0200, "Flemming Jensen"
<CyberOrc@tiscali.dk> wrote:

>Nå', det var ikke ment som en opfordring til en eller anden hacker om at
>prøve. Jeg mente blot, at det jo i dette tilfælde er ligegyldigt, da
>databasen ikke ligger sammen med siderne på serveren.

OK, bare for at pinde lidt mere i det:
Hvis det ikke er din egen server (fx webhotel), kan de folk, der
arbejder med serveren, uden problemer få fat i db'en.

Hvis det er din egen server, ligger den så i webscope eller udenfor
(forhåbentlig det sidste)?

Selv hvis det er din egen server, og kun du har adgang, så er hashing
og andre tiltag for at skjule pw (som tidligere nævnt) også en
beskyttelse af dig: Det er sværere at mistænke dig for at have
misbrugt andres passwords.

Eller sagt på en anden måde: Bare fordi man ikke er paranoid, betyder
det ikke, at de ikke kan være efter dig.

Alt skal selvfølgelig vurderes i en konkret sammenhæng (som slet ikke
har været inde i debatten): Hvem er brugerne? Åben eller lukket net?
Etc.

>Det var jo noget andet
>hvis man smed en hashed værdi i en query til en anden side, hvor man jo så
>sagtens kunne se den hashede kode.

Selvfølgelig.

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

---

Jørn Andersen skrev:

> OK, bare for at pinde lidt mere i det:
> Hvis det ikke er din egen server (fx webhotel), kan de folk, der
> arbejder med serveren, uden problemer få fat i db'en.

Server da selv =)

> Hvis det er din egen server, ligger den så i webscope eller udenfor
> (forhåbentlig det sidste)?

Den ligger pt. sammen med, men med det samme siden kommer op, kommer den
uden for webscope. Har database kaldet i en #include file, så det kan ændres
på 2 sek.

> Selv hvis det er din egen server, og kun du har adgang, så er hashing
> og andre tiltag for at skjule pw (som tidligere nævnt) også en
> beskyttelse af dig: Det er sværere at mistænke dig for at have
> misbrugt andres passwords.

Det er lige præcis derfor, at jeg gør det.

> Eller sagt på en anden måde: Bare fordi man ikke er paranoid, betyder
> det ikke, at de ikke kan være efter dig.

Huh? Jeg er ikke paranoid? Skulle jeg være det? Hvem kan være efter mig?

__
Flemming Jensen

---

Flemming Jensen wrote :

> Jørn Andersen skrev:

>> Hvis det er din egen server, ligger den så i webscope eller udenfor
>> (forhåbentlig det sidste)?
>
> Den ligger pt. sammen med, men med det samme siden kommer op, kommer
> den uden for webscope. Har database kaldet i en #include file, så det
> kan ændres på 2 sek.

Det er da fint ... eller ? For mig at se ville det være vigtigere at
sikre mig, at _ingen_ fejl i dine scripts kan give information om
databasens placering. Hvis din databases placering er blevet
kompromiteret - og downloadet - så hjælper det dig jo ikke meget, at du
kan ændre dens placering i løbet af nul-komma-vupti ...

>> Selv hvis det er din egen server, og kun du har adgang, så er hashing
>> og andre tiltag for at skjule pw (som tidligere nævnt) også en
>> beskyttelse af dig: Det er sværere at mistænke dig for at have
>> misbrugt andres passwords.
>
> Det er lige præcis derfor, at jeg gør det.

eller lige så vigtigt : fordi man kan ... :)

--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

Jørn Andersen wrote :

> On Fri, 18 Oct 2002 20:36:00 +0200, "Flemming Jensen"
> <CyberOrc@tiscali.dk> wrote:

>>Det var jo noget andet
>>hvis man smed en hashed værdi i en query til en anden side, hvor man
>>jo så sagtens kunne se den hashede kode.
>
> Selvfølgelig.

hvorfor 'selvfølgelig' ?

MD5 er "stærkt kollosions-fri", hvilket betyder, at det er svært, givet et
xi og md5(xi) at finde et xj, hvor md5(xj) = md5(xi). Derudover er det i
det hele taget svært at finde to xi og xj, hvor md5(xi) = md5(xj) [1].
Derfor _bør_ det principielt ikke være et sikkerhedsbrud at offentliggøre
hash-værdierne af passwords.

[1] Hvad tror du er sværest ?

--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

On Fri, 18 Oct 2002 20:12:35 +0000 (UTC), Jesper Stocholm
<jespers@stocholm.invalid> wrote:

>Jørn Andersen wrote :
>
>> On Fri, 18 Oct 2002 20:36:00 +0200, "Flemming Jensen"
>> <CyberOrc@tiscali.dk> wrote:
>
>>>Det var jo noget andet
>>>hvis man smed en hashed værdi i en query til en anden side, hvor man
>>>jo så sagtens kunne se den hashede kode.
>>
>> Selvfølgelig.
>
>hvorfor 'selvfølgelig' ?

Fordi spørgsmålet gik på, at ingen af os egentlig kunne sige noget
præcist om, *hvor* sikkert MD5 er. På den baggrund er det vel rimeligt
at sige, at MD5-sikkerheden har større betydning i det mere åbne miljø
(querystring) end i det mere lukkede miljø (script-afvikling og script
-> database-overførsel).

>MD5 er "stærkt kollosions-fri", hvilket betyder, at det er svært, givet et
>xi og md5(xi) at finde et xj, hvor md5(xj) = md5(xi). Derudover er det i
>det hele taget svært at finde to xi og xj, hvor md5(xi) = md5(xj) [1].
>Derfor _bør_ det principielt ikke være et sikkerhedsbrud at offentliggøre
>hash-værdierne af passwords.

Det var også nogenlunde sådan jeg opfattede det, sidst det blev
diskuteret.

>[1] Hvad tror du er sværest ?

Umiddelbart vil jeg sige det første - men det lyder svært nok til at
jeg ikke gider teste efter

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

---

Jørn Andersen wrote :

> On Fri, 18 Oct 2002 20:12:35 +0000 (UTC), Jesper Stocholm
> <jespers@stocholm.invalid> wrote:
>>Jørn Andersen wrote :
>>>
>>> Selvfølgelig.
>>
>>hvorfor 'selvfølgelig' ?
>
> Fordi spørgsmålet gik på, at ingen af os egentlig kunne sige noget
> præcist om, *hvor* sikkert MD5 er. På den baggrund er det vel rimeligt
> at sige, at MD5-sikkerheden har større betydning i det mere åbne miljø
> (querystring) end i det mere lukkede miljø (script-afvikling og script
> -> database-overførsel).

ok ... så kan jeg jo sige lidt om sikkerheden. MD5 er faktisk uhyre
sikker ifht kollisioner. Der findes ganske enkelt ikke nogle (simple)
angreb, der er nemmere end blot at prøve sig frem. Dertil kommer at MD5s
udfaldsrum er på 128-bits - hvilket ikke "bare lige er noget man bryder".

>>MD5 er "stærkt kollosions-fri", hvilket betyder, at det er svært,
>>givet et xi og md5(xi) at finde et xj, hvor md5(xj) = md5(xi).
>>Derudover er det i det hele taget svært at finde to xi og xj, hvor
>>md5(xi) = md5(xj) [1]. Derfor _bør_ det principielt ikke være et
>>sikkerhedsbrud at offentliggøre hash-værdierne af passwords.
>
> Det var også nogenlunde sådan jeg opfattede det, sidst det blev
> diskuteret.
>
>>[1] Hvad tror du er sværest ?
>
> Umiddelbart vil jeg sige det første - men det lyder svært nok til at
> jeg ikke gider teste efter

det er også korrekt :) Men argumentet for, hvorfor 1 er sværere end 2 er
sådan set nogenlunde intuitivt. Hvis du har en bestemt værdi i hånden og
skal finde endnu en værdi, der giver samme hash-funktion, så er det altid
markant sværere end blot at finde to andre værdier, der har fælles hash-
værdi. I sidste tilfælde kan du jo bare tage de første to par du finder -
hvorimod du i det første tilfælde _skal_ finde en værdi, der passer med
den oprindelige værdi.

--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

Jesper Stocholm wrote:
> I sidste tilfælde kan du jo bare tage de
> første to par du finder - hvorimod du i det første tilfælde _skal_
> finde en værdi, der passer med den oprindelige værdi.

Huh? Den tror jeg godt at jeg kan modargumentere. At finde et par er da
næsten lige så svært som at en xj givet xi. Ved de matchene par, har du
jo også givet xi, men den skifter bare jævnligt. Det skulle dog ikke
undre mig om der ligger underligt logik á la fødselsdagssyndromet bag
(altså noget *virkelig* skal tænke sig om før man svarer).

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote :

> Jesper Stocholm wrote:
>> I sidste tilfælde kan du jo bare tage de
>> første to par du finder - hvorimod du i det første tilfælde _skal_
>> finde en værdi, der passer med den oprindelige værdi.
>
> Huh? Den tror jeg godt at jeg kan modargumentere. At finde et par er da
> næsten lige så svært som at en xj givet xi. Ved de matchene par, har du
> jo også givet xi, men den skifter bare jævnligt.

Nej, for modargumentet er ikke korrekt. Forestil dig, at du står ved en
kasse med par af alle tal i. Nu tager du et tilfældigt tal op og nu skal du
finde dets makker. Derfor begynder du at tage tal op - ét ad gangen.
Sandsynligheden for at du finder netop det manglende tal er (meget) mindre
end sandsynligheden for, at du undervejs kommer forbi to tal, der er ens.
Du kan jo hele tiden se tilbage og se efter, hvilke tal du allerede har
taget op. Derfor "skifter" den ikke jævnligt - i hvilket tilfælde du i
øvrigt ville have ret (som jeg læser det du skrev). Hvis du har et "fast"
xi, så kan du blot smide de optagne værdier væk, hvis de ikke matcher. I
tilfælde 2 kan du gemme dem, da du blot skal finde "any pair of two
numbers".

> Det skulle dog ikke
> undre mig om der ligger underligt logik á la fødselsdagssyndromet bag
> (altså noget *virkelig* skal tænke sig om før man svarer).

det gør det også - og specielt fødselsdagsangrebet (som det hedder) er
meget vigtig i forbindelse med analyse af hash-funktioner.



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

On Sat, 19 Oct 2002 10:22:44 +0000 (UTC), Jesper Stocholm
<jespers@stocholm.invalid> wrote:

>fødselsdagsangrebet (som det hedder)

??

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

---

Jørn Andersen wrote :

> On Sat, 19 Oct 2002 10:22:44 +0000 (UTC), Jesper Stocholm
> <jespers@stocholm.invalid> wrote:
>
>>fødselsdagsangrebet (som det hedder)
>
> ??

når man anvender "egenskaberne" i fødselsdagsparadokset, så hedder det et
"fødselsdagsangreb" eller "birthday attack".



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

On Sat, 19 Oct 2002 12:24:04 +0000 (UTC), Jesper Stocholm
<jespers@stocholm.invalid> wrote:

>når man anvender "egenskaberne" i fødselsdagsparadokset, så hedder det et
>"fødselsdagsangreb" eller "birthday attack".

OK så: Hvad er "fødselsdagsparadokset"?

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

---

Jørn Andersen wrote :

> On Sat, 19 Oct 2002 12:24:04 +0000 (UTC), Jesper Stocholm
> <jespers@stocholm.invalid> wrote:
>
>>når man anvender "egenskaberne" i fødselsdagsparadokset, så hedder det
>>et "fødselsdagsangreb" eller "birthday attack".
>
> OK så: Hvad er "fødselsdagsparadokset"?



http://www.howstuffworks.com/question261.htm

--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

On Sat, 19 Oct 2002 13:22:51 +0000 (UTC), Jesper Stocholm
<jespers@stocholm.invalid> wrote:

>> OK så: Hvad er "fødselsdagsparadokset"?

>http://www.howstuffworks.com/question261.htm

Aha - Tak!

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

---

Jesper Stocholm wrote:
> Du kan jo hele tiden se tilbage og se
> efter, hvilke tal du allerede har taget op.

Hov ja. Det er jo faktisk fuldstændigt magen til fødselsdagsparadokset.
Skægt, egentlig, da det var mere eller mindre tilfældigt jeg nævnte det,
og så falder jeg selv i samme hul. Hvad er sandsynligheden for det?

> det gør det også - og specielt fødselsdagsangrebet (som det hedder)

Jeg ved heller ikke hvorfor jeg oversatte "paradox" til "syndrom"

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote :

> Jesper Stocholm wrote:
>> Du kan jo hele tiden se tilbage og se
>> efter, hvilke tal du allerede har taget op.
>
> Hov ja. Det er jo faktisk fuldstændigt magen til fødselsdagsparadokset.

Ja, det er vist korrekt ...

> Skægt, egentlig, da det var mere eller mindre tilfældigt jeg nævnte
> det, og så falder jeg selv i samme hul. Hvad er sandsynligheden for
> det?

1
------- , x --> inf
lim(x^2)

?



--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

Jesper Stocholm wrote:
> 1
> ------- , x --> inf
> lim(x^2)


Hvis man dog bare selv kunne vælge hvor man vil lægge denne
sandsynlighed. Så kunne jeg have vundet samtlige Lottospil siden 7.
oktober 1989.

Din formel for mig også til at tænke på the Infinite Improbability Drive
i the Heart of Gold.

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote :

> Jesper Stocholm wrote:
>> 1
>> ------- , x --> inf
>> lim(x^2)
> Din formel for mig også til at tænke på the Infinite Improbability Drive
> i the Heart of Gold.

jeps ... og husk på, at det netop var denne fremdriftsmåde der bevirkede,
at der den dag i dag ikke findes et "største" primtal.



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

Jesper Stocholm wrote:
> MD5 er "stærkt kollosions-fri", hvilket betyder, at det er svært,
> givet et xi og md5(xi) at finde et xj, hvor md5(xj) = md5(xi).
> Derudover er det i det hele taget svært at finde to xi og xj, hvor
> md5(xi) = md5(xj) [1]. Derfor _bør_ det principielt ikke være et
> sikkerhedsbrud at offentliggøre hash-værdierne af passwords.
>
> [1] Hvad tror du er sværest ?

Tjoo... MD5 scrambler jo værdierne ret godt, men den gør det ikke
"100%". Derfor vil det altid være nemmere at pejle sig frem til to ens
MD5'ere, end det er at finde xj, når xi kendes. Principielt burde det
dog være lige svært.

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote:
> Tjoo... MD5 scrambler jo værdierne ret godt, men den gør det ikke
> "100%". Derfor vil det altid være nemmere at pejle sig frem til to ens
> MD5'ere, end det er at finde xj, når xi kendes. Principielt burde det
> dog være lige svært.

PS: Dette er bare et (nogenlunde) kvalificeret gæt. Det er ikke noget
jeg er sikker på. Det jeg mener med 100% scrambling er at den krypterede
værdi skulle være 100% uafhængig af den oprindelige værdi, men
resultatet af krypteringsalgoritmen skal selvfølgelig stadig være den
samme hver gang (og det kan jo ikke lade sig gøre, for det vil kræve en
samling af samtlige mulige værdier tilknyttet de (tilfældigt generede)
krypterede værdier, og sådan en samling vil være uendeligt stor).

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote :

> Jakob Møbjerg Nielsen wrote:

> PS: Dette er bare et (nogenlunde) kvalificeret gæt. Det er ikke noget
> jeg er sikker på. Det jeg mener med 100% scrambling er at den
> krypterede
> værdi skulle være 100% uafhængig af den oprindelige værdi,

men det dur jo ikke. Den vigtigste egenskab ved en hash-funktion er jo, at
man kan sammenligne hash-værdier - ellers kan man jo ikke bruge det til
noget. Men hvis hash-værdien er 100% uafhængig af input, så går dette
formål jo i vasken. Hele arsagen til at anvende en hash-funktion er jo, at
den der deterministisk.

> men
> resultatet af krypteringsalgoritmen skal selvfølgelig stadig være den
> samme hver gang (og det kan jo ikke lade sig gøre, for det vil kræve en
> samling af samtlige mulige værdier tilknyttet de (tilfældigt generede)
> krypterede værdier, og sådan en samling vil være uendeligt stor).

Der er jo også et aspekt af hash-funktioner, som vi slet ikke har snakket
om - og det er komprimering. Der er jo sådan set ikke noget i vejen for, at
en hash-funktion ikke komprimerede de data den modtog - men fx at længden
af hash-værdien var den samme som den originale tekst. Så ville man jo - et
langt stykke hen ad vejen - være ude over problemet med kollisioner. Disse
opstår jo, da man putter udfaldsrummet af "hele verden" ned i et 128bits
rum ... og det _må_ jo give kollisioner.



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

Jesper Stocholm wrote:
> men det dur jo ikke. Den vigtigste egenskab ved en hash-funktion er
> jo, at man kan sammenligne hash-værdier - ellers kan man jo ikke
> bruge det til noget. Men hvis hash-værdien er 100% uafhængig af
> input, så går dette formål jo i vasken. Hele arsagen til at anvende
> en hash-funktion er jo, at den der deterministisk.

Uuuhh... måske kunne jeg have formuleret mig lidt bedre. Det jeg mente
var at hvis man laver en fortløbende række af fx. tal eller en række af
lignende tekster, og hasher dem, så må det ikke kunne spores i
MD5-værdierne at der netop er tale om en række. En mere rigtigt term
havde måske været "100% uafhængig af inputtets omkringliggende eller
lignende værdier". Og det er det jeg mener ikke kan lade sig gøre, men
MD5 kommer *meget* tæt på.

> Disse opstår jo, da man putter
> udfaldsrummet af "hele verden" ned i et 128bits rum ... og det _må_
> jo give kollisioner.

Selvfølgelig. Det bliver (blev) jo også brugt til at ændre beskeder.
Efter ændringen tilføjede og fjernede man mellemrum, linjeskift,
stavefejl, osv. Det kan lade sig gøre ved 32bit, er utroligt svært ved
64bit og stort set umuligt ved 128bit.

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote :

> Jesper Stocholm wrote:
>> Disse opstår jo, da man putter
>> udfaldsrummet af "hele verden" ned i et 128bits rum ... og det _må_
>> jo give kollisioner.
>
> Selvfølgelig. Det bliver (blev) jo også brugt til at ændre beskeder.
> Efter ændringen tilføjede og fjernede man mellemrum, linjeskift,
> stavefejl, osv. Det kan lade sig gøre ved 32bit, er utroligt svært ved
> 64bit og stort set umuligt ved 128bit.

jeps ... og jeg skal måske også sige, at de mest effektive angreb, der
findes på fx hash-funktioner alle har en meget vigtig uhensigtsmæssighed:
de kræver aaaaaalt for meget plads til lagring af de løbende værdier.



--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

Jakob Møbjerg Nielsen wrote :

> Jesper Stocholm wrote:
>> MD5 er "stærkt kollosions-fri", hvilket betyder, at det er svært,
>> givet et xi og md5(xi) at finde et xj, hvor md5(xj) = md5(xi).
>> Derudover er det i det hele taget svært at finde to xi og xj, hvor
>> md5(xi) = md5(xj) [1]. Derfor _bør_ det principielt ikke være et
>> sikkerhedsbrud at offentliggøre hash-værdierne af passwords.
>>
>> [1] Hvad tror du er sværest ?
>
> Tjoo... MD5 scrambler jo værdierne ret godt, men den gør det ikke
> "100%".

Hvad mener du med det ? Jeg er ikke sikker på, at jeg helt forstår det.
Udfaldene fra hash-funktionen er "ligeligt" fordelt i udfaldsrummet - der
er af størrelsesordenen 128bits.

> Derfor vil det altid være nemmere at pejle sig frem til to ens
> MD5'ere, end det er at finde xj, når xi kendes.

Det er nemlig præcist korrekt.

> Principielt burde det dog være lige svært.

Men det kan det jo ikke. Det er jo ikke en egenskab ved specielt hash-
funktioner - sådan _er_ det jo bare ... ligeom tyngekraften og hende der
den irriterende i Go'morgen Danmark på TV2. Det er der jo ikke noget at
gøre ved.



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

Jakob Møbjerg Nielsen wrote in
> Du laver bare endnu et passwordfelt, og så sammenligner du de to
> passwords på den side du submitter til.
Min bruger giver sig selv brugernavn og password i en insertform der
submittes og derefter sendes brugeren til logon siden.
Er det ikke på den side brugeren udfylder formen der skal checkes?
Når brugeren kommer til logon siden er man jo oprettet?
Med venlig hilsen
Michael Tillgaard



--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP ???
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Michael Tillgaard wrote:
> Er det ikke på den side brugeren udfylder formen der skal checkes?

Nope

> Når brugeren kommer til logon siden er man jo oprettet?


Det bliver han vel først på den side? Lav et check inden oprettelsen, og
hvis det fejler, så skriv hvad der er galt:

---opret.html---
<form method="post" action="logon.asp">
<input type="text" name="brugernavn">
<input type="password" name="password">
<input type="password" name="password">
</form>
----------------

---logon.asp---
<%
if StrComp(request("password"), request("password2")) = 0 then
'Check at password og brugernavn overhovedet indeholder
'noget og opret brugeren
else
response.write "Passwords er ikke ens"
end if
%>
---------------

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote:
> <input type="password" name="password">
> <input type="password" name="password">


Den sidste skulle selvfølgelig være:
<input type="password" name="password2">

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
http://www.jakobnielsen.dk/ | -- Terry Pratchett, Reaper Man
Jeg søger et fuldtidsjob som programmør. Tag et kig på hjemmesiden.

---

Jakob Møbjerg Nielsen wrote in dk.edb.internet.webdesign.serverside.asp:
> Det bliver han vel først på den side? Lav et check inden oprettelsen, og

Først tak for hjælpen til Jakob og Jørn.
Det kan godt være det ikke er pænt eller elegant men jeg har fået det til
at virke. Ved uoverensstemmelse mellem de to passwords føres brugeren til
en passwordfejl side.
Det var dog på siden hvor brugeren udfylder insert formen det skulle gøres
og ikke på logon siden (elevstart.asp).
Jeg kan ikke forklare hvorfor men det virker sådan her:

<%
' *** Insert Record: set variables
if StrComp(request("maaladgangskode"), request("maaladgangskode1")) = 0
then

If (CStr(Request("MM_insert")) = "form2") Then

MM_editConnection = MM_maal_STRING
MM_editTable = "maalbrugere"
MM_editRedirectUrl = "elevstart.asp"
MM_fieldsStr =
"maalbruger|value|maaladgangskode|value|maalefternavn|value|maaladresse|val
ue|maalby|value|maalmail|value|maaltelefon|value"
MM_columnsStr =
"maalbruger|',none,''|maaladgangskode|',none,''|maalefternavn|',none,''|maa
ladresse|',none,''|maalby|',none,''|maalmail|',none,''|maaltelefon|',none,'
'"

' create the MM_fields and MM_columns arrays
MM_fields = Split(MM_fieldsStr, "|")
MM_columns = Split(MM_columnsStr, "|")

' set the form values
For MM_i = LBound(MM_fields) To UBound(MM_fields) Step 2
MM_fields(MM_i+1) = CStr(Request.Form(MM_fields(MM_i)))
Next

' append the query string to the redirect URL
If (MM_editRedirectUrl <> "" And Request.QueryString <> "") Then
If (InStr(1, MM_editRedirectUrl, "?", vbTextCompare) = 0 And
Request.QueryString <> "") Then
MM_editRedirectUrl = MM_editRedirectUrl & "?" & Request.QueryString
Else
MM_editRedirectUrl = MM_editRedirectUrl & "&" & Request.QueryString
End If
End If

End If
else
Response.Redirect( "/maal/passwordfejl.asp" )
end if

%>

Med venlig hilsen

Michael Tillgaard

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP ???
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials