mboost-dp1
Apropos hashes
http://www.troyhunt.com/2012/06/our-password-hashi...
er ret interessant.
Den har en masse tekniske detaljer.
Jeg synes dog at han ikke forklarer helt tydeligt hvad han demonstrerer. Han viser ikke at SHA-2 hashes med salt af passwords can rigtigt brute forces. Han viser at SHA-2 hashes med salt af passwords som findes i password lister er nemme at finde med dagens hardware *og* at en stor del af brugere vælger passwords som findes i password lister.
er ret interessant.
Den har en masse tekniske detaljer.
Jeg synes dog at han ikke forklarer helt tydeligt hvad han demonstrerer. Han viser ikke at SHA-2 hashes med salt af passwords can rigtigt brute forces. Han viser at SHA-2 hashes med salt af passwords som findes i password lister er nemme at finde med dagens hardware *og* at en stor del af brugere vælger passwords som findes i password lister.
Det er interessant hvor mange hashes en GPU kan beregne i sekundet. Men en milliard hashes i sekundet er stadigvæk ikke nok til at bryde stærke passwords på begrænset tid.
Den mest interessante observation er hvor mange brugere, der vælger svage passwords. Og en salted hash er stadigvæk en god idé. Den flytter grænsen mellem svage og stærke passwords lidt, således at færre passwords bliver brudt.
Diskussionen omkring brug af langsommere hashfunktioner har nogle relevante pointer, men samtidigt kommer han også med udsagn, der er helt til grin.
Langsommere hashing er et kompromis. Det øger tidsforbruget for både legitim brug og angreb. Han påpeger desuden også, at dette skader legitim brug mere end angreb fordi angreb kan bruge specialiseret hardware, hvorimod legitim brug ofte er nødt til at køre på en normal CPU.
Til gengæld giver jeg ikke noget for hans påstand om at det ikke er et reelt problem.
Lad os lige huske, at for at nå op på 100 samtidige loginforsøg ikke behøver betyde 100 individer. Det kan være blot en enkelt person som udsætter dit site for et DoS angreb.
Det kræver ikke nogen særlig hurtig internetopkobling at sende 100 HTTP requests i sekundet.
Man kan forsøge at beskytte sig imod det ved at begrænse antallet af requests per IP adresse. Men et botnet med 10.000 computere kunne sende 100 requests i sekundet i næsten to minutter før der ville komme to requests fra samme IP adresse. Og det ville ikke engang bruge nogle resurser af betydning i botnettet. Sådan et botnet ville nok kunne drive tusindevis af websites i knæ samtidigt.
Hvor mange forsøg på at indtaste et korrekt password vil du mene en legitim bruger bør have? Jeg vil sige mindst tre forsøg før du overhovedet overvejer at blokere IP adressen. Så ville ovenstående scenarie betyde at angrebet kunne vare i fem minutter før serveren overhovedet begynder at blokere IP adresser.
Og brugere som forsøger at logge ind i løbet af de fem minutter vil nok opleve fejl og forsøge igen. Du kommer nemt til at blokere nogle legitime brugere i løbet af sådan et angreb.
Det er muligt at offloade noget af beregningen ved legitime logins til klienten. Jeg har lavet et proof of concept, men idéen bør undersøges mere grundigt før den bruges i praksis.
En anden metode er at justere antallet af iterationer afhængigt af styrken på passwordet. Estimer entropi af passwordet og sæt antal iterationer derefter. Lad være med at gemme estimatet i databasen, da det afslører noget om passwordet.
Det vil reducere resurseforbruget på serveren lidt, da du kun skal bruge det maksimale antal iterationer ved svage passwords. Og det giver brugere endnu en grund til at bruge stærke passwords. Jo længere password man bruger, des hurtigere kan man logge ind.
Den mest interessante observation er hvor mange brugere, der vælger svage passwords. Og en salted hash er stadigvæk en god idé. Den flytter grænsen mellem svage og stærke passwords lidt, således at færre passwords bliver brudt.
Diskussionen omkring brug af langsommere hashfunktioner har nogle relevante pointer, men samtidigt kommer han også med udsagn, der er helt til grin.
Langsommere hashing er et kompromis. Det øger tidsforbruget for både legitim brug og angreb. Han påpeger desuden også, at dette skader legitim brug mere end angreb fordi angreb kan bruge specialiseret hardware, hvorimod legitim brug ofte er nødt til at køre på en normal CPU.
Til gengæld giver jeg ikke noget for hans påstand om at det ikke er et reelt problem.
I would love to have this problem! Imagine the scale you need to reach to have 100 discrete individuals simultaneously attempting to hash a password via logon, registration or password change on a frequent basis – what a glorious problem to have!
Lad os lige huske, at for at nå op på 100 samtidige loginforsøg ikke behøver betyde 100 individer. Det kan være blot en enkelt person som udsætter dit site for et DoS angreb.
Det kræver ikke nogen særlig hurtig internetopkobling at sende 100 HTTP requests i sekundet.
Man kan forsøge at beskytte sig imod det ved at begrænse antallet af requests per IP adresse. Men et botnet med 10.000 computere kunne sende 100 requests i sekundet i næsten to minutter før der ville komme to requests fra samme IP adresse. Og det ville ikke engang bruge nogle resurser af betydning i botnettet. Sådan et botnet ville nok kunne drive tusindevis af websites i knæ samtidigt.
Hvor mange forsøg på at indtaste et korrekt password vil du mene en legitim bruger bør have? Jeg vil sige mindst tre forsøg før du overhovedet overvejer at blokere IP adressen. Så ville ovenstående scenarie betyde at angrebet kunne vare i fem minutter før serveren overhovedet begynder at blokere IP adresser.
Og brugere som forsøger at logge ind i løbet af de fem minutter vil nok opleve fejl og forsøge igen. Du kommer nemt til at blokere nogle legitime brugere i løbet af sådan et angreb.
Det er muligt at offloade noget af beregningen ved legitime logins til klienten. Jeg har lavet et proof of concept, men idéen bør undersøges mere grundigt før den bruges i praksis.
En anden metode er at justere antallet af iterationer afhængigt af styrken på passwordet. Estimer entropi af passwordet og sæt antal iterationer derefter. Lad være med at gemme estimatet i databasen, da det afslører noget om passwordet.
Det vil reducere resurseforbruget på serveren lidt, da du kun skal bruge det maksimale antal iterationer ved svage passwords. Og det giver brugere endnu en grund til at bruge stærke passwords. Jo længere password man bruger, des hurtigere kan man logge ind.
kasperd (4) skrev:Det er interessant hvor mange hashes en GPU kan beregne i sekundet. Men en milliard hashes i sekundet er stadigvæk ikke nok til at bryde stærke passwords på begrænset tid.
Den mest interessante observation er hvor mange brugere, der vælger svage passwords.
Og den konklusion for han slet ikke fremført ordentligt.
kasperd (4) skrev:Og en salted hash er stadigvæk en god idé.
Og der lykkes det ham næsten at konkludere det modsatte (og forkerte).
Windcape (2) skrev:Stort set enhvert [a-zA-Z0-9]{8} password kan findes i en password / hash liste i dag.
[a-zA-Z0-9]{8} = 218 GB alene for password liste med precis 8 og et salt.
Hvis du så tillægger et random salt af samme form: [a-zA-Z0-9]{8} bliver din størrelsen på din rainbowtable 4.76E16 GB alene for passwords på precis 8 karakterer. Dertil kommer hasherne ;-)
Jeg køber ikke din påstand.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund