Sziasztok!
Pár napja került ki egy kétmilliárd soros név/jelszó és egyéb adatokat tartalmazó adatbázis. Nekem már egy bankkártya és egy véletlen 2FA nélkül maradt Instagram fiók miatt lezárt Facebook accountom bánja. Legalábbis ezt sejtem az esetek mögött...
Troy Hunt: Telegram Combolists and 361M Email Addresses
Z
"You may not have Apple products, but if you have an access point and someone near you owns an Apple device, your BSSID will be in [Apple’s] database,” he said. “What’s important to note here is that every access point is being tracked, without opting in, whether they run an Apple device or not. Only after we disclosed this to Apple have they added the ability for people to opt out.”
https://krebsonsecurity.com/2024/05/why-your-wi-fi-router-doubles-as-an-apple-airtag/
Nagyon durva.
Jó ideje használom nagy megelégedéssel a Bitwarden szolgáltatását. Elő is fizettem rá, mert olcsónak találtam és így a 2fa is támogatott.
Amin gondolkodom:
Természetesen a bitwarden helyettesíthető egyéb népszerű pwmanagerrel is. Ezek közül többet is hallottam, hogy sikeresen feltörtek és hozzáfértek széfekhez.
Hint. Androidon FirefoxFocust használok, és van 2fa beállítva a Bitwardenhez is. Linux alatt Chrome böngésző van, azt nem hiszem, hogy valaki is megfertőzné, de win10 alatt simán elképzelhető, láttam is ilyet. Olyankor vitték pl a google jelszavakat is. Kérdésem: tudják vinni a bitwarden széfet is?
Ui. Most látom volt hasonló téma a hupon, de nem a jelszókezelők sérülékenysége, hanem a böngészőben tárolt jelszavak volt a téma.
Köszönöm a válaszokat!
Sziasztok!
Felteszem volt már ilyesmi téma, de azt gondolom hogy ez elég összetett probléma ahhoz hogy együtt kezeljem,
Tehát a rövid spoiler az, hogy szeretném biztonságban tudni (legalább hozzávetőlegesen) az itthoni cuccaimat.
Van az internet szolgáltató oldalán egy huawey modem, ő csinál az optikából lant. Tud wifit is, L1 a neve. Az ő kimenete bemegy egy 8 portos switchbe. Ebbe megy még két másik wifis router, amiket bridge-nek használok, csücsülnek a lanon, és szórják a wifit (L2, és L3). Ez tehát három wifi eszköz, amikre csatlakozik egy marék androidos telefon, egy porszívó meg egy chromecast.
Vezetéken kapcsolódik még a switchhez egy raspberry nas (samba), aki torrent (transmission) kliens is, egy tvbox, továbbá egy asztali pc, olykor linuxszal, olykor win10-zel. Nem piszkáltam őket, alap beállításokkal mennek.
A routereken a szokásos TKIP&AES WPA2 van beállítva.
(Így leírva szembesülök vele hogy ez jó sok motyó).
Véleményetek szerint az így beállított wifin be tudnak jönni az ügyeskedők? Nyilván nem a vérprofikra gondolok, azok mindenhova bemennek :)
Ha másképpen kellene felépíteni a hálózatot, akkor ti hogyan tennétek?
Köszönöm előre is a válaszokat!
http://sg.hu/cikk.php?cid=157550
hat igy kell... :)
A PuTTY egy hibás metódust használt az elliptikus ív kulcsgeneráláshoz, ami során kikerültek a privát kulcsok.
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-b…
Javítás: frissíteni 0.81-re, és minden olyan kulcs cseréje, ami a korábbi verzióval használva volt.
Bővebben: a PuTTY a NIST P521-et használta (ecdsa-sha2-nistp521), amiben sérülékenységet fedeztek fel (CVE-2024-31497). A javított verzió nem használja már ezt a konkrét metódust ezzel a konkrét kulcsmérettel. Öröm az ürömben, hogy más kulcsméretek úgy látszik nem voltak érintettek, illetve akkor sincs baj, ha a szerver oldali SSH-ban le volt tiltva a NIST P521, ezért a handshake-nél más metódust választott a PuTTY. Az nem egészen világos számomra, hogy lehet kihasználni ezt (feltéve, hogy a szerver is ugyanaz a security domain), de jobb a biztonság.
Kedves Ügyfelünk!
Ezúton szeretnénk tájékoztatni az SSL tanúsítványához kapcsolódó fontos változásról!
A vonatkozó iparági szabványok változására tekintettel az SSL tanúsítványok esetében a UserNotice mező használata a nem engedélyezett.
A szabványváltozásnak történő megfelelés miatt a 2023. szeptember 15. napján és ezt követően kiadott SSL tanúsítványok esetében a jelenlegit lecserélendő, új, a UserNotice mezőt már nem tartalmazó tanúsítvány kerül kibocsátásra, ütemezetten és tervezetten 5 napon belül. Ez a jelenlegi SSL tanúsítványának megújítását jelenti a gyakorlatban.
Az új kiadáshoz tartozó tömörített és jelszóval ellátott tanúsítványt, külön emailben küldjük meg az Ön részére.
Önnek annyit kell tennie, hogy a megküldött új tanúsítványt lecseréli rendszereiben.
Fontos, hogy erre egy megadott időablakban van lehetőség!
Időablak: új tanúsítvány érvényességének kezdete és 2024.04.09. 09:59 óra (közép-európai idő) között.
Új tanúsítvány érvényességének kezdete: a kiadást követő napon, az eredeti tanúsítvány kiadásának (óra/perc) idejétől kezdődik.
Új tanúsítvány érvényességének vége: megegyezik az eredeti tanúsítvány érvényességi idejének végével.
Kérjük tehát, hogy mindenképpen cserélje le a meglévő tanúsítványt az új tanúsítványra az új tanúsítványban szereplő érvényességi idő megkezdését követően, de legkésőbb 2024.04.09-e 09:59 óráig (közép-európai idő szerint).
A cseréhez a tanúsítványmegújítás technikai lépéseit kell figyelembe vennie. Az alábbi linkre kattintva érheti el szerverleírásainkat: https://netlock.hu/termektamogatas/. (Kérjük, görgessen az “Eszköz és szerver beállítások” sorig.)
Az új tanúsítvány kiadását követően az eredeti tanúsítvány legkésőbb 2024.04.09. napján közép-európai idő szerint 09:59 órakor visszavonásra kerül, amelyről külön értesítést már nem fogunk küldeni.
Tájékoztatjuk, hogy az új tanúsítvány díjmentesen kerül kiállításra.
Amennyiben a fentiekkel kapcsolatban kérdése merülne fel keressen bennünket bizalommal az alábbi elérhetőségeken.
Együttműködésételőre is megköszönjük és az okozott kellemetlenségért elnézést kérünk.
Üdvözlettel:
NETLOCK
https://www.openwall.com/lists/oss-security/2024/03/29/4
Érdekesség: sem a hivatalos forrásban, sem a github forrás mirrorban nem található meg a backdoor, csak a github release-ben.
Minden olyan distro érintett, ami ez utóbbit használja (például a debian csomag is ebből generálódik).
Ha jól emlékszem, akkor pont ilyenbe bukott bele a sourceforge, ezek szerint ugyanez a sors vár a github-ra? Sourceforge esetében a mirror volt a ludas, kíváncsi vagyok, a github-on hogy kerülhetett bele.
Sziasztok!
Ismerős a káhánál bankol. 1 hete letiltotta a bank a hozzáférését a netbankhoz, telefonos alkalmazáshoz mert valaki egy új telefonon keresztül akart hozzáférni az ő számlájához (ismerősnek almás telefonja van, az új eszköz pedig androidos). Elvileg ennél a banknál van egy azonosító és egy jelszó felírva valami kis kártyára és azzal kell regisztrálni új eszközt (lehet nem tökéletes minden infóm). Ezek az adatok valahol mélyen el vannak rejtve egy széfben, nem fért hozzá senki. Az telebankos ügyintéző szerint ukrán ip-ről jött a próbálkozás és több felhasználót is érint a probléma. Ugyanarról az ipről több azonosítóhoz próbáltak hozzáférni. A bank tiltotta a számlákhoz való hozzáférést.
Az ismerős nem adta ki a telepítési információit, nem hívta senki, hogy segítene neki mert baj van a számlájával, nem akart semmit fb-on eladni. Szóval elvileg nem hibázott ami miatt kikerülhetett bármilyen szenzitív infó.
Hogyan lehet megelőzni az ilyen helyzeteket?
Az ismerős hibázott vagy sem ?
Hogyan lehet, hogy mégis megvolt minden infó amivel hozzáférhetnek a számlához ?
Előre is köszönöm a válaszokat.
Sziasztok!
Egy béna kérdésem lenne. Ha egy alkalmazásban (Zimbra levelezés) bekapcsolom a 2fa-t, akkor a kliensekhez (thunderbird, stb.) kell generálnom egy passcode-ot. Ez egy 16 karakteres kód, amit az adott appban (és esetleg másikban is) használhatok jelszó helyett. Ez a passcode mennyivel komolyabb védelem annál, minthogy előírnám a usereknek,hogy eleve minimum 16 karakteres jelszót használjanak? Van így bármi értelme a 2fa-val szenvedni?