Login script

[sven-o]

Yahoo er det eneste eksemplet jeg kommer på, så det er vel ikke så vanlig som jeg trodde. Den kamelen skal jeg svelge.

 

 

Jaja gutter... For all del. IKKE krypter det i javascript. Jeg prøver bare å foreslå bedre løsninger. Og de _ER_ bedre. Men dersom dere syntes det blir for mye jobb så kan dere la være.

[Torbjørn]

blir det slik http://www.dinadresse.com/side.php?passord=DITTPASSORD ??

 

Da har du jo bare brukt $_GET istedet for $_POST...

Hva snakker du om egentlig? Jeg vet da forskjell på post og get. Klartekst betyr at det ikke blir kryptert! Passord bør krypteres før de sendes av klienten. Dette er helt vanlig.

greit det, men forklar gjerne dette og, "Dette er helt vanlig", jeg vil fortsatt påstå at det er mye vanligere å sette opp en SSL linje enn å begi seg inn i javascript jungelen for å kryptere data.

[sven-o]

greit det, men forklar gjerne dette og, "Dette er helt vanlig", jeg vil fortsatt påstå at det er mye vanligere å sette opp en SSL linje enn å begi seg inn i javascript jungelen for å kryptere data.

Jeg trenger da aldeles ikke å "forklare" meg. Jeg trodde det var mer vanlig, rett og slett fordi fordi det er så enkelt å gjøre.

Kan ikke du heller forklare uttrykket "begi seg inn i javascript jungelen"? Det er da ingen jungel. Dessuten vil det jeg snakker om ikke bety mer enn toppen 10 ekstra linjer med kode. Er det urimelig? Er det en jungel? Tror ikke det kompis.

[Torbjørn]

greit det.

 

spør bare fordi jeg ikke forstår hvordan javascriptkryptering i det hele tatt kan fungere med toppen 10 linjer ekstra kode.

 

gitt at klient A sender data til server B. Klient A kjører javascript og krypterer form data før de sendes over en ukryptert http forbindelse. Siden server B skal ta høyde for at det kan komme både krypterte og ukrypterte data, må kllient A på et eller annet vis si fra at det nå kommer krypterte data. kryptert=1 f.eks.

 

cracker C sniffer denne trafikken. han ser kryptert=1&password=046889550bdbd599a06f398b509b4fe9

 

Så cracker C sender så sin egen HTTP request til server B like etterpå, identisk med den som klient A sendte, og valideres på samme måte og får samme session cookie tilbake igjen som klient A fikk. og vips er han inne.

[????????]

Grunnen til at det ikke er vanlig å bruke javascript for å sende et skjema, som f.eks. logginn, skyldes at det er mange som ikke har javascript enabled og at javascript support varierer i forskjellige browsere og browserversjoner.

 

Tenk deg følgende eksempel:

For å ikke overdrife sier vi at 98% har javascript enabled (tror det er rundt 95% - men er ikke helt sikker). La oss videre anta at du lager et script som fungerer med alle browsere (inkl. mac og webtv).

Da er vil 2 av 100 brukere ikke få logget inn. Problemet er at disse to vil sende en mail til kundeservice for å få svar på hvorfor de ikke får logget inn. 2 personer høres ikke så ille ut - men tenk deg at du har 200 besøkende - dvs. 4 personer som ikke får logget inn. Tenk deg så et helt år, da blir det 1460 mail til kundeservice. Det er mange mail å svare på!

 

200 personer tilsvarer en liten eller medium stor side, så problemet blir enormt så fort du får flere besøkende.

 

Problemet blir ennå større hvis du ikke lager et script som støttes av alle browsere.

 

Tror ikke noen mener å fornærme deg med å si at det er bedre å løse det problemt i PHP - men rett og slett fordi da vil flere kunne bruke scriptet.

[sven-o]

Torbjørn:

1. Selve md5 funksjonen er en ferdig implementert funksjon som kan lastes ned og brukes gratis, så selve JS-krypteringen gjøres med 1 linje kode.

2. Skjemaet sendes vha POST, så man kan ikke logge inn vha å manipulere querystring.

3. Skjemaet MÅ sendes fra MIN side, da php-scriptet sjekker sessionid'en til skjemaet.

4. Når en bruker logger inn, og får godkjent, kan som du sier en hacker snappe opp alt som trengs for å bli godkjent av systemet. Han lager da kjapt et eget form med den ønskede dateen. Siden han også snappet opp SID, blir også denne sendt. Men blir den godkjent? Nei. Idet den "ekte" brukeren logger inn, blir det utført en session_regenerate_id(), som gjør det umulig å logge inn med dataen hackeren først skaffet seg. Dette gjøres også for hver request. Eksempler på dette finnes på php.net.

 

 

?????:

Nei. Som nevnt tidligere er det enkelt å detektere om nettleseren støtter JS. Derfor vil det kunne brukes av alle. Dersom javascript ikke er støttet utføres kryptering på serversiden.

Edit: Å benytte js til form-validering ER helt vanlig. Mener du da at disse sidene ikke kan benyttes av disse 2% brukerene? Feil....

Endret 3. februar 2004 av sven-o

[????????]

Edit: Å benytte js til form-validering ER helt vanlig. Mener du da at disse sidene ikke kan benyttes av disse 2% brukerene? Feil....

Jeg har aldri sagt at det ikke er mulig å benytte JS til formvalidering - poenget er om du skal sende et felt kryptert og JS ikke er enabled vil det komme frem feil.

 

Hvorfor vil du kryptere før det sendes?

 

For å sjekke om en bruker har javascript må dette sendes til php så du må lage et to delt javascript.

1. sjekke om brukeren har JS, og sende den videre til en annen side slik at php får beskjed om dette

2. lage et javascript som krypterer passordet

 

Hele den biten kan jo byttes ut med f.eks.

$var = md5($var);

 

3. Skjemaet MÅ sendes fra MIN side, da php-scriptet sjekker sessionid'en til skjemaet.

Den gjør ikke scriptet sikkert!! Da kan brukeren gå på siden din så har den en session. Der er mer vanlig å bruke HTTP_REFERER - da får du se dirkete hvor skjemaet kommer fra.

 

Spørsmålet er hvorfor du vil kryptere det før det sendes?

Du vil på den måten svekke scriptet litt, for et JS script er jo tilgjenglig for alle og da ser de hvordan du har kryptert passordet. Hvis du må kryptere på først er det lurt om du legger til noen variabler i passordet på serveren.

[sven-o]

For å sjekke om en bruker har javascript må dette sendes til php så du må lage et to delt javascript.

1. sjekke om brukeren har JS, og sende den videre til en annen side slik at php får beskjed om dette

2. lage et javascript som krypterer passordet

NEEEEEI! Hvem har sagt det????? Dersom login-skjemaet har en hidden input "js_enabled" som er default satt til "0", kan du idet siden lastes sette denne til "1" vha, nettopp, javascript. Dersom JS d ikke er enablet vil:

1. js_enablet belholde sin verdi 0.

2. passorder ikke bli kryptert.

Da kan du på serversiden utføre:

if(!$_POST['js_enabled'])
  $pass = md5($pass);

Er det så vanskelig?? NEI. PUNKTUM!

 

 

Den gjør ikke scriptet sikkert!!Da kan brukeren gå på siden din så har den en session.

Nei. Men det blir mer sikkert enn om jeg ikke hadde gjort det.

 

 

Der er mer vanlig å bruke HTTP_REFERER - da får du se dirkete hvor skjemaet kommer fra.

Riktig. Men det er ikke det vi diskuterer nå.

 

Hvorfor vil du kryptere før det sendes?

Svar meg heller, hvorfor ikke? Hvis du kunne velge, når du logger inn et sted, om du vil kryptere passordet før det sendes fra maskinen din, ville du da valgt "nei"?

 

 

Du vil på den måten svekke scriptet litt, for et JS script er jo tilgjenglig for alle og da ser de hvordan du har kryptert passordet. Hvis du må kryptere på først er det lurt om du legger til noen variabler i passordet på serveren.

Hvorfor det? MD5 er en enveis hashing-algoritme som ikke kan dekrypteres.

Dersom du allikevel vil "salte" passordet ditt som du sier, kan du fremdeles gjøre det;

if(!$_POST['js_enabled'])
  $pass = md5($pass);
$pass = mp5($salt.$pass)

[The Red Devil]

sven-o:

Eg lurte på om du har noko link til ein side kor eg kunne lest meir om enkryptering med javascript ?

 

Ville likt og lest meir om det.

 

På forhand takk.

[sven-o]

Her kan du lese mer.

[Torbjørn]

sven-o, jeg er ikke ute etter å gi deg pepper, jeg mener fortsatt at dette ikke er noen vanlig løsning - det er mye vanligere å sette opp en SSL linje for sensitive data.

 

du bør innse at det fortsatt ikke er noe problem å logge inn ved å sniffe innloggingen til en annen person.

 

det er selvsagt ikke noe problem å få en gyldig session id fra din side først. det er ellers ikke noe som heter "å logge inn fra en side" i HTTP. jeg skjønner hva du mener og hva du sikter til, men å f.eks bruke HTTP_REFERER for noe som helst som har med sikkerhet å gjøre, er på grensa til å være direkte latterlig og en gyldig session cookie kan crckeren sannsynligvis også få (hvordan skal du vite at han er en cracker?). Det samme gjelder å skille mellom GET/POST.

 

Hvis jeg skal håndtere personnummer og kredittkortnummer er det ikke 11-åringer som skriver username=foo&password=bar inni URL'en jeg er urolig for.

 

Da er det fyren som har sniffet encrypted=1&password=md5 som er mitt problem. Hvordan du skal kunne hindre ham i å bruke den informasjonen vil jeg fortsatt gjerne se.

 

Alt i alt blir det mye mer strevsomt å gjøre et sikkert JS enn å sette opp en SSL linje og nesten ignorere problemstillingen.

[sven-o]

Vel. Å ta imot pepper for å gjøre en løsning bedre har vel aldri vært aktuelt heller.

Om noen virkelig vil inn, gjør de sikker det. Om de sniffer, hacker seg inn på serveren eller hva f* de gjør. I alle tilfeller vil de IKKE vite hva passordet mitt er dersom det ble kryptert før det ble sendt. DET er mitt poeng, og det har det vært hele tiden. Om du kaller det falsk trygghet, javel. Men jeg foretrekker å holde passordene for meg selv. Det er en mening jeg deler med mange. Spesielt de som bruker samme passord på flere nettsteder.

 

 

Akkurat nå ser jeg ingen vei ut av denne diskusjonen. Jeg klarer tydeligvis ikke å overtale dere, og jeg kan si med sikkerhet at dere vil aldri kunne overbevise meg.

Om jeg ønsker å benytte meg av klientkryptering, gjør jeg det. Det vil i ingen tilfeller gjøre systemet dårligere. Syntes det er rart du mener det gir meg så mye ekstraarbeid, for det er det ikke på noen måte.

[????????]

Jeg skjønner like vel ikke hvorfor du vil kryptere passordet?

... eller er det kun noe du gjør for morro skyld?

 

Du vil ikke sende passordet fordi du vil ikke at andre skal plukke det opp på veien?

Da forsvinner likevel poenget med å kryptere før det sendes...

for om "passord" eller "asfdsadkjfha" sendes til serveren så blir teksten likevel plukket opp!

 

Du må også innrømme at det vil bli mer programmering?

Hvis det ikke utgjør noen nytte er det ingen som vil betal for det - og det er derfor det ikke er vanlig.

[Cucum(r)]

Hmm.. jeg vil si dette har gått _EN SMULE_ off topic nå.. kansje likegreitt å endre tittelen på innlegget til "Krypterings-diskusjon" elns..

 

Så kan trådstarter starte en ny tråd...

[????????]

 

Det er et diskusjonsforum vet du... hvor mange diskusjoner har du deltatt i som har sluttet med samme tema som det begynte med?

[Cucum(r)]

Ja, men det jeg lurte på, det var om trådstarter har fått det han søker etter...

[sven-o]

Jeg skjønner like vel ikke hvorfor du vil kryptere passordet?

... eller er det kun noe du gjør for morro skyld?

 

Du vil ikke sende passordet fordi du vil ikke at andre skal plukke det opp på veien?

Da forsvinner likevel poenget med å kryptere før det sendes...

for om "passord" eller "asfdsadkjfha" sendes til serveren så blir teksten likevel plukket opp!

 

Du må også innrømme at det vil bli mer programmering?

Hvis det ikke utgjør noen nytte er det ingen som vil betal for det - og det er derfor det ikke er vanlig.

 

Siden du syntes det er det samme om en sniffer plukker opp kryptert eller ikke kryptert passord, er du da også likegyldig til at passodret krypteres på serveren?

Dersom du stoler på serverens administrator, trenger du vel ikke kryptere det der heller da? "Det blir jo mer programmering".

Det er jo lettere å sniffe opp passordet ditt ved innlogging enn å hacke seg inn på serveren og rappe passordet der?

[Torbjørn]

når man krypterer hele HTTP sessionen (og ikke bare passordet av den) kan man ikke sniffe passordet eller md5 hashen.

 

å slenge på mp5() i en SQL spørring kvalifiserer ikke til "mere programmering"

 

I mysql ligger passordene å "venter" på å bli sett. det er en helt annen situasjon enn å snappe dem opp underveis fra A til B.

 

Dette vet du da sannsynligvis like godt som oss?

 

Jeg sier igjen - jeg har aldri vært borti javascript kryptering før sending av passord.

 

Jeg satte meg ned og tenkte gjennom hvorvidt det kan løses helt sikkert, men jeg tror ikke det kan det.. man må uansett lagre et lokalt sertifikat på et vis - cookies nytter ikke, da de sendes fram og tilbake hele tiden.

[sven-o]

når man krypterer hele HTTP sessionen (og ikke bare passordet av den) kan man ikke sniffe passordet eller md5 hashen.

Tenker du på ssl? Eller vet du noe jeg ikke vet? Den forstod jeg ikke helt.

I så fall har jeg aldri sett på klientkryptering av passord som noe erstatning for ssl.

 

 

å slenge på mp5() i en SQL spørring kvalifiserer ikke til "mere programmering"

1. Neida. Vet jo det. Ville bare være vanskelig.

Etter min mening er det nemlig ikke "ekstraarbeid" å kryptere passord med js heller.

Dessuten heter det md5. Mp5 er et lett maskingevær.

 

 

I mysql ligger passordene å "venter" på å bli sett. det er en helt annen situasjon enn å snappe dem opp underveis fra A til B.

 

Dette vet du da sannsynligvis like godt som oss?

Joda. Var bare vanskelig igjen. Når ????? sier at det er likegyldig om en sniffer plukker opp passord i klartekst fremfor hashet, stusser jeg litt på det...

 

 

Jeg satte meg ned og tenkte gjennom hvorvidt det kan løses helt sikkert, men jeg tror ikke det kan det..

Vel. Jeg stoler ganske godt på ssl. Sikkert lettere å sette opp det, enn å gjøre innlogging 70% sikkert.

[dan1el]

Jeg har et liggende. Det er to filer.

 

http://dan1el.net/scripts/pastebin/?id=15

http://dan1el.net/scripts/pastebin/?id=14

 

Si ifra hvis dem falt i smak.