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: MacTommy | den 26 oktober 2011 Kl 12:30
Prio 1 skydda dig utifrån... SQL-injection, XSS och starka olika lösenord för den som administrerar sidans olika delar... Då har man kommit långt i ens egna säkerheten. Kommer du inte åt infot på de vanliga sättet med XSS-attacker, SQL-injection eller att man inte fångat upp lösenordet ifrån en hemsidas oskyddade databas... vad spelar det då för roll om det är hashat eller inte om man försvårat alla vägar in?

När alla dörrar är stängda så kommer lösenorden i databasen och känner man att man vill hasha och SALT:a så gör man det. Men man måste vara medveten om hur datorer kommunicerar och att mycket av kommunikationen sker "öppet" i någon ända och ju fler ställen man uppger samma inloggning så finns det risk att något olovligen tar sig in där de inte bör vara genom att man har tillgång till olika databser med olika inloggningsuppgifter. IT-säkerhets policy: Använd unika långa lösenord för alla ställen där det finns känsligt material att upphämta.

Styrk skalskyddet först. Man ställer inte in ett olåst skåp i en öppen obevakad lokal där det är fritt fram att hämta innehållet. Först ska det vara svårt att ta sig in i lokalen, sen gör man det svårare att nå innehållet i skåpet genom att göra en extra inlåsning t.ex. hashat lösenord. Men börja inte att safe:a upp sidan i fel ända.
Skriven av: elof | den 26 oktober 2011 Kl 12:54
Citerar MacTommy:

vad spelar det då för roll om det är hashat eller inte om man försvårat alla vägar in?


Jag blir änna mörkrädd över att ett sånt här uttalande kommer från någon som driver ASPsidan - och jag hoppas att du förstår varför det spelar roll.

Jag håller med om att man inte ska börja i fel ände med säkerheten, men jag håller inte med om att hash+salt är fel ände - snarare rätt, och jag hoppas verkligen att jag inte är den enda som tycker det.

Att inte lämna öppet för XSS och SQL-injektioner handlar ju om att programmera defensivt, men om någon olovlig väl kommer åt databasen (vilket kommer att hända om någon verkligen vill), så skulle jag känna mig som en ärkeidiot om jag lagrade lösenord i klartext. Det är ju bara urbota korkat.

[kompletterat username=elof datum=2011-10-26 12:59]Puttar in lite bra referenser,

http://stackoverflow.com/questions/326699/difference-between-hashing-a-password-and-encrypting-it

http://stackoverflow.com/questions/615704/preferred-method-of-storing-passwords-in-database

http://stackoverflow.com/questions/116684/what-algorithm-should-i-use-to-hash-passwords-into-my-database

http://stackoverflow.com/questions/829838/how-to-store-passwords-correctly

http://stackoverflow.com/questions/797626/is-using-a-salt-all-that-good

http://stackoverflow.com/questions/2999197/do-i-need-a-random-salt-once-per-password-or-only-once-per-database[/kompletterat]
Skriven av: MacTommy | den 26 oktober 2011 Kl 13:58
Jag är inte emot hash/MD5/kryptering och SALT på lösenord i databasen, men jag vill belysa att det finns många sätt att komma över lösenord, även om man har försvårat i databasen.

Kan man köra en enkel SQL-injection och få en lista på alla inloggningar och passwords så är det busenkelt att ta del av info. Skyddar man sig mot SQL-injection så måste man angripa sidan ifrån annat håll om den är tillräckligt intressant. XSS borde vara en snigelvariant att komma över mänder info eftersom den ligger på user-nivå alt. att admin har blivit XSS:ad och man visar för mycket info för admin. Här är det viktigt att man kan stänga av och visa en egen felsida så att inte felaktiga SQL-satsen exponeras då man kan få ta del av namn på tabeller och fält.

Jag tror att en hackare som är ute efter en viss information löser problemet och tar sig in på något sätt - oavsett sida. "Kalle" som vet hur SQL-injection funkar ger sig på alla sidor han hittar. Finns ett hål så nyttjar man det... finns det inte så drar man vidare. Jag tror inte att man står och stampar på t.ex. bloggtoppen.se och provar hacka om sidan varit skyddad mot SQL-injection... Då hade inte detta återkommande hysteri om spridda lösenord uppstått och att det ska hashas och SALT:as hit och dit. De som tillverkar och driver sidor måste bli mer medveten om vad man kan göra på en sida om man inte skyddat ev. vägar in.

Nu är det två olyckliga omständigheter med bloggtoppen.se 1) Sidan var troligtvis inte säkrad mot SQL-injection. 2) Människans lathet gör att man har samma inloggning på flera sidor.

Inget är 100% säkert, utan det tar bara olika lång tid att nå målet. För att kunna driva en säker site så måst man vara medveten hur kommunikationen funkar mellan client och server och vara medveten om att de flesta request sker på öppen lina.
Skriven av: MacTommy | den 26 oktober 2011 Kl 17:19
Måste komplettera lite mer... i en ny post för att det ska bli lättare att läsa.

Opponera att jag bygger "Plus"-sidan till Aftonbladet. För att få logga in där så måste ni lämna ut personnummer, namn, adress, epost och ev. kontokortsnummer för att det kostar pengar att få logga in och vi behöver ha koll på allt som skrivs på sidan.

Det är alla möjliga som vill ta del av Plus-sidorna... både Svennsons, kändisar och journalister.

Kontentan av påhoppen mot det jag säger ang. hachning av lösenorden är att det finns värre uppgifter i en databas som behöver skyddas. Uppgifter som behövs i klartext i vissa lägen för att ta betalt och för att säkerställa personens identitet. Lösenord behövs egentligen aldrig i klartext.

Jag börjar bygga min sida som är helt skyddad mot SQL-injection, XSS och jag har lagt världens säkraste lösenord med hash och SALT efter alla sidor uppmaningar på nätet. Jag får hela min sida SQL-injectad eftersom de har missat en sida på sport.aftonbladet.se sedan tidigare som då inte är skyddad mot SQL-injection och någon får ut hela databasens members-tabell... namn, epost, kontokortsnummer, personummer och då mitt fina hashade lösenord. Även om lösenordet är i klartext så finner jag det allvarligare att bli av med kontokortsnummer, personnumret, telefonnummer och adresser i en SQL-inject attack.

Fokus måste ligga på strukturen på databasen och fundera över säkerheten i en helhet mer än att sikta in sig på att lösenordet måste hashas till varje pris. Hur bygger man tabellerna, är det lämpligt att ha lösenord i samma tabell som membershiptabellen. Ska man ha en separat bara för telefonnummer, epost, kontokort m.m.? Eftersom vi har wildcard så behöver vi inte veta om fältens namn, utan enbart tabellen och då får vi ut allt i ett svep eller är det mer safe att JOIN:a tabllerna som behvös för att man inte ska behöva riskera att allt kan tömmas enkelt med att köra SELECT * FROM membership...

Ett lösenord är förändligt, men personnummer är svårare att byta... om man är känd så blir det jobbigt att flytta och alla personer i min databas epostadresser hamnar på en spam-lista som pumpar ut 100-tals mail i veckan. Telefonnummer sprids till höger och vänster på Flashback. Kontokort kan snabbt användas för att beställa varor innan någon fattat vad som hänt.

Varför hashar man ett lösenord i en databas? Av den enkla anledningen att man vet om att folk har samma lösenord på flera sidor. Hade man behövt använda hashade lösenord i en databas om t.ex. alla slumpade ut ett lösenord på 8 tecken till varje användare som inte går att byta och hela sidan är skyddad mot diverse attacker?
Skriven av: Elof | den 26 oktober 2011 Kl 19:17
Jag tycker du missar poängen helt och hållet, och skjuter väldigt mycket över målet.

Sen vill jag tillägga att om du ens har tanken på att spara ett kontonummer i en databas så blir du härmed tilldelad ett IG.

Diskussionen är kring lösenord. Vill du spara personuppgifter så har du ju ett helt uppslagsverk av regler du behöver följa. I frågan om man ska spara lösenord i klartext eller hashat så är svaret alltid hashat. Det är i princip inget extraarbete - så varför envisas?
Skriven av: MacTommy | den 26 oktober 2011 Kl 19:58
Citerar MacTommy:

Hade man behövt använda hashade lösenord i en databas om t.ex. alla slumpade ut ett lösenord på 8 tecken till varje användare som inte går att byta och hela sidan är skyddad mot diverse attacker?


Återigen så skickas de flesta request öppet där ingår lösenordet i klartext... Den som tillverkar en hemsida måste ta ett helhetsansvar och säkerställa alla delar, inte bara lösenordet. Det jag opponerar är just det att stirra sig blind på att lagra lösenordet hashat... Epost, telefonnummer m.m. kan likaväl vara illa om det kommer ut på Flashback.
Skriven av: mighty | den 26 oktober 2011 Kl 23:50
Självklart ska lösenord hashas och saltas. All inloggning med SSL.

Hur är det med lösenorden här på aspsidan?
Skriven av: MacTommy | den 27 oktober 2011 Kl 06:04
Citerar MacTommy:

Hade man behövt använda hashade lösenord i en databas om t.ex. alla slumpade ut ett lösenord på 8 tecken till varje användare som inte går att byta och hela sidan är skyddad mot diverse attacker?

Jag kommer ställa denna fråga om och om igen... tills det kommer ett vettigt svar...

Återigen så har jag inget emot hash och SALT av lösenord i databasen och driver flera små sidor där jag kör med hashade och SALT:ade lösenord. Men alla måste vara medveten att någonstans på väg till en inloggning så kommer användarnamn och lösenord att vara exponerade i klartext... oavsett om sidan heter Twitter, Facebook, ASPsidan eller Aftonbladet. Bara för att man slår sig på bröstet och säger att "Vi har hashat och SALT:at alla våra lösenord i databasen så är vi safe mot det som hände Bloggtoppen." så är inte lösenorden helt skyddade... Inte ens med en säker SSL-ansluten inloggning. Någonstans så kommer lösenordet synas i klartext för att vi ska kunna göra om det till ett hashat och SALT:at lösenord för att slå det mot databasen. Detta syns aldrig i disskusionen om varför man ska hasha och SALT:a ett lösenord i databasen och detta är den svagaste länken i kjedjan, förutom klantigheten att inte skydda sig mot SQL-injection och XSS.

Fråga nummer 2 som jag oxå gärna skulle vilja ha ett svar på...
Om bloggtoppen hade kört med parametiserande frågor mot databas, om bloggtoppen hade kört med XSS-skydd på sidan, om bloggtoppen hade kört med starka unika lösenord in på FTP eller DB. Hur stor chans hade det varit att någon kom över alla desas uppgifter på 2-3 dagar när man "har lite tid över" efter det man kan läsa i en intervju på Expressen.se?

Med den säkerheten så har man inte brytt sig eller så har man stor okunskap vad som krävs för att sidan ska vara säker och vad vissa saker kan ställa till med. Hade skalskyddet varit bättre så hade inte vi behövt läsa detta i tidnignarna eftersom vi aldrig hade fått reda på att de inte hade hashat och SALT:at lösenorden i databasen, utan det är bara de som har tillgång till inloggningskoden och db:n som vet om hur allt ser ut.

Jag har sniffat ett nätverk där man har en programvara med en säkerhetsnyckel liggandes på en USB-sticka på en server. Programvaran får installeras på vilka clienter som helst i nätverket och säkerhetsnyckeln håller reda på att det bara är x antal maskiner åt gången som har tillgång till att köra programmet. Sniffningen har inget med att ta reda på hur man kan kringå och köra fler maskiner, utan förstå varför programmet stannar 2sekunder varje minut. Säkerhetskollen är att den skickar en hashad sträng fram och tillbaka mellan server och client 50 gånger varje minut för att säkerställa att clienten har rätt att köra mjukvaran. Under kollen så låser man systemet som är helt idotiskt eftersom det går inte att jobba med en dator som låser sig 2 sek varje minut. Detta system skulle vara ohållbart för en inloggning på en sida, men den är knölig att bygga en egen servermjukvara som svarar på clientens fråga när det sker så pass många gånger och det är olika nycklar som skickas varje minut.

Det enda sättet att driva en sida med helt säkra lösenord är möjligheten att kunna autogenerera ett nytt lösenord för varje inloggning över en säker SSL-lina, typ inloggningen till Swedbank med säkerhetsdosa. Då har man säkert skalat bort mer än 99% av alla" hackare"... Men det skulle vara kostsamt att driva en liten sida om alla måste ha en säkerhetsdosa per site.

Driver man en "normal" sida så skydda er mot SQL-injection med parametisernade frågor, skydda er mot XSS, ha ett stark unikt lösenord in på FTP och till DB som ni inte använder på något annat ställe. Använd en egen felsida som visar ett allmänt fel och spara undan själva felkoderna så att ni kan läsa de själva... "It's for your eyes only"... Påtvinga era användera ett unikt anävndarnman och lösenord som inte kan ändras. Varje användare har nu en unik inloggning på sidan och ni har gjort ert för att driva sidan säkert. Att de använder samma slumpade lösenord på andra sidor är nu upp till varje användare. Sen får ni sjävla fundera på meningen med att hasha ett lösenord som ändå exponeras i klartext någonstans mellan client och server. Ja, jag hatar oxå dessa slumpade lösenord som inte går att byta... men det ger unika lösenord och kanske framtvingar att alla har minst 2 lösenord på internet.

Hur saker med säkerheten ser ut på ASPsidan så kommer jag enbart säga att nya versionen kör enbart med parametiserande frågor. Det är dumt att disskutera db-struktur och andra säkerhetsfrågor öppet, där det finns risk att man kan få påhälsning. Med C# så kollar jag även att ID:et som kommer in verkligen är ett tal innan det skickas vidare längre in i systemet eller till databasen. Det har jag haft som genomgående tanke för att slippa få ev. felmeddelande om man provar mata in tal istället för bokstäver och man får en klassisk error-sida exponerad där man inte har kontroll över vad som visas.

Vi har fått indikation på att folk försökt med SQL-injection på gamla sidan och det såg ut som om SQL-injection var möjlig när man kollade upp felmeddelandet. Men i koden så visade det sig att det inte var någon som helst risk. Enkelt, smart och genialiskt sätt att testa om sidan är exponerbar för SQL-injection som tar några få sekunder att köra på en sida.
Skriven av: vimpyboy | den 27 oktober 2011 Kl 14:03
Varför inte bara ha en egen felsida istället för att visa hela felmeddelandet? Kör RemoteOnly för customErrors så är den biten löst.

Vad gäller lösenord så ska de självklart hashas och saltas (om man nu verkligen måste lagra användarnamn och lösenord öht) - det är ingen idé att ens diskutera den saken då det är så självklart.

Skydda sig mot SQL Injections är busenkelt som ni alla vet. Det gäller bara att göra det. Problemet vad gäller SQL Injections på Aspsidan är alla gamla artiklar och scripts här som nybörjare tar del av. Jag ser inget alternativ än att helt och hållet rensa bort det som innehåller osäker kod.

När det kommer till XSS så finns det mängder av sätt att få in skadlig kod på. Använder man ASP.NET 4.5 så inkluderas Anti-Cross Site Scripting Library, och använder man en tidigare version av ASP.NET så kan man ladda ned det här:
http://www.microsoft.com/download/en/details.aspx?id=5242

Jag tog upp lite exempel med det här:
http://weblogs.asp.net/mikaelsoderstrom/archive/2010/05/09/skydda-dig-mot-xss.aspx

Använder man ASP.NET MVC är det dessutom enkelt att skydda sig mot CSRF:
http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Att skydda sig mot enbart XSS och SQL Injections är absolut inte säkert på något sätt. Ser man på när Spray blev hackat så gick det ut på att hackaren använde ett uppladdningsformulär för att ladda upp en php-fil som hämtade informationen från databasen. Det är ett klurigt sätt att lösa det på, men visar på att hur mycket man än tänker på säkerheten så kan det alltid gå att komma runt, och därför så måste man alltid skydda alla olika lager så gott det går (XSS, SQL Injections, hashade lösenord osv osv).

Att skippa något av stegen bara för att man tror att resten är säkert är en riktigt dålig lösning.
Skriven av: MacTommy | den 27 oktober 2011 Kl 20:20
Citerar MacTommy:

Hade man behövt använda hashade lösenord i en databas om t.ex. alla slumpade ut ett lösenord på 8 tecken till varje användare som inte går att byta och hela sidan är skyddad mot diverse attacker?


Idag hade jag en intressant diskussion med en konsult på jobbet. Där jag tog upp detta med att lösenordet på de flesta sidor är i klartext någonstans på vägen mellan clienten och servern och lösenorden aldrig är 100% säkra i databasen bara för att det är hashade och SALT:ade. Detta är det normala inloggnignsförfarandet när man kör med loginuppgifter i en vanlig request till servern... Helt öppet och en person kan alltid logga requesten för att få allt serverat i klartext innan det hashas. Det kan vi vara överens om att de flesta inloggningarna sker öppet i en request om man går igenom sidor på internet, även om lösenrodet är HASH:at i databasen. Right?

Han sa direkt varför skickas det öppet... utan tvekan. Varför hashar man inte lösenordet i clienten med JavaScript när man trycker submit och skickar över hela hassträngen som ett lösenord? Busenkelt, man kan även lägga till en checkbox som gör att man kan skicka lösenord i klartext om man vill om man skanar JavaScript. Detta kräver ändringar i databasen, men det är inget komplicerat.

Jag som har tillgång till kod och databas på en sida kommer aldrig att få ta del av lösenordet i något led om det hashas på clienten. Jag kommer åt hassträngen men inte själva lösenordet, SALT:et gör hassträngen unik för sidan. Lösenordet i databasen är hashsträngen som clienten skapat med deras egna lösenord, men användaren använder fortfarande kanske sina 6-20 tecken precis som vanligt.

Nu är frågan varför är detta inte är en standardlösning som ett normalt förfarande för inloggning på en sida oavsett storlek? Det kostar inget mer än tid och det är inget hokus pokus för användaren eller då den som tar emot information på servern, mer än att man slipper hasha och SALT:a ett lösenord i klartext. Det finns många exempel på nätet som är lätta att modifiera, såg nu att det även finns ett jQuery.SHA256-plugin att använda och då är det ännu simplare om man kan ta hand om saker med jQuery.

Nu kan till och med jag ändra mig och säga att lösenorden ska vara "skyddad" i databasen, för nu finns inte lösenordet i klartext mer än på clienten i dess sökruta och det är bara där den går att läsa och veta vad lösenordet är.

Detta är något som jag kommer att kolla på inom kort för ASPsidan och nya versionen att i nya versionen så kan man skapa ett client-hashat lösenord att använda med nya versionen för inloggning, om man kan logga in med JavaScript påslagen d.v.s.. Detta för att sidans medlemmar aldrig ska behöva exponera ett ev. lösenord oavsett vem det är som driver sidan i framtiden.

För Mickes del så hittar jag en variant som gör det enkelt att köra med Windows CardSpace på sidan i FF i framtiden så är koden redan klar att använda Windows CardSpace för inloggning. :)
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 3,9844 sekunder att ladda sidan