mboost-dp1
Anonymous
For 2-3 år siden lukkede jeg min Paypal account, fordi de ikke understøttede OpenID og jeg ikke turde bruge samme password på en betalingsside som Paypal som jeg brugte andre steder og jeg samtidig vidste at hvis ikke jeg brugte samme password som andre steder, ville jeg ikke have en chance for at huske passwordet.
Det må være på tide at websider holder op med at kræve brugernavn og password fra deres brugere og samtidig forventer at disse er unikke, så de ikke kan være brugt på andre sider.
Hvis alle websider i stedet tilbød OpenID, så ville jeg kun have brug for et enkelt brugernavn og password og websites med dårlig sikkerhed ville ikke kunne have mit password liggende, således at andre kunne stjæle det.
Det må være på tide at websider holder op med at kræve brugernavn og password fra deres brugere og samtidig forventer at disse er unikke, så de ikke kan være brugt på andre sider.
Hvis alle websider i stedet tilbød OpenID, så ville jeg kun have brug for et enkelt brugernavn og password og websites med dårlig sikkerhed ville ikke kunne have mit password liggende, således at andre kunne stjæle det.
AzCii (1) skrev:5. November ER Guy Fawkes dag, det er ikke noget Anonymous har udråbt den til.
5. november 1605 - Guy Fawkes og flere andre bliver taget på fersk gerning i færd med at gøre klar til at sprænge Parlamentet i luften i England.
En dag der er fuldstændig misforstået. Guy Fawkes var ikke revolutionær. Han var en gemen slambdert der bare ville have mere magt. Pointen ved deres lille stunt var at bane vejen for en kongefamilie de kunne styre.
Det er også derfor man i England brænder ham af den 5. november. Man hverken mindes eller ærer ham.
Guy Fawkes var alt det Anonymous kæmper imod. Desværre har mange et forkert indtryk efter at have set V for vendetta
Mort (2) skrev:For 2-3 år siden lukkede jeg min Paypal account, fordi de ikke understøttede OpenID og jeg ikke turde bruge samme password på en betalingsside som Paypal som jeg brugte andre steder og jeg samtidig vidste at hvis ikke jeg brugte samme password som andre steder, ville jeg ikke have en chance for at huske passwordet.
Det må være på tide at websider holder op med at kræve brugernavn og password fra deres brugere og samtidig forventer at disse er unikke, så de ikke kan være brugt på andre sider.
Hvis alle websider i stedet tilbød OpenID, så ville jeg kun have brug for et enkelt brugernavn og password og websites med dårlig sikkerhed ville ikke kunne have mit password liggende, således at andre kunne stjæle det.
Så du mener det er bedre at have 1! site til at stå for verdens sikkerhed med passwords, lyder til at det vil være ret oplagt at angribe for hackere da de kun skal kunne komme igennem 1 gang og vupti du har millioner af passwords til ALLE brugere, Så hellere noget ala lastpass som kan generere unikke koder og hvor du kan vælge at lagre passwords lokalt.
Unbound (5) skrev:#3
Guy Fawkes var en syndebuk, han var bare civilist, hvor hovedparten af de andre var adelige.
det gør ikke hans eller hans kumpaners motiv mere ædelt.
Det kan godt være Guido Fawkes ikke var adelig, men han besad en stilling umiddelbart under en. Han manglede hverken magt, penge eller uddannelse. I øvrigt en dekoreret kaptajn i hæren.
Han var klog nok til at vide hvad han havde gang i, hvilke motiver de andre havde og hvad han ville få ud af det.
f-style (4) skrev:Så du mener det er bedre at have 1! site til at stå for verdens sikkerhed med passwords, lyder til at det vil være ret oplagt at angribe for hackere da de kun skal kunne komme igennem 1 gang og vupti du har millioner af passwords til ALLE brugere, Så hellere noget ala lastpass som kan generere unikke koder og hvor du kan vælge at lagre passwords lokalt.
Ja, jeg mener det er bedre at 1 site, som jeg stoler på, står for alle mine passwords.
Der er mindre risiko for at hackere kan bryde ind i mit ene site end at de kan bryde ind i et af de 30 websites som jeg benytter, hvor jeg bruger samme brugernavn og password, fordi det er den eneste chance jeg har for at huske passwordet.
Derudover så har jeg med OpenID selv mulighed for at vælge hvilken sikkerhedsmetode som jeg mener er den rigtige. Lige nu bruger jeg Google, som har en 2 faktor authentication, som gør at hackeren både skal have mit brugernavn, password og min mobiltelefon, for at kunne få adgang til min konto.
Det undrer mig at paypal trods alt ikke udsender en officiel meddelelse. Jeg vil da gerne vide med sikkerhed om min konto er blevet hacket eller ej.
Ja, i England fejrer man at han mislykkedes og at kongen overlevede, men I de tidligere kolonier Australien og New Zealand blev traditionen lettere misforstået, så dér drikker de sig bare stive og sætter ild til ting uden nogen egenlig grund. Den manglende historieundervisning gør at dagen blandt unge er set som en hyldest til anarki.
mfriis (3) skrev:
Det er også derfor man i England brænder ham af den 5. november. Man hverken mindes eller ærer ham.
Ja, i England fejrer man at han mislykkedes og at kongen overlevede, men I de tidligere kolonier Australien og New Zealand blev traditionen lettere misforstået, så dér drikker de sig bare stive og sætter ild til ting uden nogen egenlig grund. Den manglende historieundervisning gør at dagen blandt unge er set som en hyldest til anarki.
f-style (4) skrev:Så du mener det er bedre at have 1! site til at stå for verdens sikkerhed med passwords, lyder til at det vil være ret oplagt at angribe for hackere da de kun skal kunne komme igennem 1 gang og vupti du har millioner af passwords til ALLE brugere, Så hellere noget ala lastpass som kan generere unikke koder og hvor du kan vælge at lagre passwords lokalt.
Uh uh, jeg har en ide!
Hvad nu hvis vi laver private og offentlige nøgler, som vi lægger på samme lokation der er sikker? Så vi slipper for at brugeren kan komme til at give sin nøgle og kode ud?
Og hvis vi så også laver noget smart java-fis til at authenticate med, så kan vi jo tjekke op på ting på brugerens computer i samme omgang?
For at det er sikkert, bruger vi selvfølgelig engangskoder på et stykke pap - for folk stoler på engangskoder på papir - og hvis folk stoler på det, så er det jo per definition sikkert, ikke?
Hvad synes i om min originale ide, jeg lige har fået?!? :-D
Aaaah - Anonymous. Gad vide hvornår de indser, at det ikke just giver dem flere tilhængere at frigive sensitiv information?
Come on - hvor svært kan det da være for "legionen" at indse, at vejen til bedre datasikkerhed ikke just er at smide masser af sensitive oplysninger ud på nettet, så Allah og hver mand kan misbruge det?
Come on - hvor svært kan det da være for "legionen" at indse, at vejen til bedre datasikkerhed ikke just er at smide masser af sensitive oplysninger ud på nettet, så Allah og hver mand kan misbruge det?
Lars.dk (6) skrev:Anonymous er til grin en flok retaderet som ikke passer ind i et normalt samfund og så skaber de sig på nettet.
Det er ikke pænt at kalde andre retarderet når man ikke selv kan stave til det. Og indsæt den sædvanlige reminder om at enhver idiot kan kalde sig anonym og derved har termet "anonymous" ingen substans som en gruppe/instans/bevægelse.
Hvis man har skaffet sig sådan en liste over passwords, så kan man nemt offentliggøre dem i en sådan form at brugere selv kan undersøge om deres password er på listen, men den offentliggjorte liste kan ikke bruges til at logge på sitet.
Det kræver faktisk blot at man tager de passwords man har skaffet sig adgang til og beregner en saltet hash.
Jeg har selv konstrueret proof of concept kode til at gøre ovenstående, og anvendt det på et par lister af passwords som andre allerede havde lækket på nettet.
Hvis målet er at demonstrere et sites usikkerhed uden at ramme de enkelte brugere, så er ovenstående metode brugbar.
Samtidigt kan brugere få definitivt bevis for at deres eget password er lækket, og hvis nok brugere kan bevidne at deres eget password er lækket, så kan usikkerheden af sitet betragtes som værende dokumenteret.
Med den rette brug af kryptografi i protokollen (zero-knowledge og sigma protokoller) kan man faktisk bruge samme password til alle sites uden at det udgør et problem for sikkerheden.
Jeg så intet i filmen som klart pegede på den ene eller den anden fortolkning.
På den DVD med ekstramateriale som fulgte med filmen er en 10 minutters gennemgang af noget mere af baggrunden. Af den gennemgang fremgår det at komplottet var en reaktion på styrets undertrykkelse af en religiøs minoritet.
Det kræver faktisk blot at man tager de passwords man har skaffet sig adgang til og beregner en saltet hash.
Jeg har selv konstrueret proof of concept kode til at gøre ovenstående, og anvendt det på et par lister af passwords som andre allerede havde lækket på nettet.
Hvis målet er at demonstrere et sites usikkerhed uden at ramme de enkelte brugere, så er ovenstående metode brugbar.
Samtidigt kan brugere få definitivt bevis for at deres eget password er lækket, og hvis nok brugere kan bevidne at deres eget password er lækket, så kan usikkerheden af sitet betragtes som værende dokumenteret.
Enig. Men jeg mener ikke at OpenID er løsningen. Jeg mener at der er langt bedre løsninger end OpenID, men de kræver en lille tilføjelse til http protokollen.Mort (2) skrev:Det må være på tide at websider holder op med at kræve brugernavn og password fra deres brugere og samtidig forventer at disse er unikke, så de ikke kan være brugt på andre sider.
Med den rette brug af kryptografi i protokollen (zero-knowledge og sigma protokoller) kan man faktisk bruge samme password til alle sites uden at det udgør et problem for sikkerheden.
Jeg mener ikke at filmen giver nogen klar skildring af Guy Fawkes. Han kunne ses som en frihedskæmper, men han kunne lige så vel være en korrupt mand der forsøgte at misbruge en idé. Idéen levede videre og kunne bruges til et nobelt formål selvom manden der oprindeligt havde den var korrupt.mfriis (3) skrev:Desværre har mange et forkert indtryk efter at have set V for vendetta
Jeg så intet i filmen som klart pegede på den ene eller den anden fortolkning.
På den DVD med ekstramateriale som fulgte med filmen er en 10 minutters gennemgang af noget mere af baggrunden. Af den gennemgang fremgår det at komplottet var en reaktion på styrets undertrykkelse af en religiøs minoritet.
1000tusind (10) skrev:I de tidligere kolonier Australien og New Zealand blev traditionen lettere misforstået, så dér drikker de sig bare stive og sætter ild til ting uden nogen egenlig grund. Den manglende historieundervisning gør at dagen blandt unge er set som en hyldest til anarki.
Lidt lige som når folk fejrer påske og pinse her i landet
#17: Eller nytår i Ecuador :P
(seriøst, det ligner at der er oprør...)
Generelt er det vel som så ikke uden fortilfælde at et egenkærligt forsøg på berigelse ender "galt", medfører en legende og ellers fortolkes grueligt skævt af historien, grundet udfaldet og folks fortolkning?
(seriøst, det ligner at der er oprør...)
kasperd (16) skrev:Idéen levede videre og kunne bruges til et nobelt formål selvom manden der oprindeligt havde den var korrupt.
Generelt er det vel som så ikke uden fortilfælde at et egenkærligt forsøg på berigelse ender "galt", medfører en legende og ellers fortolkes grueligt skævt af historien, grundet udfaldet og folks fortolkning?
#16 Jeg ville ikke uden videre opgive min kode og bruger til et fremmed site, så det kunne "tjekke" om den allerede var i databasen. Så den metode er heller ikke helt hensigtsmæssig. Men jeg er enig, der er klart bedre måde at fortælle om en sides dårlige sikkerhed, end at offentliggøre dens data, ombefattet kodeord og telefonnumre.
Magten (20) skrev:Jeg kan umiddelbart ikke finde et eneste site jeg ville stole så meget på.
Det er jo en af de smukke ting ved OpenID. Det er op til hver enkelt bruger hvordan de vil have deres login løsning.
Hvis du foretrækker at have 20 forskellige login providers, så har du mulighed for det.
Hvis jeg foretrækker samme provider og samme account, så har jeg mulighed for det.
Lige meget hvilken løsning vi vælger, så skal websitet kun lave een OpenID løsning, hvilket vil virke for alle OpenID providers.
Det var så sandelig heller ikke den metode jeg beskrev. Man tager den komplete liste af lækkede passwords og for hvert password på den liste vælger man et (psuedo)tilfældigt salt og hasher passwordet med det pågældende salt. Så frigiver man hele listen af saltede og hashede passwords så alle kan downloade dem.bjerh (19) skrev:Jeg ville ikke uden videre opgive min kode og bruger til et fremmed site, så det kunne "tjekke" om den allerede var i databasen. Så den metode er heller ikke helt hensigtsmæssig.
Hvis du vil undersøge om dit password er på listen sender du intet til serveren. Derimod gennemløber du listen og for hver eneste linje i listen beregner du og sammenligner hashværdierne på din egen computer. Det tager nok en times tid at gennemføre denne beregning. Den kode man skal køre for at søge efter sit eget password i listen er ganske simpelt og selvfølgelig stilles kildekoden til rådighed.
Ja, andre kunne i teorien prøve at lave brute force på den hashede udgave. Men det ville være meget omfattende beregningsmæssigt. Passwords er altså langt bedre beskyttet i den offentliggjorte udgave end i den oprindeligt lækkede udgave. Og såfremt det lykkes at bryde nogle få af de svageste passwords, så mangler man stadigvæk at finde ud af, hvilke brugere de er til.
Du opretter ikke 20 providers, du opretter en konto hos hver af de 20 providers, eller opretter 20 konti hos een provider, hvis det er det du er ude efter.
Der findes masser af OpenID providers, det er bare at google efter dem. Jeg er sikker på at hver af dem har en forklaring på hvordan du opretter en konto hos dem.
Der findes masser af OpenID providers, det er bare at google efter dem. Jeg er sikker på at hver af dem har en forklaring på hvordan du opretter en konto hos dem.
Magten (27) skrev:Så har jeg 20 forskellige logins, så jeg slipper for at have 20 forskellige logins? :P
Nej, det var dig som ville have 20 forskellige logins, fordi du var bange for at et enkelt login var lettere at misbruge.
Hvis du vil have 20 forskellige logins, så har du fri mulighed for det, med OpenID. Hvis jeg kun vil have et enkelt login, så kan jeg få det med OpenID.
OpenID giver hver enkelt mulighed for at få deres login løsning som de bedst kan lide den, i stedet for blive tvunget til at huske 20 forskellige logins og kodeord.
Nej, der er ikke nogen grund til at bruge OpenID, hvis du kun vil opfylde dit eget behov, for at have det samme brugernavn og password spredt ud over 20 forskellige websider.
Behovet opstår når nogen af os ikke bryder os om at hvert website vi bruger skal have sit eget brugernavn og password og godt ved at eneste chance for at det kommer til at ske er at genbruge brugernavn og password på disse sites.
Hvis et af disse sites så har dårlig sikkerhed (Og det har historien lært os at det har de) så kan brugernavn og password bruges på på alle de andre websites vi ellers har genbrugt det brugernavn og password.
Behovet opstår når nogen af os ikke bryder os om at hvert website vi bruger skal have sit eget brugernavn og password og godt ved at eneste chance for at det kommer til at ske er at genbruge brugernavn og password på disse sites.
Hvis et af disse sites så har dårlig sikkerhed (Og det har historien lært os at det har de) så kan brugernavn og password bruges på på alle de andre websites vi ellers har genbrugt det brugernavn og password.
Der er masser af sites som sagtens kan finde ud af at beskytte passwords. Problemet er at som bruger er det umuligt at se forskel på sites med god sikkerhed og sites med dårlig sikkerhed som bare har været heldige indtil nu.Mort (30) skrev:Hvis et af disse sites så har dårlig sikkerhed (Og det har historien lært os at det har de)
Bruger du samme password på mange sites, så er det meget sandsynligt at et af disse sites har dårlig sikkerhed.
Hvis vi rent hypotetisk antager at fordelingen er 50/50, så vil et password man anvender på f.eks. 20 forskellige sites være så godt som lækket allerede. Chancen for at alle 20 sites har styr på sikkerheden er kun en ud af en million.
kasperd (31) skrev:Der er masser af sites som sagtens kan finde ud af at beskytte passwords. Problemet er at som bruger er det umuligt at se forskel på sites med god sikkerhed og sites med dårlig sikkerhed som bare har været heldige indtil nu.
Bruger du samme password på mange sites, så er det meget sandsynligt at et af disse sites har dårlig sikkerhed.
Hvis vi rent hypotetisk antager at fordelingen er 50/50, så vil et password man anvender på f.eks. 20 forskellige sites være så godt som lækket allerede. Chancen for at alle 20 sites har styr på sikkerheden er kun en ud af en million.
Der ligger også et andet aspekt i det. Langt de fleste sites har folk bag dem som ikke har spidskompetencer inden for auth og id. Det giver langt mere mening for dem at benytte openid, google, facebook, twitter ellign lign. til at stå for den del af deres website. Sandsynligheden for ejerne af websitet laver en dårlig implementering eller ikke får vedligheholdt deres pt tidsvarende implementering er ganske stor.
Google og de andre auth providers har højt kvalificerede folk hvis fuldtidsjob er at lave en god og sikker auth. Det er fjollet for de fleste websites ikke at anvende dem.
Jeg er enig i at en mulighed for at identificere sig med OpenID er en langt bedre løsning end at bruge et password, hvor serveren er nødt til at se password i klartekst.mfriis (32) skrev:Det giver langt mere mening for dem at benytte openid, google, facebook, twitter ellign lign. til at stå for den del af deres website. Sandsynligheden for ejerne af websitet laver en dårlig implementering eller ikke får vedligheholdt deres pt tidsvarende implementering er ganske stor.
Google og de andre auth providers har højt kvalificerede folk hvis fuldtidsjob er at lave en god og sikker auth. Det er fjollet for de fleste websites ikke at anvende dem.
Men en opdateret autentifikationsprotokol, hvor serveren aldrig ser password i klartekst, og hvor klientsoftwaren kan verificere at serveren overholde protokollen vil være at foretrække. Det vil fjerne problemet med sites som slækker på passwordsikkerheden fordi man ganske enkelt ikke vil kunne oprette et password eller logge ind, hvis ikke sitet håndterer det korrekt.
kasperd (33) skrev:Jeg er enig i at en mulighed for at identificere sig med OpenID er en langt bedre løsning end at bruge et password, hvor serveren er nødt til at se password i klartekst.mfriis (32) skrev:Det giver langt mere mening for dem at benytte openid, google, facebook, twitter ellign lign. til at stå for den del af deres website. Sandsynligheden for ejerne af websitet laver en dårlig implementering eller ikke får vedligheholdt deres pt tidsvarende implementering er ganske stor.
Google og de andre auth providers har højt kvalificerede folk hvis fuldtidsjob er at lave en god og sikker auth. Det er fjollet for de fleste websites ikke at anvende dem.
Men en opdateret autentifikationsprotokol, hvor serveren aldrig ser password i klartekst, og hvor klientsoftwaren kan verificere at serveren overholde protokollen vil være at foretrække. Det vil fjerne problemet med sites som slækker på passwordsikkerheden fordi man ganske enkelt ikke vil kunne oprette et password eller logge ind, hvis ikke sitet håndterer det korrekt.
SRP er desværre ikke modent nok endnu til at blive brugt i et browser miljø. Ældre javascript motorer er ikke stærke nok til at beregne de beviser der skal sendes til serveren. Vi kiggede til det under sidste opdatering af vores login system, vi fandt ingen andre websites der brugte det i praksis.
En client side kryptering af passwordet krævet at krypteringsnøglen sendes i klar tekst (over https) til klienten fra serveren. Sikkerheden er højere end i klar tekst men det er primært som følge af det ikke direkte er gennemskueligt at nøglen sendes først.
Google, facebook osv. sender i øvrigt password i klar tekst (dog over https naturligvis).
Vi har desværre her ikke den luksus at kunne anvende facebook, google og andre oauth providers da vi arbejder med nordamerikanske børn (COPPA).
Jeg kender ikke lige den specifikke protokol. Men jeg søgte og fandt denne artikel om Secure Remote Password protocol. Jeg går ud fra det er den du refererede til.mfriis (34) skrev:SRP er desværre ikke modent nok endnu til at blive brugt i et browser miljø.
Jeg er udmærket klar over at der ikke er på nuværende tidspunkt er nogen moden løsning som opfylder det jeg skitserede. Det var også ment som en langsigtet løsning.
En javascript løsning vil alligevel aldrig kunne opnå det niveau af sikkerhed jeg ville sigte efter. Hvis serveren kan kompromitteres, så kan javascript koden modificeres til at lække passwordet. For at det kan blive sikkert, så skal det være indbygget i browseren og operere på samme niveau som http authentikation.mfriis (34) skrev:Ældre javascript motorer er ikke stærke nok til at beregne de beviser der skal sendes til serveren.
En javascript løsning kan anvendes som supplement for at understøtte ældre klienter i overgangsperioden. Men ydelsen er en udfordring.
Jeg lavede på et tidspunkt et eksempel på en måde at offloade nogle af beregningerne i konventionel password validering fra serveren til klienten. Målet var at opnå sikkerhed på linje med en ittereret saltet hash uden at gøre serveren sårbar overfor DoS angreb pga. stort CPU forbrug.
Dette eksempel er på ingen måde på linje med det jeg gerne så implementeret. Men det er lille skridt i den rigtige retning. Da jeg skrev det prøvede jeg at finde ud af hvilke operationer der findes i javascript. Udfra de oplysninger jeg kunne finde frem til fandtes der ikke en eneste kryptografisk operation i standard javascript. Det vil sige at alt skulle laves i fortolket kode.
kasperd (35) skrev:Jeg kender ikke lige den specifikke protokol. Men jeg søgte og fandt denne artikel om Secure Remote Password protocol. Jeg går ud fra det er den du refererede til.
Jeg er udmærket klar over at der ikke er på nuværende tidspunkt er nogen moden løsning som opfylder det jeg skitserede. Det var også ment som en langsigtet løsning.En javascript løsning vil alligevel aldrig kunne opnå det niveau af sikkerhed jeg ville sigte efter. Hvis serveren kan kompromitteres, så kan javascript koden modificeres til at lække passwordet. For at det kan blive sikkert, så skal det være indbygget i browseren og operere på samme niveau som http authentikation.mfriis (34) skrev:Ældre javascript motorer er ikke stærke nok til at beregne de beviser der skal sendes til serveren.
En javascript løsning kan anvendes som supplement for at understøtte ældre klienter i overgangsperioden. Men ydelsen er en udfordring.
Jeg lavede på et tidspunkt et eksempel på en måde at offloade nogle af beregningerne i konventionel password validering fra serveren til klienten. Målet var at opnå sikkerhed på linje med en ittereret saltet hash uden at gøre serveren sårbar overfor DoS angreb pga. stort CPU forbrug.
Dette eksempel er på ingen måde på linje med det jeg gerne så implementeret. Men det er lille skridt i den rigtige retning. Da jeg skrev det prøvede jeg at finde ud af hvilke operationer der findes i javascript. Udfra de oplysninger jeg kunne finde frem til fandtes der ikke en eneste kryptografisk operation i standard javascript. Det vil sige at alt skulle laves i fortolket kode.
Ja lige præcis Secure remote protocol. Princippet i det er faktisk ganske smart. Matematikken bag det er benhård så hvis det interresserer dig så tag et kig på det.
Nu står jeg lige midt i aftensmaden og har kun lige skimmet din løsning, men er det du gør ikke at salte password hashet med usernamet? Password sendes så hashet sammen med login til auth servicen. Det vil forhindre de fleste angrebsvektorer :) Har du afprøvet din løsning i IE7 og 8? Det var den generation af browsere vi havde problemer med. Kan se din løsning også er "tung" på javascript beregninger.
Er du faldet over nogen uhensigtmæssigheder ved din løsning?
Der er ikke et rigtig salt i min kode, men man kan godt sige at brugernavn og sitenavn indgår som salt i beregningenmfriis (36) skrev:Nu står jeg lige midt i aftensmaden og har kun lige skimmet din løsning, men er det du gør ikke at salte password hashet med usernamet?
Det er velkendt at det er usikkert at lagre passwords i klartekst på serveren. En hashet version er mere sikker, og smider man et salt i den hash bliver det endnu mere sikkert.
Men de svageste passwords kan stadigvæk brute forces selv når hashværdien er saltet. Derfor er der ofte et ønske om at beregningen af hashfunktionen skal være langsom. Til det anvendes typisk en itereret hash. Men hvis serveren skal iterere en hashfunktion, hver gang nogen afprøver et password, så bliver serveren sårbar overfor DoS angreb. Den kommer til at skulle bruge meget CPU tid på det.
Det mit proof-of-concept viser er hvordan dette CPU forbrug kan flyttes fra serveren til klienten. Den sidste iteration af hashing skal stadigvæk foregå på serveren, og den iteration skal bruge et rigtigt tilfældigt valgt salt.
Jeg har ikke implementeret nogen serverside i min proof-of-concept kode, fordi der intet nyt foregår på serversiden. Serversiden er bare en saltet hash.
Nej.mfriis (36) skrev:Har du afprøvet din løsning i IE7 og 8?
Ja. Og det er lidt en ulempe. Problemet er at det ekstra overhead ved at udføre beregningerne i javascript kun tager ekstra tid for legitim brug. Hvis man vil forsøge at bryde passwords ved brute force af hashværdien, så kan man udføre det med native kode. Dermed har angriberen en fordel.mfriis (36) skrev:Kan se din løsning også er "tung" på javascript beregninger.
Men på trods af den ulempe kan man godt beregne nogle tusinde runder af hashing i javascript uden at det går langsomt i de browsere jeg har testet. Og nogle tusinde runder af hashing hjælper stadigvæk meget imod brute force.
Den udgør stadigvæk ingen beskyttelse imod en kompromitteret server. En sådan beskyttelse ville som sagt kræve en mere kompliceret løsning, og kan ikke laves i javascript.mfriis (36) skrev:Er du faldet over nogen uhensigtmæssigheder ved din løsning?
Den udgør stadigvæk ingen beskyttelse imod en kompromitteret server. En sådan beskyttelse ville som sagt kræve en mere kompliceret løsning, og kan ikke laves i javascript.
SRP vil være en løsning der sikrer imod en kompromiteret server. Men som det er nu kræver det at din organisation er villig til at sige farvel til brugere på ældre browsere.
Med SRP bliver password aldrig sendt over tråden. Det opbevares heller ikke på serveren. Kort sagt så sender serveren en beregning til din klient som der udregnes et bevis på. Beviset sendes så tilbage og sammenlignes med det bevis serveren forventer (som er forskelligt fra gang til gang).
Stanford har lavet en fin whitepaper (http://srp.stanford.edu/doc.html#papers) på emnet og en kort beskrivende tekst: http://srp.stanford.edu/whatisit.html
Den korte tekst giver en hurtig intro i hvad, hvordan og hvorfor
Det er i øvrigt bigint implementationen der får de gamle js motorer til at kaste op. Derfor anvender Stanford også en java applet til det i deres demo. JS motorne har et max antal loops de tillader før de tror det er en uendelig løkke. Den rammer bigint og IE7-8 spørger brugeren om de vil fortsætte script afvikling eller stoppe den.
mfriis (38) skrev:SRP vil være en løsning der sikrer imod en kompromiteret server.
Din beskrivelse hænger ikke helt sammen.mfriis (38) skrev:Derfor anvender Stanford også en java applet til det i deres demo.
Hverken java eller javascript løsninger kan opnå sikkerhed imod en kompromitteret server. Man kan ikke basere sin sikkerhed på kode der downloades fra serveren, for hvis serveren er kompromitteret, så er den kode også kompromitteret.
Jeg kiggede på de forskellige links om SRP men ingen af dem nævnte en eneste browser eller webserver med support for SRP. Er der nogen, som faktisk har support for det?
Og den liste over design mål, som du linkede til, nævner heller ikke en kompromitteret server som et scenarie hvor protokollen skulle være sikker.
kasperd (39) skrev:Din beskrivelse hænger ikke helt sammen.mfriis (38) skrev:Derfor anvender Stanford også en java applet til det i deres demo.
Hverken java eller javascript løsninger kan opnå sikkerhed imod en kompromitteret server. Man kan ikke basere sin sikkerhed på kode der downloades fra serveren, for hvis serveren er kompromitteret, så er den kode også kompromitteret.
Jeg kiggede på de forskellige links om SRP men ingen af dem nævnte en eneste browser eller webserver med support for SRP. Er der nogen, som faktisk har support for det?
Og den liste over design mål, som du linkede til, nævner heller ikke en kompromitteret server som et scenarie hvor protokollen skulle være sikker.
Nej det er klart at der ikke er noget at gøre hvis serveren er kompromiteret i en grad hvor angriberen kan skifte javascript og service ud med sit eget software.
Men i en mere naturlig situation hvor angriberen blot har formået at få et dump af databasen eller IIS logs (eller tilsvarende på andne webserver) så har angriberen ikke noget data der kan dekrypteres eller bruteforces til at give et resultat der er brugeresn password i klar tekst.
SRP sikrer imod "man in the middle attacks", at nogen kigger med i HTTP traffiken, webserver logs bliver leaked samt at databasen udstilles.
Det sikrer ikke imod at backendservice & javascript udskiftes af en angriber.
Jeg vil dog, lidt forsigtig, påstå at det er et meget sjældent scenarie, og slet ikke et nogen af de virksomheder der henover det sidste år her har været udsat for.
Sandsynligt eller ej, så længe angrebet er muligt, er brugere nødt til at bruge forskelligt password til hvert site.mfriis (40) skrev:Jeg vil dog, lidt forsigtig, påstå at det er et meget sjældent scenarie, og slet ikke et nogen af de virksomheder der henover det sidste år her har været udsat for.
Det mål jeg vil sigte efter er at brugere uden at bekymre sig om sikkerhedsrisikoen kan anvende samme password til hundredvis af sites. Et enkelt af disse sites kan nemt blive kompromitteret, og det er da heller ikke utænkeligt at et site er lavet udelukkende med formål at indsamle passwords. Selv i den situation skal man ikke være udsat for nogen risiko, selvom man bruger samme password til sin netbank.
Problemet kan løses med en passende protokol. Og det vil være mere sikkert og mere brugervenligt end den nuværende situation. Jeg ved ikke endnu om SRP kan bruges, men uanset hvilken protokol man vil bruge, så skal den være indbygget i browseren for at den kan blive sikkert.
kasperd (41) skrev:Sandsynligt eller ej, så længe angrebet er muligt, er brugere nødt til at bruge forskelligt password til hvert site.
Det mål jeg vil sigte efter er at brugere uden at bekymre sig om sikkerhedsrisikoen kan anvende samme password til hundredvis af sites. Et enkelt af disse sites kan nemt blive kompromitteret, og det er da heller ikke utænkeligt at et site er lavet udelukkende med formål at indsamle passwords. Selv i den situation skal man ikke være udsat for nogen risiko, selvom man bruger samme password til sin netbank.
Problemet kan løses med en passende protokol. Og det vil være mere sikkert og mere brugervenligt end den nuværende situation. Jeg ved ikke endnu om SRP kan bruges, men uanset hvilken protokol man vil bruge, så skal den være indbygget i browseren for at den kan blive sikkert.
Men den svaghed at vi vælger det samme password til flere sites bliver ikke undgået ved at have en browser implementeret protokol. Ej heller vil vil problemet blive fixed hvis det var umuligt at skifte backenden ud på websitet. Brugerne kan stadigvæk have samme password mange steder og passwords kan fortsat ved at uheld blive skrevet i en chat eller fortalt videre til andre når man er stiv eller lign :)
Mit argument er at netop fordi vi har en tendens til at bruge det samme password flere steder så giver det langt mere mening at flere sites tvinger brugerne til at anvende en auth provider som fx Google. 1 password, 1 authprovider, ingen websites ud over google selv der kan leake det. Jeg har mere tiltro til Google kan administrere det end bobsautohjælpoghamsterbutik.net
At vi som internetbrugere har en tendenstil at bruge samme passwords mange steder er næppe en opførsel der kan ændres. Vi har immervæk stadigvæk ikke fået folk til at droppe "password" som password
Jeg kan komme i tanke om to mulige årsager til at man kunne komme til at skrive et password i det forkerte vindue.mfriis (42) skrev:Brugerne kan stadigvæk have samme password mange steder og passwords kan fortsat ved at uheld blive skrevet i en chat
1. Det kan være en dårligt designet UI, hvor det ikke er tydeligt hvor det er man er ved at indtaste sit password.
2. Det kan være at man har brugt copy'n'paste på sit password og efterfølgende kommer til at paste det igen.
Det første kan løses med mere fornuftigt UI design. Det andet kan løses ved at have færre passwords, sådan at man kan huske dem og altid indtaster dem i stedet for at kopiere dem fra en password manager.
Hvis man er så påvirket, at man ikke kan indse, at det er en dårlig idé. Så er man nok heller ikke i stand til at huske sit password i situationen.mfriis (42) skrev:eller fortalt videre til andre når man er stiv eller lign
kasperd (43) skrev:Jeg kan komme i tanke om to mulige årsager til at man kunne komme til at skrive et password i det forkerte vindue.
1. Det kan være en dårligt designet UI, hvor det ikke er tydeligt hvor det er man er ved at indtaste sit password.
2. Det kan være at man har brugt copy'n'paste på sit password og efterfølgende kommer til at paste det igen.
Det første kan løses med mere fornuftigt UI design. Det andet kan løses ved at have færre passwords, sådan at man kan huske dem og altid indtaster dem i stedet for at kopiere dem fra en password manager.Hvis man er så påvirket, at man ikke kan indse, at det er en dårlig idé. Så er man nok heller ikke i stand til at huske sit password i situationen.mfriis (42) skrev:eller fortalt videre til andre når man er stiv eller lign
Men igen, Google og de andre har jo folk dedikeret til at lave de bedste login flows. Folk som analyserer og eksperimenterer for at finde det mest intuitive UI så muligt.
Den mulighed har bobsautohjælp ikke :) Jeg syntes det er endnu et argument for at de fleste websites bør anvende auth providers istedet for selv at forsøge at finde noget der fungerer.
Lige netop det UI aspekt som jeg nævner er at det skal være så tydeligt som muligt om det felt man er ved at indtaste sit password i er et legitimt password felt eller et phishing website.mfriis (44) skrev:Google og de andre har jo folk dedikeret til at lave de bedste login flows. Folk som analyserer og eksperimenterer for at finde det mest intuitive UI så muligt.
Det vil sige at det drejer sig overhovedet ikke om intuition, det drejer sig om at lave en UI der ser ud på en måde som er absolut umulig at lave et website, for at brugerne kan se forskel på det legitime password felt og et phishing website.
Når man har indset det successkriterie, så er det åbenlyst at den rigtige løsning ikke implementeres som et website.
Det er browserne der skal understøtte en sikker protokol og samtidigt have en UI der ikke lukker op for phishing. De enkelte websites skal ikke tænke på UI. Hvis enkelte websites overhovedet har indflydelse på hvordan UI til password håndtering ser ud, så er browseren designet forkert.
Det vil sige at det bliver nemmere for webudviklere at håndtere passwords. De skal bare bruge en webserver med support for den rigtige protokol (eller et plugin til webserveren). Og gør man det vil brugere se en ensartet login dialog på alle websites som bruger den sikre protokol. Og det vil være sikkert for brugerne at bruge samme password på alle sites, så snart de ved hvordan den rigtige dialog ser ud.
kasperd (43) skrev:Jeg kan komme i tanke om to mulige årsager til at man kunne komme til at skrive et password i det forkerte vindue.
1. Det kan være en dårligt designet UI, hvor det ikke er tydeligt hvor det er man er ved at indtaste sit password.
2. Det kan være at man har brugt copy'n'paste på sit password og efterfølgende kommer til at paste det igen.
Det første kan løses med mere fornuftigt UI design. Det andet kan løses ved at have færre passwords, sådan at man kan huske dem og altid indtaster dem i stedet for at kopiere dem fra en password manager.
Tillad mig at give dig et trejde eksempel :)
Man skal til at taste sit password ind, og en anden app stjæler fokus :)
Eller som det sker for mig fra tid til anden, at når man sidder med flere skærme, og en remote maskine på hver skærm, så tror man at man er på den ene remote, men er i stedet på en anden.
Det er så en af de ting jeg kalder for dårligt UI design. Fokus må kun skifte som følge af brugerens handlinger. Hvis fokus skifter uden at brugeren forventer det, så er det en bug i brugerfladen.Saxov (46) skrev:Man skal til at taste sit password ind, og en anden app stjæler fokus
Brugeren ser på skærmen og giver derefter input til computeren baseret på hvad der blev set på skærmen. Det tager tid. Før dette input når tilbage til computeren kan billedet på skærmen være ændret, og input kan blive fejlfortolket.
Dette er en race condition.
Det opstår til tider som følge af at computeren også skal bruge tid på at reagere. Brugeren kan foretage en handling som vil ændre fokus, men den tid det tager for computeren at reagere kan være så længe, at inden fokus ændres har brugeren givet andet input.
Udfra hvad jeg har hørt andre steder fra har computeren 20ms til at give feedback for at brugeren naturligt vil føle at det sker som en direkte effekt af brugerens egen handling. Det vil sige, at hvis man klikker og der som en konsekvens af det klik skiftes fokus indenfor 20ms, så er det helt fint.
Hvis brugeren er forberedt på at netop det klik vil skifte fokus, så der nok en lidt længere tålmodighed. Hvis man klikker og forventer at nu skal der skiftes fokus, og det sker efter 200ms, så kommer det nok heller ikke bag på brugeren.
Men hvis man f.eks. vælger at starte et nyt program, så kan det i nogle tilfælde tage flere sekunder før det kommer frem på skærmen. I så fald kan det nemt komme bag på brugeren når fokus pludseligt ændres. Det er en vanskelig situation, da man nok ikke altid kan indlæse et vilkårligt program på under 200ms.
Man kan kræve at brugeren selv aktiverer programmet, hvis det har taget mere end 200ms at indlæse det. Men hvis brugeren ikke foretager sig noget imens programmet indlæses og blot sidder og venter, så er det til irritation hvis programmet starter minimeret og man selv skal klikke igen for at få vinduet frem på skærmen.
Alternativt kan man måske inden de 200ms er gået finde ud af om programmet vil åbne et vindue, og hvor stort det vil være. Så kan man indenfor 200ms lade vinduet komme til syne på skærmen sådan at brugeren ved at det område vil blive brugt af dette program, også selvom vinduet intet indhold har endnu. Så kan brugeren selv vælge at minimere vinduet, hvis ventetiden skal bruges på noget andet.
Det er en udfordring at lave en brugerflade som gør det rigtigt, fordi timing kan være så kritisk. Og derudover forventer brugeren at brugerfladen opfører sig ens, uanset om en handling tager lidt længere tid at udføre. Og hvis computeren er belastet kan det også være svært at vide præcist hvor lang tid en handling egentlig har taget. Noget af håndteringen kan være nødvendigt at flytte ned i kernen for at garantere at timingen er rigtig.
Nogle af de tilfælde hvor fokus stjæles er som følge af popups som åbnes helt uden at brugeren selv har foretaget en handling. Det er bare uacceptabelt UI design. Den slags er nemmere at gøre rigtigt, fordi den slags aldrig skal tage fokus. Der skal være et sted på skærmen hvor den slags beskeder kan dukke op, og hvor brugeren kan klikke for at aktivere dem. Og det sted på skærmen skal ikke bruges til andet, for så kunne brugeren klikke der og få et uventet resultat, hvis en besked dukkede op på samme tid.
mfriis (42) skrev:. Jeg har mere tiltro til Google kan administrere det end bobsautohjælpoghamsterbutik.net
Hvis bobsautohjælpoghamsterbutik.net bliver hacket, så er det kun kodeordet til den side hackeren får fat i, hvis de hacker google, eller på anden måde får adgang til din google konto, så har de adgang til alt!
Justin (48) skrev:mfriis (42) skrev:. Jeg har mere tiltro til Google kan administrere det end bobsautohjælpoghamsterbutik.net
Hvis bobsautohjælpoghamsterbutik.net bliver hacket, så er det kun kodeordet til den side hackeren får fat i, hvis de hacker google, eller på anden måde får adgang til din google konto, så har de adgang til alt!
Nej det er ikke korrekt. Vi har netop i tråden her slået fast at typisk bruger adfærd er at have det samme password på de fleste hvis ikke alle websites. Ryger bobsautohjælp så er der også adgang til newz, arto og danskeswingere.dk
Sikkerheden hos bobsautohjælp er betydeligt ringere end den hos google. Skal man vælge imellem risikoen for et singlepoint of failure hos Bobsautohæjlp eller Google så vælger jeg google :)
mfriis (49) skrev:Justin (48) skrev:mfriis (42) skrev:. Jeg har mere tiltro til Google kan administrere det end bobsautohjælpoghamsterbutik.net
Hvis bobsautohjælpoghamsterbutik.net bliver hacket, så er det kun kodeordet til den side hackeren får fat i, hvis de hacker google, eller på anden måde får adgang til din google konto, så har de adgang til alt!
Nej det er ikke korrekt. Vi har netop i tråden her slået fast at typisk bruger adfærd er at have det samme password på de fleste hvis ikke alle websites. Ryger bobsautohjælp så er der også adgang til newz, arto og danskeswingere.dk
Sikkerheden hos bobsautohjælp er betydeligt ringere end den hos google. Skal man vælge imellem risikoen for et singlepoint of failure hos Bobsautohæjlp eller Google så vælger jeg google :)
undsklyd viste ikke det var slået fast af man skulle bruge den samme kode overalt ;)
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
- ⟨
- Nyheder
Gå til bund