kryptera lösenord...

[ulrikajosefsson]

Jag bygger en sajt där man kan regga sig som användare och lagrar info om personen i mySQL-db. Vill på något sätt lagra lösenordet krypterat.

Vad jag förstår är md5 bäst/säkrast? Men det går väl inte att "kryptera upp" det? Anledningen till att jag vill göra detta är att användaren ska kunna ändra lösenord på en redigeringssida och när jag då hämtar lösenordet från db i en input-password-ruta är det ju många fler tecken än det verkliga lösenordet...

Om man ska kolla lösen vid inloggning måste man alltså köra md5 innan man jämför mot db? För visst är det så att md5 alltid returner samma sträng(?) på samma ord?

/ulrikajosefsson

 

[inlägget ändrat 2003-02-12 17:01:38 av ulrikajosefsson]

[dune]

Jag bygger en sajt där man kan regga sig som användare och lagrar info om personen i mySQL-db. Vill på något sätt lagra lösenordet krypterat.

Vad jag förstår är md5 bäst/säkrast? Men det går väl inte att "kryptera upp" det?

 

i mySQL finns en funktion som heter PASSWORD() som du kommer att ha nytta av. Det går inte att vända på proceduren så att du ur en md5-sträng kan få fram ursprungsvärdet, därför är md5 (och många andra algoritmer för den delen också) bra. Däremot går det fortfarande att använda metoden "brute-force" för att försöka knäcka lösenordet.

 

Anledningen till att jag vill göra detta är att användaren ska kunna ändra lösenord på en redigeringssida och när jag då hämtar lösenordet från db i en input-password-ruta är det ju många fler tecken än det verkliga lösenordet...

 

Om du kan vända på det så är det ju ingen mening med att kryptera det över huvud taget, inte sant?

 

Bättre att du låter användaren ange följande när han/hon skall byta lösenord:

 

Nytt lösenord, bekräfta nytt lösenord och det gamla lösenordet. På så sätt kan du göra en extra kontroll mot det gamla lösenordet innan du byter lösenord åt användaren.

 

Mer information om mySQL-funktionen PASSWORD hittar du tex här: http://www.mysql.com/doc/en/Miscellaneous_functions.html

 

Mer information om MD5 hittar du tex här: http://www.faqs.org/rfcs/rfc1321.html

 

 

.dune.

==============

Tempus fugit

 

[ulrikajosefsson]

Om du kan vända på det så är det ju ingen mening med att kryptera det över huvud taget, inte sant?

Jag tänkte närmast på att det ligger krypterat i databasen (det ska väl iofs vara svårt att ta sig in, men ändå)...

Förklara lite närmare hur du menar, är inte riktigt med på ditt sätt att tänka.

 

Bättre att du låter användaren ange följande när han/hon skall byta lösenord:

 

Nytt lösenord, bekräfta nytt lösenord och det gamla lösenordet. På så sätt kan du göra en extra kontroll mot det gamla lösenordet innan du byter lösenord åt användaren.

 

Bra idé. Tack för tipset. När jag gjorde min redigeringssida tänkte jag göra det så enkelt som möjligt för användarna. En ruta av password-typ där lösenordet står. Däri kan de skriva ett nytt.

 

[dune]

Jag tänkte närmast på att det ligger krypterat i databasen (det ska väl iofs vara svårt att ta sig in, men ändå)...

Förklara lite närmare hur du menar, är inte riktigt med på ditt sätt att tänka.

 

Såhär: Om det finns en möjlig, enkel funktion för att läsa ett krypterat lösenord till ett okrypterat så skulle ju inte lösenorden vara skyddade. Den som skulle komma åt din funktion skulle kunna läsa ut lösenorden lika lätt som att de var okrypterade.

 

... slutsatsen skulle då vara att det inte var någon poäng i att kryptera över huvud taget )

 

Bra idé. Tack för tipset. När jag gjorde min redigeringssida tänkte jag göra det så enkelt som möjligt för användarna. En ruta av password-typ där lösenordet står. Däri kan de skriva ett nytt.

 

För att ta in lite ytterligare ett par säkerhetsaspekter:

 

När du skickar ett lösenord till användaren (eller när användaren gör det till dig/webbsidan) så är informationen okrpyterad (förutsatt att du inte kör via en säker anslutning, något som förvånadsvärt få gör). Därför bör man om möjligt försöka skicka lösenord så få gånger som möjligt.

 

Om du skickar användaren en sida med ett lösenord i tex ett INPUT-fält så kommer denna sidan att lagras hos användaren i dess CACHE (förutsatt att webbläsaren skapar en cache, men det gör de flesta webbläsare idag) och om någon senare går in och letar i cachen så kommer de med rätt stor sannolikhet att kunna hitta detta lösenordet.

 

Att betänka när man jobbar med säkerhet så är det alltid ett motsatsförhållande mellan bekvämlighet och säkerhet. Att göra det bekvämt för dig som programmerare och för användarna innebär alltid att man måste trumma på säkerheten.

 

 

.dune.

==============

Tempus fugit

 

[ulrikajosefsson]

Ok. Nu är jag med.

 

Att betänka när man jobbar med säkerhet så är det alltid ett motsatsförhållande mellan bekvämlighet och säkerhet. Att göra det bekvämt för dig som programmerare och för användarna innebär alltid att man måste trumma på säkerheten.

 

Jo, det är ju alltid kompromisser man får jobba med. Känner att det här med säkerhet är något jag borde läsa på mycket mer om. Speciellt när det gäller inloggningssystem.

 

På tal om säkerhet, frågan passar väl kanske inte här, hur bygger man siter med https:// istället för http://. Vilka är skillnaderna och hur gör man? Är det någon speciell kod som behövs?

 

[dune]

På tal om säkerhet, frågan passar väl kanske inte här, hur bygger man siter med https:// istället för http://. Vilka är skillnaderna och hur gör man? Är det någon speciell kod som behövs?

 

Beroende på webbserver så är det alltid olika hur man går till väga men någon förändring för dig som programmerar dyker egentligen inte upp. Det är själva webbservern som skapar en krypterad anslutning till den dator/webbläsare som skall ta emot informationen.

 

Läs mer om webbservern Apache och SSL

http://httpd.apache.org/docs-2.0/ssl/ssl_intro.html

 

 

.dune.

==============

Tempus fugit