Varför har FB inte HTTPS?

Som i rubriken: varför ger inte Flashback möjlighet till HTTPS för inloggning?

jag är också lite nyfiken på varför inte fler kör det
t ex. alla skumma små forum som diskuterar olagliga grejer borde ju vara intresserade

om jag förstått det rätt krypterar ssl informationen mellan sändare och mottagare hela vägen. hushmail kör det, tom gmail gör det väl nuförtiden? varför inte flashback? har det nån teknisk förklaring - typ att det är krävande för servrarna eller nåt?

I synnerhet borde man oroa sig om man loggar in från skola/arbetsplats/café eller så, då skickas lösenordet i klartext genom okänd utrustning. Därför bör man upprätta en VPN-anslutning mot hemmet när man skall logga in om man bryr sig om sin säkerhet.

Problemet här är vem som är mottagaren. När SSL används hos både hushmail och gmail för deras gmail webmailtjänster (men även för IMAP/POP/SMTP i en emailklient) är det deras servrar som är mottagarna -- huruvida SSL används mellan hushmail/gmail och emailets mottagares mailserver är inte lätt att få garantier för. Det är därför inte garanterat att emailet är krypterat hela vägen. För email bör man se SSL som en metod att dölja inloggningsuppgifter, inte mer.

I vilket fall så kommer SSL-krypteringen att avlägsnas hos din mailtjänst, så de kan se emailet i sin helhet. Har man varit duktig och använt Hushmails java-applet för att applicera GPG-kryptering på meddelandet så kommer detta att förbli dolt för Hushmail, men det gäller i lika hög grad gmail (och vilken emailtjänst som helst) om man själv krypterar meddelandet med lämplig programvara så att endast emailets mottagare kan dekryptera det, m.a.o. end-to-end-kryptering.

[quote=sEBbe85]varför inte flashback? har det nån teknisk förklaring - typ att det är krävande för servrarna eller nåt?
Resurserna som krävs för alla kryptografiska operationer som SSL genererar är ganska omfattande. Det skulle dock vara en poäng att göra deta vid inloggningen. Just nu verkar dock åtminstone lösenordet hashas vilket åtminstone är något, men eftersom människor har usla lösenord så kan de antagligen lätt knäckas med en dictionary-attack.

Man ska alltså tunnla hem den känsliga traffiken krypterat genom ett VPN för att sedan släppa lös den i klartext på Internet genom hemmets uppkoppling? Vad är poängen med det? Om tjänsten i fråga är utformad så att inloggningsuppgifterna skickas i klartext så är det så -- man kommer inte undan det (utan att vara absurd).

Eller syftar du på att logga in på någon tjänst i hemmets LAN? Då är VPN meningsfullt.

Jag är ingen admin här, men svaret är nog ganska enkelt. Det kräver mer resurser att hantera en SSL-session jämfört med en klartext dito. Med tanke på antalet samtidiga besökare på FB så handlar det nog bara om att sajten för närvarande inte har kapacitet att hantera det. Man brukar lösa detta med SSL-terminator/accelerator alternativt fler, kraftigare servrar.

En kostnadsfråga mao.

flashback's inloggningsystem
När du vill logga in på flashback finns det två stora säkerhetsförbättrningar gentemot andra communities. Dessa förbättringar gör att det fortfarande är relativt säkert att logga in på flashback.

Ni får gärna rätta mig om jag skrivit något som är felaktigt i detta inlägg, jag "vaknade" för 5 minuter sedan och sitter med laptopen i sängen. Känner att jag är lite seg.

• SSL över HTTPS (vid inloggning)
  Även om du kanske inte hinner märka det så skickas faktiskt användaruppgifterna över protokollet https när du vill logga in. Detta ska, enligt min erfarenhet, göra det mycket svårt (nästintill omöjligt) för någon att snappa upp vad du skrivit in och sedan göra om det till plaintext.
  
  
  Citat:

  Ursprungligen postat av flashback's webserver

  <form action="https://www.flashback.info/login.php" method="post" onsubmit="{...}">
  {...}
  </form>
  
  
• Lösenordet skickas som MD5, om du vill.
  Om du har javascript aktiveras kommer ditt lösenord (som plaintext) aldrig att lämna din dator överhuvudtaget. Istället körs en funktion som skapar en MD5-hash utifrån det lösenord du skrev in, och denna hash skickas med istället. Detta gör att om någon nu, mot förmodan, skulle sniffa dina uppgifter måste h*n även försöka knäcka hashen på diverse sätt. Har du ett start lösenord finns det ingenting du behöver oroa dig över med andra ord.
  
  
  Citat:

  Ursprungligen postat av flashback's webserver

  <form action="https://www.flashback.info/login.php" method="post" onsubmit="md5hash(vb_login_password, vb_login_md5password, vb_login_md5password_utf, 0)">
  
  {...}
  
  <input name="vb_login_md5password" type="hidden">
  <input name="vb_login_md5password_utf" type="hidden">
  </form>
  
  
• Sessioner, endast ditt IP
  Sessioner används för att webservern ska kunna spara specifika uppgifter om de användare som just nu befinner sig på webplatsen. En cookie-stealer snor session's nyckeln och hackern backom försöker sedan använda denna för att utge sig för att vara någon annan.
  
  På flashback går detta dessvärre inte eftersom den session's cookie som används är knuten till en specifik IP. Så om inte hackern i fråga sitter på samma lan som du, och även använder samma internetanslutning så att ni delar IP är du relativt säker.
  
  
  Citat:

  Ursprungligen postat av Administratör beng

  Citat:

  rätta mig om jag har fel men fb kakor är ej kopplade till ip
  

  Kakorna är inte kopplade till ett speciellt ip. Men sessionkakan är. Och det är den du behöver för att kunna "ta över en annan användare". Som det är nu kan du "bara" t.ex försöka lura användaren att ange sitt lösenord igen, t.ex i ett fält som attackern skapar.
  

Källor

• flashback.info + view source
  
• Xss-hål i Flashbacks Webchat - Sidan 3 - Flashback Forum

Man borde ju fortfarande kunna använda det uppsniffade hashet för att logga in, det används ju på samma sätt som ett lösenord. Men visst är det bättre än plaintext.

En ide vore ju att skapa ett hash av lösenord tillsammans med en timestamp. Så även om man har det uppsniffade hashen, så kommer man inte kunna använda den för att logga in senare.
Eller skulle det kunna tas runt på något sätt?

Tack för ett bra inlägg metapod.

Lite offtopic:
Säger man EN hash eller ETT hash?

En hash.

Detta betyder att FB lagrar osaltade MD5or eller klartextlösenord. Om de hade lagrat i något annat format, så skulle de inte kunnat avgöra om hashen verkligen är av det riktiga lösenordet. Förutsatt att javascriptet inte saltar innan den beräknar MD5-summan (jag har inte undersökt saken).

Angående idé

Menar du ungehär såhär?

• Webservern generar ett salt
  
  • Detta salt används i javascript-funktionen md5hash
    
  • Saltet sparas även i en session's varibel så att webservern kan använda det senare, denna sessions variabel skall endast vara valid i 5 minuter. (Vilket innebär att webservern måste genererar ett nytt salt var 5:e minut)
    
• Användaren försöker logga in, funktionen md5hash retunerar något som md5(salt.md5(password))
  
• Webservern jämför den hash som användaren skickade, med den hash som finns i databasen. Om de är lika får användaren behörighet till sidan ifråga.

Varje IP får alltså ett unikt salt, vilket gör det betydligt mycket svårare att knäcka hashen. Din idé kan faktiskt vara väldigt användbar om man vill skydda sina users från att bli sniffade, dock känns det lite lättare att använda sig utav protokollet https, precis som flashback gör.

Nackdelar
I skrivandets stund kan jag ej klura ut hur man ska göra med ovanstående metod om man även vill salta de hashes som finns i databasen.
Problemet ligger i följande:

• Information
  Hash #1 -> Method client: md5(salt.password)
  Hash #2 -> Method database: md5(salt.md5(password)
  
  
• Frågeställning
  Hur ska vi kunna manipulera hash #1 så att den matchar hash #2?

Om vi struntar i metoden ovan, och endast MD5ar lösenordet kan vi kolla om det är rätt på det sätt som finns nedan.
Psuedo kod:

Hoppas du förstår ungefär hur jag menar, antar att min beskrivning är något luddig men vill du veta mer om hur jag tänker så fråga gärna.

Bevis?

Ovanstående text tror jag är felaktig, du har inga bevis för att flashback lagrar användares lösenord utan att salta dem. Skrev ihop lite PHP-kod för att bevisa att man självklart kan använda en md5-hash som kommer från en användare när man kollar om det är rätt lösenord.

Nedan följer den PHP-kod som är näst intill onödig eftersom jag inte ser någon som helst teori som stödjer det ouverte nämnde ovan.

Som det ser ut nu skulle inte det hjälpa att ha https vid inloggning då lösenordshashen skickas titt som tätt i en sessioncookie.

Precis som Metapod tog upp så är detta inte säkert. De kan lagra lösenordet hashat, låt oss säga 1000 gånger. Eftersom din webbläsare hashar det en gång innan den skickar iväg det, så behöver servern bara hasha det 999 gånger till, och sedan jämföra det mot det sparade värdet, exempelvis.

Jag har för mig att vBulletin kör med det klassiska MD5( MD5($pass) + $salt ), och om detta är fallet med Flashback så har klientsidan redan utfört ett steg i operationen, och på serversidan får du istället: MD5( $senthash + $salt ), för att sedan jämföra detta med det som ligger lagrat i databasen.