---

Hej,

På min hjemmeside har jeg en logon-form.
Jeg vil gerne forhindre at kodeordet kan "sniffes" af andre på netværket, og
tænkte derfor på at "kryptere" kodeordet inden det sendes - for eksempel ved
at lave en hashkode af det eller lignende.

For at forhindre at selve "hashkoden" (ved ikke om det staves haskode
egentligt) bliver sniffet, og brugt til at logge ind, skal kodeordet flettes
sammen med en random string (for eksempel SessionID).

Fra klienten skal dette gøres med javascript, på det indtastede kodeord.
På serveren skal det samme gøres med kodeordet fra databasen (i vb).
Derefter sammenlignes de to "hashkoder" med hinanden, hvorved jeg kan
verificere at det er det rigtige kodeord...

Hvad synes i om den plan? Lyder det som en god sikkerhed imod
packetsniffing?

Har i nogle forslag til scripts der kan bruges til dette? Det er vigtigt at
krypteringen kun går én vej; man må fra hashkoden ALDRIG kunne udlede
passwordet.

På forhånd tak for hjælpen!

---

Casper Bang wrote:

> På min hjemmeside har jeg en logon-form.
> Jeg vil gerne forhindre at kodeordet kan "sniffes" af andre på
> netværket, og tænkte derfor på at "kryptere" kodeordet inden det
> sendes - for eksempel ved at lave en hashkode af det eller lignende.

> For at forhindre at selve "hashkoden" (ved ikke om det staves haskode
> egentligt) bliver sniffet, og brugt til at logge ind, skal kodeordet
> flettes sammen med en random string (for eksempel SessionID).
>
> Fra klienten skal dette gøres med javascript, på det indtastede
> kodeord. På serveren skal det samme gøres med kodeordet fra databasen
> (i vb). Derefter sammenlignes de to "hashkoder" med hinanden, hvorved
> jeg kan verificere at det er det rigtige kodeord...
>
> Hvad synes i om den plan? Lyder det som en god sikkerhed imod
> packetsniffing?

Tjoeh, men spørgsmålet er imo mere, om problemet er reelt eller en
akademisk øvelse. Hvis netværket er "sat rigtigt op", så vil det næsten
være umuligt at sniffe andres data.

Hvis du vil hashe password på klientsiden, så er det korrekt, at man så
ikke kan aflæse brugerid via pakkesnifning, men det bibringer ikke reelt
noget sikkerhed.

Forestil dig følgende:

Scenarium 1:
Bruger A indtaster sit password og sender det ukrypteret til din server.
Du hasher nu det modtagne password på din server og sammenligner den
hashede værdi med data i din database. Undervejs opsnappes det af bruger
B, der nu kan logge ind som bruger A.

Scenarium 2:
Bruger A indtaster sit password og noget javascript [1] udregner
hashværdien og denne sendes til din server. Du sammenligner nu den
modtagne hashværdi med data i din database. Undervejs opsnappes
hashværdien af bruger B og han kan nu logge ind som bruger A.

At flette hashværdien sammen med et sessionid gør det ikke mere sikkert,
da denne værdi skal sendes med i klartekst over netværket før du kan
bruge den serverside - og så kan den også opsnappes.

Den eneste måde du kan sikre dig imod packetsnifning er SSL eller
lignende (alternativt klientside Java eller ActiveX)

[1] http://www.frez.co.uk/freecode.htm#md5

--
Jesper Stocholm http://stocholm.dk

Programmer's code comment:
//It probably makes more sense when you're stoned.

---

>> Hvad synes i om den plan? Lyder det som en god sikkerhed imod
>> packetsniffing?
>
> Tjoeh, men spørgsmålet er imo mere, om problemet er reelt eller en
> akademisk øvelse. Hvis netværket er "sat rigtigt op", så vil det næsten
> være umuligt at sniffe andres data.

Det er et globalt website - så det vil være fra netværk, uden for min
kontrol.


> Scenarium 1:
> Bruger A indtaster sit password og sender det ukrypteret til din server.
> Du hasher nu det modtagne password på din server og sammenligner den
> hashede værdi med data i din database. Undervejs opsnappes det af bruger
> B, der nu kan logge ind som bruger A.

Korrekt, det vil muligvis give en midlertidig adgang til systemet - men
efter at "hackeren" logger ud, vil der ikke være adgang til systemet - den
samme hashværdi vil ikke kunne bruges to gange.

> Scenarium 2:
> Bruger A indtaster sit password og noget javascript [1] udregner
> hashværdien og denne sendes til din server. Du sammenligner nu den
> modtagne hashværdi med data i din database. Undervejs opsnappes
> hashværdien af bruger B og han kan nu logge ind som bruger A.

Same as above


> At flette hashværdien sammen med et sessionid gør det ikke mere sikkert,
> da denne værdi skal sendes med i klartekst over netværket før du kan
> bruge den serverside - og så kan den også opsnappes.

Jeg havde egentligt ikke tænkt på at sessionID også bestemmes af
browseren... det gør helt sikkert sessionID som en mindre attraktiv løsning.
Men igen vil det begrænse det tidsrum som den opsnappede kode kan bruges.


> Den eneste måde du kan sikre dig imod packetsnifning er SSL eller
> lignende (alternativt klientside Java eller ActiveX)
>
> [1] http://www.frez.co.uk/freecode.htm#md5

Hmm, SSL er en mulighed - kræver det dog ikke diverse offentlige
certificeringer etc...?
Java og ActiveX er ude af billedet; nogle brugere ville ikke kunne afvikle
dette korrekt etc...


Jeg takker for dit input. Det gav mig lidt flere vinkler på min idé.

---

Casper Bang wrote:

>>> Hvad synes i om den plan? Lyder det som en god sikkerhed imod
>>> packetsniffing?
>>
>> Tjoeh, men spørgsmålet er imo mere, om problemet er reelt eller en
>> akademisk øvelse. Hvis netværket er "sat rigtigt op", så vil det
>> næsten være umuligt at sniffe andres data.
>
> Det er et globalt website - så det vil være fra netværk, uden for min
> kontrol.

Så vil jeg vurdere, at du ikke behøver at bekymre dig om snifning af
pakker. Du skal sidde meget "tæt" på serveren for at alle pakker kommer
forbi dig.

>> At flette hashværdien sammen med et sessionid gør det ikke mere
>> sikkert, da denne værdi skal sendes med i klartekst over netværket
>> før du kan bruge den serverside - og så kan den også opsnappes.
>
> Jeg havde egentligt ikke tænkt på at sessionID også bestemmes af
> browseren...

SessionID bestemmes ikke af browseren - det dannes af serveren. Men da
det sendes til browseren som en cookie, så medsendes dette sessionID i
samtlige forespørgsler imod serveren - i klartekst.


> det gør helt sikkert sessionID som en mindre attraktiv
> løsning. Men igen vil det begrænse det tidsrum som den opsnappede kode
> kan bruges.

Ja, men hvis man har mulighed for at sniffe pakker, så venter man jo bare
til den næste logger ind. Tidsperspektivet du omtaler, bør ikke have
betydning for din implementering af sikkerhed omkring logon.

> Hmm, SSL er en mulighed - kræver det dog ikke diverse offentlige
> certificeringer etc...?

Næeh, men hvis du vil undgå at brugerne bliver mødt med en advarsel som
på [0], så skal man betale for det. Ellers kan certifikater købes ved bla
Thawte.

> Java og ActiveX er ude af billedet; nogle brugere ville ikke kunne
> afvikle dette korrekt etc...

Ok

> Jeg takker for dit input. Det gav mig lidt flere vinkler på min idé.

[0] https://www.pf.dtu.dk/login/

--
Jesper Stocholm http://stocholm.dk

Programmer's code comment:
//It probably makes more sense when you're stoned.