Krypteringsdjungeln

oskob skrev:

Fram tills nu har jag varit ganska slarvig med kryptering av inloggning osv. Jag har på min höjd krypterat lösenorden på serversidan så de inte sparas som ren text i databaserna, men lösenordet skickas ju ändå som klartext från klienten så det känns ganska tunt. Hur lätt är det att avlyssna en klient som skickar data till en server?

Lätt och lätt. Tillvägagångssättet (paketsniffning) är välkänt men inte helt trivialt. Lite jobbigare än att knycka godis från ett småbarn men knappast som att göra intjack på Fort Knox.

oskob skrev:

Vill man gå ett steg längre kan man ju kryptera lösenordet innan det skickas med javascript och typ MD5. MD5 verkar dock inte vara så svårt att knäcka, brute force style, om någon skulle ge sig fan på det.

Det spelar ingen roll om det går att knäcka eller inte. Vet de om hashen på lösenordet behöver de ju bara skicka in den till din inloggning för att bli inloggade, eller hur? Vill du ha säker inloggning är det SSL som gäller.

Hashning är inte kryptering. Anledningen till att man hashar lösenord är delvis en fråga om personlig integritet (vissa av mina lösenord skulle nog skicka mig till Haag ;) ), delvis är det för att man ofta använder samma lösenord till olika inloggningar, men mest för att man, om man får tillgång till databasens innehåll, inte ska kunna logga in hur som helst utan att ändra lösenordet (vilket snabbt kan upptäckas).

oskob skrev:

Hur säkert är htaccess:s lösenordsskydd egentligen? Har hört ett antal gånger att det är rätt simpelt. Hur mäter det sig mot andra metoder?

Det är bara ett ramverk som kan använda flera olika backends, allt efter behov och smak. Det "säkra" i autentisering via webbservern är att man automatiskt kan låsa in hela kataloger - inklusive statiska filer etc - utan att behöva lägga in det i sin kod. Du kan få samma funktionalitet genom något webbramverk (se nedan).

oskob skrev:

Det säkraste valet, som jag har fattat det, är SSL, eftersom det gör det omöjligt för någon att "avlyssna" uppkopplingen, hur nu det går till. Men det kräver konstiga certifikat och sånt som kan kännas overkill om man inte håller på med kontonummer och liknande.

Spontant är jag böjd att hålla med. men å andra sidan är det inte direkt fel med SSL och det kan bespara framtida huvudvärk/magsår. Det kräver ingen ändring av din kod, så det är egentligen bara att plugga in och peka om några länkar så att de använder https istället. Om du tjänar pengar på din webbplats tycker jag nog att ett SSL-certifikat är en god investering.

Ett sista tips: Dumpa PHP för andra tillämpningar än snabb-/fulhack (vilket PHP är utmärkt till). Riktiga webbramverk som Asp.net och nåt ur Javadjungeln (och Ruby on Rails, och ...) har mycket bättre inramning av webbapplikationer än PHP. I PHP skriver man script som inte har någon inbördes relation (annat än i ditt huvud, och i eventuell dokumentation). Har man ett Riktigt Ramverk hålls allt samman på ett standardmässigt sätt, vilket underlättar allt enormt många saker, inklusive autentisering.

Exakt vad menas med hashing? Låter gott ;)
Och sen har jag hört att man kan använda något som heter "salt" i samband med hashing/kryptering.

Vad tycker vi om javascriptlösningen då?

Och jag har hört att man kan använda SSL utan cert men att man då som användare får upp en tura som frågar om man litar på hemsidan. Jag har sökt runt på hur man använder SSL men jag vet inte riktigt hur jag ska börja. Är det något som webbhotellet måste ha stöd för?

Och ett certifikat, är det hemsidan får får ett cert eller jag som webbutvecklare? M.a.o. är det en engångssumma?

Tack för svar!

oskob skrev:

Exakt vad menas med hashing? Låter gott ;)
Och sen har jag hört att man kan använda något som heter "salt" i samband med hashing/kryptering.

Det du får ut ur en MD5-funktion är en hash, d.v.s. ett värde av fix storlek som är uträknad på en variabel mängd med data. Läs http://en.wikipedia.org/wiki/Hash_function och de relaterade länkarna under (så har du att göra hela julen ;) ).

oskob skrev:

Vad tycker vi om javascriptlösningen då?

Det gör vi inte ;) Den höjer inte säkerheten men tillför komplexitet. Jag antar att du hade tänkt göra nåt i stil med detta:

<form action="login.php" method="post"
onsubmit="this.md5sum.value = md5(this.password.value); this.password.value=''; return true;">
<input type="text" name="username" /> Användarnamn
<input type="text" name="password" /> Lösen
<input type="hidden" name="md5sum" /> 
</form>

Men snappar jag upp en hash finns det inget som hindrar mig från att göra ett eget formulär där jag skriver in hashen direkt, och således kan logga in som någon annan.

oskob skrev:

Och jag har hört att man kan använda SSL utan cert men att man då som användare får upp en tura som frågar om man litar på hemsidan. Jag har sökt runt på hur man använder SSL men jag vet inte riktigt hur jag ska börja. Är det något som webbhotellet måste ha stöd för?

Har du ett webbhotell kanske de kan se till att fixa certifikat åt dig. Hör med supporten.

oskob skrev:

Och ett certifikat, är det hemsidan får får ett cert eller jag som webbutvecklare? M.a.o. är det en engångssumma?

Det är bara ett certifikat per webbplats (domän, egentligen). Jag själv har inte stenkoll på bitarna i den här frågan, men certifikaten har iaf en giltighetstid så helt "engångs" blir kostnaden inte.

spango skrev:

Det gör vi inte ;) Den höjer inte säkerheten men tillför komplexitet. Jag antar att du hade tänkt göra nåt i stil med detta:

<form action="login.php" method="post"
onsubmit="this.md5sum.value = md5(this.password.value); this.password.value=''; return true;">
<input type="text" name="username" /> Användarnamn
<input type="text" name="password" /> Lösen
<input type="hidden" name="md5sum" /> 
</form>

Men snappar jag upp en hash finns det inget som hindrar mig från att göra ett eget formulär där jag skriver in hashen direkt, och således kan logga in som någon annan.

Visserligen, men man får ju aldrig ut lösenordet i klartext. Utan måste i så fall forcera det först. Borde inte detta vara lite bättre (om man inte har ssl) för att skydda besökarnas lösenord.

spango: AH! nu fattar jag. Ja det är ju klart att det är bara att avlyssna det krypterade och skicka samma data till servern. Servern vet ju inte om man hoppat över javascriptet. Det känns som att man kan dela in all säkerhet i 2 kategoier. SSL och icke-SSL. Hur mycket man än krypterar hos klient och server så går det ju ändå att lura servern med tjuvlyssning.

Nu har jag lite kött på benen. Tack!

mozilla skrev:

Visserligen, men man får ju aldrig ut lösenordet i klartext. Utan måste i så fall forcera det först. Borde inte detta vara lite bättre (om man inte har ssl) för att skydda besökarnas lösenord.

Förvisso, men det är rätt mycket jobb för en mycket marginell säkerhetsvinst. Och kan man använda SSL är det en miltals bättre lösning.

oskob skrev:

Hur mycket man än krypterar hos klient och server så går det ju ändå att lura servern med tjuvlyssning.

Exakt. Och, med risk för att låta tjatig ;) , så är hashning inte kryptering. Det är bara ett sätt att räkna ut ett tal med ett visst antal bitar från en godtycklig mängd data. Det finns kryptografiska tillämpningar som kan använda hashning, men det är i sig inte kryptering av data (vilket är att göra något oläsligt men som med rätt nycklar görs läsligt igen), utan en irreversibel förvanskning av data.

Förresten, vad gäller salt som du nämnde i ditt tidigare inlägg, så är det att man hakar på en extra sträng på det man hashar för att försvåra ordlisteattacker. Alltså, om man skulle skriva det i PHP och använda SHA1 så säger man sha1($password.'någon slumpmässig sträng') istället för sha1($password). Saltet är, förstås, samma sträng hela tiden för varje lösenord. Vill man göra det extra marigt kan man använda t.ex. användarens ID eller nåt liknande som komponent av saltet, så att man måste brutforsa varje lösenord för sig. sha1($password.'någon slumpmässig sträng'.$userId)

Hashar man t.ex. lösenord bara som de är, kan en illvillig person redan ha en databas över hashade strängar. Hittar man en hashad sträng och har en sån hashdatabas är det bara att slå mot den för att se vilken sträng som motsvarar vilken hash.

Är hashen saltad, däremot, måste man generera alla hashar för alla strängar med just det specifika saltet, vilket tar en enorm tid.

Okej... Läste lite om hashing på wiki. Fattade jag rätt om jag säger att flera olika strängar kan få samma hash, alltså att det inte finns en specifikt motsvarande sträng för alla hashar och kryptering är unik för varje kombination av bokstäver, så att den går att dekryptera och få ut exakt samma data som krypterades?

oskob skrev:

Okej... Läste lite om hashing på wiki. Fattade jag rätt om jag säger att flera olika strängar kan få samma hash, alltså att det inte finns en specifikt motsvarande sträng för alla hashar och kryptering är unik för varje kombination av bokstäver, så att den går att dekryptera och få ut exakt samma data som krypterades?

Precis. En hash har en fix storlek (iaf de som används i det här sammanhanget, SHA1, MD5, osv) och således finns det en ändlig mängd hashar, men man kan räkna ut en hash för alla strängar, och det finns ju förstås en oändlig mängd möjliga strängar.