Az 1Password nem osztja a LastPass optimizmusát

Titkosítás, biztonság, privát szféra

Mint az ismert (HUP fórumtopik), "minden létező - titkosított és titkosítatlan - felhasználói adathoz hozzáférhettek a hackerek" a LastPass biztonsági incidense során.

"Az incidens óriási méretű felhasználói bázist érint, ebből kifolyólag óriási fogás is a hackereknek: a LastPass a világ egyik legnagyobb jelszómenedzsment-szolgáltatója, melynek jelenleg körülbelül 33 millió egyéni és több mint 100 ezer üzleti/céges ügyfele van."

"A szolgáltatás védvonalai ennek megfelelően meglehetősen szofisztikáltak, így a bejelentkezési azonosítóit és jelszavait olyan "digitális széfekben" (vault) tárolják, melyek csak a tulajdonos által ismert mesterjelszóval nyithatók.

A novemberi betörés során ezek az egyébként 256 bites AES-titkosítással ellátott digitális széfek is a hackerek kezébe kerülhettek, melyeket a fejlett kriptográfiai eljárásnak köszönhetően rendkívül nehéz feltörni, ám ahogy arra a LastPass is felhívja a figyelmet, ez csak akkor igaz, ha a fiók tulajdonosa követte a mesterjelszó létrehozásakor a biztonsági ajánlásokat, azaz kellően hosszú, bonyolult és máshol nem használt jelszót állított be mesterjelszónak."

Az LastPass konkurense, az 1Password most egy blogbejegyzésben arról ír, hogy nem millió éveket: jóval kevesebb időt és befektetést vehet igénybe egy LastPass jelszó feltörése.

( marcabru | 2022. 12. 30., p – 16:25 )

Kicsit sem megnyugtato, amikor az egyik secrurity ceg elkeni a sajat incidenset, a masik meg az elobbi incidens sulyossagaval riogat. Nehez azert ugyanezt elkepzelni mas biztonsagi szempontbol kritikus iparagban, mondjuk, hogy az Airbus azzal reklamozna, hogy a Boeing lezuhan. 

Erre próbáltam utalni, ha lezuhan a gép bárhol, akárcsak egy kétfedelű kisgép Budaörsön, akkor független vizsgálat indul, és nyilvános lesz az eredménye. A legutóbbi Boeing para eredményei még ennél is jelentősebbek voltak, hiszen ott maga az engedélyezési folyamat is megváltozott, és megszűnt a gyakorlat, hogy a gyártó maga certifikálhatja az új alkatrészeket/típusokat. 

De szerintem ezeket az adatközpontokat őrzik fizikailag is éjjel-nappal. Legalábbis a jobbakat biztosan.

A te gépedet, amin tárolod a titkosított jelszavakat, őrzik fegyveres, kutyás őrök éjjel-nappal, ünnepnapokon is? Ha nem, akkor mi van, ha valaki hóna alá kapja a gépet és már viszi is a jelszavakkal együtt?

Azt nem állítom, hogy ez kevésbé biztonságos lenne, de ez másfajta biztonság, lásd: https://en.wikipedia.org/wiki/Security_through_obscurity

( arpi_esp v | 2022. 12. 30., p – 18:39 )

"Ten billion guesses would cost about 100USD."

azert az meg messze nem az osszes kombinacio... meg 8 karakternel se.

 de nem is 100 dollárjuk van azoknak, akik ezt majd használni is fogják

Hány dollárjuk van arra, hogy random userek vaultjait fejtegessék vissza, amiben aztán vagy lesz valami érdekes, vagy nem? Ugye ha találsz egy potus@whitehouse.gov accountot, arra megérheti több pénzt elkölteni, de ahogy a másik threadben is felvetettem már, közel sem biztos, hogy egy bruteforce költsége kevesebb lesz, mint egy célzott támadásé.

Plusz egy csomó jelszó még csak 8 karakter hosszú sincs

Jah, de aki egy online jelszókezelőbe betolja a fél életét, és utána <8 karakteres jelszót ad meg decryption key-nek, az masszívan PEBKAC.

hogy random userek vaultjait fejtegessék vissza, amiben aztán vagy lesz valami érdekes, vagy nem?

Az a baj vele, hogy a Lastpass-os CEO saját bevallása szerint is kikerültek a vaultokhoz tartozó metaadatok. Vagyis a támadóknak elég jó hintjeik vannak, hogy melyik vaultban lesznek érdekes dolgok.

közel sem biztos, hogy egy bruteforce költsége kevesebb lesz, mint egy célzott támadásé

Itt sajnos sok implementációs részletet ismerni kéne, hogy PBKDF hogy is van megoldva náluk. Ha megfelelően saltolva volt és mondjuk Argon2 vagy valami hasonló, szándékosan nagy CPU és memóriaigényű függvényt használtak, akkor lehet igaz, amit írsz. Ha viszont valami saját kendács-megoldás volt, akkor lehet, hogy rainbow-table-ös tömeges hash-tesztelés is működhet. 

de aki egy online jelszókezelőbe betolja a fél életét, és utána <8 karakteres jelszót ad meg decryption key-nek

Egyrészt emlékeim szerint a Lastpass nem engedett 8 karakteres master passwordöt, elég nagy entrópiát követelt meg. (De lehet, hogy ez enterprise accountnal az account-gazda által beállított policy-n múlott. Privát lastpass accom sosem volt.)

Viszont ez az "online jelszókezelőbe betolja a fél életét" dolog sok esetben céges policy volt, hogy ne plaintextben menjen a céges chaten, meg emailben, amikor valakivel meg kell osztani valamit.

Apropó, technikailag nem mellékes kérdés, hogy a shared folderek vajon kinek a vault-jában vannak tárolva és kinek a jelszavával titkosítva... Itt is lehetnek trükkös támadási felületek.

Régóta vágyok én, az androidok mezonkincsére már!

Ezért írtam, hogy nem érdekes, hogy valamelyik account feltörése akár megvan 100 dodóból, mert neked nem a random userek Gmail jelszavai kellenek, hanem egy bizonyos account jelszavai. Akinek meg 100 dollárból brute force-olható manapság az accountja, annak annyit is érnek az adatai. :)

(Még mielőtt "de fejlődik a technológia": igen, addigra meg kell változtatni az összes kiszivárgott jelszót, de méginkább jobb auth folyamatokat kell kitalálni statikus jelszavak helyett.)

Nekem az egész sztori azért büdös, mert persze, a LastPass most elbaszta, de ha mondjuk nekem az a master key, hogy: "m,}zMbhN4do8J@uY4'pAyC;ATOj#Q6@c@Xcxi;%^^an$lF.&ZG", akkor azért most mégsem kell aggódnom a 100 dolláros hackek miatt. Ezt bekopizva a security.org-on, az az eredmény, hogy "1 sesvigintillion years", és hát azt sem tudom, eltelt-e már ennyi idő az ősrobbanás óta, vagy hogy egyáltalán mi a pék az a sesvigintillion. :)

szerk: ez egy váratlanul érdekes oldal

Kicsit azért ezt árnyalnám.

Először is az account fogalmát érdemes pontosítani. Nem feltétlen a "user" account érdekes, hanem az "enterprise" account, amiben sok user account lehet. Egy szervezet sikeres megtámadásához akár egyetlen user vaultját is elég lehet feltörni. Akár úgy, hogy ennek a felhasználónak a jogosultságával élnek vissza és jutnak be (érdekes ínception-jellege a történetnek, magát a lastpasst is így nyomták fel). Akár úgy, hogy a usernek voltak a lastpasson belül shared folderekhez hozzáférései és akkor nagyon implementációs részleteken múlik, hogy egy user feltörése elég-e a shared folder teljes tartalmának eléréséhez.

A valódi kérdés az, hogy létezik-e legalább 1 user az egész szervezeten belül, akinek 100 dollárból brute force-olható a master jelszava.

Még mielőtt "de fejlődik a technológia"

Szerintem itt nem a technológia fejlődésétől kell igazán félni, hanem hogy a lastpass saját implementációja mennyire volt atombiztos, amikor az incidens történt. Egyébként itt van a CLI (https://github.com/LastPass/lastpass-cli) és felületes rápillantásra úgy tűnik, hogy benne van a titkosított vault file formátum kezelése (blob.c), a jelszókezelés (password.c), a jelszóból kulcs generálás (pbkdf2.c) és a titkosítás (cipher.c) is. Szóval elvileg át lehet vizsgálni, hogy van-e valami problémás részlet. (Ami nem világos nekem, hogy a PBKDF2 iterációk száma mennyi, a kódból nagyon úgy néz ki, hogy ezt a paramétert szerver oldalról kapja meg a cmd-login.c:98 helyen, ez döntő lehet abban a kérdésben, hogy mennyi a brute force valódi költsége)

EDIT: szóval PBKDF2-t használnak, aminek elvileg lehet az erősségét a fordulók számával növelni, de már 2013-ban felmerült, hogy túl könnyű ASIC-ot csinálni rá, és jó lenne lecserélni valami brute-force ellenállóbb megoldásra. 2015-ben volt pályázat az utódjára, akkor választották ki az Argon2-t, amit pl Linuxban a LUKS is használ. Szóval nem "korszerű" a lastpass megoldása. Ettől még elvileg lehetne biztonságos, ha őrülten sok fordulót csinálnak PBKDF2-ből, csak ugye pont ezt nem tudjuk.

de ha mondjuk nekem az a master key, hogy: "m,}zMbhN4do8J@uY4'pAyC;ATOj#Q6@c@Xcxi;%^^an$lF.&ZG",

Remélem nem szándékosan kevered a master key és a master password fogalmát. Én most felteszem master jelszóra gondoltál. Ha ez a master jelszavad, akkor sok szerencsét a napi többszöri hibátlan begépeléséhez. Valószínűleg egy jelszó-manager kell a jelszó manageredbe belépéshez. :) Viccet félretéve, kizárt dolog, hogy gyakorlatban ehhez hasonló komplexitású master jelszava legyen valakinek.

Régóta vágyok én, az androidok mezonkincsére már!

"Ettől még elvileg lehetne biztonságos, ha őrülten sok fordulót csinálnak PBKDF2-ből, csak ugye pont ezt nem tudjuk."

De: https://support.lastpass.com/help/about-password-iterations-lp030027 Legalábbis azt tudjuk, hogy mit állítanak :)

Viszont hogy ez sok-e vagy sem... passz.

Hát 100100 az not great, not terrible. SHA256-hoz már 310000-et javasolnak, de ebben nyilván van egy jövőbiztossági szorzótényező is. A kliens kódja alapján (kdf.c) arra következtetek, hogy SHA256-ot használnak, nem SHA512-t.

while LastPass in 2011 used 5,000 iterations for JavaScript clients and 100,000 iterations for server-side hashing.[5] In 2021, OWASP recommended to use 310,000 iterations for PBKDF2-HMAC-SHA256 and 120,000 for PBKDF2-HMAC-SHA512

Vicces, hogy a PBKDF-ről szóló wikipedia oldalon a Lastpass tételesen említve van :) Ami viszont nagyon furcsa és sok kényelmetlen kérdést vet fel: hogy lehet különböző a PBKDF iterációszám a javascript-es kliensben, mint minden másban, ha ugyanazt a vault-ot használják? Az eredeti hivatkozás már broken, már nincs hol utánaolvasni, hogy is kellene ezt érteni. Jóhiszemű tippem van rá, de még ez is megsérti a "zero-knowledge" állításukat.

A másik kellemetlen kérdés, hogy ha idővel változtattak a defaulton, akkor vajon a korábbi vault-ok is "upgrade"-elve lettek? Ennek azért elég bonyolult lehet a logisztikája egy sok-useres enterprise accounton belül. Vagy lehetséges, hogy vannak még régi accountok, amik kevesebb iterációs PBKDF-en ragadtak?

Régóta vágyok én, az androidok mezonkincsére már!

A valódi kérdés az, hogy létezik-e legalább 1 user az egész szervezeten belül, akinek 100 dollárból brute force-olható a master jelszava.

Az enterprise Lastpasst egyáltalán nem ismerem, szóval fixme, de nem lehet beállítani valami policy-t? Mert ha igen, PEBKAC. :)

Remélem nem szándékosan kevered a master key és a master password fogalmát.

Lastpass esetében nem maga a password az encryption key? Ha nem, akkor sorry.

Ha ez a master jelszavad, akkor sok szerencsét a napi többszöri hibátlan begépeléséhez.

Nyilván nem ez, de hasonló. Ha csak az első 20 karaktert nézem, az is "3 sextillion" év. Meg amúgy is, miért kellene napjában többször begépelni?

kizárt dolog, hogy gyakorlatban ehhez hasonló komplexitású master jelszava legyen valakinek.

Akkor nem voltak fontosak a védett adatok, ennyi. A kényelmes-biztonságos skálán kell belőni, hogy mi indokolt, mi túlzás, és mi nem elégséges. Ha ez nem sikerült, PEBKAC. :)

de nem lehet beállítani valami policy-t? Mert ha igen, PEBKAC. :)

Mivel account owner nem voltam az enterprise accountban, ezért jogosultságom sosem volt ilyen policy-k beállítására. Úgyhogy sajnos nem tudom, de én is feltételezem, hogy lehet. Amit viszont biztos nem tudsz policy-ből garantálni, hogy az egyes felhasználók a jelszavaikat nem hasznosítják-e újra valamely más szolgáltatásnál.

Lastpass esetében nem maga a password az encryption key?

Szerintem a világon ma már sehol nem a password az encryption key. Nem is lenne praktikus, a kulcsnak a titkosító algoritmus által meghatározott hosszúságúnak és formátumúnak kell lennie. Mindig van valami függvény (aka Password-Based Key Derivation Function - PBKDF) ami előállítja a jelszóból a kulcsot. Hogy mennyire könnyű brute-force-olni a jelszót, az erősen függ a függvénytől.

Nyilván nem ez, de hasonló. Ha csak az első 20 karaktert nézem, az is "3 sextillion" év. Meg amúgy is, miért kellene napjában többször begépelni?

Nekem is 20 karakter feletti passphrase-em volt. De nem véltelenül mondtam passpharse-t, mert nem csak ilyen pwgennel generált krix-krax random spec karakterekből állt, hanem volt értelmes szó is benne. Nem állt össze értelmes mondattá, és volt közéjük szúrva szám és spec karakter is, de azért az entrópiája ennek nyilván nem egyenlő egy teljesen random 20 karakterével. A lastpass saját toolja egyébként a lehető legmagasabb erősséget jelezte rá.  Én azért élek a feltételezéssel, hogy nagyon hosszú jelszavakat már szinte minden emberi lény passphrase-szerűen fog kitölteni. Ezek a sextillió évek ezért eléggé félrevezetőek. Ha megköveteled, hogy 40 karakter legyen és ne lehessen értelmes szó benne, akkor szerintem pontosan tudod, hogy mi fog történni... post-it cetli a monitoron.

Miért kell többször begépelni? Pl a lastpass command line kliense (amikkel szerverekre belépés automatizálva volt) úgy működik, hogy van egy "agent" módja, ami a vault-ot 1 óráig nyitva tartja. Ennyi ideig használhatod jelszó nélkül, de ezen túl újra ki kell nyitnod.

Akkor nem voltak fontosak a védett adatok, ennyi. A kényelmes-biztonságos skálán kell belőni, hogy mi indokolt, mi túlzás, és mi nem elégséges. Ha ez nem sikerült, PEBKAC. :)

Szerintem azért ebben a mostani konkrét helyzetben nincs teljesen igazad. Azon a bizonyos skálán (hivatalos nevén "thread and risk analysis") például beszámított az, hogy a lastpass megkövetelte a 2FA-t a vault kinyitásakor (megintcsak nem tudom, hogy ez default működés-e vagy policy-ből kapcsolható, nekünk mindenesetre kötelező volt). Nyilván a 2FA csak a titkosított vault online tárból a kliensbe letöltését tudja védeni, a vault lokális felnyitását már nem. Ez a védvonal most teljesen megszűnt és ez nem a felhasználókon múlott.

Régóta vágyok én, az androidok mezonkincsére már!

Amit viszont biztos nem tudsz policy-ből garantálni, hogy az egyes felhasználók a jelszavaikat nem hasznosítják-e újra valamely más szolgáltatásnál.

Ezeket (= PEBKAC :)) tooling szinten sosem fogod tudni teljesen megoldani. Nyilván ez egy valós probléma, de bőven túlmutat azon, hogy mennyire secure a Lastpass.

Ha megköveteled, hogy 40 karakter legyen és ne lehessen értelmes szó benne, akkor szerintem pontosan tudod, hogy mi fog történni... post-it cetli a monitoron.

Nem a 40 karaktert kell megkövetelni. Ha száz dollárt érnek a titkosított adatok, akkor olyan password kell, amit 200 dollár brute force-olni. Ha egymilliót, akkor kerüljön kétmillióba, stb. 

Pl a lastpass command line kliense (amikkel szerverekre belépés automatizálva volt) úgy működik, hogy van egy "agent" módja, ami a vault-ot 1 óráig nyitva tartja.

Nem ismerem ezt a toolt. Ilyenkor a szerveren van 1 db account, és belép "helyetted", vagy neked van n szerverre n db accountod, amit lastpassban tárolsz, és csak a copypaste-et automatizálod? Miért nem 1 account - n szerver?

Szerintem azért ebben a mostani konkrét helyzetben nincs teljesen igazad. 

Lehet, de kicsit messze is kerültünk az eredeti kontextustól. Ugye a téma még onnan indult (még az eredeti lastpassos threadben), hogy van pénz brute force-olni, és ha csak 8 karakteres a master pw, akkor "csak" egy évig kell pörgetni AWS-en egy 8 x A100 GPU-s gépet, ami "mindössze" 160k dollár, mindmeghalunk. Innen indult az, hogy ha a te adataid ennél többet érnek, és mégis az abszolút minimum 8 karaktert adtad meg jelszónak, akkor szopó van, igen, de ez PEBKAC. ha a 8 karakteres jelszó helyett egy gigászi, megjegyezhetetlen tíz karakteres jelszót választana, akkor most évtizedei lennének megváltoztatgatni az elmentett jelszavakat.

A PEBKAC-ban az a jó, hogy bármire ráfogatod :) PEBKAC ha a user gyenge master passwordöt használ, PEBKAC ha az enterprise admin nem állít be policy-t erős jelszóra, PEBKAC ha túl erős jelszópolicy miatt a userek nem bírják megjegyezni, PEBKAC ha a user post it cetlire írja, PEBKAC ha a cég Lastpasst használ ("minekmentoda"), PEBKAC ha a Lastpass fejelsztő benyal valami phishinget és kikerül az összes vault stb. stb.

Ha száz dollárt érnek a titkosított adatok, akkor olyan password kell, amit 200 dollár brute force-olni. Ha egymilliót, akkor kerüljön kétmillióba, stb. 

Csak azt mondd meg, honnan tudod előre megmondani, hogy valójában mennyibe kerül brute force-olni... Az egy dolog, hogy az ilyen threat and risk doksikban nyilván számol az ember valamivel a szolgáltató (kriptográfiai paraméterekről szóló) állításai alapján, mert muszáj. De a számoláshoz használt előfeltételezések kb órák alatt borulhatnak.

Ilyenkor a szerveren van 1 db account, és belép "helyetted", vagy neked van n szerverre n db accountod, amit lastpassban tárolsz, és csak a copypaste-et automatizálod?

Csak a copypaste-et automatizálod vele. Nem feltétlen csak szerverre, lehet ansible-be érzékeny változókra is stb. Elvileg még tud olyat is (ezt csak a webes böngésző extension tudja, fogalmam sincs a command line kliens mit kezd ezzel), hogy a megosztott jelszó tulajdonosa csak arra ad jogot, hogy használd a jelszót belépéshez, de plaintextben nem mutatja meg, nem copyzhatod ki. Nyilván ez nem egy kijátszhatatlan dolog, de a PEBKAC-ok ellen véd.

Miért nem 1 account - n szerver?

Erről nagyon hosszasan lehet mesélni, hogy hány külön cégtől összevásárolt dolgok, hány külön cloud szolgáltatónál, hány accountban és még on-premben is, egy része windows a másik linux, egyik helyen futó cuccok egyik AD domainben, a másikak másikban. A harmadikak ne is legyenek AD-be kötve, mert <insert nem technikai céges/szervezeti okfejtés here>.

Ugye a téma még onnan indult (még az eredeti lastpassos threadben), hogy van pénz brute force-olni

Igen és az én problémám pontosan az volt vele, hogy igazából nem is feltétlen csak a jelszó erősségén múlik a dolog, hanem egyéb implementációs részleteken, ami nincs a végfelhasználó kontrollja alatt. Egy jól implementált Argon2ic PBKDF-nél 2 másodperc egyetlen próbálkozás és ezen előreláthatólag egy évtized technikai fejlődése sem tud számottevően gyorsítani. Egy szarul implementált PBKDF-nél meg akár 40 full-random karakteres jelszó ellenére is simán feltörhető.

Régóta vágyok én, az androidok mezonkincsére már!

PEBKAC ha a user gyenge master passwordöt használ, PEBKAC ha az enterprise admin nem állít be policy-t erős jelszóra, PEBKAC ha túl erős jelszópolicy miatt a userek nem bírják megjegyezni, PEBKAC ha a user post it cetlire írja

Igen,...

PEBKAC ha a cég Lastpasst használ ("minekmentoda")

véleményes, de inkább nem, ...

PEBKAC ha a Lastpass fejelsztő benyal valami phishinget és kikerül az összes vault

nem. Pontosabban PEBKAC ez is, csak nem a user oldalán. :)

mar van egy csomo leakelt password adatbazis. eleg csak az ott levo jelszavakat raprobalni a megfelelo accountokon, es lehet nyilik a zar, utana meg lesz 100 masik jelszo, azt meg jo penzert el lehet adni. nemkell egybol arra gondolni hogy nsa/fbi/stb valakinek a jelszavara utazik, es ezert tortek be oda.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Charybdis | 2022. 12. 31., szo – 12:07 )

Jaj de okosak ezek ketten (LastPass és 1Password), de kezdjük ott, hogy mindkettő zárt forrású, tehát miért is higgyek bármelyiknek is? Én most már nem bízik egyikben sem, következő projekt lesz áttérni Bitwardenre.

Azt mondja az 1Password, hogy van ez a Secret Key: https://support.1password.com/secret-key-security/

Hát hú de nagy találmány ez. Ez ugyanaz, mintha megjegyeznéd a mester jelszavad egy részét, a másik részét pedig felírnád valahová és tárolnád a helyi eszközödön. Aztán amikor be kell jelentkezni, akkor a mester jelszó egyik részét fejből gépeled be, másik részét bemásolod a lementett fájlból (és a lementett fájlban lehet jó hosszú a jelszó).

Ha jól értem, az 1Password gyakorlatilag ezt csinálja.

De akkor ha csak 1 db eszközön van meg a Secret Key és az az eszköz megadja magát, akkor ha jól értem, többet nem tudod elérni a titkosított jelszavakat, tehát lehet mindenütt új jelszót kérni, személyesen bankba bemenni stb. (több napos történet lesz)

Hiszen írja is az 1Password, hogy:

Keep it safe. Save your Emergency Kit, which contains your Secret Key. Then you’ll be able to find it, even if something happens to your devices.

Aztán meg van ez az oldal: https://support.1password.com/emergency-kit/

  • Print a copy to keep in a safe deposit box or with your passport or birth certificate.
  • Write your 1Password account password in at least one printed copy of your Emergency Kit.
  • Save it to your personal cloud storage, so you always have a digital copy available.
  • Give a copy to someone you trust, like your spouse or someone in your will.

"Save it to your personal cloud storage" - ??? És ez miért biztonságosabb, mint az általuk szidott LastPass? A "personal cloud storage"-ban ha nincsen zero-knowledge titkosítás, akkor ez a secret key szinte semmit sem ér. Ha meg van zero-knowledge titkosítás, akkor megint csak a mester jelszót tudni kell a personal cloud storage-hoz, tehát vagy emlékszel rá (de akkor meg nem biztos, hogy elég hosszú lesz), vagy tárolod az 1Password-ben. De ha az 1Passwordben tárolod, akkor annal feloldásához kell a Secret Key, amit nem tudsz elérni.

Amúgy meg ha az 1Password generálja a Secret Key-t helyben és automatikusan felhasználja a bejelentkezéshez, akkor ez nem pont zero-knowledge. Azt mondja ,hogy a Secret Key-t nem tudja meg sosem az 1Password szerver. De ezt el kell hinnünk a zárt forráskód miatt.

Mi van, ha a LastPass-hoz generálok egy Secret Key-t, ugyanúgy "felírom egy papírra", ahogy az 1Password tanácsolja (LOL), és a mester jelszavam a LastPasshoz az lesz, hogy az eleje amit fejből tudok, a vége pedig az elmentett Secret Key? Akkor ez miért nem ugyanolyan biztonságos, mint az 1Password?

Úgy érzem, hogy az 1Password próbál hülyére venni engem ezzel a blogbejegyzéssel.

De akkor ha csak 1 db eszközön van meg a Secret Key és az az eszköz megadja magát, akkor ha jól értem, többet nem tudod elérni a titkosított jelszavakat, tehát lehet mindenütt új jelszót kérni, személyesen bankba bemenni stb. (több napos történet lesz)

Ha nem csinálsz róla biztonsági mentést, akkor igen. Ebben nincs semmi kuriózum szerintem.

És ez miért biztonságosabb, mint az általuk szidott LastPass?

Mert ha mondjuk Google Drive-on tárolod a kulcsot, akkor nem elég a 1Password vaultot megszereznie a támadóknak, hanem hozzá kell férnie a Google Drive-od tartalmához, ami egy másik cég, és mivel te egy okos user vagy, ezért nem ugyanazt a jelszót használod mindkét helyen, meg még MFA is van beállítva. Ugye? :)

A "personal cloud storage"-ban ha nincsen zero-knowledge titkosítás, akkor ez a secret key szinte semmit sem ér.

Ezt nem teljesen értem. Úgy gondolod, hogy triviális lenne megszerezned a Google Drive-om tartalmát? Mondjuk fogadnál is erre valamiben? :)

Mi van, ha a LastPass-hoz generálok egy Secret Key-t, ugyanúgy "felírom egy papírra", ahogy az 1Password tanácsolja (LOL), és a mester jelszavam a LastPasshoz az lesz, hogy az eleje amit fejből tudok, a vége pedig az elmentett Secret Key?

A semminél jobb, mert hosszabb lesz a jelszavad (és így nem lehet azon rugózni, hogy 100 dollárból fel lehet-e törni), de pl. keyloggerre ugyanúgy érzékeny lesz.

Úgy érzem, hogy az 1Password próbál hülyére venni engem ezzel a blogbejegyzéssel.

Ja, hát a marketingeseknek szűk határidőre össze kellett dobni valamit, van ez így.

( zrubi v | 2022. 12. 31., szo – 12:32 )

de kezdjük ott, hogy mindkettő zárt forrású, tehát miért is higgyek bármelyiknek is?

Ez a kérdés nem technikai, hanem politikai.

 

személy szerint pl én sem bízom/hiszek egyik profit orientált cégnek sem, amelyik zárt forrású szekjúr akármit próbál eladni minél több helyre...

A cégem azonban 'megbízik' ezek valamelyikáben, innentől az övé a felelőség. Ha pedig feltörik az online kócerájt, lejátszák egymás között. - a usereket ez nem kell hogy érdekelje.

 

És - továbbra sem védeném egyiket sem - de ez még nem azonnali katasztrófa, hiszen a usereknek megvan a lehetőségük hogy kicseréljenek minden ott tárolt jelszót - még mielőtt valóban feltörnék...

persze, ez macera, idő, és bizalomvesztés... - ennek megfelelően szerződéstől függően lehet őket érte perelni vagy kártérítést kérni.

 

Természetesen a privát jelszavaimat a saját belátásom szerint tárolom. - az a megoldás azonban nem olyan kényelmes, nem 'enterprise ready' (bármit is értsenek ezalatt) és nem lehet könnyen shared vault-ot létrehozni...

Szóval ismét a kényelem és a valós biztosnág között kell mérlegelni és a kockázatelemzés eredménye alapján dönteni.

 

Hozzáteszem - céges szinten ez még mindig sokkal jobb (értsd kisebb kockázat) , mint amiket a valóságban (igen komolynak hangzó helyeken) látok... bárcsak az lenne a legnagyobb probléma, hogy egy x.y.z online szolgáltatásra bízták a jelszavaikat!

zrubi.hu

( uid_4672 | 2023. 01. 01., v – 04:46 )

sima unix pass... linugzon, androidon... 

( dyra | 2023. 01. 01., v – 20:16 )

Szerkesztve: 2023. 01. 01., v – 20:18

Egyre kellemetlenebb ez a történet. Pár évig én is használtam a szolgáltatásaikat de több felhős incidens után (nem nálunk más felhős szolgáltatóknál) úgy döntöttem annyira azért nem bízok a felhőben, hogy a jelszavaimat és a fontosabb jegyzeteimet oda rakjam fel. KeePassXC a kulcs fájl meg titkosított lemezen, az adatbázis pedig egy másik eszközön és csak akkor nyitom meg a jelszókezelőt mikor kell. Tudom ez se százas de így legalább én kezelem 100%. UI: tudom maceráns és kényelmetlen igen... a biztonság ára..