Fick detta mail imorse..

"ANSTALTEN HACKAD!

Vi fick idag veta att vi har blivit hackade. Alla lösenord har publicerats på Flashback´s forum, ni som har samma lösenord på andra sajter bör OMEDELBART byta dessa då risken finns att andra kommit över det lösenord ni haft på anstalten.

Vi har valt att stänga av sajten tills vi kommit till rätta med problemen och säkrat upp den.

Det är beklagligt att vi inte tidigare vidtagit åtgärder för att säkra upp sajten men vi jobbar just nu på att göra om lösenordshanteringen så att lösenorden väl krypterade.

Vi räknar med att vara uppe inom 24 timmar.

På grund av säkerhetsluckor i presentationerna har hackare lyckats använda skadlig kod, i den nya versionen kommer därför celleditorn att vara utbytt och html kommer inte att kunna användas lika fritt.

MVH
Anstalten.nu"

Tråkigt för dem :(

Var lösenorden i okrypterad form?

Alla lösenord är i klartext.

212677 rader med användare.

---

Även: http://www.gravbortskane.se/ blev hackad i gårkväll vad jag förstått.

bra jobbat av de som ägde siten, att nyhet efter nyhet läsa om alla communitys som blir hackade och har sina lösen i klartext, likt förbannat gör dom inget föräns det händer.

Jag gillar texten hackarna har lagt på http://www.gravbortskane.se/
Sansat klart och bra skrivet, vilket är ganska ovanligt.

Hehe, ja de va något nytt.

Och när vi ändå är igång så sprids cdon.se´s källkod på diverse forum nu också.

Nej det är ju normt idiotiskt. Faktum är att jag tillochmed börjad göra något innan det hände men inte gjorde det helt klart. Något som nu känns som om man kanske borde prioriteras.

Tyvärr är det ingen som jobbar aktivt med anstalten, jag har mer än fullt upp på annat håll.

Ett idiotiskt misstag som våra användare får betala för :(

En uppmanade till alla som läser tråden: Använd för fan krypterade lösenord.
Kan dock erkänna att jag själv kör 1 tjänst som är cleartext, men det är ingen publik tjänst och det gör jag av diverse anledningar och jag riskerar inte heller att 200.000+ användare får sitt lösenord läckt :)

Tråkigt.

Oj oj oj vad de kommer få spam nu från diverse aktörer.

Jag körde endast md5() på lösenorden på en ganska stor sajt.
Men när jag blev lite mer säkerhetsmedveten och byggde om till en svårare saltad hash så var det inte så svårt att göra denna övergång helt omärkbart och smärtfritt genom att låta nya hashen skapas när användare loggar in.. samtidigt som de gamla systemet fungerar. Efter en månad tog jag bort det gamla systemet bara och folk som inte ännu loggat in så ny hash skapas fick köra email reset password.

Det är väl så här det går när man enbart går in för att suga ut så mycket pengar som möjligt av sina (unga) användare. Och skiter totalt i sajten man driver i övrigt.

Hade gått att göra med ett tillfälligt script och en ny rad i databasen. När scriptet kört klart tar man helt enkelt bort det och den gamla raden med lösenord ur databasen. Det hade gått på någon minut och en del hade inte behövt återställa sina lösenord.

Bara ett tips :)

Till nästa gång så kan du göra så att deras tidigare md5-hash är deras "lösenord".
Dvs, du saltar om hela databasen med t ex:
md5(användarens tidigare lösenord som är md5 strängen + $salt).

När de då loggar in så blir det:
md5(md5(Inskrivet lösenord) + salt) som lösenord, så slipper du ha två system.

alla användare har nu en salt som är unik för användaren, lösenordet är md5(pass+salt), är detta vettigt?

Någon som har något bra tips på hur vi skall låta användarna byta lösenord, det voe ju dumt att släppa på dom md sina gamla...

Fyll i nick + email för att få ett mail med kod för att nollställa lösenordet? Eller finns det bättre föslag?

Förutsatt att lösenorden nu inte var hashade redan tidigare.
Om lösenorden som på Anstalten låg i klartext hade man som du säger bara gjort ett script som krypterade allt och ändra koden för login ^_^

Mycket smartare.. så långt tänkte inte jag. :rolleyes:

Nej, för om dom kommer över databasen, så kommer dom även över salten.
Bygg dina lösenord på både användarnamn, lösenord och salt.
På så sett kan en md5-hash aldrig bli lika dan, eftersom användarnamnet är unikt.
Salten är dessutom statisk för samtliga användare, och är inget som sparas i databasen utan hårdkodad.

Om de använder md5($pw . 'asd87asd9asdiuh213'); så bör väl det räcka?

Ofta hackkers knäcker den kombinationen, eller?

sant för om man har inte satt de på användarnamnet också så kan dom ju med hjälp av lösenordet se på ett ungefär vad hashen blir när de skrivit sitt lösen. och om man tillåter en bokstav i lösen så skapar dom ju bara några användare så har dom hash för varje bokstav :P

Jag är själv inte så duktig när det gäller detta område, men finns det ingen bra guide någonstans när det gäller att göra en super säker databas?

Om det fanns en sådan sida så hade ju alla använt den.

för hur många vet egentligen hur man gör en säker databas?

tydligen inte många.

Om du hashat lösenordet med md5 så går det inte att reversa. Det man kan göra är att testa olika kombinationer (t.ex. ord från en databas) och hasha dem för att sedan jämföra med det hashade lösenordet. Om hemsidan skippade saltet och du hittade en kombination som ger samma hash så skulle du kunna logga in, men inte om saltet finns med (jag förutsätter att saltet är okänt för hackaren) Observera dock att md5 inte är en injektiv funktion så bara för att md5(x) = md5($pswd) så har du inte att x = $pswd. Om du då använder x på en annan hemsida som inte använder md5 (eller samma salt) lär du inte komma in.

Still - vi säger att "Kalle" och "Petter" har samma lösenord, de får då även samma hash.
Vi säger också att en eventuell hackare kommer över databasen, och kommer över lösenordet för en hash - då kan han söka efter den hashen mot övriga användarnamn, och därmed veta att han har samma lösenord.
Mitt tips är, som jag tidigare hämde, att även slänga in ett dynamiskt värde som är unikt till användaren, vilket lämpligast är användarnamnet.

aah, har inte tänkt så.

Är det ingen sajt som drar in några vettiga pengar (i förhållande till arbetsinsats givetvis) och man inte har speciellt mycket tid och allt har fungerat fint fram tills dags dato så gör man inte något. Det handlar sällan om okunskap vilket alla flitigt påpekar gång gå gång.... De här diskussionerna börjar bli tjatiga och rejält långtråkiga....

Instämmer dock här då tror jag att det handlar om okunskap.
I början så gjorde man ju precis samma sak, dvs, körde allt i klartext.
Sedan lärde man ju sig md5(), och strax efter det så fick man reda på att det var ganska värdelöst vid diverse rainbow-tables, och då flyttade över till salt.
Genom då att tänka vidare lite så började jag pleta in deras användarnamn så att alla hashar är unika.

Dock så instämmer jag att tråden börjar bli tjatig och bör härmed låsas om ingen har något vettigt att säga om själva intrånget. ;)

Mja, att påstå att MD5 är ganska värdelöst är väl mer än en rejäl överdrift...?

Om man samtidigt har en policy som till exempel tvingar användaren att skapa lösenord med både gemena och versala bokstäver och en eller flera siffror och tvingar minst 8 tecken skulle jag gissa att du inte hittar mer än ett par av dessa lösenord i någon regnbågstabell i världen...

Men visst, med dessa tabeller kan man kanske få fram ett lösenord, men bara om användarna skapar väldigt simpla lösenord.

Möjligen, men jag gillar inte heller att "tvinga" användaren att använda ett annat lösenord än vad personen i fråga själv vill använda.
Då ser jag heller som jag påpekat massa gånger tidigare, en rejäl salt, och där användaren får ha precis vilket lösenord hon/han vill.

Vidare, om då användaren väljer att ha lösenordet "a", så är det sårbart mot dictionary/bruteforce attack (vilket man kan skydda sig via serverside).

Kommer angriparen åt källkoden så kan denne generera saltet själv eftersom han vet hur det är uppbyggt. Han väljer ut en administratör, skriver ihop ett bruteforce-skript som inkluderar saltet...
För att få det så säkert som möjligt ska man alltså hasha lösenord + unikt salt för varje användare, samt kräva ett starkt lösenord.

hur skulle en sådan kod se ut?


skulle vara schysst, bara att man ändrar på salten sen ju :)

och variabel för användarnamn?

man ska verkligen inte tvinga "EXTRA SÄKERT" lösenord!
det leder till att folk sparar dom på papper, browsers, i handflatan, glömmer av dom osv osv.
och det skapar stor irritation att man ska behöva kunna 30 olika lösenord till olika siter för alla har olika krav osv osv..
Själv är jag tvungen att kunna många olika svårknäckta lösen i huvudet men det är av egen fri vilja till mina egna saker.
Till andra siter drar jag mig för att använda 16+ tecken med minst 3 stora och minst 3 små tecken, minst 3 "special" tecken och sen en magisk symbol som ingen hittar..
Ork.
Salta+kryptering på säkert vis på serverside istället.

Det pratas ganska mycket om hur man ska skydda sig när någon har kommit över databasen. Men vad är det från första början som gör att någon kommer över databasen? Hur ska man skydda sig bäst mot sånt? Tänkte att det kanske är bättre att försöka stoppa folk redan i dörren och inte behöva kasta ut dem när de redan är inne, så att säga.

Självklart ska man även kryptera hit och dit i fall någon tar sig in. Men kan någon ta sig in och plocka ner databasen, så kan de säkert även ställa till med annat som man säkert vill stoppa?

Det där lät intressant. Har du några referenser för påståendet?

Min erfarenhet är att användarna inte gillar krångliga lösenord, däremot brukar dom acceptera att lösenordet måste vara ganska långt, åtta tecken.
Ett lösenord på åtta tecken är väldigt mycket mera svårforcerat än ett på enbart sex tecken. Det är alldeles för många som väljer lösenord i stil med "hej" eller "johan".

1. det är ganska logiskt. Folk stör sig på det och har svårt att minnas de olika lösenorden.
2. Jag har läst om det för bara ett år sedan ca. Skriver inte upp var jag hittar all info jag bara läser o minns ;).
Men google ger dig säkert svar.

Jag hatar siter som inte tillåter vettiga lösenord (dvs längdbegränsning, eller filtrering av tecken), och jag hatar siter som ställer annat än längdkrav. Stämmer inte mitt lösenord in på mallen så måste jag hitta på ett nytt lösenord, och sedan, utöver att komma ihåg det nya lösenordet utöver mitt vanliga, även komma ihåg på vilken site som jag har vad..

Jag kan stå som referens.

Trots att jag använder alfanumeriska lösenord blir jag ibland tvingad till att använda X antal tecken (antingen minimum eller MAXimum!), speciella karaktärer (och andra som INTE tillåter speciella karaktärer) eller t.o.m inte ens få byta mitt lösenord!

Det blir ganska snurrigt till slut.

Det sistnämda är helt sjukt, och gjort att jag varit tvungen att skriva ned lösenordet eftersom jag bara använder det på en sida, och kommer därför aldrig ihåg det.

har slutat att försöka komma ihåg alla lösen för länge sen... använder keepass till det numera vilket funkar bra.

Ska vi inte ta och börja hålla oss till ämnet?

Kryptera lagrade e-mailadresser, lösenordshashar och ev annan känslig information. Då blir en DB-dump inte särskilt användbar om man inte samtidigt kommer åt att läsa PHPn där kryptoknyckeln står. Eller så kan man lösa krypteringen och dekrypteringen med en stored procedure i SQLen som användaren PHP loggar in med inte har rättigheter att läsa, bara att köra.

Man kan även köra flera "omgångar" MD5 för att göra bruteforcning 'dyrare'.
md5(md5(md5(md5(...(pw|salt)...
Då går det helt plötsligt åt mycket mer CPU-tid för att cracka ett lösenord.

om man kör md5 i flera "omgångar" hur påverkar det prestandan för databasen/servern?