Sikker innlogging - hva må til?

[????????]

jorgis da... jeg har skrevet PHP i veldig mange flere år enn deg, og jeg vet at du er veldig flink så det er ikke gøy å bli sagt i mot - men forsøk heller å se på dette som tips.

 

1. sleep()

Jeg sier at sleep() er en god ting, nettopp fordi det har ekstremt lite å si for en bruker - men utgjør et stort hinder for hackere. Nå vet ikke jeg hvor gammel du er, men om du kikker på mange nettbanker så ser du at det tar litt tid å logge inn. Det samme gjelder vel paypal og mange flere også. Så uavhengig av om du liker det så er det mange som mener at dette øker sikkerheten.

 

2. Bruteforce

Bruteforce er betegnelsen for å dekryptere en beskjed, dvs. de er avhengige av å ha hashen. Så der er jeg redd du surrer litt.

Hvis du vil vite mer om dette så anbefaler jeg google.com. Når du setter deg litt mer inn i dette så kan du se alle hackerforsøkene som gjøres på dette, det finnes til og med en spennende konkurranseside: distributed.net/des/

 

3. Optimalisering

sleep() går ikke utover optimaliseringen på serveren og utgjør kun en treghet for den brukeren den gangen han logger inn.

 

4. Flere plattformer

Alle disse tipsene er det mulig å følge helt uavhengig av plattformer!

 

Hvis du der i mot mener http service (http server) som apache så er den eneste forskjellen at dersom man ikke kjører apache så kan man bare legge passord filer i en mappe utenfor webområdet. Jeg skriver at de må være utilgjelig for brukere, og at htaccess er en god løsning - sier ikke at den er den eneste.

 

Videre så glem ikke at apache har ca. 70% av markedet - og som vi alle vet så kjører PHP på flest *nix servere - så hvor lav prosentandel det er av PHP brukere som ikke har apache kjenner jeg ikke til, men det er ikke så veldig mange.

 

5. Portabilitet

Men unntak av htaccess så er scriptet helt åpent for portabilitet så jeg regner med at du er trøtt når du skrev dette.

 

6. GLP

All lansering av opene koder vil føre til at alle kan se logg inn rutinen og det er ikke mulig å lage noe script som hindrer noen å finne ut login rutinen.

 

 

 

Som du sikkert forstår så har ikke jeg plutselig bestemt meg for å finne på litt om sikkerhet. Dette er samlet fra bøker, artikler og erfaringer gjennom mange år. Og jeg regner med at du ved å studere tipsene litt nærmere ser at de har ingen ting med plattforavhengighet, egen server eller noe med et spesielt oppsett å gjøre.

 

Du kommer med to viktige ting, som jeg ikke skal si i mot.

1. Ren og versiktlig kode er ekstremt viktig!

2. Du mener at sleep() er et hinder og ikke en fordel. Jeg mener at det er fordel, men det er selvfølgelig avhengig av hvor viktig sikkerhet er.

 

Som jeg sier så er dette tips, alle får bruke de som de ønsker. Isteden for å forsøke å si i mot tipsene ønsker jeg det heller velkommen til å gi flere bidrag som de to punktene over

[El Nino]

Må bare blande meg inn her.. dette er en så utrolig morsom tråd..

 

Brute Force:

Definisjonen på Brute Force er kort forklart å prøve alle mulige kombinasjoner inntil en løsning er funnet.

 

Man trenger nødvendigvis ikke å ha passordet "foran seg" for å bruke Brute Force metoden da det er fullt mulig å sette opp et script som prøver alle mulige kombinasjoner av et passord til et form skjema for så å analysere resultatet.

 

Det er derfor riktig at en sleep() funksjon vil virke avstøtende for crackere (ikke hackere, la oss ha definisjonene riktig her).

 

Foruten om de gode rådene (fra ???????? vel og merke), så kan man legge til en funksjon som genererer en tilfeldig sikkerhetskode som et bilde som brukeren må taste inn når man skal logge seg på.

[????????]

Nå måtte jeg sjekke der El Nino, men utgangspunktet for bruteforce er nok at man kjenner en kryptert melding.

 

Et raskt søk på google.com gå meg følgende:

 

http://www.gnupg.org/gph/de/manual/a1949.html

Oversatt: Attack on encoded data, with which all possible key combinations

 

http://en.wikipedia.org/wiki/Brute_force_attack

In cryptanalysis, a brute force attack is a method of defeating a cryptographic scheme by trying a large number of possibilities; for example, exhaustively working through all possible keys in order to decrypt a message.

 

http://searchnetworking.techtarget.com/gDe...i499494,00.html

Brute force (also known as brute force cracking) is a trial and error method used by application programs to decode encrypted data such as passwords or Data Encryption Standard (DES) keys...

 

http://www.pcmag.com/encyclopedia_term/0,2...&i=38980,00.asp

The systematic, exhaustive testing of all possible methods that can be used to break a security system. For example, in cryptanalysis, trying all possible keys in the keyspace to decrypt a ciphertext.

 

Brute force er vel en gammel teknikk som forsøker å dekode en melding. I utgangspunktet eller innen kryptografi hvor jeg anta termnelogien oppstod så er vel meningen å dekryptere. I dag er vel dette ofte kjent som en teknikk for å prøve seg frem og derfor "likestilt" med cracking.

 

Dere må gjerne rette meg om jeg tar feil, men bruteforce er vel nettopp ment for å dekryptere?

 

Et generelt søk på google.com etter brute force gir meg i alle fall veldig mange treff på dekryptering enn bare tilfeldig prøving og feiling.

[jorgis]

Det er her å begrense antall login-forsøk kommer inn i bildet, noe som i mine øyne er mer viktig enn å legge på en forsinkelse i systemet. Et begrensning på antall logins vil ikke bare hemme, men stoppe f.eks. forsøk på å knekke et passord via bruteforce el.l. Å begrense antall login-forsøk kan til en viss grad også hemme forsøk på innbrudd via social engineering (gjetting av passord basert på at man kjenner vedkommende).

 

EDIT: typo

Endret 28. august 2005 av jorgis

[????????]

Tja... det har jeg allerede dekket jorgis:

Lagre alle logg inn forsøk. På den måten kan du se om samme brukeren har forsøkt å logge seg inn mer enn for eksempel 10 ganger. I så fall vis brukeren en link til glemt passord og ikke gi den mulighet til å logge inn igjen på for eksempel en time.

 

Men det har sine svakheter. Har noen klart å få tilgang til databasen din, så har de jo mange brukernavn, og kan da bare velge å begynner på nytt på neste brukernavn.

Endret 28. august 2005 av ????????

[jorgis]

Om man ikke bare tar brukernavn som utgangspunkt, da.

 

La oss si vi logger alle mislykkete innloggingsforsøk, og logger IP/brukernavn/UA og timestamp på hver. Da kan man sette forskjellige regler for forskjellige ting. F.eks. å sette maksimalt 10-20 mislykkete forsøk mellom hvert vellykkete forsøk per IP, og f.eks. 3 forsøk per brukernavn. Dermed vil man la skoler eller andre steder hvor man har mange klienter bak samme IP unngå at en bruker ødelegger for alle (det må i så fall være mer enn fem brukere som taster feil sine tre ganger før noen logger inn rett for at det skal blokkes), samtidig som man blokker for at noen bare kan hoppe til et annet brukernavn.

 

Og dessuten: om noen har tilgang til databasen dette kjøres på, vil de i de fleste tilfeller har mulighet til å direkte manipulere databasen, og dermed slippe å måtte bruke bruteforce. Har en inntrenger mulighet til å sette inn sin egen admin-bruker via en sql injection, vil han foretrekke det enn å lese ut litt info fra databasen og bruke lang tid på å knekke det. Bruteforce er siste utvei, slik jeg ser det.

[????????]

Hehe... forstår tankeganen din jorgis, men IP er ikke mye å stole på.

[jorgis]

Hehe... forstår tankeganen din jorgis, men IP er ikke mye å stole på.

Skjønner det, og da kan man pøse på med andre måter å kjenne igjen brukere på. UA-strenger (evt. fravær av UA-strenger), å sette sessions på mislykkete login, gjenkjenne mønstre i bruteforce-forsøket (om b ble prøvd før a, osv.) og seff total blokkering av systemet om det skulle være VELDIG mange feile logins (10 000+).

 

Men uansett hva som gjøres, er det utrolig vanskelig (nesten umulig?) å sikre seg mot bruteforce eller andre sleske måter å bryte seg inn på. Sleep vil bare kjøpe deg nok tid til forhåpentligvis å kunne reagere, begrensning av login-forsøk vil kunne omgås på forskjellige måter, salting vil kunne avsløres om det er GPL eller PHP dør, og social engineering vil ikke kunne blokkes i det hele tatt. Går noen virkelig inn for det, vil de komme seg inn, uansett hvor skuddsikker kode du skriver.

 

EDIT: sleep() kan forresten ha noe for seg om man kun bruker det på feilslåtte logins. Da har man ingen forsinking på vanlige logins (ingen dårlig brukeropplevelse), men likevel beskyttelse mot bruteforce (til en viss grad).

Endret 28. august 2005 av jorgis

[El Nino]

Det kommer litt ann på hvordan man har tilgang til databasen. Har man tilgang til databasen slik at man har mulighet til å endre på den, så har jorgis rett. Brute Force er unødvendig da.

 

Har man tilgang på databasen som en flatfil, f.eks. pga av backup eller lignende så kjører man ikke Brute Force på passordet opp mot serveren, men på lokal maskin da det går ekstremt mye kjappere. Når man så har funnet passordet (collisionen), så er det bare å spasere rett inn.