Sök  
 
Skribent Inlägget Löst
Google
 
     

  Forum » ASP.NET 2.0 » Säkerheten i krypteratlösenord med membership  
 
Skriven av: Rivermen | den 25 oktober 2011 Kl 18:57
Säkerheten i krypteratlösenord med membership
Med tanken på den senaste händelsen mot bloggtoppen så kanske man ska ta en koll på hur säkert det egentligen är, det man har.

Jag kör med asp.net 2.0 membership och deras standard lösning med md5 kryptering men hur säkert är det egentligen? Vad mer kan man göra?

Antal svar 28



NAVIGERING: [1] 2 3
Skriven av: LordDaimos | den 25 oktober 2011 Kl 19:19
Lägg på något sorts salt så man inte enkelt kan slå upp det i ett dictionary. Du kan även lägga på egen manipulering i efterhand (kan vara något enkelt, typ byt plats på första och sista bokstaven) för att försvåra det ännu mer. I övrigt så är det ju att se till att folk inte får åtkomst till din databas via t.ex. sql injections eller andra säkerhetshål på din site.
Skriven av: MacTommy | den 25 oktober 2011 Kl 21:20
1) Skydda er mot SQL-injection. Använd alltid parametiserande frågor och inte klassikern "buggfix"...
2) Skydda er mot XSS.
3) Lås inloggningen efter 3st misslyckade inloggnignsförsök x antal minuter/timmar.
4) Välj unika starka lösenord på FTP och DB-inloggning till sidan och byt med jämna mellanrum.
5) Vill man ha autoinloggning spara en GUID kopplad till usern som byts vid varje ny inloggning. Tufft om man kommer över en cookie att veta vem den tillhör och om den är aktiv.

Fixar man detta så kan man skita i att MD5:a och salta lösenord i databasen... Det alla glömmer bort är att vi inte kör inloggningarna via en säker anlsutning. Allt som skickas mellan client och server skickas i klartext och här spelar det ingen roll hur säkra lösenorden är i databasen.

Ladda ner ett nätverkssnifffnings verktyg ifrån nätet och logga en unik dator och ni behöver inte vara några superhacker för att få tag på kollegans inloggningsuppgifter. Direkt när man fyller i inloggnings uppgifter så skickas det över till servern i ett helt vanligt anrop och detta kan enkelt läsas ner med ett sniffverktyg med filterfunktion. Dessa går även att ställa in att bara logga alla anrop ifrån dator 192.168.0.xxx som kör anrop mot port 80 för att inte behöva gå igenom allt för mycket data. Detta kan vi inte skydda oss från som driver sidor, men vi kan göra det tufft genom att stoppa alla ev. vägar in i systemet som gör att man kan få tag på en mängd data per gång. Tar lite tag att få tag på alla 90000 inloggningar på detta sätt med att sniffa trafik tillsammans med att man måste ha en dator inkopplad på "rätt" ställe.

En variant är att köra med Windows CardSpace eller liknande för inloggning. Nya verisionen av ASPsidan har jag lekt med Windows CardSpce för inloggning och det funkar bra i IE. Tog bort det för att jag inte hittade en bra lösning för att använda det i FF. Alla SQL-satser i nya versionen kör med parametiserande frågor om någon undrar.

För att hjälpa till i världen så tvinga användarna till att byta lösenord efter 1 månad... det gör att deras vanliga lösenord är nu förbrukat. Sen kan man tvinga att byta varje år, gärna lås alla gamla lösenord så man hela tiden tvingas till nya. Tvinga användarna att använda inte bara bokstäver och siffror, släng med lite specialtecken och ni har ställt till det för ev. "brute force"-attacker eftersom man måste gå på hela ASCII-tabellen. Genom att lägga till specialtecken så är oftast det vanliga lösenordet förbrukat då man inte normalt kör med "kalle123!", vissa gör det men långt ifrån alla. Tillåt aldrig användarna att bara lägga till åratal på slutet som oftast brukar vara lösningen på lösenordsträsket "kalle2011" och "kalle2012". Alla konton som har tillgång till hela userdatabsen måste ha ett starkt-lösenord, normal usern kan ha lite lättare.

Varför man ska skydda sig mot XSS är för att man enkelt kan med AJAX skicka inloggningen som skrivs in i klartext i input-rutor till sidan X och sen fortsätta med inloggningen där man är. Enkelt script som kan ställa till en hel del oreda om man inte skyddar sig mot XSS. Tänk på att WYSIWYG-editorer inte alltid är säkra mot XSS, därför har jag valt att behålla den gamla BB-code hantering för ett tag när man skriver inlägg på ASPsidan.
Skriven av: stefan | den 25 oktober 2011 Kl 22:31
Jag ger mig in i debatten och motsäger mig specialtecken! Titta här http://xkcd.com/936/
En jättebra förklaring tycker jag. Det är ett h**vete att hålla reda på alla konstiga lösenord, och med det där systemet kan jag dessutom på ett enkelt sätt ha samma lösenord på alla sajter, men ändå unika.

Låt oss säga att jag väljer tre ord istället för fyra, pansarvagn, leopardskinn och tomtebloss. Sen slänger jag in något unikt för varje sajt, så mitt lösenord på aspsidan blir pansarvagnaspsidanleopardskinntomtebloss
Bara små bokstäver, men jättelångt. Titta sedan på en sån här tabell: http://www.lockdown.co.uk/?pg=combi
Den talar om att ett lösenord med 20 små bokstäver tar 631 miljarder år att knäcka. Mitt lösenord är 40 tecken, så jag tror jag är ganska säker.

Sen håller jag med Tommy om att den stora faran ligger i hur våra inloggningsuppgifter dels skickas mellan klient och server, dels hur min inloggning hanteras på klienten. Det är därför det är viktigt att ha olika lösenord på alla tjänster. Jag skiter väl i om nån hackar mitt konto på aspsidan, men om det innebär att man kan logga in här, hitta min mejladress och logga in på mitt mejlkonto med samma uppgifter, då blir det läskigt. Mejlen är nyckeln till det mesta, så den vill vi absolut inte ska komma på vift.

Sen tycker jag att vi ska kryptera (om vi räknar in hash där) lösenorden i databasen, och jag tycker att hash och salt är en bra lösning. Detta för att inloggningsuppgifter inte ska komma på vift om databasen hamnar på villovägar.

Membership-providern erbjuder ett fullgott skydd, men det stora arbetet ligger i att lära användarna att använda starka lösenord, och olika på alla tjänster.
Skriven av: Elof | den 25 oktober 2011 Kl 22:32
MacTommy tar upp många bra punkter, men jag skulle vilja komplettera med lite egna erfarenheter.

Att tvinga användare att byta lösenord varje månad kommer att ställa till problem. Det är alldeles för ofta. Var tredje månad brukar fungera bra.

Att låsa ett konto efter tre felaktiga inloggningar kan bli jobbigt för användare som får sina konton låsta av någon som försöker ställa till bekymmer. Det är bättre att inte låsa några konton men istället logga ovanliga inloggningsförsök (där kan man ju räkna in tre misslyckade inloggningsförsök som något ovanligt). Om man verkligen vill låsa konton så gör det efter någon högre siffra, säg fem, och glöm inte att nollställa räknaren när inloggningen lyckats.

Om man går på spåret att inte låsa konton så kan man istället lägga till en fördröjning på ett par sekunder efter ett par felaktiga inloggningsförsök. Ju fler felaktiga försök desto längre fördröjning.

Specialtecken i lösenord i all ära, men jag föredrar att uppmana användare att välja ett långt lösenord. Fördelen är att det blir något användaren får lättare att minnas, t.ex kan ett sådant lösenord vara "mormors gröna tröja är stickad i storlek large". Om användare väljer något liknande som de själva kan relatera till så får dom mycket lättare att minnas sitt lösenord än om man tvingar fram t.ex "xY76!d#fg".

Om man har en "glömt lösenord"-länk (vilket man borde ha) så skicka inga lösenord till någons mailadress. Generera en länk med ett engångstoken som används för att ställa in sitt nya lösenord. Länken borde också bli ogiltig om den inte använts på säg 24 timmar.

Kör SSL för inloggningen så har du försvårat det väldigt mycket för någon att sniffa några lösenord.

Det är bara en dum idé att spara krypterade/klartext-lösenord. SHA256-hasha alla lösenord med ett unikt salt.
Skriven av: LordDaimos | den 26 oktober 2011 Kl 07:47
Har inte orkat läsa igenom hela tråden nu på morgonen men det du säger om att det inte är lönt att MD5a i databasen är ju helgalet MacTommy. Varför låta databasen vara vidöppen för avläsning bara för att man tror att resten av siten är säker, det är ju så många har fått sin användarinformation stulen. Nej säkerhet i alla led är det enda rätta, helt plötsligt så är det någon som gör någonting som man inte tänkt på (t.ex. snor lösenordet från en administratör och börjar peta runt i administratörsgränssnittet alternativt ftp) och sen får de alla användares information serverad på silverfat.
Skriven av: MacTommy | den 26 oktober 2011 Kl 09:01
Stefan... Ju fler tecken desto bättre... Har en kollega som hade möjlighet att köra med 64 tecken långt lösenord sin fickkalender... han glömde bort en del i lösenordet så var det bara att kasta skiten. Normalt om man kör med 6st tecken och väljer in ett speicaltecken gör att man måste "Brute forca" på hela ASCII-tabellen istället för klassikern a-z och 0-9 som de flesta lösenord har.... och 6st tecken med vanliga bokstäver och siffror går tämligen fort och därför måste man låsa inloggningen efter x antal misslyckade försök... men ju fler tecken desto längre tid och kör man 40 tecken inkl. specialtecken så borde det vara ännu fler kombinationer och ta ännu längre tid. Även om man inte måste, men att sidan har möjlighet att köra med specialtecken kommer nog ställa till de som funderar på "Brute force"-attacker.

Fortfarande så sker mestadels inloggningen helt öppen. Om jag driver bloggtoppen.se och MD5:ar alla lösenord och jag är seriös. Jag säljer sidan vidare till "Kalle", Kalle är inte seriös men han ser inte lösenorden i klartext i databasen. En enkel SQL vid inloggning gör att jag enkelt kan spara undan alla inloggningar och lösenord i klartext innan jag gör om lösenordet till MD5:at med SALT för att checka mot databasen. MD5:ade lösenordet är kass i databasen eftersom vi fortfarande leker med inloggnignar i klartext. Att skydda sidan mot SQL-injection och XSS och ha starka lösenord på databasen och FTP:n så ska det inte vara någon risk att informationen läcker. Gör den fortfarande så har man inte tillräckligt starka lösenord och man har missat att skydda vitala delar av sidan. När jag började bygga om ASPsidan så har jag kört stenhårt på parametiserande frågor mot databasen från början. Jag känner mig inte orolig för SQL-injection på nya sidan.

SSL är ett komplement, men man måste fundera på vad det är för sida man driver. Är det ett litet forum så kan det kännas overkill.

Jag menar inte att man ska byta lösenord 1gång per månad, utan efter en månad... sen kan det ligga flera år... Men just att man tar bort det "vanliga" lösenordet som alla använder efter 1månad kommer göra att man måste minst ha två grund lösenord.

Så att så länge vi jobbar med öppna linor så kommer vi alltid ha ha det mest sårbara när inloggning och lösenord skickas i klartext. Därför måste vi som driver sidor minst ha 3st inloggningar per site. Admin-login, FTP-login och DB-login... Dessa måste vara starka lösenord och man bör byta dessa minst en gång per år. Ju längre lösenord desto bättre. Enkel sak är att dubblera lösenordet... "kalle123" blir då "kalle123kalle123" och man går från 8 till 16 tecken enkelt och det kommer ta längre tid att "Brute forca"-lösenordet in i databasen eller in på FTP-kontot. Men man ska bara använda unika löseordet in på FTP/admin/db-kontot eftersom vi inte vet vilka sidor och hur bra skyddade de är.  

Känner en kristen kvinna. Hon tog en bibelcitat som lösenord, om man låtsas att Elofs text "mormors gröna tröja är stickad i storlek large"  är en bibeltcitat så var hennes lösenord "mgtasisl"... Först bokstaven i varje ord och man kan även ta en sångs refräng man tycker om. Ett lösenord som är mumbojumbo för den icke insatta, men kan man sången så har man lösenordet. Efter några månader tog hon en nytt bibelcitat och fick en liten andlig stund vid inloggningen. Så att det går att få till bra lösenord utan att behöva använda ord i SAOL.

Men sidan är aldrig säkrare än dess svagaste punkt.
Skriven av: elof | den 26 oktober 2011 Kl 10:09
Citerar MacTommy:

Fortfarande så sker mestadels inloggningen helt öppen. Om jag driver bloggtoppen.se och MD5:ar alla lösenord och jag är seriös. Jag säljer sidan vidare till "Kalle", Kalle är inte seriös men han ser inte lösenorden i klartext i databasen. En enkel SQL vid inloggning gör att jag enkelt kan spara undan alla inloggningar och lösenord i klartext innan jag gör om lösenordet till MD5:at med SALT för att checka mot databasen. MD5:ade lösenordet är kass i databasen eftersom vi fortfarande leker med inloggnignar i klartext.


Det måste vara den sämsta jämförelsen jag hört den här sidan av sommaren och du missar ju poängen med att hasha lösenorden. Det är väl självklart att den som äger koden, äger sidan, kan göra vad han vill med datan, och även lägga till skadlig kod. Bara för att den som redan driver sidan kan komma åt alla lösenord om han vill, så betyder det ju inte att man ska spara lösenord i klartext! Du saltar och hashar dina lösenord för att den som INTE äger sidan men ändå vill komma åt dina användares lösenord ska få det jobbigt.

Hur hade det sett ut om banken låste ytterdörren när de stängde, men lämnade alla bankfack öppna?

Sen håller jag inte med om att SSL är overkill. Släng upp en https://login.example.com och kör alla dina loginanrop dit. SSL är inte dyrt, ett certifikat kostar några hundralappar på GoDaddy. SSL drar inte nämnvärt mer processorkraft nu för tiden. SSL förhindrar att dina anrop skickas i klartext.

Jag känner också en kristen kvinna, och hennes lösenord blev brute-forcat långt innan den okristna kvinna jag känner som använde en lösenordsfras, och inte åtta helt vanliga gemener.

Det är väl klart att en applikation aldrig är säkrare en dess svagaste länk, men man behöver ju inte servera allt på ett smörgåsbord bara för att man är lat.

Här är en lista på punkter man bör följa om man någon gång sysslar med användaruppgifter,
* Hasha ALLA (inga undantag!) lösenord med salt. Gärna SHA256 - MD5 till lösenord är IG. Du ska aldrig kunna läsa dina användares lösenord.

* Om du har möjlighet, kör loginanropen via SSL.

* Ha ingen löjlig maxgräns för längden på lösenord. Lösenord/lösenordsfraser ska få vara hur långa de vill. Jag blir arg när jag ser "Ditt lösenord måste vara mellan 8-16 tecken"

* När en användare glömt sitt lösenord, generera en engångslänk (som också bara är giltig i 24 timmar) och maila ut länken till användaren.

* För att hindra att robotar försöker brute-forca någon stackars användares lösenord kan man till exempel visa en CAPTCHA efter tre misslyckade försök och/eller lägga till en fördröjning så att ett inloggningsförsök tar 3 sekunder.

* Ha aldrig någon "Security Question" för att låta en användare återställa sitt lösenord. IG.

* Till dig som administratör - använd olika lösenord för sajtlogin, FTP-login, SSH-login, databaslogin, osv. Du har ingen ursäkt. Det finns bra lösenordshanterare, men glöm för sjutton inte att använda ett STARKT lösenord till dessa, alternativt en Private Key (som du skyddar!).
Skriven av: Rivermen | den 26 oktober 2011 Kl 10:53
Tack för tipsen! Men vitsen med säker krypterad databas är väl ändå om datan eller databasen skulle få fötter. Spelar ju ingen större roll om webbsidan är fort-knox om till exempel leverantören/webbhotellet har har något säkerhetshål, hur lagras backuper? Vem har åtkomst till serverhallen (är väl säkert på de seriös leverantörerna men vem vet, kanske finns någon slarvig svensson där någonstans, som tar en genväg en fredag kväll....)

Men jag håller med att man ska göra allt för att motverka attacker enligt tipsen ovan! Men om det skulle ändå hända så vill man gärna att lösenorden ska vara skyddade!
Skriven av: MacTommy | den 26 oktober 2011 Kl 11:12
Jag är mycket väl medveten om varför man hashar och saltar. Men jag anser fortfarande att den svagaste länken är den som driver sidan och att allt skickas öppet mellan server och client. Hur man än vänder sig så kommer alltid en som driver sidan komma över dina inloggnignsuppgifter i alla lägen hur mycket man än säger att allt ska krypteras och SALT'as i databasen. Även en SSL anslutning gör att jag som driver sidan kan komma över dina inloggningsuppgifter på servern när jag tar emot anropet. XSS script på en sida gör att jag enkelt kan skicka vidare inloggningsuppgifter i en request till sidan X och fortsätta inloggningen. Kan vara så att SSL:en stoppar den typen av XSS-script... Har man känslig information så är SSL ett måste vid inloggning för att skydda requesten.

Att gå ut och säga att allt ska krypteras och SALT:as i databasen och tro att lösenorden är 100% safe är inte korrekt... Den kommer aldrig att bli safe beroende på vem det är som har tillgång till koden som tar emot requesten för inloggning eller har möjlighet att sniffa nätverket som requesten passerar. Det måste man alltid ha i bakhuvudet att krypterat och SALT är inte en total lösning i en databas för att skydda ett lösenord. Stärk skyddet i den svagaste länken, för det är där man slår till om man är smart. SQL-injection är en svag länk om sidan inte är skyddad, lättare än att "brute forca" databas inloggningen.

Visst man försvårar om någon kommer över inloggningen till databasen om allt är hashat och SALT:at, då har man antinge fått kontot "Brute forcat" eller så har man använt samma inloggning till andra sidor som blivit hackat eller att den som driver servern inhämtade uppgifterna olovligt. Lösning... välj ett långt och starkt lösenord och använd olika lösenord och se till att skydda mot SQL-injection och XSS. Använd SSL om sidan innehar känslig material. Kommer det upp att infot kommit ifrån sidan X så kan man med högt huvud säga att sidan är skyddad och lösenordet in i databsen är 20 tecken långt och bör ta x antal år att knäcka.

Som Stefan skriver "20 små bokstäver tar 631 miljarder år att knäcka"... Logga in på FTP och db med "kalle123kalle123kalle123kalle123" och din okrypterade databas bör vara safe för bruteforce attacker några år framöver. Byt lösenord varje år och det blir ett helvete om man väljer att inte köra med samma lösenord.

Om alla använder unika lösenord till sina inloggningar så är det inga problem med att ett lösenord kommer på villovägar eftersom den kommer bara in på sidan och inte mail, FB, Twitter o.s.v. och man slipper det som hände Bloggtoppen. Detta borde vara en policy som tidningar, partier och företag borde ta upp i dess IT-säkerhets policy. Använd aldrig samma inloggningsuppgifter till ställen med känslig information.

Den enda sidan som är 100% safe ligger på en dator som inte har några kablar anslutna, är avstängd och ingjuten i tonvis med betong tills någon tar bort betongen och kopplar in sladdarna.
Skriven av: elof | den 26 oktober 2011 Kl 12:04
Jag säger inte att man alltid kan vara 100% säker och skydda sig mot allt och inget. Men att låta bli att hasha och salta för att den som äger sidan ändå kommer åt uppgifterna är ju helt barrockt! Det är ju attacker utifrån man ska skydda sig mot!
NAVIGERING: [1] 2 3
 
     

  Svara på inlägg  
 
Du måste vara medlem på ASPsidan för att kunna skriva i forumet.
För att bli medlem klicka här.
 
     

  » Logga in  
 
Användarnamn

Lösenord

 
     

  » Bli medlem  
  Bli medlem på ASPsidan!  
     

     
  Microsoft  
     

  » Partners  
  Comsolvia  
     
  » ANNONS  
  ingen annons än  
     

  » Senast online  
  Endast för inloggade  
  Antal inloggade: 1  
     

Copyright © 2007 www.ASPsidan.se
ingen sponsrar längre ASPsidan med Dedikerad Server
ASPsidan RSS
   
 XHTML / CSS
Det tog 9,7500 sekunder att ladda sidan