200 000 000 hashar? det är ingenting om man försöker leta efter hashkollisioner...
En säker hashfunktion beräknas lämna en kollision efter 2^(n/2) försök där n = antalet bits på 'slutsumman'.
Så om man har en hashfunktion som ger 50 st tecken (8-bitar) blir det ca 2^200 försök, att köra igenom 2^200 värden kommer att ta miljontals år även om man använder alla jordens datorer samtidigt, det är därför man inte testar hashfunktioner genom vanliga bruteforce attacker.

Ett av dom vanligaste felen när det gäller krypteringskydd är att man försöker göra en egen algoritm.
Det finns nog ingen i världen som kan göra en egen säker kryptografisk funktion helt själv, 99.9% av alla officiella algoritmer som finns har blivit granskade och testade av oberoende experter under en lång period innan dom blivit accepterade som kryptografiskt säkra. Det finns redan många bra säkra algoritmer, därför är det helt onödigt att göra någon egen, och om algoritmen inte ska skydda någonting viktigt behöver man ju ingen...

jag vet inte du missförstod mig eller om jag missförstår det du skrivit. Med dem där 200 000 000 hasharna menar jag följande:

Bokstaven A i md5 eller sha1 blir alltid samma hash sträng. Bokstaven A i den funktion jag använder för internt bruk blir "aldrig" samma hashsträng. Det första testet jag gjorde med min var att generera 200 000 000 hash strängar i en loop, med samma ord som utgångspunkt och det blev noll dubletter. Det system jag körde på när jag genererade detta blev tjurigt som tusan när jag försökte generera fram fler hashar än så.. så helt ärligt vet jag inte hur mkt den kan generera utan att få dubletter.

Men, som du även nämner så har alla officiella algoritmer testats hårt och länge innan dem blivit acepterade, vilket jag inte gjort med min. Men, det behöver inte betyda att min är sämre, inte bättre heller.. bara annorlunda ;)

Edit* Man kanske inte ens kan kalla min funktion för hash... den är väl inte Direkt baserad på någon algoritm, utan något annat också. Det går dock inte att återskapa ordet om man kör funktionen baklänges, och du behöver vissa andra parametrar för att kunna matcha en sträng mot en sträng.


Edit igen* Jag är ingen expert i detta området, så jag ska kanske inte säga för mycket heller. Men, jag använder inte just denna funktionen på nätet, mest för att jag inte vill riskera att någon del ska bli public. Det är också därför jag inte visar hur en sträng ser ut.

Avslutar mina uttalanden i denna tråd med att säga:

Använd sha1+salt Intet

En säkerhetslösning som baseras på att informationen om hur en "algoritm" gör för att generera en sträng förblir hemlig känns inte speciellt säker.
Hur säker är dina hashar om nån får tillgång till din källkod? ;)

Därför inte externt bruk. Sen är det väldigt svårt för mig att förklara hur den funkar utan att avslöja för mycket.. men jag kan säga att det inte kommer hjälpa så mycket med källkoden... svårt att förklara som sagt. Det behövs andra verktyg för att matcha saker och ting... tänk er bankdosa with a twist.

Edit* slutar kommentera här nu och låter experter på detta framföra sina åsikter.

Poängen med en bra algoritm är att man inte kan "avslöja för mycket". Det hela bygger ju på att även med total öppenhet som i fallet med md5 och sha1 så ska det vara lika svårt att "knäcka" hasharna. Jaja, vi lämnar det nu.

Lite o.t men:
Det roliga med siter som försöker ÖKA säkerheten genom att införa regler runt valet av password faktiskt ger så många tips till en bruteforceknäckare att det minskar antalet möjliga kombinationer, dvs får motsatt effekt. Nog hjälper det att öka upp antalet tecken i ett password, men övriga regler + mänsklig psykologi stjälper mer än det hjälper.

Ta följande regler:
"Använd minst 8 tecken i ditt password": fint, nu behöver vi bara bruteforca strängar som är ca 8 till 10 tecken. I många fall är passwordet paddad med extratecken för erhålla rätt längd.

"använd konstiga bokstäver" gör att folk använder minst ett q, z eller x. Bra, då minskade antalet kombinationer då vi kan först bruteforca genom att testa med dessa tecken på alla 8-10 positioner. Vi vet nu att minst ett tecken är av dessa tecken (konstiga tecken är kulturberoende btw).

"Använd minst en siffra": de flesta paddar sina passwords med siffran sist så då minskade antalet kombinationer på just den teckenpositionen (7-10) ner till 10 st iställer för 255.

"Blanda stora och små bokstäver": Nyttig info även detta.

Sedan kan bruteforce attacken börja med att tillämpa dessa regler enligt ett dictionary så får man antagligen en träff mycket snabbare än att köra en tokslump.

... nu har vi reducerat det totala antalet möjliga ord ner till en mycket mindre mängd. :)

Och för att svara på din ursprungliga fråga: ja, ditt user-id som guppar omkring i serverns minne är kopplat till en sessionscookie som webläsaren skickar med vid varje fråga till din server. Det enda sättet det går att hijacka en session skulle vara om någon annan lyckas fejka en redan aktiv cookie och skicka med denna i ett anrop (och så fungerar det väl med alla teknologier?). Detta har egentligen inget att göra med vilket data du lagrar i sessionen (dvs i serverns minne).

Kloka ord från Robert, så sant som det är sagt.

En vanligt "komplexitet-policy" i datorvärlden är ju att lösenordet ska innehålla minst tre teckentyper av fyra möjliga (gemener, versaler, siffror och specialtecken) samt vara minst 8 tecken. Jag kan inte se att det skulle hjälpa en "bruteforceknäckare", snarare avskräcka! :)

Visst, man behöver inte testa kombinationer som inte uppfyller dessa krav, men å andra sidan så blir det väldigt tungt att knäcka lösenorden. Utan en sån policy så är det många som väljer svaga lösenord och dessa blir knäckt alldeles för fort.
Den enda praktiska nackdelen är ju att folk tycker att det blir komplicerat att välja lösenord, speciellt om dom är van att ha "hej" som lösenord.

Tack Robert för ett mer exakt svar än många andra utsvägningar:) . Men vad tolkar jag av ditt svar som, att det är "ok" att köra den tekniken ur säkerhetsynpunkt eftersom allt körs på serversidan? Som jag sa i inledningsvis, jag hanterar ingen sekretessbelagd information eller ens personnummer på använadre. Så jag är ute efter om det "duger" som säkerhet och inte är allmänt enkelt för Agda 85 att gå runt säkerheten...

Intet: Kör på sessioner, men undvik att lagra känsliga uppgifter i sessionsvariabler. Om möjligt så lagrar du bara user-id.

Tack Fredrik, will do.

Det är väl just det man inte ska göra? Hasha som sagt ihop id, ip och e-post åtmindstonde.

Helt rätt, tar man med IP så kan man göra en check som gör att sessionen blir låst till sin ursprungliga IP-adress. Och kommer något anrop från en annan IP-adress så dödas t.ex. session. Att hasha ihop userid + ip eller ha dessa i olika sessionsvariabler är väl en smaksak.
Men vad vinner man på att ha med e-postadressen?

Vad spelar det för roll vad ni lägger för något i session? Ingen mer än er egen kod kommer ju kunna läsa vad som står där ändå..

Normalt sett, ja. Men rent generellt så bör man jobba enligt principen att all data (speciellt känslig data som lösenord etc.) enbart ska lagras i databasen, inte i sessioner och FRAMFÖR ALLT inte i cookies hos klienten.

Jag har t.ex. varit med om ett flertal gånger att man i delade miljöer/shared hosting har kunnat läsa sessionsfilerna på servern via ASP/PHP-script. Detta är såklart katastrof och en ren konfigurationsmiss, men likväl så bör man vara försiktig med vart man lagrar saker.

Många sidor har en automatisk inloggningfunktion (typ "kom ihåg mig") som bygger på att användarnamn och det hashade lösenordet ligger lagrat i en cookie hos klienten. Detta är en säkerhetsrisk eftersom man vid en XSS-attack kan sno cookie-informationen från besökarna.

Tillägg till mitt tidigare inlägg: Att hasha ihop id + ip funkar nog mindre bra eftersom det blir lite jobbigt att få fram "vem är jag" i så fall :)
Ska man låsa sessions till ett IP så får man helt enkelt spara IP-adressen separat.

Men tänk efter nu... det ni säger är att något som körs i serverns minne måste vara krypterat? Va? Ska man kryptera variabler i den körande koden också?

Som någon sa så gick det för honom att läsa sessioner från fil på servern, hmmmm då måste det vara fråga om någon form av persistent sessions eller någon specialare, eller att sessioner hanteras via databas om du kör klustrade webservrar. Men om man inte gör det så spelar det ingen roll vilken info som lagras i sessionen för det finns inget "interface" för en hacker att titta på variabeln även om denna person skulle lyckas hijacka en sessionscookie. Och om cookien (sessionen) blir hijackad så blir det enda resultatet att hackern helt plötsligt befinner sig i samma state som ursprungsägaren till cookien, tex att han helt plötsligt är inloggad på siten. DÅ har vi ett helt annat problem, men det är också en helt annan story.

Många här verkar prata om hur man authentiserar ägaren av en cookie, och visst, man kan lagra besökarens IP i sessionen och sedan kolla så att besökarens IP överenstämmer med det som han använde vid förra requesten, det skulle antagligen hindra en del skurkar då de inte kan uppfinna en befintligt sessionscookie ur tomma intet utan måste även spoofa fram korrekt IP.

Tänk bara på att inte lagra för stort data i sessionen då det kan bli lite trångt i minnen på servern om man har mycket besökare (och har lång sessionstid). Det idealiska ÄR alltså att bara lagra userid i sessionen för det är just det man behöver för att koppla det anonyma webanropet till en befintlig användare i databasen.

Jag särskiljer på en dictionaryattack (som tar några sekunder att utföra) jämfört med en brute force attack som kan ta tusentals år. Jag utgick däremot från att bruteforce attacken började med att köra igenom en dictionary innan den ägnar sig åt tokslump! :)

Det enda som en sådan komplexity policy bidrar till är om Nisse försöker gissa Kalles password genom att skriva in namnet på hans katt i password rutan och trycka submit. För Nisse blir kalles password tusen gånger mer komplext med dessa regler, men för en dator så blir de enklare. Fast det är ju min åsikt förståss... :)

En liten utvikning: vi lagrar ofta värden i kakor för att identifiera en återkommande användare. Identifieringen syftar till att komma ihåg enklare värden som inställningar, ej känslig data.
Vad är bra praxis (försöker använda svenska ord här)?
Att lagra oskyldig info om användare på ett krypterat sätt i kaka på användarens dator?
Att lagra oskyldig info om användare okrypterat i kaka på användarens dator?
Att endast lagra en unik identifierare i kaka hos användaren i krypterad form. Identifieraren används sedan för att hämta användarens fortfarande oskyldiga uppgifter i en databas.

Jag förutsätter att ingen obehörig har åtkomst till datorn och sitter och går igenom kakburken, och att uppgifterna det handlar om visserligen är personliga men harmlösa ur integritetssynpunkt för användare och säkerhetssynpukt för webbplatsen.

Praxis är väl att det spelar ingen roll om det gäller icke känslig data. Det vanligaste exemplet på data som lagras oskyddad på klienten är tex språkval för en site, om användaren vill ha större typsnitt etc. Men detta behöver ju inte lagras i klartext för det. Ett språkval kan ju lika gärna vara siffran '1' som att det skulle stå 'us-en' eller dylikt.

Regeln man kan tillämpa är väl den att om data behöver krypteras så är det ändå för känsligt för att ö.h.t lagras på klienten.

Jag hade valt att endast lagra en unik identifierare för att automatinloggningsfunktionen.
Kommer någon över cookien så kommer dom in på sidan, men man kommer aldrig åt lösenordet vilket är väldigt viktigt eftersom många har samma lösenord på flera ställen.

Default så lagrar PHP all sessionsdata i filer istället för i minnet som är fallet med ASP. I de fall jag pratar så har webbserveranvändaren helt enkelt haft läsrättigheter i den mappen där filerna ligger samt på filerna. Inga konstigheter eller specialfall på något sätt. :)

Jag är på din linje med att enbart lagra user-id i sessionen, mer behövs inte. Möjligen att man som sagt lagrar IP för att låsa sessionen till IP-adressen.

Nu börjar det här bli lite uttjatat... :)

Att lagra känsliga uppgifter i en cookie bör man vara försiktigt med, själv sparar jag inga egna uppgifter i cookies, det som enda som lagras i cookies är PHPs egna slumpnummer PHPSESSID.

Så här gör jag för att få minimera säkerhetsproblem:

Pseudo-kod för Login-sida med PHP:

1. Visa login sidan för klienten, klienten fyller i uppgifterna och POSTar

2. Rensa POST variablerna från ej tillåtna tecken och kontrollera ev. tomma fält

3. session_start() för att skapa PHP sessionen (PHP skapar cookien PHPSESSID)

4. Om variabel $_SESSION['count'] ej satt, sätt den till 1

5. Om variabel $_SESSION['count'] == 5, presentera en sida som säger "För många
felaktiga försök, prova igen om xx minuter", exit;

6. Kontrollera användarnamn och lösenord mot min databas

7. Om fel användarnamn eller lösen, öka $_SESSION['count'] med 1 och gå tillbaka till punkt 1.

8. Om anv.namn + lösenord stämmer:
Skapa $_SESSION['hash'] = md5(PHPSESSID + user_id + $_SERVER['REMOTE_ADDR])
Skapa $_SESSION['userid'] = userid från databasen

9. Visa klientens skyddade sida


Underliggande skyddade sidor startas alltid med check_login();

Pseudo-kod:

funktionen check_login()
{
session_start();

kolla att $_SESSION['hash']==md5(PHPSESSID + $_SESSION['userid'] + $_SERVER['REMOTE_ADDR])

Om det ej stämmer , presentera inloggningsidan, exit;
Om ok, bara att gå vidare och visa den skyddade sidan för klienten
}

SimonP: Ett tips är att lagra antalet misslyckade försök i databasen istället för i sessionen, eftersom en angripare kan använda ett script som raderar sessionscookien efter varje misslyckat försök och på så sätt få en ny session för varje försök.
I övrigt tycker jag det ser bra ut!

Absolut, det är kan man göra, dock får man lite mer SQL belastning, men det kan det vara värt i vissa fall


På en ny sida som jag håller på med kommer jag att skippa PHPs sessionshantering, och göra en en egen sessionshantering i MYSQL, där mysql tabellen är av MEMORY-typen för att få bra prestanda och slippa hårddiskbaserade lösningar, PHPs egna sessioner lagras som default på serverns hårdisk.

Har man egen server så är det snabbt gjort att ändra i php.ini så att sessionshanteringen ligger i minnet, men att bygga en egen sessionshantering är ju också ett alternativ! :)

En bra grej att göra är att typecast'a värden som är integers om du tar in dessa från användaren. typ

$id = (int)$_POST['id'];

Så blir det inga problem i databasen sen :)

Nja, det är väl inget som ingår i en standard PHP installation ?
Jag testade med session.save_handler = mm på två Windows servrar och det funkade inte.

Har inte testat på linux servrarna ännu.

Jag har aldrig testat i Windows, det kanske inte finns stöd för det helt enkelt...
Om inte annat så är det bara att skapa en ramdrive ange den som session.save_path

(Tog bort mitt inlägg då det hamnade helt fel och allt blev ologiskt.)

eaccelerator finns väl till windows(jo) och då kan man nog köra session.save_handler = eaccelerator och sätta eaccelerator.sessions="shm".

edit: FAST eaccelerator.sessions verkar inte fungera så bra vad jag testat på min linuxburk idag. Så kanske inte är så mycket att ha...:)

Ok, jag har läst liknande om andra tredjeparts sessionshanterare.
Jag tänkte sätta save_handler = user och hantera det med egna funktioner.

En liten fundering bara:

Hur förhåller sig det som diskuterats i den här tråden när det gäller lösenordsskyddade sidor med hjälp av .htaccess? (Alltså inte rent personliga sidor, utan sidor som en viss grupp av personer har tillträde till)

Kan vara bra att lägga in en liten delay om man skriver fel användarnamn eller lösenord.

Nja, behövs inte eftersom kontot blir spärrat i 60 minuter efter 5 felaktiga inloggningar.

Jovisst, men om man skulle komma runt det på något sätt... (inte för att jag kommer på hur just nu.. men om) :P

// Mats

Hmm, jag satt och googlade runt lite så hittade jag de här som du kan vara lite intresserad av!
http://dev.pellesoft.se/login/articl...ommunity_1.asp

TS undrade vad man behöver tänka på när det gäller sessioner och säkerhet.

Scriptet på länken du postade verkar mkt osäkert i mina ögon...

För inte rensar väl ASP Form-variabler automatiskt från SQL-injections?

Ja du simonP, de var bara något jag snubblade över och skumade igenom väldigt snabbt, jag är inte så på läst om den.