---

Jeg har sat mig for at finde en godkendelses-protokol der kan benyttes
til websider uden SSL og som kun bruger en hash-funktion (SHA1)..
Adgangskoden må ikke findes i klartekst i databasen.

Jeg har kigget på SKEY protokollen samt forsøgt at lave en simpel
challenge-response protokol. Jeg vil gerne høre jeres forslag - både på
andre protokoller eller ændringer til de to jeg nævner her.

Derudover vil jeg gerne høre hvordan man sikrest "samler" to værdier i
en hash-funktion - altså hvordan a + b i H(a + b) skal implementeres?
Konkatenering? Xor?


C er klienten (browseren), S er serveren, Hn(x) er hash-funktionen H
udført n gange på x.

*SKEY*:
C kender: pw
S kender: n, seed, last = Hn+1(pw + seed)

S -> C: n, seed
C -> S: Hn(pw + seed) = t
S udfører: hvis H(t) == last så last = t og n = n - 1


*Challenge-response*:
C kender: pw
S kender: seed, base = H(pw + seed)

S -> C: random, seed
C -> S: H(H(pw + seed) + random) = t
S udfører: hvis t == H(base + random)


Jeg ved ikke om det kan betale sig (?), men jeg forestiller mig at den
sidste protokol kan modificeres så adgangskoden beskyttes mod
dictionary-attack på følgende måde:

S -> C: random, seed
C -> S: H(Hi+1(pw + seed) + random) = t, i
S udfører: hvis t == H(Hi(base) + random)


På forhånd tak for hjælpen
Morten

---

Nå ja, jeg forestillede mig også at klienten kunne skifte adgangskoden
ved (fra challenge-response protokollen):

S -> C: random, seed
C -> S: H(H(pw + seed) + random) XOR H(new_pw + seed) = t
S: base = H(base + random) XOR t

---

Morten Dahl wrote:
>
> Derudover vil jeg gerne høre hvordan man sikrest "samler" to værdier i
> en hash-funktion - altså hvordan a + b i H(a + b) skal implementeres?
> Konkatenering? Xor?

I de fleste tilfælde vil jeg betragte konkatenering som det
sikreste. En af de væsentlige egenskaber ved en hash funktion
er kollision resistance. Men hvis du starter med at XORe dine
to værdier sammen kan du reelt have en kollision allerede
inden du hasher.

Om det har betydning i det konkrete tilfælde kan jeg ikke
gennemskue.

En anden ting man skal være opmærksom på er, om de to
bitstrenge du konkatenerer altid har samme længde. Hvis deres
længder varierer kan det være nødvendigt at indsætte længden
i starten.

>
> C er klienten (browseren), S er serveren, Hn(x) er hash-funktionen H
> udført n gange på x.
>
> *SKEY*:
> C kender: pw
> S kender: n, seed, last = Hn+1(pw + seed)
>
> S -> C: n, seed
> C -> S: Hn(pw + seed) = t
> S udfører: hvis H(t) == last så last = t og n = n - 1
>
> *Challenge-response*:
> C kender: pw
> S kender: seed, base = H(pw + seed)
>
> S -> C: random, seed
> C -> S: H(H(pw + seed) + random) = t
> S udfører: hvis t == H(base + random)
>
> Jeg ved ikke om det kan betale sig (?), men jeg forestiller mig at den
> sidste protokol kan modificeres så adgangskoden beskyttes mod
> dictionary-attack på følgende måde:
>
> S -> C: random, seed
> C -> S: H(Hi+1(pw + seed) + random) = t, i
> S udfører: hvis t == H(Hi(base) + random)

Jeg kan ikke overskue konsekvensen af en server,
der snyder i disse protokoler. Og hvis man ville
stole på serveren kunne man sikkert slippe afsted
med en simplere protokol.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.