Elsőnek természetesen a Cég és a vele kapcsolatban levő politikusok jószándéka,
mely ingyen van és mégis felbecsülhetetlen. Nemzeti Érték™!
Másodsorban nézzük az EKRSZ_44899914 sz. közbeszerzést, melynek
részletei
itt olvashatóak. Eszerint a Digitális Kormányzati Ügynökség Zártkörűen Működő Részvénytársaság
nyílt eljárásban tendereztette meg a cégeket. A nyertes egy Softline Services Kft. nevű
cég lett (Budapest 3, Galagonya u. 5., adószáma 26187817241), ami a pályázati anyagból
láthatóan egy kisvállalkozás.
A pályázat szerinti 2.194.893 db licencért cserébe ez a kisvállalkozás 7 millió eurót,
mai ráfolyamon hozzávetőlegesen 2,5 milliárd forintot kapott, ami nem rossz
üzlet egy durván 100 ezer dolláros forgalmú cégnek.
A közbeszerzési eljárás amúgy rendben zajlott: mind az egy jelentkező megfelelő ajánlatot
adott be, és sikeresen kiválasztották közülük azt az egyet, aki nyert. Az övé volt a
legolcsóbb ajánlat! Persze a legdrágább is. Meg az összes. De bizonyos, hogy nagyon öldöklő
árverseny folyhatott a beadáskor.
Nézzünk rá a nyertes becsületes, magyar kisvállalkozóra is! A nyertes Softline Services Kft.
egy kis magyar cég,
ügyvezetője a láthatóan üzletileg profi Mészáros Zoltán úr, aki a céget (aminek állítása
szerint 8 alkalmazottja van) egyedül vezetgeti. Szép eredmény!
Talán a képet árnyalja kissé, hogy ezen igazi, magyar kisvállalkozás valójában a Softline Group
nevű cég magyarországi Kft.-je, mely cég 2019-et mintegy 1.54 milliárd dollár forgalommal zárta
(ez mintegy 456 milliárd forint), ami egy „kisvállalkozástól” egészen szép eredmény!
Ezek után már az ember szeme sem rebben amikor megtudja, hogy ez a cégecske valójában Moszkvából
irányítva tengeti napjait, hiszen amúgy is mi gondunk lenne exSzovjet testvéreinkkel, meg
azzal, hogy a befizetett adónk egy része Oroszországba, egy része a Microsoft™ reklámtevékenységére
megy (máshol fizetnek cégek azért, hogy az ő termékükkel etessék be a diákokat, de Magyarországon
mi fizetünk azért, hogy megetessék velünk a reklámjukat), és csak tényleg kis része menjen el a
saját nemzeti politikusaink jobb megélhetését bitosító magánkezelésű alapokba.
Úgyhogy jó ez a „tisztaszoftver”, a mi két és félmilliárd forintunkból, cserébe az ennek töredékébe
kerülő szabad software-ek támogatásával szemben, no meg azzal, hogy a diákok ne csak egyetlen kereskedelmi terméket
ismerve kerüljenek ki az iskolapadból. Mert kétség ne legyen: ha a (legtöbb) tanár alá odatolják a Microsoft™
reklámterméket akkor majd hülye lesz alternatívákat is mutatni a gyerekeknek! És az
a kikerülő dolgozó aki sosem látott mást nem is fog tudni mást használni. Fizet otthon, fizet a
cége, fizet mindenki -- a Microsoft™nak! Jó befektetés -- politikusokat venni.
Avagy: https://o365.oh.gov.hu/ - Ingyenes Office letöltés a Nemzeti Fejlesztés Minisztérium Tisztaszoftver
programjának köszönhetően! -- Az „ingyenes” bizonyos értékeire.
Ez most csak az adminoknak szól, akik spamassassint használnak.
Nagy mennyiségű magyar bankos phishing indult mostanában.
Közösségi jócselekedetként megosztom ez a configot. Az
/etc/spamassassin/hubank.cf file-ba lehet pl. beírni.
(UPDATED: 2020/11/04)
#$Id: rule_hubank_hu.cf,v 6413efa4969d 2020/11/04 12:52:50 grin $
## hungarian fake bank email
if (version >= 3.004002)
ifplugin Mail::SpamAssassin::Plugin::WLBLEval
enlist_addrlist (HUBANK) *@mkb.hu *@raiffeisen.hu
enlist_addrlist (HUBANK) *@otpbank.hu *@otp.hu
enlist_addrlist (HUBANK) *@budapestbank.hu
enlist_addrlist (HUBANK) *@cib.hu
enlist_addrlist (HUBANK) *@erstebank.hu
enlist_addrlist (HUBANK) *@kh.hu
enlist_addrlist (HUBANK) *@unicreditbank.hu
reuse _FROM_ADDRLIST_HUBANKS
reuse FROM_HUBANK_FAKE_RP
header __FROM_ADDRLIST_HUBANKS eval:check_from_in_list('HUBANK')
describe __FROM_ADDRLIST_HUBANKS Felado egy magyar bank
header __EFROM_FROM_COUNTRY_HU X-Envelope-from =~ /\@.+?\.hu>$/i
describe __EFROM_FROM_COUNTRY_HU X-Envelope-from address from .HU
score __EFROM_FROM_COUNTRY_HU -0.1
header FROM_FROM_COUNTRY_HU ALL =~ /^From +\S+\@\S+?\.hu\s/
describe FROM_FROM_COUNTRY_HU From " " hu
score FROM_FROM_COUNTRY_HU -0.01
## ehhez szükséges a loadplugin Mail::SpamAssassin::Plugin::RelayCountry
## az init.pre file-ban.
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /CN|KR|RU/
describe RELAYCOUNTRY_BAD Relayed through China/Korea/Russia at some point
score RELAYCOUNTRY_BAD 2.0
header RELAYCOUNTRY_HU X-Relay-Countries =~ /^HU/
describe RELAYCOUNTRY_HU First untrusted relay is in Hungary
score RELAYCOUNTRY_HU -1.0
meta FROM_HUBANK_FAKE_RP0 __FROM_ADDRLIST_HUBANKS && !__ENV_AND_HDR_FROM_MATCH
describe FROM_HUBANK_FAKE_RP0 Hamisitott magyar bank email, eltero sender/from
score FROM_HUBANK_FAKE_RP0 2.57
meta FROM_HUBANK_FAKE_RP1 __FROM_ADDRLIST_HUBANKS && !__EFROM_FROM_COUNTRY_HU
describe FROM_HUBANK_FAKE_RP1 Hamisitott magyar bank email (nem .hu)
score FROM_HUBANK_FAKE_RP1 4.66
meta FROM_HUBANK_FAKE_RP2 __FROM_ADDRLIST_HUBANKS && !RELAYCOUNTRY_HU
describe FROM_HUBANK_FAKE_RP2 Hamisitott magyar bank email (nem magyar relay)
score FROM_HUBANK_FAKE_RP2 6.66
meta FROM_HUBANK_FAKE_RP3 __FROM_ADDRLIST_HUBANKS && RELAYCOUNTRY_BAD
describe FROM_HUBANK_FAKE_RP3 Hamisitott magyar bank email (spamorszag relay)
score FROM_HUBANK_FAKE_RP3 6.66
endif
endif
Hajótörést szenved és egy lakatlan szigeten köt ki az angol, a német és a szovjet férfi.
A sziget amúgy kellemes, szép, zöld, nem is túl kicsi; nem lenne különösebb bajuk, víz is
van, de a szigeten csak bogyókat, növényeket találnak ennivalóként. Telik-múlik az idő,
és pár hét múlva már mindenki feszült, ideges.
Az egyik portyázásuk során hogy-hogy nem, találnak egy nősténykecskét. Tanakodnak, hogy
megegyék-e, de a német azt mondja, hogy lássák be: az, hogy nincs a szigeten nő igencsak
nagy probléma, és a kecskét esetleg lehetne ilyen célokra is használni. Nem túl sok ellenvetés
hangzik el, így megegyeznek, hogy a kecskét nem eszik meg, hanem az őszinte szerelem eszköze
lesz. Abban is megegyeznek, hogy minden nap egyikük hálhat vele, addig a többiek őket békén
hagyják.
Na, az első nap elmegy a német. Egész nap és egész éjjel elvan, másnap kérdezik a többiek,
hogy milyen volt?
A német lelkendezik. Olyan jó volt, olyan jó hozzábújni, olyan kedves, szelíd teremtés…
Mindenki ámulva hallgatja. Másnap az angol megy el. Utána ő is hihetetlenül lelkesen
mesél.
A harmadik nap a szovjeté, ő is elvonul a kecskével. Másnap reggel nézik, hát a szovjet ott
horkol, a kecske meg sehol. Felrázzák:
– Hol van a kecske, Vologya?!
– Miféle kecske?
– Hogy-hogy miféle? Hát ami itt a szigeten volt. Hol van?
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 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.
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… 😁