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.