Håller på att utvecklar en sajt med inloggningsmöjligheter för användare. Jag har i ett första utkast gjort så att vid lyckad inloggning (matchat användarnamn och lösen i databasen) så sätts en sesionsvariabel som är samma som "UserID" i databasen.

Nu börjar jag fundera på hur säkert det egentligen är. Kan man manuellts skapa sesionsvariabler på en webbsajt för att på så sätt "logga in" på andras konton? Eller räcker det som säkerhet?

Påpekas skall att det inte handlar om någon känslig information för användarna, så inga kontonummer eller liknande riskeras att komma ut någons konto blir kapat.

Kan jag köra med "sesionsvarabel-varianten" eller är jag ute och cyklar?

Jag hade börjat med att planera hur man ska spara lösenorden, dvs inte i klartext och inte i endast md5. Sen hade jag gått idare med hur man skickar lösenorden via get och post (om du gör det överhuvudtaget).

Tack för dina synpunkter. Det är sant att jag borde kryptera lösenorden i databasen. Gällande POST eller GET så vet jag inte riktigt hur sättet jag hanterar det på kallas. Jag kör ASP.NET och textboxarna på hemsidan är körs som " Runat="server" ".

Läste en några veckors gammal tråd där vissa veteraner anmärkte att sajten hamsterpaj som blev hackat förra året inte enbart skulle ha använt sig av md5.

Utan att dem minst borde ha använt SHA1+salt, hur man nu gör det. Att döma av alla tips som sades i den tråden så verkade md5 inte vara tillräckligt. På grund av databaser så som det här
http://www.md5decrypter.com/

Ta bort denna post..

man ska aldrig enbart använda md5 på lösenord... om du vill köra med md5 kör då md5+salt. Men helst av allt ska du komma på en egen funktion.

Allt skickas i klartext via formulär, så du borde fundera på ssl också. Att spara id i en session variabel går väl bra, men inte i klartext. Som tidigare person nämnde skulle du kunna baka ihop alla kriterier (id, namn, epost) till en sträng som du sedan SHA1+1 och sparar detta i session variablen.

Vi föredrar att skapa egna funktioner för detta, så har du kunskapen tycker jag du ska försöka göra det i alla fall.

Se sedan till att kontrollera allt som har med databasen att göra. Om man t ex loggar in ska du kontrollera vad personen skrev i formuläret. Om det handlar om PHP så ska du inte förlita dig på magic_quotes utan escapa allt själv också, samt limitera accessen till databasen och kör helst PDO.

Med limitera accessen till databasen menar jag att du ska bara ha precis så många databas accesser som krävs för att sidan ska fungera, och se till att begränsa all databaspåverkan som användare ska ha (Ändra profil, lösenord osv osv).


EDIT* Såg precis att du hade skrivit ASP.NET... jag är inte insatt i det överhuvudtaget...

Vad har det för betydelse om det är klartext då all sessionsdata lagras på serversidan?

Edit: Stava!

Du kan plocka upp/Kapa sessionen

Det kan du ju inte såvida du inte kan köra egen kod på servern, och har du kommit på ett sånt säkerhetshål så att du kan läsa andras sessioner, och även skriva nya värden till din session så finns det ju inget som hindrar att du kopierar någon annans sessionsvaribel.
Kryptering/hashing ger ingen ökad säkerhet på det sättet.

Edit: Det som kan öka säkerheten är däremot att man knyter sessionen till IP-numret!

Spoofa ip går hur bra som helst.. ger liten säkerhetsökning. Det hela handlar om att göra allt svårare för "hackaren". Det är sant att det inte ger någon säkerhet på det sättet.

Låt oss säga att du ska du kör i klartext och du har en session som innehåller id't på personen som är inloggad, och man kan som användare ta bort saker i databasen som är kopplade till detta id't. Då har du möjligheten att spamma ut id'n till scriptet som raderar data beroende på id't, vilket resulterar i att databasen töms. Om man istället kör med allt hashat/krypterat kan han bara rensa datan som är kopplad till sessionen, samt att man inte kan gissa sig till andra id'n.

Tänk dig "DELETE FROM tabell WHERE id='$id' LIMIT 1";

$id innehåller då '10' i klartext...

Om du istället hashar/krypterar detta id så att du får "adsdP(912314FA)FA)" eller liknande, då kan sedan göra en säker select som inte är baserad på vad scriptet får in, och du plockar ut id'n och konverterar dem till samma hash/kryptering på servern, och sen matchar du och deletar.

Finns mkt bättre sätt att lösa säkerheten på dock.

Glömde tillägga att du bör använda moment som är unika för varje gång man loggar in.

Session Hijacking...

Hittade denna precis som jag tyckte var rätt värd att läsa
http://www.brainbell.com/tutors/php/php_my..._hijacking.html
Dock cookies

Tack för alla synpunkter. Men nu börjar det bli många bollar i luften.

"Vad har det för betydelse om det är klartext då all sessionsdata lagras på serversidan?"

Stämmer det att sessionsvariablen körs enbart på serversidan i ASP.NET ? för isf är det ju inget probelm alls. Eller?

Den ska enbart köras på serversidan... men om man som hackare registrerar sig själv på din sida och öppnar sin session (på något sätt) kan han ju ändra sina uppgifter till dina... dvs om han har id '10', kan han ju prova att ändra till '11' osv...

kass på ASP.NET, vet inte alls hur det fungerar. Men jag kan tycka att det är bra praxis att aldrig köra med saker i klartext.

Well, jag delar inte din uppfattning om att det skulle ge en ökad säkerhet. :)
Du bör ju designa alla SQL-frågor så att dom är i stil med "DELETE FROM tabell WHERE user = '" . $_SESSION['id'] . "' LIMIT 1".

absolut :) alltså jag skrev '10' som exempel, vilket $_SESSION['id'] innehåller.

Alla har sina egna sätt att programmera :) så är det bara. Personligen kör jag aldrig i klartext på något.

Kryptering av sessionsdata skyddar inte mot kapning av sessioner.
Kommer en person över din sessions-cookie eller på annat sätt får reda på ditt sessions-id så kommer han att kunna ta över din session, såvida den inte är knuten till IP-adressen.

IP är osäkert, men bättre än inget... går dock att spoofa ip adresser.

EDIT* Klippt bort vissa delar pga feltänk av mig.

Hehe, du missar poängen.
En användare kan aldrig ändra sitt värde i sessionen, och kommer alltså aldrig kunna radera något annat än sin egen data.
Såvida inte personen lyckas köra egna SQL-satser via något annat hål som inte har med sessionshantering att göra.

ajajaj... ignorera delar av vad jag skrivit. Har suttit med POST och GET i huvudet medans det handlade om sessioner. Dessa kan du ändra hejvillt och på så sätt själv bestämma vad som ska skickas till SQL-satsen.

Jag står dock fast vid att aldrig köra något i klartext.

Hehe... När det gäller att skicka diverse ID via querystringen så håller jag med om att det ger en ökad säkerhet genom att man inte kan "gissa sig fram" via 1, 2, 3 o.s.v.
Men den grundläggande säkerheten ska ändå vara att SQL-frågan matchar på både user (sessions-id) och databas-raden som kommer via GET.
Gör man det så behövs ingen kryptering av datan på querystringen.
Kryptering av "GET-värden" kan skydda om du t.ex. inte skyddat dig mot SQL-injections överallt.

Exakt. PDO+Bra SQL frågor som är limiterade+behandling av mottagen data via GET/POST+lösenordspolicy+Inget i klartext.

Har du några länkar där man kan läsa mer om hur man gör det här i PHP. Jag har bara info på hur man implementerar md5 den berättar inte så mycket hur man tillämpar andra krypterings algoritmer för en login funktion på sin hemsida.

Eller vad är bra sökord i google om jag vill lära mig att göra det du just skrev om att själv baka SHA1+1 och spara alla datafält/poster (kom inte ihåg vilket) i en sträng för sessions variabeln. (Är ingen programmerare så måste typ läsa från scratch)

Att komma på en egen krypteringsfunktion är ju ändå att ta i ;-)

Finns en himla massa artiklar som berör PHP och säkerhet. Googla lite på PHP security, SSH, SSL, MD5 och annat som du kan komma på. Leta efter så nya artiklar som möjligt.

http://www.phpit.net/article/handling-pass...rds-safely-php/

Hittade jag nu precis och är relativt ny. Den ger väl en liten inblick på hur man skulle kunna göra.

Inte om det ska vara säkert. Med lite fantasi och knowhow så går det bra att skapa en egen envägs hash.

EDIT* En egen kryptering är inte så skoj däremot.

Tack för länktipset ser inte så farligt ut. Det mesta av koden ser bekant ut trodde jag behövde koda minst 500 rader för att åstadkomma det ni pratade om.

Skriva en helt egen one-way krypteringsmethod är ju inte något man gör på en kvart, men jag antar att du menar att utveckla md5()'en lite så att den blir säkrare? ;-)
Isf är det precis som du säger, använda lite fantasi och ta lite randoms :)

Nä inte en kvart :) Man kan absolut ta md5 och trixa till den lite, eller om man vill, har tid, ork och lust.. skriva en egen.

Skriv inte en egen, kommer om möjligt bli ännu enklare att knäcka :/

Ptja, förusatt att algoritmen är publik alt. bruta det.

Förutsätter väl att man har kommit in i servern och kan se algoritmen? Då tror jag man har större bekymmer att tänka på ;)

Tycker själv att det är onödigt att skriva en egen då SHA1+salt (det menas alltså att man använder SHA1-kryptering men lägger till bokstäver för att det inte ska vara enbart SHA1).

Även jag lägger min röst på SHA-1 + salt.
Personligen så brukar jag använda användarid + ett förbestämt ord som salt.
Detta för att två personer med samma lösenord inte ska få samma hash-värde i databasen. Att salta med användarnamnet funkar också, men det innebär att användaren måste byta lösenord om man byter användarnamn.

Att låta användarna byta sina användarnamn är väll inte så jätte vanligt, men om man vill han sån funktionalitet kan man väll bara be dem att fylla i sitt lösenord igen, som en säkerhets åtgärd.

Jag lägger i alla fall också min röst på sha1 + salt när det gäller lösenord. ASP.net är dock inte mitt starkaste område, men som sessions id borde du ha nån lång slumpad sträng för att göra dem svårare att identifiera.

Lånar tråden lite:
Tidigare i tråden diskuterade ni sessionskapning och visade ett antal exempel sql strängar. Vad är fördelarna/nackdelarna med att lagra sessionerna i en databas vs t.ex. phps inbyggda sessionshantering?

Beroende på situationen, röstar jag först på sha1+salt. Men i vissa situationer kan en egen lösning vara bättre.

Det var det jag funderade på, vad byte av algoritm skulle skydda mot är ju främst om någon lyckas göra en dump på databasen, att då ha något hemmasnickrat lär inte stoppa mycket, och många användare får problem.. Bättre är ju som sagt salt + någon välkänd hash-algoritm

Tillägg till mitt tidigare inlägg: Det är bra om du saltar med en sträng i stil med "e33DcÄfas#x70gr@m%" , d.v.s. ganska lång och med många teckentyper.
Det ger ett ökat skydd mot bruteforce av hashen i fall användarna använder korta/svaga lösenord.
Om någon kommer över databasen OCH källkoden så har du såklart nada hjälp av att du saltat lösenorden eftersom dom då ser vad saltet består av.

Jo, du har hjälp av saltet; en rainbow-table kan du inte använda, du måste bruteforca.. (En rainbow-table innehåller i regel inte ditt salt redan)

Helt rätt, fel av mig! :)
Å andra sidan går det snabbt att skapa egna rainbow-tables där saltet ingår.
Jag skulle tro att det flesta väljer att göra det innan man ger sig på en jobbig bruteforce.

Jag läste för nåt år sen då PirateBay killarna blev fråntagna medlemsdatabasen vid en razzia. Då hade en av killarna sagt i tidningen att allting var lugnt att dem hade en jättesäker kryptering. Är deras fall samma sak som när hamsterpaj blev hackat och man kunde köra md5 dekryptering på dem? Bara det att dem körde en annan sorts krypterings algoritm.

Om ja hade dem enbart använt sig av SHA1+salt för att skydda sin databas. Eller körde dem nånting egensnickrat som nån här har föreslagit?

Att använda egensnickrat så som vissa beskriver det, behöver inte alls vara osäkert och lätt att bruteforca. Det gäller dock att vet vad man gör, har tid att göra det och testar funktionen hårt.

Exempel på samma ord
MD5: b7bc47bd82143c3c21943e55d4eae087
Sha1: c3d303de5c0ddf84bc5f1f6f4c758ba47722f746
Min: 50 tecken. Bokstäver, siffror, specialtecken. Dessutom, om man omvandlar samma lösenord två gånger blir det inte samma sträng. Har inte lyckats få en dublett på samma ord på 200 000 000 genererade hashar.

Men hur kan man veta att det är rätt lösenord när man loggar in frågar ni :) Det ni, det säger jag inte :)

Den används inte externt (internet) dock, så man kan aldrig säga att det är supersäkert... allt går att hacka sig igenom.