Dropbox drabbas av läcka – miljontals användaruppgifter på vift

Decent lösenord i bas som jag har 100% memoriserat sen lägger jag till ett ord beroende på sida. Typexempel: 1r2e3w4QGoog för googlekonto, 1r2e3w4QDB för dropbox. Det unika ordet har jag nedskrivet på en virtuell post-it lapp.

Det är anledningen till varför jag rekommenderar att man "l33tifierar" sina lösenord. Helst med ett eget system. Det vill säga att man ersätter vissa bokstäver med siffror och symboler. Detta ökar säkerheten markant, då en sådan här typ av attack då måste testa alla tänkbara teckenkombinationer för varje enskilt ord.

Exempel där ordet "bok" ökar säkerheten mångfalt:

Gissa hur många kombinationer det finns på lösenordet "MittJättefinaLösenord" ... l33tifierat...
Det består av 4 ord. Men lägg nu till att varje ord inte bara är "ord", utan innehåller även teckenvarianter på varje enskilt ord.
Hur många gånger måste man inte "loopa igenom" ordlistan på 100 000 - 150 000 ord för att testa alla tänkbara teckenkombinationer också? ... för varje enskilt ord.

Jo, med tillräckligt många ord och sprinklat med lite slumpmässighet, så blir det definitivt svårknäckt.

Vet inte exakt vad det projektet handlade om utöver en snabb googling och genomskumning, men Yubico (delvis baserat i Sverige, faktiskt) erbjuder redan idag färdiga lösningar så som Yubikey Neo som troligen är en smidigare lösning för säker autentisering. Ytterst lovande teknologi, även om "lovande" kanske är fel ord då de redan används skarpt av stora företag.

Jag har ingen koppling till företaget, och äger inte ens någon av deras produkter, men jag följer utvecklingen då det verkar riktigt intressant. Inte minst är det roligt att läsa på om tekniken bakom.

http://rt.com/news/195244-snowden-rid-dropbox-privacy/

Om vi nu tittar på helheten i "hotet", så uppstår några frågor:

• Vilka är det som fått tag på lösenorden?

• Var lösenorden lagrade i klartext-format? I så fall är det riktigt illa.

• Vad kan de göra med Dropbox-kontona de får access till?

...och det är den sista frågan jag är mest intresserad av.
För mig lär det inte vara så farligt. Jag förutsätter nu att de redan har tillgång till mitt Dropbox-konto.
Visst. De får tag på en del personlig information om mig. Men inget de kan använda för att komma åt mina ekonomiska tillgångar.
På sin höjd kan de använda min identitet (Namn, Adress, personnummer) till vissa begränsade tjänster.
Jag har en extremt tungt trippelkrypterad (AES, Twofish, Serpent) dabasfil som innehåller lite känsligare uppgifter. Men jag tror ingen kan få access till den, då den kräver både ett mycket långt lösenord (över 90 tecken) och flertal nyckelfiler på 8 KiB vardera.
Jag skulle ALDRIG NÅGONSIN lagra känsliga uppgifter okrypterat i någon molntjänst överhuvudtaget, oavsett vad de lovar om sin säkerhet.

Lagrar man känsliga uppgifter i någon molnlagringstjänst, okrypterat, så är man verkligen urbota korkad. En badboll har mer intelligens i det fallet. Hårda ord ja, men så är fallet enligt min mening.

Texten var mer tänkt som en fördjupning (om än fortfarande ytlig) i vad XKCD-metoden egentligen försöker illustrera gällande informationsteori. Visst, 44 bitars entropi håller inte länge för en lokal riktad attack som jag nämner.

Ska man ge sig in i den "luddigare" implementationsdelen av knäckverktyg så ger entropimåttet i sig snarare bara ett mått på ett teoretiskt "worst-case scenario" för hur få kombinationer som en attackerare kan behöva gå igenom under förutsättning att metoden är känd — om den exakta implementationen av lösenordsskapandet skiljer sig minimalt men icke-trivialt från en lista med vanliga ord så blir det direkt svårt för automatiserade verktyg att utnyttja en vanlig ordlisteattack. Om man har en någorlunda unik egen metod som genererar ett vettigt antal tecken så skulle det dels kräva att metoden var känd samt en riktad attack mot just ditt konto för att attacken skulle skilja sig nämnvärt från "brute force" av slumpade tecken.

I praktiken så riktar lokal lösenordsknäckning av dumpar från större "vanliga" sidor in sig på lågt hängande frukt, då det finns så mycket av den att enkelt plocka. I detta ingår säkerligen både "Tr0ub4dor&3" och "correct horse battery staple"-tekniker. Det kontrolleras även mot listor från tidigare databasdumpar där lösenorden kanske till och med lagrats i klartext, vilket leder till problemet med lösenordsåteranvändning, där inte ens 32 slumpade tecken är mycket till hjälp om exakt denna sträng använts tidigare.

Ok, tackar för förtydligandet.

Precis. Ett annat problem som sätter käppar i hjulen är förstås att många tjänster har väldigt kort maxlängd på lösenorden. Har svårt att se hur de som lagt in sådana begränsningar har tänkt. Använder de databaser med sträng-datatyp som max kan lagra 8 tecken? Finns det någon icke-uppenbar förklaring? Eller har de bara haft otur när de tänkt?

Du hade en dosa, med fingertrycksläsare och en display. Där du kunde lagra massa uppgifter, lösenord etc.

Gick att verifiera med fingret och blåtand. Tappade man bort den/stulen..så kunde man spärra den så fort den kom online.

Fast allt gick åt skogen nyligen.

Sen verkar folk missa att man använder en mejladress och ett lösenord tillsammans, sen kan man ju testa lite andra sajter med samma kombination, det var ju så hela karusellen började, dem kanske testar google eller facebook som nästa ställe..

två stegs varifiering eller engångskoder via dosa eller liknande är enda säkra lösningen om man nu vill vara helt säker och använda internet

För liknande säkerhetsfrågor är det många som använder "knep" som att helt enkelt ange en slumpad sträng. De går inte att använda själv, men det kan ingen annan heller. Ifall kontoåterställning verkligen skulle bli aktuell så får man ringa och prata med någon ansvarig och identifiera sig på så sätt i stället. Vissa sidor kan dock periodiskt be en användare att svara på en sådan fråga för att kontrollera att kontot inte hamnat i orätta händer, så det kan potentiellt vara vanskligt att själv inte veta svaret.

Dessa "säkerhetsfrågor" är inte alls speciellt säkra (fråga Sarah Palin), utan mest ett sätt för sidorna att minska antalet supportärenden från personer som glömt sina lösenord.

Jag läste om en person (hittar inte källan nu, trots googlande) som upplevt en sida där man skulle ange en personlig PIN-kod för att kunna återställa kontot, där de rekommenderade att man skulle använda sin mammas födelsedag. Personen tyckte det lät dumt och skrev in något annat, vilket systemet inte godtog då det inte var ett "giltigt datum" . Personen ringde i stället till företaget i fråga och fick efter några vändor tillåtelse att ange en icke-datumbaserad säkerhetskod — som fick sägas till operatören över telefon så att den kunde skrivas in manuellt i systemet .

Aktuell forumtråd i ämnet .

Det finns lite olika operationslägen: dels den starkaste "one-time pass"-autentiseringen (OTP) som används i kombination med ett lösenord och som verifieras mot en loginserver, men det går även att lagra ett "vanligt" långt lösenord som skrivs in när den fysiska nyckeln aktiveras. En variant skulle då kunna vara att använda detta långa lösenord som upplåsningslösenord för en personlig lösenordsdatabas.

Det finns likheter, men en praktisk fördel är att man kan använda nästan godtyckligt långa och starka lösenord på tjänstsidan (så långa som tjänsten accepterar) som applikationen automatiskt skriver in i lösenordsfältet och använder för att logga in. Man kan alltså fullkomligt eliminera problemet med att användare väljer lösenord som är enkla att programmeringsmässigt knäcka.

Det gör också att det inte finns någon som helst motivation till att återanvända lösenord på något sätt, vilket gör att om exempelvis en viss tjänsts databas skulle komma på vift, eller någon sniffar lösenordet via en osäker uppkoppling, så påverkar detta inte överhuvudtaget några andra konton.

Använder man ett starkt lokalt lösenord för krypteringsfilen så är den filen i sig egentligen ej heller någon fara att lägga publikt eller på annat sätt bli av med, även om det inte av nöden är rekommenderat.

När man väl har satt upp en sådan tjänst så blir inloggning på fjärrtjänster också faktiskt mycket enklare, då man bara behöver minnas ett enda lösenord, snarare än komma ihåg både användarnamn och unika lösenord för varje sida. Detta "betalar sig" inte minst när det handlar om en sida som man väldigt sällan använder, som ändå blir lika lätt att använda som någon annan man använder dagligen.

Fortfarande kan man vara sårbar för keyloggers och liknande inbrott, men tja, alla metoder har något hål någonstans. En krypterad lösenordsbank täpper till många sådana på ett enkelt sätt.

Ett användningsminus som vissa påpekar är att det blir svårt/omöjligt att logga in på tjänster från andras klienter där man inte har sin lösenordsfil tillgänglig, men när man börjar skriva in sina lösenord på enheter man inte har någon som helst kontroll över så är säkerhetstänket redan ur fokus. Om man har lösenordsbanken tillgänglig på exempelvis en mobil så kan man ju dock välja att visa lösenordet i klartext och logga in om det verkligen skulle krisa; när man sedan är "hemma" så är det bara att kasta ut detta använda lösenord och ersätta med ett nytt framslumpat dito.

Jag skulle säga att en sådan lösenordsbank är väldigt smidigt när man väl vant sig, men det kräver en viss arbetsinsats att migrera alla sina lösenord över till en sådan tjänst. Man bör ju även passa på att ändra lösenorden till de nya starkare varianterna och kontrollera att inloggningen till tjänsten fungerar.

Sant. Alla enheter som kan kommunicera kan bli hackade helt enkelt. Det enda man kan göra är att försvåra det för inkräktare och kanske försöka spåra dom.

Som det står i artikeln:

Finns inget som tyder på att Dropbox skulle ha sparat lösenord i klartext i nuläget, vad jag vet.

Glöm inte 2 stegs verifiering på Lastpass också.

Skickades från m.sweclockers.com