Nade ezekben szó sincs semmilyen szoftverről... Mert oké, kinyitod a privát címtartományokra - de nem a nagyvilágnak.

https://www.coreinfinity.tech

Adatbázis titkosításra van valami best practice-etek? Néhány személyes adat lesz csak benne, mint név, elérhetőség, stb. de gyerekekhez tartoznak, úgyhogy inkább titkosítanám. Az a gondom, hogy a név szerinti kereshetőséget erősen lerontja, ha ciphertext van a helyén. Nem tudom hogyan lehetne felindexelni így. Ezzel a problémával már régóta küzdök mondjuk más projekteknél is, hogy valahogy az indexet is titkosítani kellene. Más megoldást nem igazán látok rá, de azért érdekel, hátha van valami más nézőpont. Azt tudom, hogy vannak olyan adatbázisok, amik tudnak titkosítani, viszont ha mondjuk injection-nel használják fel a saját fiókomat, akkor ugyanott tartunk, mintha nem lenne titkosítva. A ciphertext feloldásához viszont PHP kódot kellene injektálniuk, és felhasználni a feloldó kulcsot, ami jóval nehezebb.

[ Szerkesztve ]

Buliban hasznos! =]

Encryption-at-rest a standard kb mindenhol az enterprise világban. Több DBMS támogat column-level encryptiont is query szinten, ami plusz egy fokkal biztonságosabb, illetve app szinten is meg lehet oldani, de ahogy mondtad drága/macerás lesz.

MVP esetén böven elég az encryption-at-rest és ráértek biztonságosabb (aka drágább) megoldásokra váltani, amikor az ügyfeleitek kérik és meg is bírják fizetni.

Köszi!

Buliban hasznos! =]

A LinkedIn-en olvastam egy bejegyzésben, hogy állítólag 800K magyar e-mail cím/jelszó páros szivárgott ki a napokban, és tették közzé a nyílt weben. Tud erről valaki valami konkrétabbat? Nem sok időm van keresni, egy lájtos guglizás viszont nem hozott eredményt.

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Nem lehet hogy valamelyik régebbi szivárgásból van?

Az megvan mindenkinek, hogy támadók elérték az Okta privát Github repóit, forráskódokkal együtt?

https://www.coreinfinity.tech

Én tegnap olvastam, hogy a SHA1-et teljesen kivezették, SHA2 és SHA3 ajánlott helyette.

Buliban hasznos! =]

Én csodálom, hogy még egyáltalán maradt ügyfelük

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

Miért?

https://www.coreinfinity.tech

Mostanában eléggé gyakoriak náluk a security incidensek.

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

Annyira gyorsan azért a vevők nem lépnek le, plusz a korábbi incidensek a vevőbázis kis részét érintették. A mostani viszont 10/10-es incidens - ezt lesz művészet túlélni komoly következmények nélkül.

https://www.coreinfinity.tech

Nincs. Link?

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Túl erős a vendor lock-in, egyszerűen iszonyatos seggfájás átmigrálni a teljes SSO-t, úgyhogy nem hinném, hogy igazán komoly következménye lenne.

[link]

https://www.coreinfinity.tech

Linuxon az nmcli melyik file-ból olvassa ki a wifi információkat?

https://www.coreinfinity.tech

Egy kis olvasnivaló...

[ Szerkesztve ]

https://www.coreinfinity.tech

Nem tudom miért gondolod, hogy bármiféle sunnyogás vagy felelösség hárítás van a háttérben. Más cégek breach notificationjeihez képest ez részletes, transzparens és korrekt közlemény volt. Elég ha a GoTo kommunikációját megnézed ugyanerröl a security incidensröl, hogy tudd milyen az amikor "sumákolnak".

Ha körülnézel, láthatod, nem csak én gondolom így...

https://www.coreinfinity.tech

Ugyan... A többség csak nyugtázza, hogy na még egy feltört szolgáltató, aztán a másik oldalára fordul és alszik tovább.

...ééés most mindketten leteszitek a nagyesküt, hogy ezt a vitát kellő szakmai mélységben, érvekkel bőségesen alátámasztva, színvonalas formában lefolytatjátok - a legközelebbi pH! ITSEC sörözés alkalmával...

Válasz akart lenni [erre]...

[ Szerkesztve ]

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

https://www.coreinfinity.tech

Nyilvan anecdotal evidence, de ahanyszor belulrol erintett voltam barmilyen breachben a nepek mindig hihetetlen fantasztikus torteneteket talaltak ki, aminek semmi koze nem volt a valosaghoz. Kulonosen a tech ujsagirok azok akik par clickert olyan faszsagokat talalnak ki, hogy legszivesebben orokre eltiltanam oket az irastol.

Jó reggelt, BUÉK :)

Nincs is jobb újévi ajándék, amikor reggel kapsz egy e-mail-t a haveibeenpwned.com tol, hogy az egyik e-mail címed érintett egy deezer breach-ben :D

link

Lehet több magyar is van ott abban a listában.

Ééés megint a beszállítói lánc...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Hát ja.
Amúgy ha jól értem akkor még 2019-ben történt meg a leak.

Akkor már nem gáz. Ennyi idő alatt nemet is lehet váltani, nem csak jelszót.

[ Szerkesztve ]

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

Nekem az egyik fő e-mail címemet érintette, amit még most is használok.
Mondjuk már másik helyen is ki szivárgott, szóval ez van.
Mondjuk igazából nem is emlékeztem arra hogy annó regisztráltam ezzel az e-mail címmel a Deezer-re... csak aztán nem használtam...

Jelszó-ra sem emlékeztem már...

Én az Adobe regisztrációmmal jártam így. Nem is emlékeztem rá, hogy volt náluk regisztrációm, csak mikor feltörték őket, akkor vettem észre.

Az utóbbi időben elkezdtem arra rászokni, hogy ha regisztrálnom kell és a szolgáltató elfogad MS vagy Google accountot akkor azzal regisztrálok.

[ Szerkesztve ]

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

Még egy kis adalék a LastPass történethez. Erre...

https://www.coreinfinity.tech

A LastPass és a GoTo két külön cég, külön vezetőséggel. Mivel az infrastruktúra egy része közös, ezért mindkét céget érintette a breach, viszont a GoTo nem a LastPass incidenséröl írt, hanem a saját érintettségükről.

Nekem meg az volt meg, hogy a LastPass Goto ceg... bar a konkluzio szempontjabol mindegy, az e velemenyem, hogy torvenyben kellene az etikussagot megfogalmazni kiberbiztonsagi incidensek eseteben.

Ertem en, hogy vannak olyan informaciok, amik utalhatnak a belso infrastrukturara, bizalmas informaciokra, uzleti titkokra - nem is kerem, hogyu ilyeneket nyilvanossagra hozzanak, azt viszont igen, hogy ezekkel a sunyi taktikakkal nem lehessen elrejteni informaciot.

MOD: koszonom a segitseget, kiegeszitettem az irast.

[ Szerkesztve ]

https://www.coreinfinity.tech

Hogyan fogalmaznád meg az etikusságot? Tudsz mutatni egy példát arra, hogy szerinted mi lenne a transzparens kezelése egy security incidensnek?

A hobbi lakatosok sem más zárán próbálkoznak, hogy ki tudják e nyitni, aztán utána szólnak a tulajnak, ha bejutottak, hogy rossz a zár, hanem inkább vesznek sajátot.

Buliban hasznos! =]

Szerintem hozzatettem par aprosagot az utobbi ket irasban: nem olyankor teszunk kozze hirt errol, amikor szamithatoan kevesebb emberhez jut el az informacio; nem rejtjuk el az errol szolo hireket a keresobotok elol.

A kiberbiztonsagi ipar a bizalomrol szol es a fenti ket pont ezt nagy mertekben gyengiti, ugyanakkor a leendo ugyfelek errol elrejti a korabbi, megkerdojelezheto kiberbiztonsagi incidenseket es az azok feltarasa soran kiderult hianyossagokat. A LastPass eseteben tobb olyan van, amiket evek ota reportoltak nekik es semmi nem tortent.

A fo problema: ha a LastPass, a GoTo es a Slack gyakorlata rutinna valik, azzal a bizalom konnyen semmive foszlik - ugye nehez megszerezni, de konnyu elvesziteni - es ez konnyeden vezethet olyan regulaciokhoz torvenyalkotoi oldalrol, amit mi, az iparagban erdekeltek nem szeretnenk.

https://www.coreinfinity.tech

Kár, hogy nincs kiemelés gomb. Beteszem összefoglalóba.

Buliban hasznos! =]

Szerintem ott kellene kezdődnie, hogy az online szolgáltatások esetén, legyen kötelező a rendszeres audit, esetleg minősítés/tanúsítás amit kötelező legyen publikálni és támadás esetén kötelező legyen CERT/CSIRT szervezetek felé bejelentés tenni. Ha elmarad az incidens bejelentés akkor pedig komoly büntik mehetnének.

[ Szerkesztve ]

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

Megint abból a feltételezésből indulsz ki, hogy sumákolnak. A LastPass augusztus óta folyamatosan kommunikál az incidens/breachröl, van ismerösöm aki a két ünnep között is ezzel foglalkozott, ráadásul a GDPR 72 órás notificationt ír elő, úgyhogy szerintem a reálisabb szcenárió inkább az, hogy mindenki vért pisált a LastPass-nál, hogy lezárják az investigationt Karácsony előtt és el tudjanak menni szabadságra. A nem rejtjük el dolog pedig a LastPass szempontjából irreleváns, ezt a GoTo és a Slack csinálta, felesleges összemosni, írtam is korábban mint negatív példa.

A semmi sem történt ebben a formában nem igaz. A tech média minden LastPass-al kapcsolatos sérülékenységet kritikusnak fest le, amit aztán a security csapat a belsö SLA alapján bepriorizál. Amikor én ott voltam minden külsős report kritikusként indult, így gyakorlatilag azonnal nekiálltunk. Priorizálás után lesznek olyanok amik nem fogják megütni az ingerküszöböt (pl. cleartext metadata) mert túl nagy befektetés (pl. kódbázis nagy részét újra kell írni) lenne kijavítani egy túl alacsony kockázatú sérülékenységhez képest. Lehet ezen meglepődni, de aki az iparban dolgozik, az tudja, hogy ez így működik.

Ami nekem bassza a csőröm az az álszentség a security iparban. Mindenki ítélkezik meg jobban tudja, holott fogadni mernék, hogy mindenkinél ott rohad az EoL Windows Server valahol a sarokban, van software amit évek óta nem patchelt senki és breach esetén ugyanúgy lapítanának.

holott fogadni mernék, hogy mindenkinél ott rohad az EoL Windows Server valahol a sarokban, van software amit évek óta nem patchelt senki és breach esetén ugyanúgy lapítanának.

Ééés ott a pont, ez is mehet az összefoglalóba...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Ennek egy részével egyet tudok érteni, de nem mindennel.
Nem kétlem, hogy az invesztigáció technikai oldalán nem volt megállás, de a publikus kommunikációról nem ők döntenek. Az incident responder átadja a reportot a businessnek, ők meg kármentés alapon fogják kiadni a kommunikációnak.

Ezenkívül a beérkező reportokat nem kezelik úgy, ahogy kellene, plusz a LastPass által biztonság-növelőnek szánt fejlesztések sincsenek force-olva. Példa: ha vkinek anno 8 karakter volt a master passwordje, a 12-es minimum bevezetésekor nem kellett újat kreálnia a megfelelő hosszúsággal. Példa: a LastPass büszkén hirdeti a 100100 iterációs PBKDF2 funkciót. Ezzel 2 baj van: az OWASP ajánlása 310K, plusz az iterációk számát bátran állíthatod. Igen, 1-re is.

Van még: saját implementációt használnak AES-re (nyilván a kvázi-sztenderd, megvizsgált, certified könyvtárak nem jók), ECB módban Noha nemrég váltottak CBC-re (unauthenticated), ami ECB módban került titkosításra, úgy is maradt.

Mindezeken túl van még bőven, ezek felsorolása, kivesézése önmagában lehetne egy külön blogbejegyzés témája, de a blogbejegyzésemnek nem (volt) célja ezek részletezése, sokkal inkább az unetikus viselkedésre való figyelem felhívása.

https://www.coreinfinity.tech

Ezek legtöbbször product döntések, ha enforceolod a változást, akkor le kell kódolni a logikát is, ami átmigrálja a usereket, ez pedig pénzbe kerül. Ha a user 8 karakter hosszú master passwordot állít be, akkor szerintem az az ö dolga, inkább törjék fel a hülye jelszóválasztás miatt, mint hogy kilockolja magát a 12 karakteres jelszóval a product hibájából és a supportot hívogassa. Az OWASP 310k-s ajánlása a FIPS-140 compliancere vonatkozik és semmi sem gátolja, hogy feltold az iterációt erre a számra, ha bevállalod a lassabb bejelentkezést.

A saját implementációra van valami source? Csak random tweeteket találtam, amik nem mutatnak semmilyen kódot meg a 2015-ös Black Hat talkot. Az ugye közvetlenül a LogMeIn felvásárlás környékén volt és azóta sokat fejlödött a product.

Aki úgy tölt fel valamit az internetre hogy azt 20 generált karakteresnél gyengébb jelszó védi, az ne csodálkozzon ha kitudódnak az adatai..

Tudomásom szerint nem csak a karakterek száma számit :)

Valaki mondja meg miért léteznek még olyan cégek aki Visual Foxproban készítenek könyvelő, bérszámfejtő, munkaidő nyilvántartó alkalmazásokat. (a kérdés költői volt, tudom pénz nagy úr, és ezeket fillérekből lehet fejleszteni, a biztonságot meg oldja meg a rendszergazda)

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

Amíg lesznek ügyfelek akik megveszik a hákolt szutykot, miért ne maradjon a "jólvanezígy" hozzáállás?

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

Ezek jellemzően belső fejlesztések, állami cégeknél.
Van egy darab fejlesztőjük, a Béla, aki az 1800-as évek óta dolgozik ott, még Turbo Pascal-t tanult a főiskolán (már ha egyáltalán van diplomája), és még mindig Delphi-ben tolja, viszont olcsó munkaerő, no meg különben is már szinte családtagnak számít; a menedzsment egyrészt lesz*rja, hogy miben fejleszt (nem is értik a problémát), másrészt örülnek, hogy van saját fejlesztő kapacitásuk.

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

"Ezek jellemzően belső fejlesztések, állami cégeknél."
Pont, hogy nem azok. Gugliba beírod, hogy bérszámfejtő program, vagy könyvelő program és kb 4 nagy(obb) cég kivételével mind ilyen Visual Foxpro-s szutyok. A webodalaik szerint nem is kis ügyfélkörrel.
(Mikor a "számítástechnikai programozó" szakdogámat írtam 2003-ban és már akkor elavult nyelvnek számított a foxi, de ezt kellett tanulunk. Vicces, hogy már akkor a tanárok is azt mondták, hogy semmire nem fogunk vele menni, de ezt kell tanítani.)

[ Szerkesztve ]

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

En is a BH Talkot talaltam, viszont erzek nemi ellentmondast a hsz-edben:
"...ha enforceolod a változást, akkor le kell kódolni a logikát is, ami átmigrálja a usereket, ez pedig pénzbe kerül..." vs "...azóta sokat fejlödött a product..."- nyilvan utobbi semmibe nem kerul...

Egyebkent meg nem arrol van szo, hogy a user 8 karaktert allit be, hanem annyit allitott be, amikor meg az volt a requirement. Most nem tudsz 12-nel rovidebbet beallitani, akkor sem, ha megvaltoztatod a master passwordot. Ellenben ha anno 12-nel kevesebbet allitottal be, nem figyelmeztet, nem force-olja, hogy most hosszabb legyen - tehat ez nem a user hulyesege, hanem a LastPasse.

"...Az OWASP 310k-s ajánlása a FIPS-140 compliancere vonatkozik és semmi sem gátolja, hogy feltold az iterációt erre a számra, ha bevállalod a lassabb bejelentkezést..."

Bocsanat, de ez megint nem a user hibaja, ha nem tolja fel - valoszinuleg sokuknak fogalma sincs errol, meg arrol, hova kellene nyulni a toolban, hogy feltolja. A LastPass nagyon buszken hirdeti a "stronger-than-typical" iteracios szamot - sajnos nem reszletezi, mit ertenek tipikusnak. Bitwarden 100001 iteraciot hajt vegre a kliensen es 100000-t a szerver oldalon.

A sajat AES-nek meg megyek utana, mert engem is erdekel.

[ Szerkesztve ]

https://www.coreinfinity.tech