Blodhemn

Hah. Jau.. det var raskt

Koden nevnt tidligere visste ikke hvor mange karakterer det var på forhånd. Så egentlig måtte den teste flere muligheter. Matte er ikke mitt sterkeste felt. Men tror den må sjekke så mange forskjellige kombinasjoner som dette før den finner løsningen:

25+25^2+25^3+25^4

Men, selvfølgelig. Det ville ikke ta så mye lengre tid det. Spesielt ikke hvis det er så raskt som det er.

En 4 karakters streng med a-z som mulige karakterer gir oss 25^4 mulige kombinasjoner.

La oss anta at du ikke har en ferdiglaget tabell der du har de forskjellige kombinasjonene knyttet opp mot en md5() hash av det ordet.

25^4 = 390625 mulige forskjellige kombinasjoner. Klarer du lage et PHP script som sjekker 390625 _unike_ kombinasjoner på 8 sekunder? PHP er raskt, men er det så raskt?

Statistisk sett så vil man aldri heller trenge å sjekke alle de mulige kombinasjonene. Sansynligheten for at den siste kombinasjonen man prøver er riktig er ikke stor.

Skulle gjerne sett hvor lang tid dette scriptet ville brukt på en bare litt værre streng.

a-zA-z og fire tegn vil gi oss 50 ^ 4 = 6 250 000. Det skal ikke mye til før det er så mange mulige kombinasjoner at å putte det inn i en database vil virke absurd.

I all ærlighet så var dette et ordbok ord, og det er mulig at det ble bruteforcet på denne måten.

Men kan vi være sikre at eneste måten å knekke en md5 hash er å bruteforce den?

Hvis det er eneste måten så er det ikke spesiellt vanskelig å beskytte seg mot det. Det er bare å salte passordet så mye at det vil ta latterlig lang tid å knekke den.

Tror ikke det skal ha så mye å si.. Husker ikke helt. Er i allefall ikke værre enn at du kan gå inn i httpd.conf filen å endre det.

 

Du kan jo prøve å skrive http://localhost/ i nettleseren din og se hva som skjer. Du skal få en standard side for Apache installasjonen din. Om du får den så virker Apache.

Ja!

Det virket!

Og hvis jeg nå legger inn php på maskinen og endrer litt i den httpd.comf fila,

kan jeg altså få opp php-filer i browseren, uten at jeg har lagt de ut på en webserver?

(Dårlig forklart, men skjønner sikkert hva njeg mener)

 

Men en annen ting, kan jeg sette denne opp slik at jeg kan bruke den som en filserver på et nettverk?

Jepp. Du skal kunne kjøre PHP filer på lokalmaskinen. Du må fremdeles kjøre PHP filene gjennom webserveren, i dette tilfellet Apache. Du vil ikke kunne åpne en PHP fil fra harddisken og kunne "kjøre" den, slik du kan med en HTML fil. Du må fremdeles åpne browseren og skrive inn http:// adresse. Men du slipper å laste scriptene dine opp til en ekstern webserver hele tiden. Du trenger bare lagre og kjøre

Husker ikke helt akkurat hva som må endres, men følg bruksanvisning på php.net så går det bra.

Ja, du skal kunne bruke maskinen som en filserver på et nettverk. Alt du trenger gjøre er å dele hele Document Root katalogen eller en Underkatalog i Document Root.

Høyreklikk på mappe -> Deling -> Del denne mappen på nettverket.

Jeg antar et du er bittelitt kjent med Microsoft Nettverk. Det er i allefall så lett at det ikke burde være noe stort problem dersom du ikke er det

Legg merke til at dersom du sitter på en annen PC enn der webserveren er satt opp så må du bruke webserveren's IP i stedet for localhost. F.eks slik: http://192.168.1.11/

Tror ikke det skal ha så mye å si.. Husker ikke helt. Er i allefall ikke værre enn at du kan gå inn i httpd.conf filen å endre det.

Du kan jo prøve å skrive http://localhost/ i nettleseren din og se hva som skjer. Du skal få en standard side for Apache installasjonen din. Om du får den så virker Apache.

Å vise folk hvor lett md5 kan knekkes er en god måte å overbevise hvor usikkert det er og hvordan man best beskytter seg mot det.

På en annen side så kan jeg lett forstå at man ikke ønsker å vise fram et slikt script på den måten. Det kan veldig lett gjøre mye skade.

Jeg ante ikke at det kunne knekkes så raskt. 8 sekunder på en 4 karakterer lang streng er ganske raskt. Spesielt med tanke på at folk gjerne velger passord som er lette å huske (og derfor ofte veldig korte)

Mye omtale av salt i det siste. Hvorfor heller ikke kjøre md5 på en streng som allerede er kryptert med md5. Vil ikke dette være det samme som å salte en streng?

Det vil jo gjøre det vanskeligere å bruteforce en streng med tanke på at 32 tegn i hexadecimal gir en stakkar mildt sagt en bråte med mulige kombinasjoner?

Eller er det noe jeg har gått glipp av når det gjelder dette?

EDIT:

Ved ettertanke så ser jeg kanskje et problem her. Bruteforcing går jo mer eller mindre ut på å lagre forskjellige ord og så md5'e de og legge det inn i en database. Er ingenting som hindrer de å legge på både annen generasjon og tredje generasjon md5 i tillegg da.

Ah, takk for oppklaringen

EDIT:

Det men at left join ofte er å foretrekke er generelt og gjelder ikke i dette tilfellet!

Et naturlig spørsmål vil da være; Hvorfor ikke?

SELECT * FROM bilder, album WHERE bilder.album = album.id AND album.tillatelser = 1 ORDER BY RAND()

Dette er jo strengt tatt en Join da.. den mangler bare ordet JOIN.

SELECT bilder.url FROM bilder
LEFT JOIN album ON album.id = bilder.album
WHERE album.tillatelser = 1

?

Så telle radene med mysql_num_rows og bruke rand() for å hente ut en tilfeldig rad vil være mer effektivt?

Kan bruke shuffle() på mysql_fetch_array og velge ut $rad[0] ellerno.

Er langt fra noen ekspert på SQL, men ville tro du kunne løse det på denne måten.

"SELECT bilder.url WHERE bilder.album = album.id AND album.tillatelser = 1"

Ville ikke forundre meg om Mysql har en eller annen funksjon for random shuffling.

Men resten bør du kunne gjøre i PHP nå.

Eller du kan fortsette å gjøre det på den skikkelige måten, måten du allerede har begynt på og lære noe i samme slengen.

Dersom du har satt opp Apache på localhost så bør den allerede fungere som en lokal server. Du må putte filene du vil "servere" i Document Root (en mappe på din maskin). Hva/hvor Document Root er på ditt system finner du i filen httpd.conf. (som også er veldig godt kommentert). Denne filen bør ligge et sted i apache mappa.

Hvis du vil kjøre php scripts så trenger du PHP. Dokumentasjonen for innstallasjon på windows er ganske god på www.php.net. Du må b.la gjøre noen endringer i httpd.conf for å få apache til å kjøre PHP. Men dette kommer veldig godt frem av dokumentasjonen.

Om du spør Google så blir du sikkert servert en hel haug med veldig utdypende tutorials for dette.

Er du uvillig til å legge en time med arbeid ned i dette så er tidligere nevnte XAMPP et bra alternativ. Det er i allefall et sted å begynne.

http://dev.mysql.com/doc/mysql/en/Date_and..._functions.html

 

mysql har en bråte med dato og tidsfunksjoner, f.eks

 

select floor(to_days(now())/365 - to_days(fodselsdato)/365) as alder from personer;

Denne spørringen funket utmerket. Dersom jeg ikke får klassen til å virke så har jeg denne å falle tilbake på.

Takk så mye

kommer det fra mysql?

Jau, ideen er at det vil komme derfra i allefall, men akkurat nå så mater jeg inn tallet manuelt.

Og det hadde jo vært kjekt om jeg kunne gjenbruke klassen i andre operasjoner som ikke nødvendigvis innvolverer en database,

Vet ikke om det har så mye å si, men:

SELECT fodselsdato, UNIX_TIMESTAMP( fodselsdato ) 
FROM personer

Gir ikke negativ timestamp på datoer tidligere enn 1970, men 0. Kollonna fodselsdato er i DATE format.

YYYY-MM-DD:

print ( Age::calculateAge("1941-05-18") );

Heh... ja, en kunne si det ville ha hjulpet.. Da må jeg ha en feil i scriptet mitt for folk blir ikke ikke eldre enn 34 år.

class Age {

function calculateAge($date) {
 $yearNow = date("Y");
 $monthNow = date("m");
 $dayNow = date("d");
 
 $birthdate = strtotime($date);
 $year = date("Y", $birthdate);
 $month = date("m", $birthdate);
 $day = date("d", $birthdate);
 
 if ( $monthNow > $month || ( $monthNow == $month && $dayNow >= $day ) )
 	return $yearNow - $year;
 else
 	return $yearNow - $year - 1;
}
}

Kalles med:

error_reporting(E_ALL);
require_once('data/age.php');
print ( Age::calculateAge("1941-05-18") );

Returnerer:

34

Edit: I ettertid ser jeg jo at strtotime() returner -1 (morro i beregninger) når den ikke klarer gjøre om til timestamp og at det er defor folk ikke blir eldre enn 34. Så det er der problemet ligger. Men om den ikke klarer gjøre om en dato til timestamps så er jeg jo like langt.

Heisann.

Jeg har trålet gjennom manualen i noen timer nå og har ikke funnet en funskjon som fjerner leading zeroes i et dato-format.

Problemet er at jeg må ha støtte for datoer før 1970 og nesten alle dato-manipulasjonsfunksjonene tar timestamps som parametere.

Det kan løses med regular expressions eller et array. Men det nå da finnes enkle funskjoner for denne slags operasjoner?

Noen som kan hjelpe?

Jeg kan fortelle deg at min athlon 1800 xp med 512ram ikke har noen problemer med den spørringen. Og nettsiden vil neppe se mer enn 4-6 online brukere samtidig. Så jeg tror det skal gå fint. Den vil heller ikke se mer enn 500 rader maksimalt.

 

Når det gjelder indexering så har jeg forstått det slik at om man indexerer for mange felter så vil den ekstra ytelsen dette medfører falle bort. Og jeg vil faktisk måtte indexere nesten alle feltene i en vanlig tabell med denne søkemotoren.  Er ikke helt klar på indexering.

 

Lagde en enkel søkemotor med fulltext search. Fordelen her er jo at man kan rangere resultater etter de med mest relevans. Men må si jeg ble litt bekymret når jeg leste comments i mysql manualen.

Med den mengden data, brukere og maskinvare er det absolutt ikke noe problem uansett hvor grisete spørringer du måtte få lyst til å lage. Med det antall rader kan du også droppe index'er da du bør kunne holde hele databasen i minnet og å søke 500rader tar stort sett svært få disk oppslag for å hente inn i minnet.

 

Når databasen blir så stor at du ikke klarer å holde alle tabellene i minnet på en gang så blir index'er nødvendig. Uten indexer så må man søke gjennom hele tabellene uansett hvordan spørring man kjører. Dette innebærer at man må laste hele tabellen inn i minnet, og hvis tabellen inneholder flere millioner rader så kan det fort ta timevis å kjøre spørringer uten indexer. Med noen velplasserte indexer kan dette reduseres til sekunder

Takk for den oppklaringen på indexer.

Dette er jo ikke noe stort prosjekt og den endelige nettsiden vil ligge på maskinvare som er enda sterkere enn min testserver.

Er ganske fornøyd med den nåværende løsningen som er MATCH basert på fulltext search.

Takk for hjelpen

hvorfor ikke bare bruke "WHERE tekst LIKE '%ord1%ord2%ord3%'" ?

blir fort litt lettere

Den betinger jo at innlegget inneholder både ord1, ord2 og ord3, mens den første spørringen gjør at nyheten ikke trenger å inneholde mer enn et av ordene. Enda en ting - den der gjør jo at søkeordene må komme i samme rekkefølge!!

Og da kan man like godt bare søke LIKE %ord1 ord2 ord3%

Lol.. uffda

Ikke vits å finne opp hjulet på nytt, nei..

Men den virker ikke like bra. Ikke i det hele tatt for å være helt ærlig

Jeg kan fortelle deg at min athlon 1800 xp med 512ram ikke har noen problemer med den spørringen. Og nettsiden vil neppe se mer enn 4-6 online brukere samtidig. Så jeg tror det skal gå fint. Den vil heller ikke se mer enn 500 rader maksimalt.

Når det gjelder indexering så har jeg forstått det slik at om man indexerer for mange felter så vil den ekstra ytelsen dette medfører falle bort. Og jeg vil faktisk måtte indexere nesten alle feltene i en vanlig tabell med denne søkemotoren. Er ikke helt klar på indexering.

Lagde en enkel søkemotor med fulltext search. Fordelen her er jo at man kan rangere resultater etter de med mest relevans. Men må si jeg ble litt bekymret når jeg leste comments i mysql manualen.

Alle respekterte nettsteder må ha en søkefunskjon. Å lage en enkel en som søker gjennom database oppføringer med LIKE er ikke akkurat det vanskeligste.

Men LIKE er litt begrensende, jeg vil gjerne at det skal gå ann å søke på flere ord i samme søk.

Løsningen min er å dele opp søke-strengen med explode. Arrayet jeg får fra explode rydder jeg opp i slik at jeg fjerner ord kortere en 3 tegn.

Jeg bruker to foreach til å konstruere SQL-spørringen, en foreach for hvilke felter som skal søkes i og en for hvilke ord som skal søkes etter.

Problemet er da at dette kan bli en veldig stygg spørring til slutt.

Under er en liten smakebit på en spørring som ble laget ved å søke i 3 felter; nyhet, ingress og overskrift.

Søkestrengen er : "interdum web server gruppa dette"

SELECT * FROM nyheter WHERE nyhet LIKE '%interdum%' OR ingress LIKE '%interdum%' OR overskrift LIKE '%interdum%' OR nyhet LIKE '%web%' OR ingress LIKE '%web%' OR overskrift LIKE '%web%' OR nyhet LIKE '%server%' OR ingress LIKE '%server%' OR overskrift LIKE '%server%' OR nyhet LIKE '%gruppa%' OR ingress LIKE '%gruppa%' OR overskrift LIKE '%gruppa%' OR nyhet LIKE '%dette%' OR ingress LIKE '%dette%' OR overskrift LIKE '%dette%'

Det er jo åpenbart at jeg må programmere inn restriksjoner på antall ord i søkestrengen, men det jeg egentlig lurer på er hvor mange rader i tabellen kan det være og hvor stygg kan select-spørringen være før databasen kneler?

Og kanskje et enda bedre spørsmål: finnes det noen bedre måter å lage søkefunskjon på?