Jeg har følgende link, som der skal være login til (de er ikke
helt færdige endnu, som I ser):
<td rowspan="3" align="left" bgcolor="#333333" width="200cm"
height="500CM"><img src="billeder/solsikker.gif" valign="top
center" width="200cm" height="125cm">
<h3><ul>
<li>Malta 2001</li><br><br>
<li>Nytår 2003</li><br><br>
<li>Claus 30 år</li><br><br>
<li><a href="default1.html">Amandas dåb</a></li><br><br>
<li>Bryllup 2003</li><br><br>
</ul></h3>
</td>
Håber nogen kan hjælpe - på forhånd tak :-)
Hilsen Lykke
--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP ???
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials
> Jeg kunne dog godt tænke mig at venner og familie kan logge sig
> ind på bestemte sider, som ikke skal være tilgængelige for andre.
Det letteste måde er blot at lave nogle sider uden henvisning fra
forsiden. Så skal de særligt udvalgte blot have en direkte adresse
til den "hemmelige" side. Du kan også lave et skjult link på
forsiden, så man fx skal klikke på et punktum i en sætning eller
lignende for at komme til den skjulte side.
Ingen af disse metoder er sikre - forstået på den måde at andre
forholdsvis nemt kan finde dine skjulte sider hvis de virkelig vil,
men hvis siderne blot skal være private, uden nødvendigvis at være
tophemmelige kan det være sikkert nok.
> Jeg kan forstå, at man ikke kan lave login i html - men i
> Javascript eller asp.
Login kræver en kommunikation mellem server og browser - og det kan
man ikke opnå i almindelig html. Javascript-løsningen vil være
bedre end de løsninger jeg skitserede ovenfor, men stadig ikke
rigtig sikker.
En "rigtig" loginløsning kræver enten et serversidesprog (typisk
asp eller php) eller også adgang til at sætte serveren op mht.
login. På unix-servere kan man gøre det ved en almindelig tekstfil,
mens man på windows-servere skal have adgang til selve serveren for
at sætte loginparametre.
> Håber nogen kan hjælpe - på forhånd tak :-)
Som du selv er inde på kan man ikke lave login direkte i html. Hvis
du vil have hjælp til en javascriptløsning kan du spørge i gruppen
<news:dk.edb.internet.webdesign.clientside>, og hvis du vil bruge
en serversideløsning kan du spørge i en passende serversidegruppe
(se <http://www.usenet.dk/grupper.pl?seek=serverside> for en
oversigt).
Hvis dine sider ligger på et webhotel skal du være opmærksom på at
serversidesprog som regel ikke kan bruges med de mindste
abonnementstyper.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html
her er en simpel en i javascript
<input id="login" type="text">
<input id="passwd" type="password">
<button onclick='if (document.all.login.value == "admin" &&
document.all.passwd.value == "letmein")
{document.location.href="hemmeligside.htm"} else { alert("forkert login og
password") }'>Go</button>
men den er meget, meget simpel at "knække " hvis man vil ind -
Hvis man skal lavet noget der er en smule sikkert skal man lave det på
serveren feks i java,
men det er de færeste web hoteler hvor man kan lave server scripts uden at
det koster en bonde gård at få det hostet
Som beskrevet i tråden "Beskytte et link med password" fra i dag vil jeg
svare på samme måde:
Jeg har simpelthen det fede trick:
Du kan få et tekstfelt hvori man skal indtaste et password og klikke OK - så
kommer man ind på siden.
Fidusen er at passwordet er det samme som mappenavnet man vil ind i. Har du
feriebilleder, lægges de i f.eks. en mappe der hedder "buller", og på siden
skriver du så at "passwordet er navnet på bedstemors afdøde hund" (hvis den
altså hed Buller), og alle der så ved det kan skrive "buller" og klikke OK
og - VUPTI er de inde i mappen. De mapper du vil bruge som "passwordmapper"
skal indeholde en index.html .
Fordele:
Nem kodning uden krav til udbyders server
Ulemper:
Man SKAL klikke OK - at trykke på Return virker ikke.
Din mappe er ikke sikret - dvs. at hvis den ses på et bibliotek kan man i
browseren efterfølgende i History finde dem frem.
Du kan dog ændre mappenavnet og dermed passwordbeskrivelsen ofte - så er det
rimeligt sikkert.
Morten
I headeren puttes javascriptet:
<script language="JavaScript"><!--
function getThePage(thePW)
{
top.location.href = thePW + "/index.html"
}
// -->
</script>
og i bodyen puttes:
<form name="theForm">
Password <input name="txtPassword" type="password" size="12" maxlength="10">
<input name="bOK" type="button" value="OK"
onclick="getThePage(theForm.txtPassword.value)">
</form>
> Ulemper:
> Man SKAL klikke OK - at trykke på Return virker ikke.
Kan nemt fikses. Flyt javascriptet fra "onclick" på submit-knappen til
"onsubmit" på form-tagget.
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
'Faith without judgement merely degrades the spirit divine.'
javasript-analfabeten: kan man begge dele ved at angive "onclick" og
"onsubmit" i samme form så både OK-knappen og return virker?
Morten
> javasript-analfabeten: kan man begge dele ved at angive "onclick" og
> "onsubmit" i samme form så både OK-knappen og return virker?
Hvis man bruger "onsubmit", så virker OK-knappen også, da den netop
forsøger at submitte formen.
De to måder man bedst fanger en form på er
onsubmit="...script..." , eller
action="javascript:...script..."
begge på form-elementet. Begge bliver fanget lige gyldigt hvordan
man forsøger at submitte formen.
Hej Lasse
Jeg har prøvet, men kan ikke rigtigt se den rigtige kode..
kan du ikke rette til og returnere?
På forhånd tak,
Morten
----------
<html>
<head>
<title>Password</title>
<script language="JavaScript"><!--
function getThePage(thePW)
{
top.location.href = thePW + "/index.html"
}
// -->
</script>
</head>
<body bgcolor="#ffffff">
<form name="theForm">
Password <input name="txtPassword" type="password" size="12" maxlength="10">
<input name="bOK" type="button" value="OK"
onclick="getThePage(theForm.txtPassword.value)">
</form>
</body>
</html>
-----------------
> Jeg har prøvet, men kan ikke rigtigt se den rigtige kode..
> kan du ikke rette til og returnere?
> <form name="theForm">
> Password <input name="txtPassword" type="password" size="12" maxlength="10">
> <input name="bOK" type="button" value="OK"
> onclick="getThePage(theForm.txtPassword.value)">
> </form>
Prøv:
<form name="theForm" onsubmit="getThePage(theForm.txtPassword.value)">
Password <input name="txtPassword" type="password" size="12" maxlength="10">
<input name="bOK" type="submit" value="OK">
</form>
Altså
"onclick" flyttet til <form> og omdøbt til "onsubmit"
Typen på knappen sat til "submit" i stedet for "button".
Det var det jeg prøvede, men det virker ikke på min Mac Explorer 5.5 eller
Netscape 4.77.
Morten :-(
> Det var det jeg prøvede, men det virker ikke på min Mac Explorer 5.5 eller
> Netscape 4.77.
Hmm. Virkede det før? Hvordan virker det ikke - fejlbeskedder eller bare
intet?
Prøv:
<form name="theForm"
onsubmit="getThePage(this.txtPassword.value);return false;">
Password <input name="txtPassword" type="password" size="12" maxlength="10">
<input type="submit" value="OK">
</form>
Det virker i NS 4.79/Windows (og Opera7, Mozilla/Phoenix, IE6),
hvis altså getThePage-funktionen virker (jeg testede med alert-funktionen).
Morten
> Fra: Lasse Reichstein Nielsen <l...@hotpop.com>
> Organisation: TDC Internet
> Nyhedsgrupper: dk.edb.internet.webdesign.html
> Dato: 17 Jan 2003 12:37:53 +0100
> Emne: Re: login - hvordan?
>
> Javascript-løsningen vil være bedre end de løsninger jeg
> skitserede ovenfor, men stadig ikke rigtig sikker.
Kan du forklare hvad der er usikkert ved javascriptløsningen?
--
Allan
http://html-faq.dk
>> Javascript-løsningen vil være bedre end de løsninger jeg
>> skitserede ovenfor, men stadig ikke rigtig sikker.
>
> Kan du forklare hvad der er usikkert ved javascriptløsningen?
Alt - javascript kører clientside hvorfor det kan "aflures" og snydes
til at sende en "godkendt" til serveren.
--
.: Henrik Stidsen - HS235.dk ::...
>> Kan du forklare hvad der er usikkert ved javascriptløsningen?
>
> Alt - javascript kører clientside hvorfor det kan "aflures" og
> snydes til at sende en "godkendt" til serveren.
Det var usikkerheden ved denne løsning jeg tænkte på:
http://www.usenet.dk/oss/dk.edb.internet.webdesign/diverse.html#Kodeord
--
Allan
http://html-faq.dk
Den er ikke mere sikker, end en hemmelig url. Jeg har set eller hørt om
mange tilfælle, hvor sådan en url pludselig ikke var hemmelig mere.
En klassisk måde det kan slå fejl på:
På de hemmelige sider er der links til andre sites. Disse sites offentliggør
et eller andet sted nogle statistikker. I disse statistikker står der bla.
referrers, der iblandt står de hemmelige sider.
En søgemaskine kommer omkring disse statistikker, og finder ad den vej de
hemmelige sider. Pludselig findes siderne nemt via Google, og de besøgende
ved oftest slet ikke, at de er på et område, hvor de ikke skulle have haft
adgang.
Så kan man jo bare lade være med at linke væk fra siderne, men der er andre
måder det kan gå galt på.
Det er fint nok hvis man bare vil vise ferie-billeder frem for familie og
venner, men ikke mener at det vedrører andre. Men til hemmelige ting ville
jeg ikke bruge det.
--
Mvh.
Niels Andersen
http://myplace.dk/articles/getpost/?lang=da
>> Alt - javascript kører clientside hvorfor det kan "aflures" og
>> snydes til at sende en "godkendt" til serveren.
>
> Det var usikkerheden ved denne løsning jeg tænkte på:
>
> http://www.usenet.dk/oss/dk.edb.internet.webdesign/diverse.html#K
> odeord
Som Niels skriver, der er mange muligheder. Dernæst, det handler jo
bare om at gætte sidenavnet. Desuden har man med den metode ingen
måde at adskille brugerers adgang på.
Hvis det skal være sikkert og ordentligt skal det køre server-side.
Ikke hvis JavaScript-løsningen går på at teste for eksistensen af et katalog
med et ikke-logisk navn indeholdende en html-fil med et ikke-logisk navn.
Der er således ikke noget i scriptet, der kan fortælle uvedkommende, hvad de
skal gå efter:
<form name="bruger" action="#" onsubmit="location.href = this.kodeord1.value
+ '/' + this.kodeord2.value + '.htm'; return false">
<input type="text" size="15" name="kodeord1"> Brugernavn<br>
<input type="password" size="15" name="kodeord2"> Adgangskode<br>
<input type="submit" value="Luk mig ind" onclick="location.href =
this.form.kodeord1.value + '/' + this.form.kodeord2.value + '.htm'; return
false">
</form>
Denne kode virker og den validerer. Kilde: AV
--
Med venlig hilsen
Erik Ginnerskov - er...@ginnerskov.dk
http://www.ginnerskov.dk - http://www.html-faq.dk
http://hjem.get2net.dk/sorgin
> Ikke hvis JavaScript-løsningen går på at teste for eksistensen
> af et katalog med et ikke-logisk navn indeholdende en html-fil
> med et ikke-logisk navn. Der er således ikke noget i scriptet,
> der kan fortælle uvedkommende, hvad de skal gå efter:
Jo, det er rimelig nemt at se at du skal finde en kombination af et
bibliotek og en fil der ender på .htm. Her ved vi allerede meget mere
end hvis samme validering var foretaget serverside og vidrestillet
med en location header.
Det kan bruges men kan knækkes forholdsvist nemt - der er jo ingen
mekanismer der evt. vil forhindre en bestemt IP i mere end 3 forsøg
eller lign. Det er bare et spm om at sætte en automatisering igang
der forespørger efter kombinationer - og laver en mængde 404 fejl...
> Denne kode virker og den validerer. Kilde: AV
AV ?
> Det kan bruges men kan knækkes forholdsvist nemt
Jeg har ofte spurgt hvem der kunne knække den - og det
er ikke lykkedes for nogen endnu.
>> Denne kode virker og den validerer. Kilde: AV
>
> AV ?
Det er mig;o)
--
Allan
http://html-faq.dk
>> Det kan bruges men kan knækkes forholdsvist nemt
>
> Jeg har ofte spurgt hvem der kunne knække den - og det
> er ikke lykkedes for nogen endnu.
Jeg kan godt - men det tager tid og det gider jeg ikke bruge på det.
Alt ialt er det simplere at automatisere en brute-force end til så
mange andre metoder.
> Jeg kan godt - men det tager tid og det gider jeg ikke bruge
> på det.
Det siger I alle. Jeg mangler dog fortsat beviset på det efter alle
disse år hvor nogen gang på gang har påstået at de kan bryde
"koden".
Brug dog tiden på det, så vi kan få manet denne påstand i jorden!
Jeg har stillet spørgsmålet med jævne mellemrum, men indtil nu
er ingen kommet med et bud - og det må da tyde på at systemet
er sikkert nok?
Mange er kommet med teorier om hvad der "kan" ske, men heller
ikke dette har hold i virkeligheden, idet ingen er kommet med et bud
på hvordan det kan brydes.
Et eksempel savnes stadig for at kunne sige "Jeg kan godt"!
--
Allan
http://html-faq.dk
>> Jeg kan godt - men det tager tid og det gider jeg ikke bruge
>> på det.
>
> Det siger I alle. Jeg mangler dog fortsat beviset på det efter alle
> disse år hvor nogen gang på gang har påstået at de kan bryde
> "koden".
>
> Brug dog tiden på det, så vi kan få manet denne påstand i jorden!
Betaler du timelønnen ?
Det handler jo bare om at afprøve alle muligheder - eftersom der ikke
er mulighed for at bygge en "stopklods" ind i systemet er det bare at
gå systematisk til værks. Det kan du vel godt selv se ikke ?
Jeg lover dig for at hvis et eneste betalingssted eller et sted som
f.eks. hotmail brugte et sådant system ville det være knækket i løbet
af få timer!
>Det siger I alle. Jeg mangler dog fortsat beviset på det efter alle
>disse år hvor nogen gang på gang har påstået at de kan bryde
>"koden".
Du har endda selv svaret på et indlæg for 1½ år siden, der har vist
problemstillingen med referer:
>Jeg har stillet spørgsmålet med jævne mellemrum, men indtil nu
>er ingen kommet med et bud - og det må da tyde på at systemet
>er sikkert nok?
Det afhænger bl.a. om hvad, der udbydes på den aktuelle webserver. Ved
ikke-jail'et/chroot'et cgi-adgang vil andre kunne se rundt. Det samme
med PHP'er ældre end 4.2.0, selvom de var i SafeMode.
>Et eksempel savnes stadig for at kunne sige "Jeg kan godt"!
Risikoen er rigtigt nok markant anderledes, idet ikke nødvendigvis
"alle og enhver" har mulighed for det, men måske kun dem der er kunde
samme sted, dem hvis site linkes til fra den "password-beskyttede"
side (som i ovenstående eksempel), dem der tilfældigvis får
referer-stien kastet i nakken ved en fejl (jeg har fået URL's fra
andre åbne browservinduer i referer-loggen), samt tilfælde, hvor andre
måske fejlagtigt kommer til at referere til siden.
Jeg har oplevet fora, hvor password-beskyttelsen ved en fejl blev
deaktiveret, og google så kunne se beskeder, folk skrev (i troen om at
de ikke blev vist for omverdenen). Her har der været links til
ikke-password-beskyttede, men stadigvæk "hemmelige", sider. Selv når
der kom password-beskyttelse på forummet, var den "hemmelige" side
blevet indekseret, og fik nu jævnligt besøg fra fx google. robots.txt
ville ikke nødvendigvis hjælpe, da URL'en nu havde stået offentligt på
et andet site, man ikke selv havde kontrol over.
--
- Peter Brodersen
Ja - på et filnavn med mulighed for - hvad er det nu vi siger om url'ers
længde? - lad os bare sige 1024 tegn med >28 mulige tegn på hver
position. Dvs vi taler ikke om (correct me if i'm wrong) 28*28 ^
(ophævet til potensen) 1024 - muligheder.
Ok - vi siger det er et absurd filnavn, så vi holder os til 10 bogstaver
i filnavnet - så har vi (28*28)^10, det giver vist 87.732.524 E20 (med
20 nuller efter, kombinationsmuligheder (mulighed for forskel på små og
store bogstaver ikke medregnet).
Det er en pæn kryptering at bryde - selv med maskine til hjælp. Jeg
lurede lidt på hvordan jeg med php og asp kunne lave en sådan engine,
men jeg kunne ikke få det til at køre.
SÅ set fra mit synspunkt rækker den kryptering faktisk et ret godt
stykke vej hvis man holder sig fra letgættelige koder...
- eftersom der ikke
> er mulighed for at bygge en "stopklods" ind i systemet er det bare at
> gå systematisk til værks. Det kan du vel godt selv se ikke ?
jeg kan godt se det - "bare" :-)
mvh
Jesper Brunholm
>> Det handler jo bare om at afprøve alle muligheder
>
> Ja - på et filnavn med mulighed for - hvad er det nu vi siger om
> url'ers længde? - lad os bare sige 1024 tegn med >28 mulige tegn
> på hver position. Dvs vi taler ikke om (correct me if i'm wrong)
> 28*28 ^ (ophævet til potensen) 1024 - muligheder.
Hvilken af dine brugere kan huske et password på 1024 tegn ?
> Det er en pæn kryptering at bryde - selv med maskine til hjælp.
> Jeg lurede lidt på hvordan jeg med php og asp kunne lave en
> sådan engine, men jeg kunne ikke få det til at køre.
Det behøver ikke lige være PHP eller ASP - jeg ville nok vælge C++
eller perl eller noget i den stil.
> SÅ set fra mit synspunkt rækker den kryptering faktisk et ret
> godt stykke vej hvis man holder sig fra letgættelige koder...
Bortset fra der overhovedet ikke er noget der ligner kryptering har
du helt ret.
Men det at der ikke er kryptering og ingen begrænsninger på antallet
af forsøg/minut gør at det bliver forholdsvis simpelt at køre igennem
- det er jo "bare" nogle loops i et program.
ja men loops tager lidt tid, lad os antage at vi kun benytter brugernavn for
at skjule vores webside...
antagelse 1) valget af brugernavn er 8 karakterer langt
antagelse 2) valget af karakterer i brugernavn er vilkårlig(dvs så vilkårlig
som muligt måske vha mersenne twister algoritmen
antagelse 3) 60 muligheder for hver karakterplads (dvs engelsk alfabet, tal
og forskel på store og små bogstaver)
antagelse 4) et delvist korrekt brugernavn vil ikke give yderligere
oplysninger
antagelse 5) en maskine bygget til formålet vil kunne genneføre 10^6
'dekrypteringer' pr mikrosekund.(og det er mange!!!)
antagelse 6) svaret fra serveren er øjblikkelig!!!
antagelse 7) bruteforce benyttes linært og ikke elliptisk
antal af forsøg for at knække brugernavn:
8^60/2 - linært efter 50% får man den rigtige kombination
tidsforbrug: 8^60/2 muligheder / 10^6 dekrypt/mikrosek = 7,66*10^47 mikrosek
7,66*10^47miksek~2,43*10^31 år
tja...det samme gælder jo for password....og hvis vi kombinerer de to kan vi
vel kun sige at vi skal lede i Anders And efter en tidsbetegnelse der passer
:)
>> Men det at der ikke er kryptering og ingen begrænsninger på
>> antallet af forsøg/minut gør at det bliver forholdsvis simpelt
>> at køre igennem - det er jo "bare" nogle loops i et program.
[snip]
> tja...det samme gælder jo for password....og hvis vi kombinerer
> de to kan vi vel kun sige at vi skal lede i Anders And efter en
> tidsbetegnelse der passer
>:)
Well, vi kan vel så konkludere at det tager skide lang tid at bryde -
men stadig er det ikke nær så sikkert som en serverside-login-ting.
Jeg kan kun give dig ret!!! :)
> Well, vi kan vel så konkludere at det tager skide lang tid at
> bryde
Jeg venter fortsat på beviset på at nogen kan bryde det;o)
> - men stadig er det ikke nær så sikkert som en
> serverside-login-ting.
Hvad bygger du den påstand på?
--
Allan
http://html-faq.dk
> Du har endda selv svaret på et indlæg for 1½ år siden, der har
> vist problemstillingen med referer:
>
> <news:3B80D8A2...@tv2i.dk>
Jeg kan ikke læse indlægget - har du et google-link i stedet?
> Det afhænger bl.a. om hvad, der udbydes på den aktuelle
> webserver.
Naturligvis!
> Jeg har oplevet fora, hvor password-beskyttelsen ved en fejl
> blev deaktiveret, og google så kunne se beskeder, folk skrev
Vi kan alle komme ud for fejl. Jeg har også været ude for at al
asp-kode kunne læses direkte i browseren, men det er jo ikke det
dette spørgsmål drejer sig om.
Det er kun sikkerheden i
<form name="bruger" action="#" onsubmit="location.href = this.kodeord1.value
+ '/' + this.kodeord2.value + '.htm'; return false">
<input type="text" size="15" name="kodeord1"> Brugernavn<br>
<input type="password" size="15" name="kodeord2"> Adgangskode<br>
<input type="submit" value="Luk mig ind" onclick="location.href =
this.form.kodeord1.value + '/' + this.form.kodeord2.value + '.htm'; return
false">
</form>
det drejer sig om - og her anser jeg den lige så høj som en
serversideløsning - der er i hvert fald inden der har givet et bud
på det modsatte.
At Henrik vil have timeløn for det kan jeg kun grine af:o)
--
Allan
http://html-faq.dk
>> Well, vi kan vel så konkludere at det tager skide lang tid at
>> bryde
>
> Jeg venter fortsat på beviset på at nogen kan bryde det;o)
Hva er det for et bevis du mangler ?
>> - men stadig er det ikke nær så sikkert som en
>> serverside-login-ting.
>
> Hvad bygger du den påstand på?
At en serverside-ting
...kan blokere hvis der fra samme IP prøves mere end 10 gange,
det kan javascript ikke.
...har bedre mulighed for kryptering
...kan checke password ved hver eneste page-request, det er
noget bøvl ved en javascript løsning.
- det var bare lidt af det.
Her er hele tråden:
http://groups.google.com/groups?hl=da&lr=&ie=UTF-8&threadm=3B80D8A2.B8DAD86F%40tv2i.dk&rnum=1&prev=/groups%3Fselm%3D3B80D8A2.B8DAD86F%40tv2i.dk%26rnum%3D1
Hvis man anvender Mozilla, findes der http://messageidfinder.mozdev.org/
som kan finde et indlæg, ud fra dets id.
--
Mvh / Regards
Morten K. Hansen
Replying by mail? Change 'spam' to my first name.
... Hvis ikke jeg har husket det hele, har jeg glemt det.
>Jeg kan ikke læse indlægget - har du et google-link i stedet?
Yep: http://groups.google.com/groups?selm=3B80D8A2.B8DAD86F%40tv2i.dk
>Det er kun sikkerheden i
[..]
>det drejer sig om - og her anser jeg den lige så høj som en
>serversideløsning - der er i hvert fald inden der har givet et bud
>på det modsatte.
Det er bare kun en halv sandhed, man her fortæller folk. Det er
relevant at påpege hvilke andre faktorer, der i det hele taget kan
gøre en "hemmelig side"-løsning usikker.
--
- Peter Brodersen
> Hva er det for et bevis du mangler ?
At du kan bryde ind på min side, som du påstår - med eller
uden timeløn.
Mange har forsøgt gennem mange år - og så kommer du og
siger at du kan;o)
Giv en demonstration af hvor nemt det kan gøres - så der måske
nogen der tror på det?
Kan du ikke bryde ind må jeg betragte min hemmelige side for
sikker nok.
--
Allan
http://html-faq.dk
> Det er bare kun en halv sandhed, man her fortæller folk. Det er
> relevant at påpege hvilke andre faktorer, der i det hele taget
> kan gøre en "hemmelig side"-løsning usikker.
Hvilke faktorer tænker du på?
--
Allan
http://html-faq.dk
>Hvilke faktorer tænker du på?
En ikke-udtømmende liste: Referer fra siden, fejlagtig referer
serverer sidens URL, browser-history, at siden har ligget på en server
med en ikke-helt-ny udgave af PHP.
--
- Peter Brodersen
>> Hva er det for et bevis du mangler ?
>
> At du kan bryde ind på min side, som du påstår - med eller
> uden timeløn.
Gider ikke bruge min tid på det.
> Mange har forsøgt gennem mange år - og så kommer du og
> siger at du kan;o)
>
> Giv en demonstration af hvor nemt det kan gøres - så der måske
> nogen der tror på det?
Den eneste der ikke tror på det er dig - alle andre har taget en
forklaring på hvordan det gøres for gode varer og accepteret at det
er nemmere at bryde end en serverside-løsning.
> Kan du ikke bryde ind må jeg betragte min hemmelige side for
> sikker nok.
Det gør du bare - der er sikkert heller ikke noget der er værd at
bryde ind efter.
> At Henrik vil have timeløn for det kan jeg kun grine af:o)
Grin du bare - det var blot en måde at fortælle dig at jeg ikke gider
bruge min tid på det.
--
Det var egl det perspektiv jeg prøvede at sætte op
> men stadig er det ikke nær så sikkert som en serverside-login-ting.
nej nej - det er vi helt enige om. Spørgsmålet er kun om det er sikkert
nok til det man vil bruge det til, hvis man ikke har adgang/kompetencer
til en serversideløsning.
Derudover så præsenterer Peter Brodersen større problemer ved løsningen
end kodeknækningen udgør, nemlig at man skal kunne stole ret meget på
brugerne og deres 1) loyalitet 2) tekniske viden så de ikke ødelægger
løsningen ved en fejl/et tilfælde
mvh
Jesper Brunholm
1) Der er ingen der siger at det ikke må være en sammenhængende sætning.
2) hvorfor tror du jeg skrev næste sætning i den mail du har svaret på?
>>Det er en pæn kryptering at bryde - selv med maskine til hjælp.
>>Jeg lurede lidt på hvordan jeg med php og asp kunne lave en
>>sådan engine, men jeg kunne ikke få det til at køre.
>
> Det behøver ikke lige være PHP eller ASP - jeg ville nok vælge C++
> eller perl eller noget i den stil.
jamen - fint - jeg er ligeglad med sproget, jeg nævnte bare det jeg
kender lidt til.
Jeg gik jo så også ud fra at det er muligt at gøre det med maskinkraft.
> Men det at der ikke er kryptering og ingen begrænsninger på antallet
> af forsøg/minut
der er vel ikke noget ved at kunne gøre et nyt forsøg før man ved om det
foregående er lykkedes, så jo - der er afgjort en begrænsning på
antallet af forsøg pr minut, men det har Henrik Eghave illustreret meget
mere gennemført end jeg lige kan.
mvh
Jesper Brunholm
>> Men det at der ikke er kryptering og ingen begrænsninger på
>> antallet af forsøg/minut
>
> der er vel ikke noget ved at kunne gøre et nyt forsøg før man
> ved om det foregående er lykkedes, så jo - der er afgjort en
> begrænsning på antallet af forsøg pr minut, men det har Henrik
> Eghave illustreret meget mere gennemført end jeg lige kan.
Det var nu ikke den slags begrænsning jeg tænkte på.
For det første er det slet ikke dumt bare at køre på og så se hvornår
man får brudt koden - hvis man f.eks. kører den i 100 tråde, altså
100 samtidige kode-knækkere, gælder det jo bare om at den der får
positivt svar tilbage melder og stopper de andre. Resourcemæssigt er
det vist rimelig ligegyldigt.
Den begrænsning i antal requests/minut jeg snakkede om er sådan en
der f.eks. ignorer dig i f.eks. "3min*antallet af loginforsøg over
5/minut". Sådan en spærring vil effektivt nedsætte hastigheden af din
kodeknækning hvis den f.eks. kører efter IP.
> Gider ikke bruge min tid på det.
OK, så lader vi det ligge hvis du ikke kan kapere opgaven.
> Den eneste der ikke tror på det er dig
Nej, der er mange der ikke tror på at du kan klare opgaven.
Du kom med "Jeg kan godt..." og så bakker du ud af projektet
når det endelig gælder;o)
Hvad viser det?
--
Allan
http://html-faq.dk
>> Gider ikke bruge min tid på det.
>
> OK, så lader vi det ligge hvis du ikke kan kapere opgaven.
Bare begynd at blive højrøvet, det gør mig ikke mere glad...
>> Den eneste der ikke tror på det er dig
>
> Nej, der er mange der ikke tror på at du kan klare opgaven.
Hvem ?
> Du kom med "Jeg kan godt..." og så bakker du ud af projektet
> når det endelig gælder;o)
>
> Hvad viser det?
At jeg gerne indrømmer at det tager alt for lang tid at gætte koden -
og at jeg ikke gider bruge tiden på det.
Du opfatter overhovedet ikke alle de andre argumenter der også er
kommet eller den forklaring du har fået på hvordan det gøres.
--
.: Henrik Stidsen - HS235.dk ::...
Visit http://hs235.dk/drugs
Det er mulig jeg er helt på jordet og ad muligens er noe annet du tenker
på men med htaccess skal det være mulig å passordbeskytte en ekelt fil
ien katalog.
Magne Heen.