mboost-dp1
ebay
Skal vi ikke bare afskrive det dersens internet som en dårlig idé hvis det alligevel giver så mange problemer hele tiden?
wow er det ikke for sent nu at lave en ny kode, hvis det skete for tre måneder siden,, men man må da sige de er goe mod deres kunder det skete kun for tre måneder siden... lidt for sent
#4
De siger at data i PayPal opbevares på en anden og meget mere sikker infrastruktur, separat fra eBay. Det er også derfor man er nødt til at logge ind på PayPal separat.
Men eftersom det er samme selskab, så undrer det mig såre at man ikke benytter samme type infrastruktur til eBay og PayPal. Ikke samme server, men samme sikkerhedsmekanismer.
De siger at data i PayPal opbevares på en anden og meget mere sikker infrastruktur, separat fra eBay. Det er også derfor man er nødt til at logge ind på PayPal separat.
Men eftersom det er samme selskab, så undrer det mig såre at man ikke benytter samme type infrastruktur til eBay og PayPal. Ikke samme server, men samme sikkerhedsmekanismer.
#6
Forklaringen ligger muligvis i at Paypal jo blev opkøbt af Ebay i sin tid, og derfor havde de allerede en infrastruktur der naturligvis var anderledes en den Ebay benyttede. En omskrivning af en af disse ville nok have været en større opgave og koste mange penge.
Forklaringen ligger muligvis i at Paypal jo blev opkøbt af Ebay i sin tid, og derfor havde de allerede en infrastruktur der naturligvis var anderledes en den Ebay benyttede. En omskrivning af en af disse ville nok have været en større opgave og koste mange penge.
#7
Spørgsmålet er hvor meget goodwill eBay taber på den her sag. Hidtil stolede jeg på at fire tjenester kunne holde mine informationer sikre: eBay, PayPal, Amazon og Google. Nu er vi nede på to -- for jeg stoler ikke på hverken eBay eller PayPal længere. Af samme grund har jeg slettet mit betalingskort fra PayPal. Så taster jeg det hellere ind hver gang.
Spørgsmålet er hvor meget goodwill eBay taber på den her sag. Hidtil stolede jeg på at fire tjenester kunne holde mine informationer sikre: eBay, PayPal, Amazon og Google. Nu er vi nede på to -- for jeg stoler ikke på hverken eBay eller PayPal længere. Af samme grund har jeg slettet mit betalingskort fra PayPal. Så taster jeg det hellere ind hver gang.
Så.. dette skal forståes som at de har ventet 3 måneder for at se informationer, aktivt blive misbrugt, før de siger noget videre?
Det giver da ingen mening.
Foruden ens kodeord, så er de emails der da længe solgt til alverdens spam netværk.
Man behøver jo ikke misbruge folks logins, og derved øge risikoen for at blive snuppet, for at tjene penge på den data, og det bliver sikkert aldrig opdaget eller fulgt op på hvorvidt emails er solgt til diverse 3. parter.
Man kan sikkert få en pæn sjat penge for en email liste på 145 millioner brugere, som alle givetvis må være folk der køber ting på nettet.
Personligt bruger jeg en junk mail til alle sketchy sign-ups hvor jeg forventer der vil komme spam, men lige til Ebay og payPal har jeg jo brugt min "rigtige" email og den kan jo ikke bare lige skiftes :S
Gmail spam filter er heldigvis ret effektiv :)
Det giver da ingen mening.
Foruden ens kodeord, så er de emails der da længe solgt til alverdens spam netværk.
Man behøver jo ikke misbruge folks logins, og derved øge risikoen for at blive snuppet, for at tjene penge på den data, og det bliver sikkert aldrig opdaget eller fulgt op på hvorvidt emails er solgt til diverse 3. parter.
Man kan sikkert få en pæn sjat penge for en email liste på 145 millioner brugere, som alle givetvis må være folk der køber ting på nettet.
Personligt bruger jeg en junk mail til alle sketchy sign-ups hvor jeg forventer der vil komme spam, men lige til Ebay og payPal har jeg jo brugt min "rigtige" email og den kan jo ikke bare lige skiftes :S
Gmail spam filter er heldigvis ret effektiv :)
Hvis du har brugt et password, som det tager fire måneder at bryde, så er det ikke for sent.joeyjoejoejoe (2) skrev:er det ikke for sent nu at lave en ny kode, hvis det skete for tre måneder siden
Denne historie viser hvorfor det er at man skal bruge stærke passwords og hvorfor man skal bruge forskellige passwords på hvert site. En password manager er mere eller mindre et must nu til dags.
Hvis jeg havde brugt ebay ville jeg kunne fortælle om det var sket. Men mon ikke der blandt de 145 millioner bruger er nogle andre, der lige som mig bruger en ny email adresse til hvert site.Pingvin (9) skrev:så er de emails der da længe solgt til alverdens spam netværk.
Det er nemt at være effektiv, når man tillader at store mængder legitime emails ender i spam filteret. Der går ikke en uge uden jeg oplever at gmail filtrerer legitime mails.Pingvin (9) skrev:Gmail spam filter er heldigvis ret effektiv
kasperd (10) skrev:Denne historie viser hvorfor det er at man skal bruge stærke passwords og hvorfor man skal bruge forskellige passwords på hvert site. En password manager er mere eller mindre et must nu til dags.
Problemet er netop at mange mennesker ikke kender til passwordmanagers. Og rigtig mange kender det at have glemt en kode og det besvær det kan give. Så begynder man at bruge det samme password alle steder.
Hvordan får vi så lært folk om alt det besvær det giver at bruge samme password alle steder? Og frem for alt, hvordan får vi lært folk at bruge en password manager?snesman (11) skrev:Og rigtig mange kender det at have glemt en kode og det besvær det kan give. Så begynder man at bruge det samme password alle steder.
Magten (15) skrev:At indbruddet er sket for 3 måneder siden betyder jo ikke at eBay har vidst det lige så længe.
Enig - men kilden uddyber så, at de har siddet på hænderne!
It discovered the breach in early May and immediately brought in security experts and law enforcement to investigate, Miller said.
"We worked aggressively and as quickly as possible to insure accurate and thorough disclosure of the nature and extent of the compromise," Miller said when asked why the company had not immediately notified users.
Hvad jeg så godt kunne tænke mig at vide var (kilden nævner det ikke) om der udelukkende er tale om ebay.com eller om de andre nationale sider også er ramt. Jeg er eksempelvis bruger af ebay.de, men har aldrig brugt .com - og aner sgutte om det er samme database...
kasperd (10) skrev:Hvis du har brugt et password, som det tager fire måneder at bryde, så er det ikke for sent.
Denne historie viser hvorfor det er at man skal bruge stærke passwords og hvorfor man skal bruge forskellige passwords på hvert site. En password manager er mere eller mindre et must nu til dags.
Måske et dumt spørgsmål; men med en password manager, så formoder jeg, at alle passwords gemmes på maskinen, krypteret selvfølgelig? Eller gemmes de på en server et sted, så man f.eks. har mulighed for at synkronisere mellem flere maskiner/recover på en ny maskine?
Hvis passwords'ne kun lægger lokalt på maskinen, så har man vel et problem når man får en ny maskine, så skal man jo pludselig huske alle de forskellige passwords man har brugt forskellige steder.
Men hvis passwords'ne ligger i skyen et sted, så vil det jo netop være et oplagt sted for hackere at prøve at hacke sig ind? Så får de jo lige pludselig adgang til en masse forskellige sites?
Overser jeg noget?
#17
Med f.eks. LastPass, så gemmes dine passwords i skyen, krypteret. Du laver et enormt stærkt password, og slår 2-faktor login til. Du kan få adgang til dine passwords på alle enheder (for $12 om året), og ifølge LastPass selv, så er selve deres login-sikkerhed høj nok til at man ikke behøvede skifte password efter Heartbleed.
Med f.eks. LastPass, så gemmes dine passwords i skyen, krypteret. Du laver et enormt stærkt password, og slår 2-faktor login til. Du kan få adgang til dine passwords på alle enheder (for $12 om året), og ifølge LastPass selv, så er selve deres login-sikkerhed høj nok til at man ikke behøvede skifte password efter Heartbleed.
Detaljerne varierer, men minimumskravet er at alle passwords er beskyttet med et stærkt masterpassword. Det gøres som regel med kryptering, men der er andre muligheder.Target (17) skrev:Måske et dumt spørgsmål; men med en password manager, så formoder jeg, at alle passwords gemmes på maskinen, krypteret selvfølgelig? Eller gemmes de på en server et sted, så man f.eks. har mulighed for at synkronisere mellem flere maskiner/recover på en ny maskine?
En god løsning kan automatisk synkronisere krypterede data mellem forskellige maskiner, hvor man selv kan vælge om udbyderens server skal være en af maskinerne, der synkroniseres imellem.
Et interessant alternativ til kryptering kunne være en offentlig tilgængelig liste af sites og deres passwordpolitik. Man kunne så have en algoritme der udfra masterpassword og site oplysninger genererer et pseudotilfældigt password, der er så stærkt som passwordpolitikken tillader. Hvis man mister de gemte data, så skal man bare kunne huske, hvornår man oprettede sit password (fordi politikken kan ændres over tid, og der kan være krav om at man skal skifte password periodisk).
Den løsning kan selvfølgelig stadigvæk gemme en krypteret liste som angiver site, brugernavn og oprettelsestidspunkt, og disse oplysninger kan synkroniseres. Men de er ikke helt så umulige at rekonstruere som de krypterede passwords, og de er heller ikke lige så hemmelige.
De data skal være krypteret på en måde, hvor passwordet aldrig kommer i nærheden af serveren.Target (17) skrev:Men hvis passwords'ne ligger i skyen et sted, så vil det jo netop være et oplagt sted for hackere at prøve at hacke sig ind?
Man kunne så med rette stille spørgsmålet. Hvis f.eks. LastPass er i stand til at autentificere brugere med en protokol, hvor de aldrig ser brugerens password, hvorfor kan alle andre så ikke også det?
Svaret er, at support for det er ikke indbygget i HTTP protokollen, løsninger i javascript ville være sårbare overfor en kompromitteret server, og phishing er for nemt. Endeligt kan brugere ikke stole på at alle sites de bruger håndterer passwords korrekt, og det er umuligt for den almindelige bruger at se om et givent site bruger en protokol, hvor serveren ikke har mulighed for at opsnappe passwords.
Derfor er en password manager en bedre løsning på nuværende tidspunkt. Den kræver blot at man kan stole på at password manager softwaren aldrig sender master password til nogen server, hverken krypteret eller i klartekst.
Det er ikke et spørgsmål om at lære "folk" at bruge password managers, det er et spørgsmål om at gøre det nemt at bruge passwords managers.kasperd (12) skrev:Hvordan får vi så lært folk om alt det besvær det giver at bruge samme password alle steder? Og frem for alt, hvordan får vi lært folk at bruge en password manager?snesman (11) skrev:Og rigtig mange kender det at have glemt en kode og det besvær det kan give. Så begynder man at bruge det samme password alle steder.
Hvis det ikke er nemt, så dropper "folk" det hellere, end at sætte sig ind i det
#19
Nej, det er man ikke.
I databasen står du ikke opført. Der er en krypteret fil, som er baseret på en streng, som er en sammensætning af din email, dit password; og dit unikke ID er så tilføjet en pseudotilfældig streng. Steve Gibson har kigget lidt på LastPass (tilbage i 2010), og han anbefaler det. Du kan læse op på tredjepartsanalyser her:
http://blog.lastpass.com/2010/07/lastpass-gets-gre... (via https://www.grc.com/sn/sn-256.htm )
http://blog.tinisles.com/2010/01/should-you-trust-...
Nej, det er man ikke.
I databasen står du ikke opført. Der er en krypteret fil, som er baseret på en streng, som er en sammensætning af din email, dit password; og dit unikke ID er så tilføjet en pseudotilfældig streng. Steve Gibson har kigget lidt på LastPass (tilbage i 2010), og han anbefaler det. Du kan læse op på tredjepartsanalyser her:
http://blog.lastpass.com/2010/07/lastpass-gets-gre... (via https://www.grc.com/sn/sn-256.htm )
http://blog.tinisles.com/2010/01/should-you-trust-...
Uanset hvor stærk LastPass (og lignende tjenester) er, så har de alle et ømt punkt:
Hvis de internt kompromitteres (eller grundet dårligt design introducerer en fejl), så en opdatering af produktet pludselig leaker master password, så er man på godt dansk fucked, da alle ens passwords nu potentielt er ude.
Det man så må overveje er om man stoler mere på at ovennævnte scenario ikke sker sammenlignet med om man tror Google, Microsoft, Amazon, Ebay, bliver kompromitteret.
Men som tidligere kommentatorer er inde på, så er et site som LastPass jo netop en kæmpe skydeskive for negative elementer, da den potentielle gevinst ved at kompromittere dem er enorm.
Hvis de internt kompromitteres (eller grundet dårligt design introducerer en fejl), så en opdatering af produktet pludselig leaker master password, så er man på godt dansk fucked, da alle ens passwords nu potentielt er ude.
Det man så må overveje er om man stoler mere på at ovennævnte scenario ikke sker sammenlignet med om man tror Google, Microsoft, Amazon, Ebay, bliver kompromitteret.
Men som tidligere kommentatorer er inde på, så er et site som LastPass jo netop en kæmpe skydeskive for negative elementer, da den potentielle gevinst ved at kompromittere dem er enorm.
Det problem gælder jo alle software opdateringer. Den eneste måde jeg kender til at komme omkring det er at flere forskellige personer læser ændringerne i kildekoden til hver opdatering, og hver især bygger programfilen, og slutteligt laver signoff af både kildekode og programfil med en digital signatur.Mukke (23) skrev:Hvis de internt kompromitteres (eller grundet dårligt design introducerer en fejl), så en opdatering af produktet pludselig leaker master password
kasperd (12) skrev:Hvordan får vi så lært folk om alt det besvær det giver at bruge samme password alle steder? Og frem for alt, hvordan får vi lært folk at bruge en password manager?
Den dag vi samtidigt lærer dem hvordan de kan have deres passwordmanager med rundt på ders mobil (så de ikke sidder fast uden deres computer), hvordan de beskytter adgangskodedatabasen, hvordan de tager backup af adgangskodedatabasen etc. Det er desværre en kompliceret process.
.oO(alternativt kan vi lære dem at bruge en online adgangskodedatabase som lastpass, men der har man omvendt risikoen ved at give følsomme oplysninger til en Amerikansk virksomhed der risikerer at blive Lavabittet hvis de ikke makker ret for NSA eller måske bare generelt sløser med sikkerheden)
#26
Lastpass kender ikke din key. Det eneste de kan give NSA/FBI er altså en krypteret fil, baseret på SHA-256 og PBKDF2 (hvor du selv kan sætte antallet af iterationer). Ganske vist har NSA og NIST været med inde over AES-krypteringen, men AES-256 er godt nok til TOP SECRET-kategorien af dokumenter i den amerikanske regering. Hvis NSA kendte til bagdøre, så ville de nok ikke godkende AES-256 til TOP SECRET.
Lastpass kender ikke din key. Det eneste de kan give NSA/FBI er altså en krypteret fil, baseret på SHA-256 og PBKDF2 (hvor du selv kan sætte antallet af iterationer). Ganske vist har NSA og NIST været med inde over AES-krypteringen, men AES-256 er godt nok til TOP SECRET-kategorien af dokumenter i den amerikanske regering. Hvis NSA kendte til bagdøre, så ville de nok ikke godkende AES-256 til TOP SECRET.
Spørgsmålet er nok om de kan tvinger Lastpass til at udgive en opdateret klient, som kompromitterer sikkerheden.gramps (27) skrev:Lastpass kender ikke din key. Det eneste de kan give NSA/FBI er altså en krypteret fil
Bagdøre i AES vil jeg betragte som meget usandsynligt. I designet af AES er der gjort en indsats for at der ikke kan være bagdøre. Det betyder dog ikke at den er sikret imod svagheder. Der er kendte svagheder i AES, og specielt i 256 bits udgaven.gramps (27) skrev:AES-256 er godt nok til TOP SECRET-kategorien af dokumenter i den amerikanske regering. Hvis NSA kendte til bagdøre, så ville de nok ikke godkende AES-256 til TOP SECRET.
Det betyder at AES-256 faktisk kan vise sig at være nemmere at bryder end AES-128. Dog er der ikke praktiske angreb imod nogen af dem endnu.
gramps (27) skrev:#26
Lastpass hævder at de ikke kender ikke din key.
Fixed.
Medmindre nogen har foretaget en validering af hele konstruktionen af deres service, så ved du faktisk ikke om de ikke er blevet pålagt at installere end bagdør i systemet og pålagt at holde kæft om den. Lavabit blev pålagt dette, men valgte i stedet at lukke deres service.
Nu har jeg ikke brugt LastPass før, men installerede det lige hurtigt og kiggede lige på sagen. De skriver følgende:
https://helpdesk.lastpass.com/security-options/password-iterations-pbkdf2/ skrev:The entire process is conducted client-side. The resulting login hash is what is communicated with LastPass. LastPass uses the hash to verify that you are entering the correct master password when logging in to your account.
Så med andre ord bliver dine hash-iterationer, EFTER at de er udført på din computer, kommunikeret over internettet til LastPass. Behøves jeg pointere det åbenlyse sikkerhedsproblem her? :o)
Dermed ikke sagt at LastPass er usikkert, men der er bestemt mere end en front hvor man kan åbne kritik af deres sikkerhedspraksis.
Edit:
kasperd (28) skrev:Spørgsmålet er nok om de kan tvinger Lastpass til at udgive en opdateret klient, som kompromitterer sikkerheden.
Det er lidt kompliceret, men så vidt jeg ved, så fungerer det sådan at en udbyder af et stykke software ikke kan tvinges til at modificere den software. En udbyder af en tjeneste kan dog derimod på visse områder pålægges at udlevere data fra tjenesten, inkl. dekryptering af data først.
Siden LastPass både er en client-side implementation og en online-tjeneste, så kan de ikke pålægges at ændre deres Client-side software, men de kan pålægges at udlevere dekrypterede brugerdata fra tjeneste/server-delen af deres foretagende, hvilket muligvis betyder at de kan tvinges til at ændre deres tjeneste for at opfylde disse krav.
Athinira (29) skrev:gramps (27) skrev:#26
Lastpass hævder at de ikke kender ikke din key.
Fixed.
Medmindre nogen har foretaget en validering af hele konstruktionen af deres service, så ved du faktisk ikke om de ikke er blevet pålagt at installere end bagdør i systemet og pålagt at holde kæft om den.
Du har ikke fixet en skid. Der er nogen som har valideret konstruktionen. Jeg linkede til dem i #22.
fuck du er dum, du kan ikke lave et stærkt password. en keylogger og din kode er lige megetgramps (18) skrev:#17
Med f.eks. LastPass, så gemmes dine passwords i skyen, krypteret. Du laver et enormt stærkt password, og slår 2-faktor login til. Du kan få adgang til dine passwords på alle enheder (for $12 om året), og ifølge LastPass selv, så er selve deres login-sikkerhed høj nok til at man ikke behøvede skifte password efter Heartbleed.
Jeg vil da lige kort forklare hvordan jeg gemmer mine passwords(efter jeg fik job og begyndte at få en ny tjeneste jeg skal kunne logge på næsten hver uge og nogle af dem som skal skiftes hver 3. måned).
Jeg benytter mig af KeePass. Det er som udgangspunkt en offline løsning som giver en fil krypteret med AES-256(eller noget andet hvis man henter plugins til det).
Selvfølgelig skal jeg en gang imellem have delt password listen mellem mine enheder, til dette har jeg OwnCloud løsning på en lille server jeg selv administrerer.
Mine farvorit ting ved KeePass fremfor de alternativer jeg har prøvet er nok at:
1. Det er mig der i sidste ende afgører hvor på skalaen fra sikker til bekvem at listen opbevares.
2. Jeg kan sætte klienten op til at låse databasen(og slette data fra ram) når jeg låser computeren eller bare jeg har været inaktiv i en periode.
Jeg benytter mig af KeePass. Det er som udgangspunkt en offline løsning som giver en fil krypteret med AES-256(eller noget andet hvis man henter plugins til det).
Selvfølgelig skal jeg en gang imellem have delt password listen mellem mine enheder, til dette har jeg OwnCloud løsning på en lille server jeg selv administrerer.
Mine farvorit ting ved KeePass fremfor de alternativer jeg har prøvet er nok at:
1. Det er mig der i sidste ende afgører hvor på skalaen fra sikker til bekvem at listen opbevares.
2. Jeg kan sætte klienten op til at låse databasen(og slette data fra ram) når jeg låser computeren eller bare jeg har været inaktiv i en periode.
#31
... Er du nu sikker på det er #17 som er den dumme her?
#33 er en udemærket måde at sikre sig mod mange af dem.
og
#17 nævner også at du skal aktivere 2-faktor login, et andet godt middel mod keyloggers. (Man kan jo altid udskifte koden hvis man har brugt en maskine man frygter har øget chance for at være inficeret)
... Er du nu sikker på det er #17 som er den dumme her?
#33 er en udemærket måde at sikre sig mod mange af dem.
og
#17 nævner også at du skal aktivere 2-faktor login, et andet godt middel mod keyloggers. (Man kan jo altid udskifte koden hvis man har brugt en maskine man frygter har øget chance for at være inficeret)
Jeg ser ikke noget åbenlyst sikkerhedsproblem i det. Jeg ville nok selv have valgt en lidt mere sikker løsning, men nu er jeg også fuldstændigt paranoid. Det du citerer er da i hvert fald bedre end samtlige de websites jeg kender, som bruger en adgangskode.Athinira (29) skrev:Så med andre ord bliver dine hash-iterationer, EFTER at de er udført på din computer, kommunikeret over internettet til LastPass. Behøves jeg pointere det åbenlyse sikkerhedsproblem her?
Var Lavabit ikke indrettet sådan at serveren umuligt kunne dekryptere brugernes data uden at lægge en bagdør i deres javascript kode?Athinira (29) skrev:så fungerer det sådan at en udbyder af et stykke software ikke kan tvinges til at modificere den software.
kasperd (28) skrev:Spørgsmålet er nok om de kan tvinger Lastpass til at udgive en opdateret klient, som kompromitterer sikkerheden.Bagdøre i AES vil jeg betragte som meget usandsynligt. I designet af AES er der gjort en indsats for at der ikke kan være bagdøre. Det betyder dog ikke at den er sikret imod svagheder. Der er kendte svagheder i AES, og specielt i 256 bits udgaven.gramps (27) skrev:AES-256 er godt nok til TOP SECRET-kategorien af dokumenter i den amerikanske regering. Hvis NSA kendte til bagdøre, så ville de nok ikke godkende AES-256 til TOP SECRET.
Det betyder at AES-256 faktisk kan vise sig at være nemmere at bryder end AES-128. Dog er der ikke praktiske angreb imod nogen af dem endnu.
Nu er det ikke kun bagdøre direkte i kryptering der er et problem.
Random generators der ikke er helt så random er sandsynglivis et større problem i dag. Vi ved i dag at Dual_EC_DRBG har en svaghed så enhver AES kryptering (uanset antallet af bits) er potentielt åben.
Hvor meget data der er krypteret på baggrund af den random generator aner jeg ikke. Jeg ved at MS ikke anvender den, de benytter i stedet CTR. Så med mindre man specifikt har valg en anden RNG så burde Bitlockers være sikre (med det vi ved nu)
I tilfælde af DECDRBG er der mere som peger på en bevidst placeret bagdør. Der er ikke særlig stor sandsynlighed for, at problemerne med DECDRBG var et uheld.mfriis (36) skrev:Vi ved i dag at Dual_EC_DRBG har en svaghed
Hvordan i alverden kommer du fra at en bagdør i en algoritme, som ikke bruges af ret mange, bliver til at problem for sikkerheden af AES?mfriis (36) skrev:så enhver AES kryptering (uanset antallet af bits) er potentielt åben.
Der er en meget væsentlig forskel på hvordan konstanterne i AES og DECDRBG er valgt. Som nævnt i #28 er AES designet efter at der ikke måtte være muligt at placere en bagdør deri. Derfor er alle konstanter i AES valgt som nothing up my sleeve numbers. Den fremgangsmåde gør det umuligt at have bagdøre som den i DECDRBG.
kasperd (35) skrev:Jeg ser ikke noget åbenlyst sikkerhedsproblem i det.Athinira (29) skrev:Så med andre ord bliver dine hash-iterationer, EFTER at de er udført på din computer, kommunikeret over internettet til LastPass. Behøves jeg pointere det åbenlyse sikkerhedsproblem her?
Det gør jeg, for det betyder vel at det er hash-værdien der er din hemmelige kode i stedet for dit oprindelige password.
Hvis LastPass bliver kompromiteret eller hvis NSA får en dommerkendelse på at få dit hash, vil de jo kunne bruge det til at få andgang til din konto.
Det du beskriver der er ikke en svaghed, det er en styrke.Emil Melgaard (38) skrev:Det gør jeg, for det betyder vel at det er hash-værdien der er din hemmelige kode i stedet for dit oprindelige password.
Hash værdien er sværere at finde en passwordet. Hash-værdien i sig selv kan ikke brute-forces, det er kun passwordet, som kan brute-forces. Og at komme fra password til hash-værdi til password kræver CPU tid. Det kræver ikke ret meget CPU tid, men det vil trods alt sløve brute-forcing af password lidt ned.
Derudover giver det en ekstra styrke fordi password ikke kan udledes fra hash-værdien. Det vil sige, at hvis password er anvendt til andet, så kan aflytning af hash-værdien på serveren ikke umiddelbart bruges til at angribe andre steder, hvor samme password måtte være anvendt.
Det er ikke helt korrekt. Du antager eksistensen af to sikkerhedshuller. Hvis ikke begge huller findes vil det angreb ikke kunne foretages.Emil Melgaard (38) skrev:Hvis LastPass bliver kompromiteret eller hvis NSA får en dommerkendelse på at få dit hash, vil de jo kunne bruge det til at få andgang til din konto.
Som du ganske rigtigt bemærker fungerer hash-værdien som password overfor serveren, derfor skal det også på serveren behandles som et password. Det vil sige, at det skal saltes og hashes før det gemmes noget sted.
Fra klientsiden kan du ikke se om serveren udfører den korrekte saltning og hashing. Den problemstilling gør sig gældende uanset hvor mange beregninger klienten udfører for at komme fra password til den værdi, som sendes til serveren. Men de ekstra beregninger giver stadigvæk ekstra adskillelse mellem password og hvad der kan aflyttes på serveren.
Hvis hashing på klientsiden desuden inkluderer en salt-værdi, så er det rigeligt med en enkelt hashing på serversiden, og man kunne også spare salt værdien væk på serversiden. Men man kan lige så godt være ekstra paranoid og salte med to forskellige værdier på klient og server.
Det andet sikkerhedshul som skal til er at hashværdien skal kunne bruges til at dekryptere de data, der modtages fra serveren. Et fornuftigt design vil være indrettet således at data fra serveren kun kan dekrypteres, hvis man kender password og ikke hvis man kun kender den hash, der er blevet sendt til serveren.
Eksistensen af det sikkerhedshul kan man i princippet afgøre ved at undersøge klientkoden. Hvis kryptering og dekryptering sker med en nøgle, der ikke kan udledes fra hash-værdien som sendes til serveren, så findes det hul ikke.
Systemet kunne være blevet endnu stærkere, hvis man brugte en digital signatur. Jeg ville have brugt det ene salt og password som seed til en PRNG. Jeg ville have brugt den PRNG til at generere et nøglepar. Jeg ville have sendt den offentlige nøgle til serveren, som så hasher den offentlige nøgle med et andet salt. Det er den hash, som gemmes i databasen. Før serveren fortæller klienten om den offentlige nøgle er korrekt skal klienten desuden bevise, at den kender den tilsvarende hemmelige nøgle.
Desuden skal alle ændringer af de krypterede data på serveren være signeret med samme nøglepar således at en kompromitteret server ikke kan slette data fra klienten.
kasperd (39) skrev:Som du ganske rigtigt bemærker fungerer hash-værdien som password overfor serveren, derfor skal det også på serveren behandles som et password. Det vil sige, at det skal saltes og hashes før det gemmes noget sted.
Det er selvfølgelig rigtigt. Hvis det bliver hashet endnu engang på serveren er der ikke noget problem.
Jeg vil endda mene at saltning på serveren ikke giver forøget sikkerhed i dette tilfælde.
Hvis der er et område jeg ikke tør diskutere med kasperd, så er det nok sikkerhed og kryptering. :-)
http://kasperd.net/~kasperd/cv.pdf
http://kasperd.net/~kasperd/cv.pdf
kasperd (35) skrev:Jeg ser ikke noget åbenlyst sikkerhedsproblem i det. Jeg ville nok selv have valgt en lidt mere sikker løsning, men nu er jeg også fuldstændigt paranoid. Det du citerer er da i hvert fald bedre end samtlige de websites jeg kender, som bruger en adgangskode.
Jeg har nu, baseret på andres undersøgelser, læst nærmere på hvordan systemet fungerer.
Brugerens MasterKey (til adgangskodedatabasen) hashes en ekstra gang sammen med brugerens password, og den resulterende hash-værdi der afstedkommer deraf fungerer så som identifikation af brugeren og sendes til serveren.
Dette er som udgangspunkt sikkert nok antaget at adgangskoden er sikker nok, bortset fra at man med denne fremgangsmetode løber ind i det teoretiske sikkerhedshuls som bl.a. HMAC (og SHA3) er designet til at lukke.
Det design der bruges i LastPass gør det desuden svært at salte hashen, da salten skal opbevares enten på serveren eller hos klienten. Skal salten opbevares hos klienten, skal brugeren selv stå for at håndtere den på en eller anden måde (inkl. at tage backup af den og bringe den med rundt etc.).
Hvis salten skal opbevares på serveren, gør dette dele af dekrypteringsprocessen afhængig af serveren, hvor ideen er at kun klienten skal stå for dekryptering. Samtidigt er det problematisk at identifikation af brugeren afhængig af dekrypteringsprocessen. Du kan ikke identificere dig selv uden at have salten først, og du kan ikke få udleveret salten uden at identificere dig først. Det er et hønen-eller-ægget dilemma.
kasperd (35) skrev:Var Lavabit ikke indrettet sådan at serveren umuligt kunne dekryptere brugernes data uden at lægge en bagdør i deres javascript kode?
Muligvis, men regeringens krav var at der skulle installeres et stykke overvågningsudstyr ved serveren, samt at ejeren skulle stille sine private krypteringsnøgler (om dette var hans SSL nøgler eller andre nøgler som indgik i hans tjenestes krypteringsprotokol ved jeg ikke).
Historien er på http://lavabit.com/. Du kan sandsynligvis finde flere tekniske detaljer andetsteds.
#43
Lastpass Pocket tilbyder at man kan downloade en krypteret version af sine data og dekryptere offline.
Lastpass Pocket tilbyder at man kan downloade en krypteret version af sine data og dekryptere offline.
Det første man skal huske er at der er to opgaver at løse, og det er tilladt at bruge to forskellige løsninger til de to opgaver. Den ene opgave er at identificere sig overfor serveren, den anden opgave er at dekryptere data.Athinira (43) skrev:Det design der bruges i LastPass gør det desuden svært at salte hashen, da salten skal opbevares enten på serveren eller hos klienten. Skal salten opbevares hos klienten, skal brugeren selv stå for at håndtere den på en eller anden måde (inkl. at tage backup af den og bringe den med rundt etc.).
Løsningen jeg foreslog med to salt værdier ville involvere at det ene salt blev sendt til klienten. Det betyder godt nok at hvem der end måtte kende brugernavnet kan få salt at vide af serveren. Men det giver stadigvæk ekstra sikkerhed at bruge et salt som er offentligt fremfor slet ikke at bruge salt. For at fremgangsmåden ikke lækker oplysninger om hvorvidt brugernavnet findes kan serveren generere et pseudotilfældigt salt, hvis der spørges efter salt til et brugernavn, der ikke eksisterer.Athinira (43) skrev:Hvis salten skal opbevares på serveren, gør dette dele af dekrypteringsprocessen afhængig af serveren, hvor ideen er at kun klienten skal stå for dekryptering.
Det ene salt ville så skulle udleveres før man identificerer sig, det andet skulle aldrig udleveres.Athinira (43) skrev:Samtidigt er det problematisk at identifikation af brugeren afhængig af dekrypteringsprocessen. Du kan ikke identificere dig selv uden at have salten først, og du kan ikke få udleveret salten uden at identificere dig først.
Selve dekryptering af data skal kunne gøres offline, så den må ikke være afhængig af serveren. At snakke om et salt i denne forbindelse giver ikke helt så meget mening, da processen med at afprøve om et givet password kan bruges til at dekryptere data lagret på klienten slet ikke lægger op til alle de angreb, man kunne anvende imod en password database, som ikke er saltet. Sagt på en anden måde, de datastrukturer der er involveret i lagring af de krypterede data fungerer i praksis som salt nok.
Det betyder selvfølgelig at man kan forsøge at lave at offline brute-force angreb på password udelukkende vha. de data, der ligger på klienten. Man kunne også forsøge et offline brute-force angreb på de data, der ligger på serveren. Men en udenforstående som kan kommunikere med hhv. klient og server vil stadigvæk være begrænset til online angreb, som kan være underlagt rate-limit på serveren.
Har man et stærkt password er ovenstående sikkert nok.
Men hvis man vil beskytte data krypteret med et middelmådigt password imod en stjålet computer, så kan man gøre det lidt bedre. Man kan f.eks. lave to forskellige fremgangsmåder til dekryptering afhængig af om man har netforbindelse eller ej.
Hvis man er online bruges en dekryptering, som kræver kommunikation med serveren. Jeg forestiller mig at der bruges blinded RSA til det formål. Blinded RSA giver ubetinget garanti for, at der ingen oplysninger lækkes til serveren. Samtidigt giver det serveren, som sidder på den hemmelige nøgle, mulighed for at håndhæve rate-limit. Hvert password der forsøges vil kræve kommunikation med serveren.
Hvis man er offline kan man i stedet bruge en algoritme, som kræver mange runder af hash beregning for at finde frem til den rigtige dekrypteringsnøgle. Det kunne f.eks. være indrettet sådan, at hvis man er online kan dekryptering gennemføres med 1 sekund CPU tid, men hvis man er offline skal der 60 sekunder til for at udlede nøglen fra password.
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