Javasolt jelszókezelési irányelvek

Arról már írtam múltkor hogy milyen a jó jelszó, amit alkalmazz. Most arról szeretnék írni, ami ott csak lábjegyzetben szerepelt, hogy milyen jelszót követeljen meg egy szolgáltatás vagy server a felhasználóktól.

A legtöbb helyen még mindig 2003-at ír a naptár: ez volt az az év, amikor szegény Bill Burr elkészítette a ma már közismert „krixkrax jelszó, rendszeresen megváltoztatva” elvet, amiért 2017-ben bocsánatot kért a világtól, és ami olyan dolgokat mondott, mint például

• a jelszó tartalmazzon legalább egy kisbetűt, egy nagybetűt, egy számot, egy írásjelet, egy kínai karaktert, egy hieroglifát, egy ősi magyar rovásjelet és egy láthatatlan karaktert,
• a jelszót kötelező legyen másfél naponta megváltoztatni, és ellenőrizzük, hogy az elmúlt 150 jelszó nem ismétlődik,
• a jelszó minimum 6, maximum 15 karakter lehet,
• a jelszó ne tartalmazzon egymás mellett két számot, két betűt, két hieroglifát, stb…
• alkalmazzunk jelszóemlékeztetőt, pl. „Mi a jó édes anyádnak… a neve?”

…mindezzel hatalmas örömöket okozva az emberek millióinak. A probléma nyilván az volt – mint az menet közben nyilvánvalóvá is vált –, hogy ezeket a jelszavakat az emberek nehezen jegyzik meg és könnyen elfelejtik, viszont a számítógépek könnyen feltörik. Cserébe viszont az emberek felírják azt egy PostIt™re és kiragasztják a monitorra. Vagyis adtunk a csillagnak egy pofont.

NIST Special Publication 800-63B

Az amerikai szabványügy viszont komolyan vette a problémát, és 2017-ben új irányelvet készített, ami szabványban határozza meg a digitális azonosítókkal szemben elvárt követelményeket. Ebben figyelembe vették nem csak azt, hogy mi lenne jó, hanem a múltbéli hibákat és az azokból kialakult káoszt is. Az eredmény egy modern, biztonságos jelszóhasználati ajánlás. Ebből szeretném kiemelni a jó jelszókezelés alapelveit.

A jó jelszókezelés

Az 5. fejezet 5.1.1 pontja szól a jelszavakról, azon belül is az 5.1.1.2 az ajánlott módszerekről. Az ajánlás lényeges részei:

• a jelszó legalább 8 karakteres, és a rendszer képes legyen legalább 64 karakteres jelmondat kezelésére is; ideális esetben a jelszó hossza nem korlátozott;
• a megadott jelszó nem kerül csonkításra kódolás vagy tárolás előtt;
• a jelszó tartalmazhat nyomtatható ASCII (RFC0020) és Szóköz karaktert (az ismétlődő szóközök eltávolítása megengedhető, ha a jelszó hossza nem csökken a minimális alá), és javasolt a Unicode (ISO-10646) karakterek kezelése, normalizálás (NFKC/NFKD) után (minden U kódpont 1 karakterhossznak számít);
• tilos a „jelszóemlékeztetők” használata („Mi volt a neve a gyerekkori Sahelanthropusodnak?”), illetve bármilyen jelszóra utaló „emlékeztető” mutatása azonosítatlan kérdezőnek;
• új jelszó megadásakor szűrésre kerül, hogy ne legyen:
  • ismert betörésben vagy jelszópublikálásban érintett jelszó;
  • szótári szó;
  • ismétlődő sorozat („zzzzzz”, „123abc”);
  • kontextushoz kapcsolható szó (név, felhasználói név, szolgáltatás, dátum, vagy ezekből származó részek).
  és amennyiben emiatt kerül a jelszó elutasításra, a rendszer közölje a pontos okát, és kérjen új jelszót.
• új jelszó megadásakor nyújtsunk segítséget „jelszóerősség” kijelzésével a biztonságos jelszó kiválasztásához, ez különösen fontos, hogy a rendszer segítse az előző pontban visszautasított okokból nem megfelelő jelszó helyett egy jó választását ahelyett, hogy az elutasított jelszó triviális módosításával próbálkozna a személy;
• a jelszópróbálkozások száma és gyakorisága korlátozott;
• semmilyen további korlátozás nem vonatkozik a jelszóra (mint amilyen a bizonyos karaktercsoportok használata, vagy bizonyos párok tiltása);
• nincs jelszónak kötelező, véletlenszerű vagy periodikus változtatása, de automatikusan és azonnal meg kell változtatni bármilyen biztonsági incidens esetén;
• engedélyezett a jelszó másolása és beszúrása, hogy a jelszavak kezelése jelszókezelővel is történhessen;
• a felhasználó kérésére a jelszó láthatóvá válhat elküldés előtt, megkönnyíteni a gépelési hibák elkerülését (vagy az utoljára megadott karakter, például mobileszközök esetében);
• a jelszavak tárolása titkosítási eljárással történjen, méghozzá olyannal, amit kifejezetten jelszavak tárolására fejlesztettek, vagy arra kifejezetten alkalmas;
• lehetőleg a jelszó kódolás előtt Key derivation függvénnyel kerüljön feldolgozásra (mint amilyen a PBKDF2 [min. 10000 iteráció], a Balloon vagy az Argon2), a tárolás pedig hashed és salted (min. 32 bit) formában történjen.

PS: Az Ön „titok꧁𓁵قᬎজ⠮щडφઊשひಊギആᠪ𐲍ᚫࠇඉᜈஐ༆𠂢꧂” jelszava nem tartalmaz számot és legalább két székely rovásjelet… 😁

Az adatbázisok szerzői jogi védelméről

Rendszeresen előkerülő kérdés, hogy abban az esetben, amikor valaki fog egy csomó szerzői jog által nem védett adatot (például egy település összes utcájának nevét) és azokból csinál egy listát (ami készülhet kézzel vagy számítógéppel), és ezt a listát nyilvánosságra is hozza, akkor mit lehet ezzel az adatbázissal jogszerűen csinálni.

A Szerzői jogi törvény (1999. évi LXXVI. törvény) vonatkozik erre az esetre, és nézzük, hogy mi ebben a kérdésben az én véleményem. Tegyük hozzá, hogy nem vagyok jogász, semi bíró, sem egyéb szakember, mindössze nagyrészt 20 éve foglalkozom szerzői jogi esetekkel.

Elöljáróban, egy mondatban:

A védelem az adatbázis egészére, vagy jelentős részére vonatkozik, és ott is általában a közvetlen másolásra vagy számítástechnikai automatizmus általi átvételre, és csak akkor, ha az adatbázis tartalmának válogatása kreatív tevékenység eredménye („nem automatizmus”).

Rövid összefoglaló

• csak akkor esik védelem alá, ha „tartalmának összeválogatása, elrendezése vagy szerkesztése egyéni, eredeti jellegű” (7.§ (1)), vagyis ha az adatbázis tartalmának összeállítása nem kreatív tevékenység (mert például „minden” házszámot, „minden” utcanevet, „minden” természetben előforduló, egyértelmű adatot, stb. tartalmaz) akkor az nem esik védelem alá.
• csak akkor illeti meg védelem az adatbázis előállítóját, ha az „az adatbázis tartalmának megszerzése, ellenőrzése vagy megjelenítése jelentős ráfordítást igényelt.” (Kérdéses, hogy a közpénz ráfodítása hogyan számít e szempontból, illetve hogy az amúgy is törvény által előírt kötelezettségként előállított adatbázisból publikált rész-adatbázis esetén, ami gyakorlatilag automatikusan és további jelentős ráfordítás nélkül előáll, ezt hogyan veszi a T. bíróság figyelembe.)
• általánosságban az adatbázisok védelme csak az adatbázis egészét vagy jelentős részét érinti (7.§(3), 84/A.§ (1)), beleértve nyilvánosságra hozatalt is (84/A.§(1)(b), 26.§(8))
• rendszeresen is lehet az adatbázis jelentéktelen részét kimásolni, ha „az nem sérelmes az adatbázis rendes felhasználására és indokolatlanul nem károsítja az adatbázis előállítójának jogos érdekeit.” (Ha egy adatbázist szabadon elérhetően publikálnak, akkor vélelmezhetően nem sérti a további publikáció az előállító érdekeit, és nem sérelmes az egyéb felhasználásokra sem.)
• jelentéktelen részt akár rendszeresen is fel lehet használni (84/B.§(1))
• magáncélra az adatbázis jelentős része is használható (84/C.§ (1)), de nem hozható nyilvánosságra.

A szerzői jogi törvény vonatkozó részei

7. § (1) Szerzői jogi védelemben részesül a gyűjtemény, ha tartalmának összeválogatása, elrendezése vagy szerkesztése egyéni, eredeti jellegű (gyűjteményes mű). A védelem a gyűjteményes művet megilleti akkor is, ha annak részei, tartalmi elemei nem részesülnek, illetve nem részesülhetnek szerzői jogi védelemben.
(3) A gyűjteményes mű szerzői jogi védelme nem terjed ki a gyűjteményes mű tartalmi elemeire.

60/A. § (1) E törvény alkalmazásában adatbázis: önálló művek, adatok vagy egyéb tartalmi elemek valamely rendszer vagy módszer szerint elrendezett gyűjteménye, amelynek tartalmi elemeihez – számítástechnikai eszközökkel vagy bármely más módon – egyedileg hozzá lehet férni.

61. § (1) Szerzői jogi védelemben részesül a gyűjteményes műnek (7. §) minősülő adatbázis.

84/A. § (1) Ha a törvény eltérően nem rendelkezik, az adatbázis (60/A. §) előállítójának hozzájárulása szükséges ahhoz, hogy az adatbázis tartalmának egészét vagy jelentős részét
a) másolat készítése útján [18. § (1) bek. b) pont] többszörözzék (a továbbiakban: kimásolás);
b) a nyilvánosság számára hozzáférhetővé tegyék az adatbázis példányainak terjesztésével vagy – a 26. § (8) bekezdésében szabályozott módon – a nyilvánossághoz való közvetítéssel (a továbbiakban: újrahasznosítás).
(3) Az adatbázis előállítójának hozzájárulása nélkül ismételten és rendszeresen nem másolható ki, illetve nem hasznosítható újra az adatbázis tartalmának jelentéktelen része sem, ha ez sérelmes az adatbázis rendes felhasználására, vagy indokolatlanul károsítja az adatbázis előállítójának jogos érdekeit.
(5) Az adatbázis előállítóját akkor illetik meg az (1)–(3) bekezdésben szabályozott jogok, ha az adatbázis tartalmának megszerzése, ellenőrzése vagy megjelenítése jelentős ráfordítást igényelt.

84/B. § (1) Nem szükséges az adatbázis előállítójának hozzájárulása ahhoz, hogy a nyilvánosságra hozott adatbázist jogszerűen felhasználó személy az adatbázis tartalmának jelentéktelen részét – akár ismételten és rendszeresen is – kimásolja, illetve újrahasznosítsa.

84/C. § (1) Magáncélra bárki kimásolhatja az adatbázis tartalmának jelentős részét is, ha az jövedelemszerzés vagy jövedelemfokozás célját közvetve sem szolgálja. E rendelkezés nem vonatkozik a számítástechnikai eszközökkel működtetett adatbázisra. (4)168 A szabad felhasználásnak az (1)–(3a) bekezdésben szabályozott eseteire a 33. §-t megfelelően alkalmazni kell.

Visszajelzés

Ha valaki jogvégzett úgy véli, hogy jól írtam, vagy nem jól írtam, akkor örömmel veszem a visszajelzést.

E-Kárbejelentő App

eKárbejelentő tapasztalatok

Megosztom veletek a tapasztalataimat ritka „karamboljaim” során tapasztaltakról, azon reményben, hogy hátha valaki okosságokat nyer belőle (amit nem is nagyon értek, hiszen én nem vagyok okos, csak sokat beszélek, na de mindegy, ez most nem téma).

A körülményekről nem sokat érdemes mondani: robogós rosszkor rossz felől előzött, megkapta a hátsó ajtót. Mindenki normális, de nem értünk egyet, senki nem siet, így hívtunk egy rendőrt, és rá várunk.

Előrelátó hősünk még hónapokkal ezelőtt találkozott a MABISZ által preferált mobiltelefonos appal, az e-Kárbejelentővel, és előrelátóan le is volt töltve a telómra. (Most nem szapulom azokat, akik Apple termékekre költik azt a pénzt, amit el is ihatának amellett, hogy lenne egy normális Androidos telójuk, de itt a link nekik is. :-)) Mivel a törzselvtársra úgyis várni kell, a embernek van ideje bepötyögni azt a valóban rengeteg adatot, amit a program kér.

Az első tanulság máris ez: egy csomó adatot érdemes otthon előre bepötyögni, mivel azt később egy kattintásra elő lehet hívni! Különösen, mivel olyan adatokat is kér, hogyaszongya „biztosítási szerződés száma, kötésének ideje”, vagy „alvázszám” (ezt mindenki imádja bepötyögni), mindenképp javasolt ezt egyszer, otthon, nyugodt körülmények között megélni.

A program amúgy egészen jól meg van írva, de stabil internet kapcsolat kell neki. (Elkezdtem írni, hogy „valószínűleg”, de aztán előkaptam, kikapcsoltam a netet, elindítottam és azonnal közölte, hogy NO NET NO CRY, szóval internet nélkül felejtsd el, ami szerintem egy alapvetően béna megoldás, hiszen később is be lehetne küldeni.) Különösen érdekes, hogy amennyiben a karambol mindkét résztvevőjénél van ilyen app, akkor mindenki kitölti a saját részét a saját telóján és a rendszer összegyurmázza a végén; az egyik ember elkezdi, és a másik a kapott kóddal csatlakozik a bejelentéshez. Ez nekünk azonnal ment.

Amint megvan mindkettőnknek a kapcsolat, a program szépen végigvezet a kitöltésen: baleset adatok, gépjármű és szerződés adatok, a vezető adatai, a karambol körülményei, a szituáció és vázlat, a felelősségi nyilatkozat. Emellett lehet hozzá fényképeket is csatolni (segít, hogy mi legyen a képen). Ha volt rendőri intézkedés, annak az adatait is bekéri. A végén ha a „B” résztvevő befejezte a bevitelt, akkor az „A” jelű le tudja zárni, és akár azonnal beküldeni (vagy mindkettő beküldi, ezt nem tudom, de mindkét telefonon megmarad az összes adat). A kék-sárgát innentől bármikor le lehet tölteni PDF-ben és akár nyomtatni.

Amúgy a rendőrök kint voltak 10 percen belül, gyorsak és segítőkészek voltak amit ezúton is szeretnék a XI. kerületi őrsnek megköszönni. Azt mondták hogy én vagyok a white-hat, a robogós a black-hat, megírták, elmentek. Ezt beleírtuk még az applikációba.

Beküldés után engem még aznap felhívott a másik fél biztosítója, hogy egyeztessünk kárszakértőt, aki amúgy szintén pár napoon belül kijött. Itt kicsit naív voltam, mert azt hittem, hogy amikor ő azt mondja, hogy „itt most megcsinál mindent, akkor csak annyi, hogy bemegyek a servízbe, adok nekik egy megbízást hogy ügyintézzenek, és nekem csak annyi a dolgom hogy begurulok a nemjó és kigurulok a jó autóval” (nem, nem akartam egyedi megegyezést, amikor ők adnak feleannyi pénzt és megoldhatom negyedannyiért, ha tudom), de erről készőbb. Mindenesetre ő is gyors volt, megírta a kárfelvételi jegyzőkönyvet, hogy azzal mehetek a sörvízbe.

Itt pottyant egy kis kaki a csokitortába, amikor a servíz szépen felvette az adatokat, eljöttem, ráadásul pont Autorizált Adottbiztosító Partnerek, így Minden A Lehető Leggyorsabban Fog Zajolni™, majd másnap emailtek hogy hát kellene a baleseti bejelentő. What the kutyafasza? Hát mindent megkaptak elektronikusan, meg hát a kárfelmérés vajjon mi alapján ment mégis, de jó, PDF export, PDF elküld, happy. Na ma kapom megint email vala, hogyaszongya ez nem a Kárbejelentő™ hanem a Baleseti Bejelentő™ és nekik töltsek ki a BiztosítóWeblapjánIsLetölthető™ 2 oldalas PDF-et, amiben minden benne van, ami az elektronikus formban volt.

Egyelőre itt tartunk, várom a biztosító telefonját, hogy megkérdezzem, hogy mi a szomorú kínai pandafaszért kellene megint ugyanazokat az adatokat megadnom egy papírra írva. Alig vagyok kíváncsi.

Frissítés: a TetszőlegesBiztosító felhívott, hogy a „tökéletes” megoldás az, ha a PDF-et letöltöm, kinyomtatom papírra, kézzel kitöltöm (ugyanazokkal az adatokkal, ami megvan nekik elektronikusan), bescannelem, elküldöm emailben, miután ők azt kézzel begépelik. Nem szeretném ezt jelzőkkel illetni azon túl, hogy valóban, ez Tök Életes™ megoldás, a 19. század csúcstechnológiája.

De összességében a rendszer szerintem működik, érdekes látni, hogy az internet nem csak elpusztítja a világot, hanem, sőt, vagy is. Addig is vezessetek óvatosan, ami nem segít, mert úgyis valaki más nem fog. ;-)

What can be learned from the break-in of Matrix.org?

It's been a short news story that matrix.org's largest server was hacked into, and they have reached one homeserver of the decentralised chat network and was able to access information generally closed from the large public (but accessibe for a server operator).

As a nice touch the person who's been behind the breakin was nice enough to share his/her thoughts about the case, and I believe (despite the fact that GitHub have been deleted the comments) there's lot to learn from the useful advices of out black hat colleague.

Let me share them with you, a bit trimmed and rephrased here and there.

• The original break-in was made possible by a Jenkins bugs (CVE-2019-1003000, CVE-2019-1003001 and CVE-2019-1003002) which made it possible to run arbitrary code on the server. This happens.

• Complete compromise could have been avoided if developers were prohibited from using ForwardAgent yes or not using -A in their SSH commands. The flaws with agent forwarding are well documented.

  This is a reference on various posts calling for avoiding AgentForward and use ProxyCommand (ProxyJump) instead.

• Escalation could have been avoided if developers only had the access they absolutely required and did not have root access to all of the servers. I would like to take a moment to thank whichever developer forwarded their agent to Flywheel. Without you, none of this would have been possible.
• Once I was in the network, a copy of your wiki really helped me out and I found that someone was forwarding 22226 to Flywheel. With jenkins access, this allowed me to add my own key to the host and make myself at home. There appeared to be no legitimate reason for this port forward, especially since jenkinstunnel was being used to establish the communication between Themis and Flywheel.
• * I was able to login to all servers via an internet address. There should be no good reason to have your management ports exposed to the entire internet. Consider restricting access to production to either a vpn or a bastion host.
• * On each host, I tried to avoid writing directly to authorized_keys, because after a thorough peak at matrix-ansible-private I realized that access could have been removed any time an employee added a new key or did something else to redeploy users. But sshd_config allowed me to keep keys in authorized_keys2 and not have to worry about ansible locking me out.
• * The internal-config repository contained sensitive data, and the whole repository was often cloned onto hosts and left there for long periods of time, even if most of the configs were not used on that host. Hosts should only have the configs necessary for them to function, and nothing else. Kudos on using Passbolt. Things could have gotten real messy, otherwise.
• * Let's face it, I'm not a very sophisticated attacker. There was no crazy malware or rootkits. It was ssh agent forwarding and authorized_keys2, through and through. Well okay, and that jenkins 0ld-day. This could have been detected by better monitoring of log files and alerting on anomalous behavior. Compromise began well over a month ago, consider deploying an elastic stack and collecting logs centrally for your production environment.
• * There I was, just going about my business, looking for ways I could get higher levels of access and explore your network more, when I stumbled across GPG keys that were used for signing your debian packages. It gave me many nefarious ideas. I would recommend that you don't keep any signing keys on production hosts, and instead do all of your signing in a secure environment.
• * 2FA is often touted as one of the best steps you can take for securing your servers, and for good reason! If you'd deployed google's free authenticator module (sudo apt install libpam-google-authenticator), I would have never been able to ssh into any of those servers. Alternatively, for extra security, you could require yubikeys to access production infrastructure. Yubikeys are cool. Just make sure you don't leave it plugged in all the time, your hardware token doesn't do as much for you when it's always plugged in and ready for me to use. Alternate-Alternatively, if you had used a 2FA solution like Duo, you could have gotten a push notification the first time I tried to ssh to any of your hosts, and you would have caught me on day one. I'm sure you can setup push notifications for watching google-authenticator attempts as well, which could have at least given you a heads up that something fishy was going on. Anyways, that's all for now. I hope this series of issues has given you some good ideas for how to prevent this level of compromise in the future. Security doesn't work retroactively, but I believe in you and I think you'll come back from this even stronger than before.

Metric system

In metric, one milliliter of water occupies one cubic centimeter, weighs one gram, and requires one calorie of energy to heat up by one degree centigrade—which is 1 percent of the difference between its freezing point and its boiling point. An amount of hydrogen weighing the same amount has exactly one mole of atoms in it. Whereas in the American system, the answer to ‘How much energy does it take to boil a room-temperature gallon of water?’ is ‘Go fuck yourself,’ because you can’t directly relate any of those quantities.

– Josh Bazell: The Wild Thing (2012)

---

A metrikus rendszerben egy milliliternyi víz egy köbcentiméter térfogatú, a súlya egy gramm, és ahhoz, hogy egy celsius-fokkal emelkedjen a hőmérséklete pontosan 1 kalória^[1] energia szükséges, ami a forráspontja és a fagypontja közötti különbségnek egy százaléka. Egy pontosan ilyen súlyú hidrogén-mennyiségben pontosan egy mólnyi atom van. Mindeközben az amerikai mértékegységrendszerben arra a kérdésre, hogy „Mennyi energia szükséges egy gallon szobahőmérsékletű víz felforralásához?” a megfelelő válasz a „Baszódj meg”, mert képtelenség azokat a mennyiségeket közvetlenül összekapcsolni.

1: igen, a kalória nem SI mértékegység. Humort magyarázni…