Beskytte Siden Din!

[JohndoeMAKT]

Har du sett i diskusjonsseksjonen for "challenge-response authentication" ?

http://en.wikipedia.org/wiki/Talk:Challeng..._authentication

 

password as challenge/response

 

Most security professionals would disagree with:

 

"The simplest example of a challenge-response protocol is password authentication, where the challenge is asking for the password and the valid response is the correct password."

 

The key feature of challenge/response is that the responder is forced to give a different answer every time. Passwords are often contrasted with challenge response systems. For references see: RFC 4949, Network Security by kaufman et al or any good book on Information Security.

 

It is possible to distinguish between cryptographic challenge response systems where a well vetted cryptographic algorithm is performed to compute the output from the input and non-cryptographic systems where some other sort of prearranged scheme is used. See for example the O'Henry Story: Calloway's Code. In the story a reporter transmits the first word in a common phrase and the receivers fill in the rest of the phrase. In the story it is not used for authentication, but it could be. Perhaps a better example would recognition systems used by navies and other military organizations. They simply issue a secret code book containing challenges and their corresponding responses. Hal lockhart 21:38, 24 October 2007 (UTC)

Det Hal lockhart her skriver er forøvrig i samsvar med det jeg har lært.

[Ernie]

For en utrolig idiotisk måte å gjøre det på ...

 

endrebjorsvik og dere andre, vennligst dropp snakket om Apache og alternative måter å beskytte sider på, det er ikke relevant til tråden i det hele tatt. Å påstå at Apache uansett er sikrere en et hvilket som helst PHP-script viser bare totalt mangel på kunnskap innenfor dette emnet.

Kjære vene! Vær så snill og ikke villed folk! Det du påstår er rimelig heftig på bærtur. Bruker du Apaches og HTTP-protokollens innebygde mekanismer har man blant annet automatisk «challange response»-system, noe jeg til nå aldri har sett i et PHP-script uten at det er introdusert nye sikkerhetsproblemer. HTTP-auth er mer enn basic authentication hvor ting foregår i plaintext. Det er faktisk noe som heter digest også ... Kort og godt: Gjort riktig (dvs. ved bruk av digest) kan jeg overhode ikke se at det introduserer nye sikkerhetsproblemer. Eneste problemet med HTTP-auth er logout, men det får du uannsett og i motsettning til det du kan med PHP etterlater du deg ikke en «session» når bruker lukker nettleseren. I motsettning til scriptet skissert i tråden her fungerer forøvrig HTTP m/digest-metoden uten SSL også. Det klarer du ikke engang med PHP. Hvis du er uenig så er det meget velkommen til å dokumentere at HTTP digest er utrygt.

 

"Challange response"-system? (Det heter for øvrig "challenge"). Så vidt jeg vet er et hvilket som helst login-script dette. Jeg siterer fra Wikipedia:

The simplest example of a challenge-response protocol is password authentication, where the challenge is asking for the password and the valid response is the correct password.

 

Nøyaktig hva legger du i dette "challange response"-systemet ditt?

Nå tenkte jeg ikke helt i den rettningen. I et vanlig login-system skrevet i PHP bruker du session. Ja, du har pr. teori en «challenge» når du logger deg inn, men utover det er det fraværende. Du må bare oppgi en ID for å bli logget inn igjen. HTTP-auth m/digest sender et nonce til klient som brukes i en prosess hvor passord, nonce og realm blir hashet. På denne måten forlater passordet aldri klienten og klienten får en «challange» for hver sidevisning. For å få falsk tilgang trenger man altså ikke å ha kjennskap til en ID, men i stedet er man pent nødt til å enten være mellom bruker og server («man in the middle attack») eller ha kjennskap til passordet.

Jeg har aldri påstått at HTTP/Apache/Whatever er utrygt, jeg tolket heller din post hvor du mener PHP er utrygt - noe jeg reagerte på

endrebjorsvik og dere andre, vennligst dropp snakket om Apache og alternative måter å beskytte sider på, det er ikke relevant til tråden i det hele tatt. Å påstå at Apache uansett er sikrere en et hvilket som helst PHP-script viser bare totalt mangel på kunnskap innenfor dette emnet

Synes det er nettopp det du sier jeg Apache (dvs. HTTP-auth) ER sikerere enn et hvilket som helst PHP-script, dog under forutsettning at man bruker digest, men man er stokk dum om man ikke gjør det. Endret 1. desember 2007 av Ernie

[vi3t]

jeg mener dette er bra basic =) ikke 100% sikkert.. men er bedre enn å ikke ha noen beskyttelse..

Hva beskytter man egentlig med noe så lite?

 

finnes plenty som mann vil beskytte sånn =) jeg har hatt det f.eks til en CV/filer/o.l. jeg la ut en gang =)

 

trenger ikke å være noe stort..er jo et lite skript som skal gjøre et lite beskyttelse.. er ikke akkurat visa kort nret ditt eller lagret noe som burde være såååå innmari beskyuttet

Endret 1. desember 2007 av vi3t

[endrebjo]

PHP-motoren kan tulle seg. Hele PHP-modulen kan faktisk falle ut. Da blir PHP-koden sendt i klartekst.

 

Men hvis derimot Apache streiker, så blir blir det ikke sendt noe som helst kode.

Mener det var en diskusjon rundt akkurat dette med mange folk som prøvde å krasje lokal server, men ingen fikk noen gang sendt ut ren PHP-kode. Du kan jo prøve?

Tidligere har jeg fått servert koden til dette forumet opptil flere ganger. Under hardt belastede tider med mye ustabilitet har det faktisk skjedd flere ganger om kvelden. Serveren har heldigvis blitt tatt ned til vedlikehold etter hvert på slike kvelder.

 

jeg mener dette er bra basic =) ikke 100% sikkert.. men er bedre enn å ikke ha noen beskyttelse..

Hva beskytter man egentlig med noe så lite?

finnes plenty som mann vil beskytte sånn =) jeg har hatt det f.eks til en CV/filer/o.l. jeg la ut en gang =)

 

trenger ikke å være noe stort..er jo et lite skript som skal gjøre et lite beskyttelse.. er ikke akkurat visa kort nret ditt eller lagret noe som burde være såååå innmari beskyuttet

Filene ligger der usikret, så hvis noen får tak i URL'en så får de også tak i filene uten problemer.

Det blir omtrent som å sette opp en plakat foran en diamantutstilling. Ingen vet hva som er bak plakaten, men med én gang de finner det ut, så er det null problem å hente det som er bak.

 

Men for all del. Hvis det bare er én enkelt HTML-side som skal sikres er det sikkert en helt grei metode.

[kimla]

if ($_POST['txt1'] != $username || $_POST['txt2'] != $password) {

 

Tipper du mener && (OG) istedenfor || (ELLER).

[endrebjo]

if ($_POST['txt1'] != $username || $_POST['txt2'] != $password) {

Tipper du mener && (OG) istedenfor || (ELLER).

Nope. Det ser riktig ut slik han har skrevet det.

Den linjen sjekker om bruker-brukernavnet ikke er lik server-brukernavnet, eller om bruker-passordet ikke er lik server-passordet. Hvis én av dem er TRUE (f.eks bruker-passordet ikke er lik server-passordet), så blir hele uttrykket TRUE, og dermed dukker innloggingsboksen opp.

[Yankes]

for det første:

Denne burde vel vært plassert under PHP forumet..

 

for det andre:

Jeg tviler på at det er du som har laget det scriptet der når hele siden din bare er et template som du har lasta ned. Er ingen som kan å lage slike PHP script når de ikke en gang kan HTML og CSS.

 

for det tredje:

ikke nekt. du ble bruker 30/10-2007 og jeg så igjennom alle emnene du har startet, med din kunnskap klarer du ikke å lage det skriptet der. Dermed basta!

 

jeg skal godkjenne denne under tvil, men i dette emnet har du skrevet at du har laget scriptet!

 

FY FY!

[grimjoey]

Spiller det noen rolle? Hva er de man ønsker å vinne ved å rakke ned på andre?

 

BTW: Ernie: er du sikker på at HTTP AUTH digest kjører challenge for hver sidevisning? trodde det var kun ved login.

 

Jeg laget en gang et challenge response brukerhåndteringssystem i php. det ligger i forumet her et sted. Problemet var at jeg aldri fant noen måte å lagre data på i klienten, så det ble ikke så veldig sikkert.