Overvejelser vdr. Glemt password / sikkerhed

Det kan vel ikke blive meget mere sikkert?

Der er en ting jeg har tænkt lidt over.. hvordan skal jeg lave det unikke link som brugeren kan trykke på? Det skal være et man ikke bare lige kan lave for sig selv, selvom det bliver lagt i db'en da man så bare kan bestille en kode og måske 'regne' sig frem til bekræftelseslinket.. nogen gode ideer?

En SHA-256 hash af f.eks.:
  rigtigt navn + tid + memory forbrug paa systemet
er ikke til at gaette.

Men jeg forstaar ikke hvad du vil beskytte dig mod. Hvis de ikke kan intercepte email kan de ikke faa passwordet og hvis de kan intercepte email, saa har de ikke behov for at gaette link.

Få serveren til at returnere en GUID og brug det i linket. http://en.wikipedia.org/wiki/Guid

#3: Det er bare for at undgå at nogen vil irriterre andre brugere ved konstant at nulstille deres password..

Man boer ikke bruge GUID's til den slags. GUID's har meget lille chance for tilfældig collision men er ikke sikre mod angreb.

re #5)

Hjælper linket på det?

Ah. Du vil forhindre at nogen uden adgang til email requester et nyt password og gaetter link URL som en form for chikane ?

#8: Lige præcis..

Der er flere som bruger GUID til den slags link arne_v

Det er muligt. Der er ogsaa mange sites som er pivaabne for SQL injection.

Hvis du laeser dit eget Wikipedia link saa staar der:

Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given the initial state one can predict up to the next 250 000 GUIDs returned by the function UuidCreate[2]. This is why GUIDs should not be used in cryptography, e.g., as random keys.

GUID's er designet til at vaere tilfaeldige men ikke til at vaere svaere at gaette.

Ja ok! arne_v :-) kom spørgsmålet så ikke fra CIA eller PET

Maaske. Men man kan jo ligesaa godt goere det ordentligt.

Men nu vi taler om det, saa skal mit forslag i #3 have mere end ca. 100 random bits for at vaere sikker.

Det kraever vist en rimelig praecis tid og flere memory oplysninger at faa det.

Men SHA-256 delen skulle vaere fin.

Hvad med det her:

$salt = uniqid() . memory_get_usage () . time();
$enc = sha1($salt);

Laver noget i retningen af:
Salt: 4aa16a6ac497e4745201252092522
Enc: 3893ee46039f9a6edf83054ba4d21282bb23fdb1

Er den nogenlunde eller?

Det er saadan noget jeg taenker paa.

Men man skal bare sikre sig at $salt har et tilpas stort range til at forhindre dictionary attacks.

Jeg kan checke de specifikke dele senere.

lige nu så tjekker den IP + email + guid med det der er lagret i DB'en ... og det skal passe ved første forsøg... ellers sletter den det entry fra databasen.. ved ikke om det lyder OK?

#16: Det må du gerne. :)

uniqid() er ikke super god i den sammenhæng.

Så vidt jeg kan se så virker den som:

function myuniqid() {
    $t = explode(' ', microtime());
    return sprintf('%08x%05x', $t[1], intval($t[0]*1000000));
}

hvilket reelt set bare er tiden i milliontedele sekunder. Den kan godt forudsiges.

Men sammen med memoryforbrug og brug af hash, så må den være så svær at ramme at det er sikkert nok.

Arne> Smid et svar

svar