Mitt føste (sikre?) innloggingsystem

[Magnus Holm]

Ikke så veldig mye... Men så klart er det jo lov å flytte pass.txt til et sted hvor andre ikke for tak i det;)

 

Jeg tenkte at den eneste måten å lære seg PHP på er å prøve å feile. Men så lenge passordene i pass.txt er hash'et (i en eller annen form) er det ganske vansklig å cracke den...

 

Men noen som har ide til en u-crackerlig måte å hash'et passordet på?

[zokra]

Men noen som har ide til en u-crackerlig måte å hash'et passordet på?

Jeg nevnte jo å blande inn salt i hashen..

[Magnus Holm]

Ops! Så det ikke!

*Unnskyld*

 

Men det beste er at man selv lager en som INGEN andre vet om

[Ernie]

Ikke så veldig mye... Men så klart er det jo lov å flytte pass.txt til et sted hvor andre ikke for tak i det;)

 

Jeg tenkte at den eneste måten å lære seg PHP på er å prøve å feile. Men så lenge passordene i pass.txt er hash'et (i en eller annen form) er det ganske vansklig å cracke den...

 

Men noen som har ide til en u-crackerlig måte å hash'et passordet på?

Nei, det finnes ingen slik måte. Hvorfor? Fordi man alltid har bruteforce og rainbow table. Bruteforce vil være å gå igjennom alle mulige kombinasjoner. Med hashen, en god maskin og et dårlig passord så tar det ikke allverdens med tid.

Så har vi rainbowtable. Dette går ut på å generere stort sett alle kombinasjoner på mellom x og y tegn. Det er ikke vanskelig å skaffe seg rainbow table for md5 og sha1. Derfor er salt + md5 eller sha1 og md5 kombinert med sha1 et bedre valg enn md5 eller sha1 alene, men med tiden til hjelp vil man alltid komme frem til passordet.

 

Hvis du skjønner det over skal du komme frem til konklusjonen "Ikke la brukernavn + passordhash være allment tilgjengelig".

Endret 9. juni 2005 av Ernie.

[trrunde]

Hva er salt? er det en måte å kryptere tekst på?

[Ernie]

Hva er salt? er det en måte å kryptere tekst på?

Det å legge til salt før man hasher en tekst er en måte å generere en annen hash ut av teksten. Noe man sikkerhetsmessig kan ha store nytter av.

Output for

<?php
echo md5("test");
?>

er "098f6bcd4621d373cade4e832627b4f6"

Output for

<?php
echo md5("test"+"salt");
?>

er "cfcd208495d565ef66e7dff9f98764da"

 

Nå, det fine med salt er at man kan generere en tilfeldig "tekst" noe som vil gjøre arbeidet med å finne hashens klartekst verre. Har man et passord på 10 tegn (1.208.925.819.614.629.174.706.176 kombinasjoner) og salt på 5 tegn (1.099.511.627.776 kombinasjoner) har du ca 1,33*10^36 teoretisk mulige kombinasjoner. Dette er basert på at alle 256 ASCII-tegnene er mulig å bruke. I praksis kan man redusere kombinasjonene på passordet ned til 10737418240000000000 (ca 1,07*10^19) kombinasjoner og totalt havne på ca 1,18*10^31. Uten salt ville det vært ca 1,07*10^19.

Endret 9. juni 2005 av Ernie.

[genstian]

Men det beste er at man selv lager en som INGEN andre vet om

hvis du vil så kan du få et hashscript hos meg, som jeg har laget selv og som du konfigurerer noen variabler selv slik at ingen andre vet hva du har hashet det til. selv ikke med scriptet.

NB basert på sha1, men en del sikrere.

[Frank2004]

#1 - Ingenting å tjene på å kjøre output fra en message digest inn i en annen.

 

Si at det er lett å finne kollisjoner for md5, spiller i så fall ingen rolle hva input til algoritmen opprinnelig var, og om den var plaintekst eller kom fra sha1..

 

Om du insisterer på å bruke to message digests lønner det seg nok å lagre output fra disse hver for seg.

 

#2 - Salting av passord brukes for å gjøre dictionary attacks vanskeligere. Saltet ligger lagret i klartekst sammen med digest(salt+passord), så gjør ikke et brute force angrep noe vanskeligere.

[Ernie]

#2 - Salting av passord brukes for å gjøre dictionary attacks vanskeligere. Saltet ligger lagret i klartekst sammen med digest(salt+passord), så gjør ikke et brute force angrep noe vanskeligere.

Den var litt vel selvmotsigende. Det brukes ikke for å gjøre bruteforce vanskeligere, men for å unngå at man bruker dictionary attacks ergo man kjenner ikke til hva salt er og må benytte brute force og gjette seg frem både på passordet og saltet. Tenk deg litt om nå.

Endret 10. juni 2005 av Ernie.

[Frank2004]

#2 - Salting av passord brukes for å gjøre dictionary attacks vanskeligere. Saltet ligger lagret i klartekst sammen med digest(salt+passord), så gjør ikke et brute force angrep noe vanskeligere.

Den var litt vel selvmotsigende. Det brukes ikke for å gjøre bruteforce vanskeligere, men for å unngå at man bruker dictionary attacks

Umm.. Er det jeg sier, ja.

 

ergo man kjenner ikke til hva salt er og må benytte brute force og gjette seg frem både på passordet og saltet. Tenk deg litt om nå.

Vet ikke om jeg forstår hva du prøver å si her.

 

Om en angriper kjenner digest(salt+passord), så kjenner de vel saltet også. Om noen prøver å brute force systemet utenfra så spiller ikke saltet noen rolle fra eller til..

[phun-ky]

hm. hvis man har et sesjonsobjekt som heter axx, og når den ikke er gitt antall, så blir man sendt bort. hvordan kan man(fiendtlig) endre det sesjonsobjektet?

Endret 11. juni 2005 av phun-ky

[Ernie]

 

ergo man kjenner ikke til hva salt er og må benytte brute force og gjette seg frem både på passordet og saltet. Tenk deg litt om nå.

Vet ikke om jeg forstår hva du prøver å si her.

 

Om en angriper kjenner digest(salt+passord), så kjenner de vel saltet også. Om noen prøver å brute force systemet utenfra så spiller ikke saltet noen rolle fra eller til..

Om man kjenner saltet er hele poenget borte. Da kan man alikevel sette igang med dictionary attacks.

Endret 11. juni 2005 av Ernie.

[Frank2004]

Om man kjenner saltet er hele poenget borte. Da kan man alikevel sette igang med dictionary attacks.

Saltet gjør det umulig å lage et lookup table på forhånd, eller angripe hele brukerlisten parallellt. Det som er hele poenget..

Endret 13. juni 2005 av Frank2004

[Torbjørn]

hm. hvis man har et sesjonsobjekt som heter axx, og når den ikke er gitt antall, så blir man sendt bort. hvordan kan man(fiendtlig) endre det sesjonsobjektet?

ved skaffe seg brukerkonto på samme domene og dermed kunne snappe opp cookies og få tilgang til sessiondata

[Terrasque]

//security.php
session_start();

function login($user, $pw) {
 //sjekk user+pass her, og level.
$_SESSION['userlevel'] = $userlevel;
$_SESSION['user'] = $user;
// all annen info, som ip osv
}

function access($level) {
//sjekk ip og annet om man vil
// hvis noe borkes her kan man ta og calle logout()
// og redirecte til index.php
if ($_SESSION['userlevel'] < $level) {
  header("Location: index.php");
}
}

function logout() {
//destroy session
}

 

//secret.php
include(security.php);
access(2);
//do secret stuff only for lvl 2 folks

 

index.php har form, og/eller vise login info (f.eks enten login form eller vise "velkommen blabla", sjekk login før den delen vises (bruk f.eks if isset $_SESSION['user'])

 

 

 

Er litt lat i dag, så skriver bare det mest nødvendige

 

Syns det ble veldig mye tjo og hei og hopp og sprett og samme kodesnutten spretter opp overalt på originalen. Var også kanskje en smule overkomplisert her og der.

 

Try to do the most work with the least effort

[ZoRaC]

Jeg gjør dette:

<?php
$string = crypt($_SERVER['REMOTE_ADDR'], $_SERVER['HTTP_USER_AGENT'];
$string = md5($string);
?>

 

Dette legger jeg i session ved pålogging og for hver side brukeren går inn på sjekker jeg at $string blir det samme som i sessionen...

 

Det er vel ganske sikkert?