Användardata på vift efter intrång hos Lastpass

Läste det faktiskt igår själv (på Ars Technica), så jag vet. Dock brukar de inte släppa information på helgen, utan de hade möjligen kunnat släppa det idag då.

Det kan dom inte, det som har läckt är användarens(kund)uppgifter samt dom URLer som fanns i valvet, obra såklart då man har fina uppgifter för phishing. Övriga uppgifter i valvet är krypterat med kunds master-password och således inget som kan läcka från lastpass.

Well, exakt samma sak kan ju likväl hända bitwarden(minus URLerna då), Kunduppgifter av samma sort har ju dom också utanför användarens valv. "Zero knowledge" används väl av alla lösenordshanterare värda namnet, inget unikt för bitwarden. Att open-source skulle bidra positivt till säkerheten är inte heller något givet.

Bytte till Bitwarden för länge sedan, men kom på nu när jag läste det här att jag har kontot kvar än.
Skulle bara ha det kvar tills jag visste att Bitwarden fungerade och glömde sedan helt bort att radera det, men nu är det gjort

Har tänkt samma. De visar all kod, vem som helst kan se fel och rätta, men illvilliga får ju reda på exakt hur det funkar och kan klura ut hur man kringgår det. Är inte säker på att jag köper okompilerad öppen kod som något säkrare än kompilerad sluten kod. Fast många påstår ju det...

Nä, med facit i hand så ska man kika på annan lösning. Bitwarden?

Eftersom Azure kan dirigera till inloggningssida för många olika företag så finns det en viss exponering från företag ut mot molntjänster.

Tydligaste exemplet är att Outlook hämtar sin mailbox från molntjänster.

Om det finns ett säkerhetshål som är gemensamt för samtliga företag så kommer de som vill komma åt användardata givetvis att fiska upp detta från alla anslutna samtidigt, även om det innebär att det blir en sökning/uppkoppling per företag.

Och den som har tittat i vad som står i användarförteckningen i AD inser att det finns många "godsaker" där. Nästan alla dina uppgifter på ett och samma ställe.

Visst, kommer man bara in på företagsnätet så går det att komma åt AD. Den som är intresserad kan laborera med Active Directory Explorer ( https://learn.microsoft.com/en-us/sysinternals/downloads/adex... ). Men gör det på ett testnät så att du inte får problem om det finns någon övervakning på detta. Allt som krävs är att använda ditt användarnamn/lösen för att läsa ut rejält med intressant info för en hacker.

Jag kan köra igång Outlook hemifrån och se hela adressboken för min arbetsplats i Outlook och den ligger i AD. Detta betyder att det finns kanaler mellan Microsoft Azure-världen och företagsnätet. En potentiell kanal för att hämta in data som kan användas vid bedrägerier eller intrång. Jag ser det således som en potentiell risk tills motsatsen har bevisats matematiskt.

Det kan bli "jättekul" att sitta och se när något som detta "exploderar".

Och om det nu är per företag så kan det t.o.m. göra det enklare för en distribuerad attack om det upptäcks ett hål eftersom det blir en mindre mängd dublett-data som skall filtreras bort.

En av mina ursäkter för att inte ännu ha skaffat lösenordshanterare har varit att sprida riskerna. Hur säkert det nu är, så finns det ett lösenord som låser upp allt så kan den som på något vis kommer över det lösenordet (keylogger etc.) ställa till maximal skada. Medan om jag har separata lösenord så kan varje intrång göra mer begränsad skada. Det är dock inget starkt argument, för det finns ju många nackdelar med en massa olika lösenord också.

Är hemlig programkod säkrare än icke-hemlig programkod? Jag tror att svaret i alla praktiska sammanhang är nej, här kommer grunden för varför jag tror så.

Kod är bara så säker som den är skriven. Dåligt skriven kod som är full av säkerhetshål blir ju inte säkrare av att vara öppen, då är det såklart bättre om en anfallare måste gissa sig till säkerhetshålen än om de kan utläsa dem ur koden. Problemet är att kod som är så dåligt skriven kan aldrig bli acceptabelt säker utifrån moderna standader, hur hemlig den än är. För det går alltid att reverse-engineera eller gissa sig till säkerhetshålen. Så även om svaret i detta fall blir ja, så är det inte praktiskt relevant.

Om vi teoretiskt tänker oss ett program som är skrivet enligt konstens alla regler, där säkerheten inte bygger på några hemligheter från koden, utan alla hemligheter lagras separat i form av kryptonycklar eller liknande. Är inte sådan kod fortfarande säkrare om den är hemlig, eftersom det kan finnas buggar som programmeraren missat? Ja, i teorin. Nej, i praktiken, eftersom

1. På samma sätt som öppen kod kan läsas av anfallare, så kan den läsas av vänligt inställda som kan hjälpa till med att hitta samma buggar. Då open-source-projekt ofta utvecklas organiskt, så hinner många buggar hittas innan mjukvaran fått sådan spridning att en anfallare har något att vinna på att attackera den. Det är en välkänd mekanism som många nämner.

2. Vad färre tänker på, är att man skriver bättre kod om man vet att jämnbördiga eller bättre programmerare kommer att läsa den. I valet mellan att leta buggar och utveckla nya features skulle de flesta att välja det senare, för ingen gillar att säkra kod i efterhand, eller att lägga till de där röriga if-satserna som hanterar randvillkoren till ens snygga oneliner. Det är otroligt lätt att vänta med buggfixandet med ursäkten att koden ändå inte kan granskas av en anfallare. Sen glöms det bort, programmeraren slutar, och den temporära koden blir legacy. Medan i open-source-fallet vet man att såväl hackers som andra programmerare man respekterar kan se ens misstag och slarv i klartext, och då har man inget annat val än att fixa säkerheten direkt.

Sen finns det ytterligare en aspekt av säkerhet som inte har med kodens kvalitet och funktionsduglighet att göra, och det är att man också måste kunna verifiera säkerheten. Det kan man bara om man kan kontrollera vad programmet gör. Samma sak kan också förstås i termer av tillit. Länken som @Yatagarasu postade ovan nämner både Zero-Knowledge och Zero-Trust. Zero-knowledge går att få till med sluten mjukvara, men inte Zero-trust. För kan du inte läsa koden så måste du lita på att skaparen inte lagt in bakdörrar, vare sig det är pga illvilja, lagkrav eller påtryckningar. Medan om koden är öppen, då behöver utvecklarna inte ens bekymra sig för påtryckningar då sådana skulle vara verkningslösa.

Hint:

Om vi bortser från själva lösenordsbiten så är det ju inte jättebra att så mycket uppgifter läcker ut. Dels kan man ju lista ut en del genvägar och/eller ringa in intressanta mål men framförallt så är det ju inte alla som har det så bra som oss i Sverige.

Här är det ju lite skit samma om någon ser vad jag surfat på tycker många men i flera länder är det, hur ska man uttrycka sig, problematiskt om det kommer fram att man har ett konto på en viss site eller besöket något som "man inte ska besöka".

Det kan ju bli jäkligt knivigt minst sagt.

Förutsatt att ni har Exchange online så är det Azure AD Connect som hanterar synkronisering av konton mellan on-prem AD till moln dito Azure var 30:e minut. Allt sker över TLS 1.2 så det är potentiellt omöjligt för dig att knäcka, rent matematiskt.

Vad jag förstår är det viktiga här, alltså användarnamn och lösenord, krypterat, inte hashat (eller inte bara hashat i alla fall), så rainbow tables/dictionarys är ingen hjälp. Så vad de har att göra är att brute-force knäcka krypteringen, separat för varje användare de vill komma åt uppgifterna för. Det kan förstås gå relativt fort om nyckeln/huvudlösenordet är simpelt eller de har extrem tur, men annars är det rätt lugnt. Kommer kvantdatorer "på riktigt" är alla lösenord körda ändå så jag vet inte om det är något att oroa sig för, men visst kan framtidens grafikkort säkert knäcka dagens säkra krypteringsalgoritmer enkelt, frågan är väl mer när vi kommer dit, och det lär dröja åratal i alla fall.

Personligen bytte jag till bitwarden när LP började ta betalt för funktioner som jag använde och som var gratis hos konkurrenterna (att använda inloggningar på både telefon och dator). Tyvärr behöll jag mitt konto på LP som en form av backup, så jag får väl ta tag i att byta alla lösenord i mellandagarna eller så. Men som sagt lär det ta ett antal år innan det blir en reell risk, inte minst eftersom jag vet att jag har ett bra lösenord på LP.

Vill du utveckla hur du själv hostar bitwarden...

Funderar på det med, men för extern åtkomst det uppstår ju givetvis en massa pulande med ddns och domän osv...

Tack för alla tips, man kan iofs ha en programvara som uppdaterar dynamisk dns till noip.com eller liknade. Testade ett tag med publik IP med just Bahnhof, men ville inte lira riktigt och Bahnhof själva sade att det var bättre med exempelvis dyndns för att ha koll på extern ip.

Många routrar har inbyggd dns adress för dynamisk IP, tex asus eller mikrotik är några jag känner till.
Man får dock väldigt långt kryptiskt namn.

Kikar seriöst på Bitwarden nu...

Jag använder pass (passwordstore) med en egen git.
Jag föredrar att själv ha kontroll över data.

För att vara ärlig så bryr jag mig inte så mycket om priset utan har ett förflutet, njae, kanske inte förflutet, men tidigare stor aktivitet inom FOSS och EFF så det spiller väl över en aning vid val. Pröjsar gärna några tior i månaden men skall ta mig vatten över huvudet och tjata på resten av de inneboende här att faktiskt börja använda detta.. få se vilka argument kan bita på en i övrigt väldans organiserad streber till hustru, med ny valp och yngsta dottern i samma veva. ...

//

...senare... mycket senare...
Jaha, LP har sina egenheter BW har andra... bara att bita ihop och lära sig. Men BW fungerar överlag bättre.