---

Hej.

Hvordan laver jeg det sådan så nye brugere modtager et
aktiverings link til deres bruger ?

Tjek min side:
www.chrlogin.frac.dk

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

---

Fandt lige ud at det er faktisk er lidt svært, så jeg skal bare
have et system, der sender en mail ud med ens bruger oplysninger.

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

---

Christian Jørgensen wrote:
> Hej.
>
> Hvordan laver jeg det sådan så nye brugere modtager et
> aktiverings link til deres bruger ?

Databasen indeholder et felt med et unikt id og evt. et lille password
felt med endnu en unik kode, men bare med mange bogstaver/tal, og et
felt der hedder fx. not_validated

Når en bruger så opretter sig, så sætter man not_validated til false og
laver en unik kode og smækker det ind i databasen.

Så sendes der en mail til brugeren med et link hvor i unikt id og den
unikke kode er i... også er det bare at opdatere not_validated til true

---

Martin wrote:
> Databasen indeholder et felt med et unikt id og evt. et lille password
> felt med endnu en unik kode, men bare med mange bogstaver/tal, og et
> felt der hedder fx. not_validated
>
> Når en bruger så opretter sig, så sætter man not_validated til false og
> laver en unik kode og smækker det ind i databasen.
>
> Så sendes der en mail til brugeren med et link hvor i unikt id og den
> unikke kode er i... også er det bare at opdatere not_validated til true

Den unikke kode kan eventuelt genereres ved at lave en MD5 som af
brugernavn+kodeord, eller andre informationer som man måtte have fået
fra brugeren. Bare et tip :)

--
Venlig hilsen
Jeppe Toustrup

---

Jeppe Toustrup wrote:
> Martin wrote:
>> Databasen indeholder et felt med et unikt id og evt. et lille password
>> felt med endnu en unik kode, men bare med mange bogstaver/tal, og et
>> felt der hedder fx. not_validated
>>
>> Når en bruger så opretter sig, så sætter man not_validated til false
>> og laver en unik kode og smækker det ind i databasen.
>>
>> Så sendes der en mail til brugeren med et link hvor i unikt id og den
>> unikke kode er i... også er det bare at opdatere not_validated til true
>
> Den unikke kode kan eventuelt genereres ved at lave en MD5 som af
> brugernavn+kodeord, eller andre informationer som man måtte have fået
> fra brugeren. Bare et tip :)

Hvis den er lavet af brugerens brugernavn + kode (dvs. informationer
brugeren selv har indtastet) skal der tilføjes en form for
securekey/salt anyway... ellers kan alle og enhver regne den ud - og
valideringen er ligegyldig.

Mvh
Johan

---

Johan Holst Nielsen wrote:
> Hvis den er lavet af brugerens brugernavn + kode (dvs. informationer
> brugeren selv har indtastet) skal der tilføjes en form for
> securekey/salt anyway... ellers kan alle og enhver regne den ud - og
> valideringen er ligegyldig.

Okay det var dårligt formuleret.
I så fald er valideringen ligegyldigt hvis man finder ud af MÅDEN md5'en
er lavet af de data man selv har indtastet.

Altså hvis man bruger MD5 skal man tilføje *mindst* en ubekendt (af
brugeren) for at det kan bruges i tilfælde som f.eks. aktiveringslink.
Derfor er det tit lige så nemt at lave f.eks.

$uniktID = md(uniqid(rand(),true));

og så lave en url der er noget ala

activate.php?uid=[unikt id]&username=[username]

--
Johan Holst Nielsen
Freelance PHP Developer - http://phpgeek.dk

---

Johan Holst Nielsen <spam@phpgeek.dk> wrote in
news:468bf3ab$0$90265$14726298@news.sunsite.dk:

> activate.php?uid=[unikt id]&username=[username]

Hvorfor tage username med i linket?

--
Henrik Stidsen - http://henrikstidsen.dk/

---

Henrik Stidsen wrote:
> Johan Holst Nielsen <spam@phpgeek.dk> wrote in
> news:468bf3ab$0$90265$14726298@news.sunsite.dk:
>
>> activate.php?uid=[unikt id]&username=[username]
>
> Hvorfor tage username med i linket?

Det er som sådan heller ikke (altid) nødvendig.

Dog skal du dog en smule ekstra sikkerhed ved at "hackeren" både skal
kende username og hashstrengen for at aktivere brugeren. Omvendt behøves
"hackeren" kun at kende hashstrengen.

--
Johan Holst Nielsen
Freelance PHP Developer - http://phpgeek.dk

---

Johan Holst Nielsen skrev:
> Henrik Stidsen wrote:
>> Johan Holst Nielsen <spam@phpgeek.dk> wrote in
>> news:468bf3ab$0$90265$14726298@news.sunsite.dk:
>>
>>> activate.php?uid=[unikt id]&username=[username]
>>
>> Hvorfor tage username med i linket?
>
> Det er som sådan heller ikke (altid) nødvendig.
>
> Dog skal du dog en smule ekstra sikkerhed ved at "hackeren" både skal
> kende username og hashstrengen for at aktivere brugeren. Omvendt behøves
> "hackeren" kun at kende hashstrengen.
>


Nu kan det selvfølgelig godt være det bare er mig der er mærkelig, men
jeg synes godt nok i besværliggør en meget simpel proces.

Tabellen users
| id | username | password | active | (og andre relevante kolonner)

Tabellen activation_codes
| id | code |

Active sættes til nul.

<?php

/*
kode der generer brugeren
*/

//prøv at gætte mig
$activation_code = md5(uniqid(time())).md5(uniqid(time()));

mysql_query("INSERT INTO activation_codes (id, code) VALUES
('".mysql_insert_id()."', '".$activation_code."')") or die(mysql_error());

?>


aktivering.php?code=den_64_tegns_lange_kode
<?php

$code = $_GET["code"];
$query = mysql_query("SELECT id FROM activation_codes WHERE
code='".$code."'");

if(mysql_num_rows($query)>0)
{
mysql_query("UPDATE users SET active=1 WHERE id=".mysql_result($query,
0, "id");
mysql_query("DELETE FROM activation_codes WHERE
id=".mysql_result($query, 0, "id");

/*
Kode efter godkendt aktivering
*/
}
else
{

/*
Hvis koden ikke eksisterer...
*/
}

?>

Koden er naturligvis ikke kørt igennem for sql injections eller
lignende, men viser blot princippet.

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm <shadyz@_REMOVETHIS_err0r.dk> wrote in
news:468c92a5$0$839$edfadb0f@dread12.news.tele.dk:

> Nu kan det selvfølgelig godt være det bare er mig der er mærkelig, men
> jeg synes godt nok i besværliggør en meget simpel proces.

Hvem er det der besværliggør noget som helst ?

--
Henrik Stidsen - http://henrikstidsen.dk/

---

Henrik Stidsen skrev:
> Hvem er det der besværliggør noget som helst ?

Beklager meget, hvis du følte dig ramt - det var blot dit indlæg jeg
valgte at svare på den generelle tråd.

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:
> Henrik Stidsen skrev:
>> Hvem er det der besværliggør noget som helst ?
>
> Beklager meget, hvis du følte dig ramt - det var blot dit indlæg jeg
> valgte at svare på den generelle tråd.

Næh det var faktisk mit indlæg du svarede... synes rent faktisk dit
forslag og mit meget ligner hinanden (faktisk gør alle). Den eneste
forskel du har i forhold til "os andre" er at du har medtaget hele
databasestrukturen osv :)

Mvh
Johan

--
Johan Holst Nielsen
Freelance PHP Developer - http://phpgeek.dk

---

Johan Holst Nielsen skrev:
> Næh det var faktisk mit indlæg du svarede... synes rent faktisk dit
> forslag og mit meget ligner hinanden (faktisk gør alle). Den eneste
> forskel du har i forhold til "os andre" er at du har medtaget hele
> databasestrukturen osv :)

Lidt træt skal man også have lov til at være... :p

Anyways, for mig, virkede det som at tråden begyndte at handle om
sikkerheden i MD5 krypteringen af bruger id eller navn og så videre.

Hvis man, ud fra det script man har lavet, virkelig fortæller hvad md5
krypteringen består af, så har man jo ikke fortjent bedre end at få
væltet sit site, på grund af den dårlige kode.

Eksempel:
aktivering.php?bruger_id=f30ac21c1aab9c1dac9a3aac7e4d5e3c

Uanset om det er tilfældet eller ej, giver man brugeren en indikation om
at den krypterede streng er brugerens brugerid.

aktivering.php?code=f30ac21c1aab9c1dac9a3aac7e4d5e3c

Ovenstående viser på ingen måde, hvad md5 krypteringen er baseret på.

e7649c8938e38a671cd82a7328505bdf
ef5c1f6daae6b1ea49bb6dc6f3812073

Personligt vælger jeg at aktivere brugeren således:

activate/e7649c8938e38a671cd82a7328505bdfef5c1f6daae6b1ea49bb6dc6f3812073

$code = $_SERVER["PATH_INFO"];

$hash1 = substr($code, 1, 32);
$hash2 = substr($code, 33, 32);

$query = mysql_query("SELECT id FROM users WHERE MD5(CONCAT(id,
username)) = '".$hash1."' AND MD5(CONCAT(email, timestamp)) =
'".$hash2."' AND active = 0");

if(mysql_num_rows($query)>0)
{
   $userid = mysql_result($query, 0, "id");
   mysql_query("UPDATE users SET active=0 WHERE id=".$userid;
}

Så slipper jeg både for den ekstra tabel og så forekommer det mig
relativt svært at gætte.

Men det er jo også kun en holdning. :)

Beklager, hvis jeg har overanalyseret tråden... :)

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm <shadyz@_REMOVETHIS_err0r.dk> wrote in
news:468d2dc5$0$19376$edfadb0f@dread11.news.tele.dk:

>> Hvem er det der besværliggør noget som helst ?

> Beklager meget, hvis du følte dig ramt - det var blot dit indlæg jeg
> valgte at svare på den generelle tråd.

Var nu ikke fordi jeg følte mig ramt - jeg kunne bare ikke se hvad der fik
dig til at sige at det blev besværliggjort. Slet ikke efter at have set din
kode der ikke var mere simpel end hvad andre havde foreslået :)

--
Henrik Stidsen - http://henrikstidsen.dk/

---

On Thu, 05 Jul 2007 06:54:12 +0200, Johan Holst Nielsen
<spam@phpgeek.dk> wrote:

>Dog skal du dog en smule ekstra sikkerhed ved at "hackeren" både skal
>kende username og hashstrengen for at aktivere brugeren. Omvendt behøves
>"hackeren" kun at kende hashstrengen.

... plus at man i særtilfælde kan risikere at bekræfte flere konti på
samme tid, hvis de har samme md5sum. Det er selvfølgelig rimeligt
usandsynligt.

I nogle tilfælde kan det være fint nok, at der bruges den samme salt.
Det kan fx være ved tvær-site-logins, hvor brugere i system 1 skal
kunne logge ind med deres rettigheder på system 2, uden at system 2
skal have adgang til system 1s brugerdatabase - dvs. uden at kende til
eksisterende brugere eller kodeord. Med andre ord, brugere på system 1
skal ikke være bekymret for at system 2 (som måske drives af et helt
andet firma) har adgang til deres egne detaljer.

Her kan system 1 så sende brugeren over til system 2 med brugernavn,
sikkerhedsniveau med mere og så en passende hash.

De to sites kan selvfølgelig også bare sende en egentligt krypteret
datapakke (evt. via klienten) til hinanden, men hash-løsningen er ret
let at komme i gang med.

--
- Peter Brodersen
Kendt fra Internet

---

> Databasen indeholder et felt med et unikt id og evt. et lille password
> felt med endnu en unik kode, men bare med mange bogstaver/tal, og et
> felt der hedder fx. not_validated
>
> Når en bruger så opretter sig, så sætter man not_validated til false
> og laver en unik kode og smækker det ind i databasen.
>
> Så sendes der en mail til brugeren med et link hvor i unikt id og den
> unikke kode er i... også er det bare at opdatere not_validated til
> true

Det er en god ide at lade variable betyde det, de hedder, og ikke det
modsatte

Hint: Du starter med at sætter not_validated til false, og til true, når man
er valideret. Ikke helt logisk...

Leif