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: vimpyboy | den 28 oktober 2011 Kl 00:23
Windows CardSpace är på väg att fasas ut till fördel för andra säkerhetsprylar från Microsoft. Diskussionen vi hade om det var när "nya" Aspsidan faktiskt var ny för något år sen.. ;)

Varför inte göra det möjligt att koppla sitt konto mot t.ex. Twitter eller Facebook med hjälp av OAuth 2.0? Då sparar du bara en hash i databasen och kan omöjligt veta vad användaren har för lösenord (så länge som du inte hackar Facebook eller Twitter förstås ;)).
Skriven av: MacTommy | den 28 oktober 2011 Kl 06:37
Det är väl inga problem att använda sig av OAuth 2.0... Det blir ju en liknande lösning som för Windows Cardspace. Men... nu har jag inte sniffat hur inloggningen sker mot FB och Twitter... Skickar vi lösenordet med en "öppen" request eller har vi det hashat ifrån clienten?

Är det ohashat ifrån clienten så är vi åter där... Någonstans i våran fantasi så tror vi att lösenordet är helt säkert och vi litar på den som tar emot det att det är hashat i databasen. Men vad görs mer med requesten?

Windows Cardspace så slapp vi skicka en öppen request på lösenordet. Så det gillar jag mer... Men det är även så nu att vi måste börja fundera över hur vi bygger våra databaser där vi lagrar lösenord eftersom med dagens teknik så får vi mer möjligheter.

Nu gjorde jag en liten snabbtest på morgonen... La till jquery-1.6.4.min.js och jquery.sha256.min.js i min head och pillade ihop detta. Kod:
$(document).ready(function() {
  $('#loginBox input[type=submit]').click(function() {
  if ($("#hashPssword").attr('checked')) {
  var output = $.sha256($("#password").val());
  $("#password").val(output);
  }
  });
});


Jag har 2st input för login och password... och 2st checkboxar för autoinloggning och för att hasha lösenordet på clienten.

Om jag kryssmarkerar min hashPassword-checkbox så byts mitt lösenord till hash-sträng innan den skickas över till servern. Några få rader och vips så slipper vi ett "öppet" problem som alla är blinda för.

Varför är detta inte en standardlösning i lösenordsträsket? :)

Jag har inte lagt till något SALT och annat utan detta är en snabbtest...
Skriven av: Elof | den 28 oktober 2011 Kl 09:19
Problemet man inte kommer undan är ju att om man ändå sniffar requesten så visst, man ser bara en SHA256-hash av lösenordet. Men en illasinnad användare kan ju istället då skicka samma request, med samma lösenordshash, och komma åt kontot ändå. Annars är detta ju fördelaktigt.

Jag vet att mot Facebook så loggar man in via SSL (https://login.facebook.com), så där har vi ju inte det här problemet med klartextlösenord i requesten.
Skriven av: mactommy | den 28 oktober 2011 Kl 10:26
Men vi har fortfarande en "öppen" request för den som sitter på servern, även om det går via SSL. Att köra detta på clienten gör att vi som driver sidor aldrig får koll på en user riktiga kod och saltat gör så att detta unikt för varje sida. Vi kommer aldrig att sprida ett lösenord som nu kan användas om och om igen om SALT:et är olika från sida till sida.

Vi kommer aldrig komma förbi en sniffning, men vi kan med ett enkelt sätt gör så att man kan använda samma lösenord på nätet på ett enkelt sätt utan att den som driver vet det egentliga "korta" lösenordet.

Så med "min" lösning så är det onödigt att hasha min users lösen i databasen, eftersom medlemens lösen är redan hashat från clienten. Det hashade lösenordet blir klartext för mig... ;)

Man kan ju hasha det hashade lösenordet, men det känns lite overkill... eftersom det inte gör någon nytta. Så client-js-hash tillsammans med en SSL-anslutning så har vi kommit en bra bit på vägen att förhindra lösenordsspridningar.

[kompletterat username=MacTommy datum=2011-10-28 05:32]Nu har man suttit och lekt lite med Wireshark och sniffat nätverket hemma... Det är intressant och se var ungarna surfar... ;)

Kontenta... En inloggning till Twitter sker med SSL, en SSL-koppling mellan client och server har redan tagit form när jag fångat paketet i Wireshark. SSL är bra och ett måste för alla sidor som rimligen borde ha råd med ett SSL-certifikat.

Loggar jag in på webmailen på home.se som inte har SSL-anslutning så tar det mig 20sec att hitta mitt lösenord i klartext eftersom jag inte byggt ett filter. Det är inte så bra... Man skulle kunna tycka att home.se är en sida som borde ha lite högre säkerhet på inloggningarna eftersom de inte är ett litet hobby projekt. Behöver inte nämna ASPsidan och andra sidor i detta fall. ;)

Båda dessa sidor bör fånga upp requesten i klartext när den når webserver-programmet för att sedan hasha det hela. Den som har tillgång till en del kan således fånga upp det olovligen om man ha onda aningar och då kan det spridas vidare.

Genom att köra hashningen på clienten med JS SHA256 och ett SSL-certifikat så är det utom våran kontroll om ett lösenord i klartext kommer på villovägar. "Ingen" kan lyssna av det mellan client och server och vi som tar emot det hela vet inte vad för fras/ord som används hos clienten. Vi ser bara "användarens" lösenord som en mumbojumbo textsträng.

Vidare i tanken med konsulten så ställde han en fråga... Alla sidor som tillåter 6-20 tecken långt lösenord, är de hashade i databsen eller ej? Hur kan vi få reda på det?[/kompletterat]
Skriven av: vimpyboy | den 29 oktober 2011 Kl 02:26
När man loggar in via t.ex. Facebook så skickas man dit för själva inloggningen, du får sedan en sträng tillbaka med det du behöver veta för att logga in användaren - ungefär som med CardSpace. Du har själv ingen kontroll alls.

Så länge som det går att skriva ett lösenord så kan det läsas av någonstans (t.ex. en keylogger eller någon som stirrar över nacken), så det kan aldrig bli helt säkert.

Vill man vara ännu säkrare så får man se till att använda BankID eller liknande.
Skriven av: MacTommy | den 29 oktober 2011 Kl 07:42
Jag vet... men då ligger det på användaren att skydda sitt unika lösenord... inte på den som driver en sida.

När man loggar in på t.ex. Facebook så skickar man requesten på en SSL-anslutning, denna request genererar en sträng tillbaka. Men var plockar man upp lösenordet och gör det till en sträng? Jag kan inte se på varken Twitter eller Facebook när man kollar koden att den gör något med lösenordet på clienten. Återigen så har inte jag kontroll på vad som sker med mitt lösenord när den lämnar datorn. Beroende på vem det är som tar emot den på en SSL-lina så vet man inte vad det görs med den. Sidan ka byta ägare... no control...

Javasript igång, ett ramverk, ett plugin och 6st rader kod gör att användarna kan logga in med ett lösenord som enbart kan läsa av på användarens dator, mottagaren får ett 64 tecken långt lösenord som är SALT:at utan någon som helst aning om vad det är. Byter sidan ägare så kan man inte logga lösenordet i klartext. Om det är unika SALT på sidan så kan man använda "tallkotte" och logga in på Facebook, Twitter och bloggtoppen utan att webbsidorna har en aning om att man använder samma lösenord.

Är inte det lite skrämmande att med lite kod så går det lätt att skydda sitt lösenord redan på clienten? Den enda kostanden är tiden att implementera det hela, så att alla borde ha råd oavsett hur stor sidan är...
Skriven av: vimpyboy | den 10 november 2011 Kl 15:50
Även om lösenordet hashas på klienten så kan jag köra en keylogger på din dator, alternativt smuggla in ett JavaScript mha XSS som fångar upp alla inmatningar i formuläret och skickar iväg det till min egen sida.
Skriven av: MacTommy | den 10 november 2011 Kl 16:01
Jepp... men det sker på clienten och vad som sker på clienten kan du se med diverse olika verktyg...

Men det som jag gör på servern i den inkommande requesten är det ingen som har koll på... Hasha det på clienten så slipper sidägaren ta del av lösenord i klartext om man nu inte väljer att köra ett litet extra JS från servern som loggar det eller man har problem med XSS... Men lösenorden i databasen är skyddad om någon tar över sidan som inte har rent mjöl i påsen...

Men det är fortfarande löjligt enkelt att få lösenordet hashat på clienten innan det skickas över... även om allt går att ta reda på, på ena eller andra sättet...
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 0,6719 sekunder att ladda sidan