[guran]

En del medlemsidor lagrar användarnas lösenord i klartext. Själv krypterar jag dem alltid och jag kan inte känna till dem. Glömmer användaren bort sitt lösenord så skickas ett nytt lösenord och det är endast mottagaren som känner till det nya.

Enligt min uppfattning tycker jag att en användare ska ha rätt att inte exponera sitt lösenord. En anledning kan vara att användaren använder det för flera sajter och medlemskap. Ja, han eller hon kan använda både användarnamn och lösenord på flera sajter.

Med andra ord, tycker jag det är lite oseriöst att lagra användares lösenord i klartext.

Jag undrar nu vilken uppfattning ni andra har?

[mypay]

Även om lösenordet lagras krypterat så har ju utvecklaren möjlighet att kika på lösenorden om han/hon vill..

Det hela handlar snarare om hur säkert dom ligger lagrade så att ingen utanför sajten kan få tag i uppgifterna. Det seriösa hos en websajtsägare borde ligga i att inte kika överhuvudtaget

[Filip]

de få gånger jag har lagrat inloggningslösenord, så har jag krypterat dem och gjort dem omöjliga för någon att läsa.
Vad tjänar jag på att inte kryptera dem?

[mypay]

Filip - då du krypterat dom så kan du ju även dekryptera dom igen.. dvs hur man än gör så är dom inte säkra från utvecklaren

[Jan Eriksson]

Man kan använda hash och lagra detta i databasen. Hash är en kontrollsumma av en sträng. När användaren väljer sitt lösenord krypterar man det med hjälp av hash och sen lagras hashvärde i databasen. När en användaren sen loggar in med sitt lösen så omvandlas detta med hash först och sen jämförs detta med det hashvärde som finns i databasen.

En hash kryptering kan inte vändas. Det går alltså inte räknat ut lösenordet med hjälp av hashvärdet. Man kan använda hash i bland annat php, asp och asp.net.

/Janne

[anders.n]

Sedan bör man använda ett 'salt' också för att man inte lika lätt skall kunna använda för-uträknade hashvärden eller kunna se vilka som har samma lösenord om man kommer över databasen, men.. sparar man inte lösenorden i klartext så bör man vara medveten om det redan.. :)

Appropå det... man kan även implementera bättre skydd på klientsidan.. Jag skulle fixa ett CMS utan tillgång till HTTPS.. När användaren loggar in (och har javascript aktiverat) så hash:ar den lösenordet lokalt innan det skickas (två gånger blah blah hash:at i databasen blah blah). Det blir således mycket säkrare om någon sniffar nätverkstrafiken. Så borde fler siter göra när de inte använder sig av https.

[Filip]

Jag har använt föjande metod i PHP:

<?php
$password = "webmasternetwork";

$encrypted = crypt($password);

if (crypt( $password, $encrypted ) == $encrypted )
echo "Lösenorden matchar!";
else
echo "Lösenorden matchar ej!";
?>

Som Jan Eriksson säger, så kan jag lagra lösenordet krypterat men ändå kontrollera om användaren skriver in samma lösenord.

[Robert]

Jag hashar också passwords i databasen. Det enda som känns osäkert är om hashmetoden i sig skulle förändras om man måste flytta systemet till en ny plattform eller dylikt (updaterar något cryteringsobjekt eller annat som förändrar den kod som påverkar hashimplementeringen). Även fast text MD5 är standard så finns det väldigt många olika implementeringar i hur man gör en korrekt MD5. Det går att kolla upp om ens egna hashrutiner producerar en korrekt chechsumma via någon website (som jag ej kommer ihåg url till) och där kan man dubbelkolla sina hashade resultat innan man börjar släppa på users i databasen.

[kullervo]

Originally posted by Robert@Jan 21 2005, 12:35
Jag hashar också passwords i databasen. Det enda som känns osäkert är om hashmetoden i sig skulle förändras om man måste flytta systemet till en ny plattform eller dylikt (updaterar något cryteringsobjekt eller annat som förändrar den kod som påverkar hashimplementeringen). Även fast text MD5 är standard så finns det väldigt många olika implementeringar i hur man gör en korrekt MD5. Det går att kolla upp om ens egna hashrutiner producerar en korrekt chechsumma via någon website (som jag ej kommer ihåg url till) och där kan man dubbelkolla sina hashade resultat innan man börjar släppa på users i databasen.

Så varför ska man använda DES-kryptering när man kan använda enkla md5 istället? Jag ser inga fördelar i ett så här enkelt exempel. MD5 är väl kraftigare med sina 128 bitar?

En mer flexibelt metod är att använda databasservens motsvarande krypteringsmetod. Från och med MySQL 4.1 är den på 160 bitar. Motsvarande funktion i äldre MySQL är inte alls lika säker och går förmodligen på kort tid att knäcka med brute force.

[eg0master]

Ni måste göra skillnad på "kryptering" och "hashning" även om "hashning" även kallas envägskryptering.

Brute Force behöver vi inte överväga som knäckningsmetod då den slår lika hårt (eller snarare löst) mot båda metoderna.

Kryptering är däremot precis lika oseriöst som klartext i detta fall eftersom den som verkligen vill ha lösenorden sannolikt kan komma över era nyklar också (eftersom ni har nycklarna i era script för att kryptera/dekryptera) lösenordet.

Det är en korrekt iaktagelse att längden på nyckeln påverkar hur svårt det är att knäcka, men det är inte samma sak som att MD5 spottar ur sig 128 bitar. För längden på en MD5 hash talar bara om hur långt resultatet blir. Ett alternativ till MD5 är SHA1 som ger en hash på 160 bitar.

Att säga att "MD5 är bra för det är standard" är rätt, men att i samma mening säga att det är ett problem för det finns olika implementationer av MD5 är inte helt korrekt. Det finns en korrekt implementation och det finns massor av felaktiga implementationer som amatörer gjort själva istället för att använda ett riktigt bibliotek. Vitsen med en standard är ju att det inte finns några tvetydigheter...

Så avslutningsvis påstår jag att om man lagrar lösenord som inte är hashade (och då helst SHA1 eller möjligen MD5) så är man inte seriös. I en perfekt värld så hashar man dessutom på klienten och inte på servern. men det är inte nödvändigt om man kör https.