hash_equals - Ett feltänk?

PHPportalen Forum Index » Diskutera webbutveckling
Lägg ett bokmärke på hela tråden
Skapa nytt inlägg   Svara på inlägget
Visa föregående ämne :: Visa nästa ämne  
Startad av: Meddelande
harald_b
Moderator



Medlem i: 4234 dagar
Från: Tavesta
Status: Offline



#742049
Inlägg Skrivet: 2017-12-25 22:44      Ämne: hash_equals - Ett feltänk? Citera

I manualen för crypt() varnas det för timing attacks, och för att skydda sig mot sådana bör använda hash_equals() istället för vanlig strängjämförelse.
Vad jag kan se så handlar en timing attack om att man gissar lösenord och mäter svarstiden, och på så vis kan bedömma om lösenordet är nära eller långt ifrån det rätta.
Vid en vanlig strängjämförelse går det åt olika mycket tid när olika stor del av strängarna behöver testas för att se om de är olika. Men med hash_equals är tidsåtgången alltid den samma.

Jag har två invändningar mot den här tankegången.
Den första är att tidsåtgångskillnaden i strängjämförelsen totalt överskuggas av andra faktorer som påverkar svarstiden, och därför är en sådan här attack i praktiken allt för svår att genomföra.

Den andra, och mer avgörande invändningen är att en tidsåtgånsskillnad beroende på lösenordets likhet med det rätta lösenordet över huvud taget inte finns, eftersom det inte är lösenorden som jämförs, utan bara en hash på lösenordet. Om man lyckas hitta ett lösenord som genererar en hash har likheter med det rätta lösenordets hash så har man fortfarande inte kommit närmare det rätta lösenordet.

Vad jag kan se så finns det ett betydligt enklare och bättre sätt att skydda sig mot den här typen av attacker. Om fel användarnamn eller lösenord anges så kör man helt enkelt en sleep() på ett par sekunder. Eventuellt kan en något slumpad tid göra det ytterligare svårare.

Tänker jag rätt, eller har jag missat något?
 

_________________
R.r - Ett fritt affärssystem
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
simius



Medlem i: 4211 dagar
Från: Skåne
Status: Offline



#742050
Inlägg Skrivet: 2017-12-26 13:09      Ämne: Citera

Det låter ju väldigt skumt att det ska vara tidsskillnad. I så fall bör det ju ses som ett implementationsfel kan man ju tycka!
 

_________________
Lägger jag en bild här igen blir jag avstängd.
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida MSN Messenger
harald_b
Moderator



Medlem i: 4234 dagar
Från: Tavesta
Status: Offline



#742051
Inlägg Skrivet: 2017-12-26 15:28      Ämne: Citera

Tidsskillnaden i sig tycker jag inte är så skum, med tanke på att det räcker att leta upp första skillnaden mellan två strängar för att avgöra om de är lika eller inte, och första skillnaden kan finnas olika långt in i strängen.
Men i fall när det handlar om en lösenordshash som saltats med slumpat, okänt salt, så borde eventuella likheter i hashen uppträda på ett för utomstående slumpmässigt sätt.
 

_________________
R.r - Ett fritt affärssystem
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Peppe L-G



Medlem i: 3976 dagar
Från: Mullsjö
Status: Offline



#742052
Inlägg Skrivet: 2017-12-26 18:49      Ämne: Citera

Jag ser inte heller hur det där skulle öka säkerheten om man använder hasning + salt.

Jag förstår att om man inte använder salt så borde hackaren genom att använda en rainbow table och timing attacks lättare kunna lista ut användarens lösenord (hackaren lär sig början på hash-värdet och har färre alternativ i rainbow table att plocka från), men gör man rätt från början genom att använda salt så hamnar man ju aldrig i denna sits.
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande MSN Messenger
simius



Medlem i: 4211 dagar
Från: Skåne
Status: Offline



#742053
Inlägg Skrivet: 2017-12-26 22:01      Ämne: Citera

Missförstod det med tidsskillnad, läst igenom post/erna igen nu, hehe, sorry! Smile

Fördelen är väl att du inte behöver bygga din egen wrapper runt compare funktionen för att få den där extra tiden som man vill ha med en lösenords-hash. Klart att det kan funka med att du lägger en sleep på ett par sekunder eller liknande, men om du har en bra lösenordsalgoritm så tar den ju tid på sig, vilket gör att en brute-force attack tar längre tid.

Kommer dom över hashen så kan dom ju göra hur dom vill, detta handlar väl snarare om ett system so utsätts för bruteforce attacker.

Det är väl best practice att använda password_hash & password_verify av just den anledningen att folk inte orkar implementera ett skydd för timing attacks på dett sättet du beskriver (och då att de funktionerna använder starka algoritmer som bcrypt och argon).

Missförstod jag igen eller är jag på rätt spår nu? Razz
 

_________________
Lägger jag en bild här igen blir jag avstängd.
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida MSN Messenger
Wedge
Administratör



Medlem i: 5627 dagar
Från: Järfälla
Status: Offline



#742054
Inlägg Skrivet: 2017-12-27 12:05      Ämne: Citera

Det låter ju helt otroligt att det över Stora Stygga Nätet skulle gå att se ifall kod som exekveras med gigahertztickade processorer gör si eller så i en jämförelse på ett litet antal bytes.

Men man ska inte underskatta angripares nytta av information. Jag har jobbat med specialbyggda kryptoprocessorer som kastar in extra klockcykler slumpmässigt i sin instruktionsexekvering, ändrar sin egen strömförbrukning ibland etc. Tidsmönster, elektriska fält... allt ska slumpifieras så att en iakttagare inte skall bjudas på någon som helst information om vad som försigggår inuti processorn.
Till och med slumptal kan ge information, det finns mer eller mindre bra slumptalsalgoritmer Smile
 

_________________
I am Groot
Till toppen på sidan
Visa användarprofil Skicka privat meddelande MSN Messenger
harald_b
Moderator



Medlem i: 4234 dagar
Från: Tavesta
Status: Offline



#742055
Inlägg Skrivet: 2017-12-28 05:53      Ämne: Citera

Wedge skrev:
Det låter ju helt otroligt att det över Stora Stygga Nätet skulle gå att se ifall kod som exekveras med gigahertztickade processorer gör si eller så i en jämförelse på ett litet antal bytes.

Enligt redogörelsen här från 2009 så gick det att mäta i storleksordningen 20µs över internet. Utifrån mina tester med en dator som är äldre än så så skulle man behöva mäta upp tidskillnader på bråkdelar av nanosekunder ifall den ordinarie strängjämförelsen i php används.
Tilläggas kan att den ordinarie strängjämförelsen i php inte testar strängen byte för byte från början till slut, utan i block om 8 byte i omvänd ordning eller något däråt, vilket komplicerar saken.


Wedge skrev:
Men man ska inte underskatta angripares nytta av information. Jag har jobbat med specialbyggda kryptoprocessorer som kastar in extra klockcykler slumpmässigt i sin instruktionsexekvering, ändrar sin egen strömförbrukning ibland etc. Tidsmönster, elektriska fält... allt ska slumpifieras så att en iakttagare inte skall bjudas på någon som helst information om vad som försigggår inuti processorn.
Till och med slumptal kan ge information, det finns mer eller mindre bra slumptalsalgoritmer :)

Jo, det är ju en bra poäng.
Men tillsvidare är nog ändå min bedömning att informationen som i det här fallet skulle läcka ut inte borde vara användbar. Om den vore det så har vi flera andra problem med lösenordshashar att hantera.

Men hash_equals gör ju absolut ingen skada i det här fallet. Men om man däremot skulle använda den i ett sammanhang där risken med en timing-attack är mer uppenbar så kommer saken i ett annat läge. hash_equals är nämligen duktig på att avslöja om längden på det testade datat är rätt. Betydligt duktigare än phps ordinarie strängjämförelse.
 

_________________
R.r - Ett fritt affärssystem
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
harald_b
Moderator



Medlem i: 4234 dagar
Från: Tavesta
Status: Offline



#742056
Inlägg Skrivet: 2017-12-28 14:10      Ämne: Citera

simius skrev:
... Det är väl best practice att använda password_hash & password_verify av just den anledningen att folk inte orkar implementera ett skydd för timing attacks på dett sättet du beskriver (och då att de funktionerna använder starka algoritmer som bcrypt och argon).

Missförstod jag igen eller är jag på rätt spår nu? :P

Min invändning var att timing-attack i just detta fall inte borde vara ett verkligt hot.
Jo, de nya funktionerna är avsedda att ersätta crypt och hash_equals, vilket i någon mån gör den här frågan inaktuell. Men även password_verify lanseras också med argument att den har skydd mot timing-attack i just strängjämförelsen av lösenordshashen.
 

_________________
R.r - Ett fritt affärssystem
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Visa tidigare inlägg:   
Skapa nytt inlägg   Svara på inlägget
PHPportalen Forum Index » Diskutera webbutveckling
Hoppa till:  
Du kan inte skapa nya inlägg i det här forumet
Du kan inte svara på inlägg i det här forumet
Du kan inte ändra dina inlägg i det här forumet
Du kan inte ta bort dina inlägg i det här forumet
Du kan inte rösta i det här forumet
Du kan inte bifoga filer i detta forum
Du kan inte ladda ner filer från detta forum
Kontakta oss på adressen: info@phpportalen.net
Webbplatsen bygger i grunden på phpBB © 2001, 2002 phpBB Group

Modifieringar har senare gjorts i systemet av PHPportalen
Sid och logotypdesign skapad av Daren Jularic