security címkéhez tartozó bejegyzések

Miért gyengíted a jelszavamat?

Nem tudom, ki hogy van vele, én nem szeretem sűrűn változtatni a jelszavaimat. Egyszerűen azért, mert macerás, viszi az időmet. A szolgáltatásokat használni szeretem, nem a beállításaikkal bíbelődni. Ennek ellenére – részben az utóbbi időszakban közzétett ellopott jelszó adatbázisoknak köszönhetően – rászoktattam magam, hogy a korábbiaknál gyakrabban cseréljem a jelszavaimat.

Az ilyenkor szokásos ajánlás, hogy a jelszó legyen komplex, és ne használjuk több helyen. Számomra komplex az, ami elég hosszú, van benne kisbetű, nagybetű, szám és még valamilyen speciális karakter is. Csakhogy nem kevés olyan weboldal van, ami ezt nem engedi beállítani.

Íme az egyik:

Aegon

Én ezt nem értem, miért nem használhatok ékezetes karaktereket? Csak nem varchar van az adatbázisban nvarchar helyett? Miért nem használhatok extra karaktereket, talán SQL injectiontől féltek? Gondoltam megkérdezem:

Aegon-Twitter

Valószínűleg rossz csatornán tettem, a Twitter fiókjukat évek óta nem frissítették, és a jelek szerint nem is olvassák. Vagy csak fittyet hánynak rá.

Persze nem ők az egyetlenek, a Nemzeti Útdíjfizetési Szolgáltató is hasonló cipőben jár:

NemzetiUtdij-Twitter

Sőt! Ők nem mondják meg, hogy mit nem tartalmazhat a jelszó, egyszerűen csak “Nem megfelelő formátum” hibaüzenetet írnak ki. Twitteren nem találtam meg őket, de megírtam nekik a kérdésemet, és alig 17 nap alatt válaszoltak is egy 5 (!) oldalas levéllel, amiből a következőket tudtam meg:

“Tárgy: Autópálya használati díj fizetésének ellenőrzése”

Ajjaj, szerintem nem, de ezen lépjünk túl. Kaptam Iktatószámot is, úgy látszik azért komolyan vesznek.

“Tisztelt Balássy György!
Társaságunkhoz intézett megkeresését köszönjük.”

Eddig minden rendben, piros pont a két-s-ipszilonért.

“Tájékoztatjuk, hogy a jelszó csupán az angol abc kis- és nagybetűiből állhat, valamint számokból.”

Ezen pattogok én is.

“Fontos, hogy egységes karakterek legyenek megadhatóak, hiszen vannak külföldi ügyfeleink, akik nem feltétlen rendelkeznek magyar billentyűzettel, ezáltal pl.: ékezettel.
A belépést és regisztrációt mindenki számára elérhetővé kell tennünk, ami az angol abc használatával valósul meg.”

Álljunk meg egy szóra. Nem úgy van ez, hogy én választok magamnak jelszót, amit azután én a saját kezemmel, a saját billentyűzetemmel gépelek be? Amilyen karaktert nem tartalmaz a billentyűzetem, azt nyilván nem fogom és ezért nem is akarom beírni, de amit tartalmaz, azt nagyon szeretném. Orosz karakter például biztosan nem lesz a jelszavamban, de csak azért nem, mert én úgy akarom.

“Továbbá attól, hogy nem adható meg ékezet és speciális karakter, még nem lesz gyengébb a jelszó.”

Ez egyszerűen nem igaz (feltételezve, hogy ugyanazt értjük “gyengébb” alatt).  Fejtegethetnénk itt most a problématér méretét, ki is próbálhatnánk L0phtCrackkel vagy John the Ripperrel, hogy kinek van igaza, de mivel a levél írójától sem várom el, hogy ilyen eszközökkel rendelkezzen, nézzünk inkább néhány kevésbé tudományos eszközt a Google találati listájáról, amik megmondják, hogy szerintük a különböző jelszavakat mennyi ideig tart feltörni:

 

“almafa”

“álmáfá”

“álmáfá!”

https://howsecureismypassword.net/

8 ms

1 perc

5 óra

https://password.kaspersky.com/

9 perc

3 óra

2 nap

http://www.passwordmeter.com/

5% – Very Weak

45% – Good

60% – Strong

http://random-ize.com/how-long-to-hack-pass/

kevesebb, mint 1 másodperc

13 másodperc

12 perc 57 másodperc

http://password-checker.online-domain-tools.com/

3 másodperc

1 nap

2 év

A számok pontosak? Valószínűleg nem, sőt még az arányaik sem azonosak. Az viszont tisztán látszik, hogy nem azonos nagyságrendben mozognak az egyes oszlopokban szereplő értékek.

“Javasolhatjuk továbbá, hogy szíveskedjen nagybetűt használni, ez még inkább növeli a jelszó erősségét.”

Mihez képest? Az angol abc kis- és nagybetűihez, valamint a számokhoz képest? Azt már használok, köszönöm.

A levél további 4 és fél oldala arról szól, hogy a fogyasztóvédelmi törvény szerint mit tehetek és hova fordulhatok, ha nem vagyok elégedett: ügyfélszolgálat, e-ügyfélszolgálat, levelezési cím, személyes ügyintézés, békéltető testület, bíróság stb. Egyébként ISO 9001, ISO 14001, BS OHSAS 18001, Certified IQNet Management System minősítésekről árulkodik még a levél.

A jó hír az, hogy itt legalább hosszú jelszót be tudok írni, amivel azért van lehetőségem elfogadható erősségű jelszót megadni, még ha nem is használhatom azt, amelyiket én szeretném. Nagyságrenddel rosszabbak azok az oldalak, ahol a jelszó hossza korlátozott.

Ezzel együtt az ilyen korlátozások bennem azt a gyanút ébresztik, hogy valami nem stimmel az oldal jelszó kezelése környékén, hiszen a hash algoritmusoknak nem szokott problémát okozni pár ékezet, aposztróf vagy felkiáltójel.

Mit tegyünk ezekkel a weboldalakkal?

 

Technorati-címkék: ,

Chocolatey és a biztonság

Úgy döntöttem, hogy a Windows 10-zel frissen újratelepített gépemre Chocolatey-vel fogom feltelepíteni az alkalmazásokat. Valójában az első ötletem az volt, hogy OneGet-et fogok használni, ami a Windows 10-ben megjelent csomagkezelő-kezelő, és aminek van egy előzetes Chocolatey providere, de mivel ezzel rövid kísérletezés után nem sok sikerélményem volt, maradtam közvetlenül a Chocolatey-nél.

Az első lépés a Chocolatey telepítése, aminek legegyszerűbb módja admin parancssorban annak az egysoros szkriptnek a futtatása, ami megtalálható a chocolatey.org honlapon:

C:\> @powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1’))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Ezzel a paranccsal három dolgot érünk el egy csapásra:

  1. Letöltünk egy PowerShell szkriptet.
  2. Futtatjuk a letöltött szkriptet a saját gépünkön rendszergazdai jogosultságokkal.
  3. Kiegészítjük a PATH környezeti változónkat.

Nem tudom, ki hogy van vele, a 2. lépéstől kiráz a hideg. És ha már itt tartunk, álljunk meg egy pillanatra és gondoljuk végig, mire vállalkozunk: gyakorlatilag ismeretlen forrásból származó alkalmazásokat fogunk telepíteni a gépünkre, hiszen amikor kiadjuk mondjuk a

choco install adobereader

parancsot, akkor fogalmunk sincs, hogy honnan mi fog letöltődni és települni a gépünkre.

Mit tehetünk?

Először is csak olyan choco csomagokat telepítsünk, amiket moderátorok jóváhagytak. A moderálás egy manuális folyamat, csúszhat bele hiba, de mégis egyfajta ellenőrzés. Egy moderált csomag, például az Adobe Reader oldalán ez jelenik meg felül nagy zöld keretben:

This package was approved by moderator gep13 on 6/11/2015.

Egy moderátori ellenőrzésen nem átesett csomag, például a Notepad2 esetén ugyanott piros keretben ezt találjuk:

This package was submitted prior to moderation and has not been approved. While it is likely safe for you, there is more risk involved.

Ha már a csomag részletes oldalán vagyunk, érdemes elolvasni mindent, amit ott találunk. Például a 7-zip csomag oldalán ezzel a figyelmeztetéssel találkozhatunk:

NOTE: The installer for 7-Zip is known to close the explorer process. This means you may lose current work.

Ugyanitt találkozhatunk hasznos opciókkal is, például Firefox esetén megadhatjuk, milyen nyelvű verziót szeretnénk telepíteni:

choco install Firefox -packageParameters "l=en-US"

Ha pedig egy kicsit lejjebb görgetünk, a kommentek között találhatunk olyan utalásokat, amik eltántoríthatnak minket egy-egy csomag telepítésétől. A CDBurnerXP csomag kommentjei között megemlítik az OpenCandy nevű szemetet, amiről eszembe jutott, hogy bizony nem egy olyan telepítővel találkoztam már, amin ha ész nélkül next-next-finish-sel megyünk végig, kapunk “ajándékba” egyéb programokat is.

Az oldal közepe táján sok esetben megtaláljuk a telepítő PowerShell szkriptet, érdemes lehet átnézni, mert abból kiderülhet, hogy milyen telepítőcsomagot tölt le és honnan. Az Adobe Reader csomagjánál ez a szkript mindössze 6 sor, a közepén ott virít az URL és könnyen érthető, hogy mi történik. De ugyanezt nem lehet elmondani a Firefox csomag 117 soros szkriptjéről, vagy a Node.js csomag egyetlen soros szkriptjéről, ami két másik csomagra hivatkozik.

Összességében a Chocolatey használata véleményem szerint egy jókora lutri. Elvégezhetjük ezeket a manuális ellenőrzéseket, frissíthetjük az operációs rendszerünket, beüzemelhetünk egy víruskeresőt, kiszűrhetjük a csibész hostokat, de a végeredmény az, hogy ismeretlen szerző ismeretlen kódját futtatjuk a gépünkön, ami sehogy sem tűnik jó ötletnek.

Én ezeket a csomagokat telepítettem fel, egyelőre nem égett le a ház tőlük:

adobereader
7zip
emet
fiddler
filezilla
firefox -packageParameters "l=en-US"
gitextensions
google-chrome-x64
join.me
keepass
nodejs
paint.net
silverlight
skype
sysinternals
vlc

Ti mit gondoltok, használtok ilyet, meritek használni, és ha igen, milyen csomagokat szoktatok még feltenni?

 

Technorati-címkék: ,,

Bitlocker TPM nélkül

A közhiedelemmel ellentétben igenis használható a Windows beépített Bitlockere a merevlemez tartalmának titkosítására akkor is, ha nincs a gépünkben TPM chip. Azokat a meghajtókat, amik az adatainkat tartalmazzák, simán hagyja is a Windows titkosítani, mindössze egy jelszót kér, és felajánlja a recovery key mentését fájlba, USB meghajtóra, sőt akár a felhőbe is. Ha viszont a C: meghajtónkat akarjuk bebitlockerezni, akkor találkozhatunk ezzel a hibaüzenettel:

This device can’t use a Trusted Platform Module. Your administrator must set the “Allow BitLocker without a compatible TPM” option in the “Require additional authentication at startup” policy for OS volumes.

bitlocker-1-tpm-error

Szerintem ez egy egészen jó hibaüzenet, mert megmondja, hogy mi a gond, és azt is, hogyan tudunk kimászni belőle. Ha még azt is megmondaná, hol keressük pontosan ezt a beállítást, egészen tökéletes lenne!

A “policy” szóra keresve ugyanis léptem nyomon a Local Security Policy-ba futhatunk bele, pedig nem az kell. A Group Policy Object Editorra van szükségünk még akkor is, ha workgroupban van az adott gép és nem tartományban. (A csoportházirendekről nekem mindig a címtár jut eszembe…)

Indítsunk tehát egy Microsoft Management Console-t (mmc), majd adjuk hozzá a Group Policy Object Editor snap-int (katt a teljes képért):

bitlocker-2-mmc-add-snapin

Ezen belül a Local Computer Policy –> Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives ág alatt találhatjuk meg a hibaüzenetben megjelölt beállítást:

bitlocker-3-policy-path

A beállításra duplán kattintva előbb válasszuk ki az Enabled lehetőséget, majd alul pipáljuk be az Allow Bitlocker without a compatible TPM jelölőnégyzetet:

bitlocker-4-policy-setting

Miután mindent leokéztunk még frissítenünk kell a házirendet, amit a gépünk újraindítása nélkül legegyszerűbben parancssorból a gpupdate parancs kiadásával tehetünk meg:

bitlocker-5-gpupdate

Ezután már gond nélkül titkosíthatjuk az operációs rendszert tartalmazó meghajtónkat is.

 

Technorati-címkék: ,,

E-mail címeket karácsonyra

Karácsony előtt megnövekszik azoknak a kéretlen leveleknek a száma, amik valamit rá akarnak sózni az emberre. Az alábbi egy kicsit kilóg a sorból:

email-lists-1

Igen, e-mail cím listákat árulnak, néhányszor tíz dollárért, országonkénti bontásban. Összesen 228 ország szerepel a listában, az árak 50 és 500 dollár között változnak, Tanzánia például az olcsóbb kategóriába esik, a legdrágább pedig az Egyesült Királyság. Az ár szempontjából Magyarország igen előkelő helyet foglal el:

email-lists-2

Alig több, mint 100 ezer forintért közel 423 ezer e-mail címet vásárolhatunk, azaz egyetlen címért körülbelül egynegyed forintot kell fizetnünk. Ennyit ér tehát a postaládánk a feketepiacon. (Talán itt érdemes egy pillanatra megállnunk és elgondolkodnunk, hogy nekünk mennyit ér.)

Nézzük, hogy ez mit jelent a többi országhoz képest, például tekintsük azokat, akik velünk egy árkategóriában ($400) vannak:

Ország Darabszám Egységár
Oroszország 2.006.321 0,05 Ft
Franciaország 1.393.935 0,07 Ft
Kanada 1.288.691 0,08 Ft
Csehország 1.236.800 0,08 Ft
Olaszország 1.207.026 0,09 Ft
Japán 1.170.301 0,09 Ft
Ausztrália 1.087.139 0,09 Ft
Lengyelország 796.495 0,13 Ft
Kína 604.476 0,17 Ft
Magyarország 422.919 0,24 Ft

A táblázat szerint nem csak a nagy országokéhoz, hanem a környező országok áraihoz képest is drága a magyar e-mail cím. Minőségi magyar termék 😉

Persze modern karácsonyról lévén szó, nem egyszerű termékről van szó, hanem SaaS ajánlatról, ami ezúttal Spam az a Service-t jelent:

email-lists-3

Ha ismét matekozunk egy kicsit, akkor az jön ki, hogy 5 fillérért küldhetünk ki egy kéretlen levelet bármelyik országba. Sokkal kedvezőbb, mint a hagyományos posta!

Ráadásul biztosak lehetünk abban, hogy a szolgáltatás működik, hiszen én is megkaptam ezt a kéretlen levelet. Ha nem érdekel, vajon kattintsak a levél végén található “Unsubscribe” linkre? 😉

 

Technorati Tags: ,,

HTTPS: rendesen vagy sehogy

Volt szerencsém Bolognába látogatni nyáron, és örömmel láttam, hogy a repülőtéren ingyenes wifi szolgáltatás van. Lehet, hogy már ekkor gyanakodnom kellett volna, de igazából akkor kezdett a dolog furcsa lenni, amikor a felkapcsolódás után ez az oldal fogadott a böngészőben:

airport-ssl-warning

A hibaüzenet szerint az oldalhoz tartozó SSL tanúsítvány “kicsit” hibás:

  • Nem megbízható a kiállítója.
  • Lejárt az érvényessége.
  • Másik weboldalra szól.

Valójában csak akkor lehetne hibásabb, ha már vissza is vonták volna a tanúsítványt.

Aki mégis továbblép, az ezzel az oldallal találkozhat a bolognai reptéren:

airport-webpage

Igazán eredeti dizájn. Oké, Bologna nem egy metropolisz, de a helyi egyetemen simán találhattak volna egy unatkozó diákot, aki egy hétvége alatt pofásabb weboldalt tud összedobni.

Ekkor már kíváncsi lettem és kis kísérletezéssel hamar kiderült, hogy a weboldalnak semmi köze ahhoz, hogy működik-e az internet hozzáférés, vagy sem.

Sok már itt a gyanús tényező:

  • Tanúsítvány
  • IP cím
  • Dizájn
  • Telefonszám gyűjtögetés

Ez volt az a pillanat, amikor konkrétan felálltam és körülnéztem, hátha ott ül valahol Troy Hunt az ő Pineapple-jével.

Egy rendes SSL tanúsítvány ezeket a kétségeimet könnyen eloszlathatta volna. De az ilyen, érvénytelen tanúsítvány semmire nem jó, mindössze annyit garantál, hogy az átlagfelhasználót idegesíteni fogja az oldal, a szakértőbb felhasználók pedig aggódni fognak az adataik biztonsága miatt. Aki HTTPS-re adja a fejét, csinálja rendesen, különben csak az ellenkezőjét éri el vele.

 

Technorati-címkék: ,

Mixed content warning

Szomorú, amikor így széthullik egy oldal a böngészőben, például Chrome-ban:

mixed content chrome

Hogy miért? Hát nem nyilvánvaló, ott van a magyarázat. Segítek:

mixed content chrome warning small

Úgy hívják, hogy mixed content warning, és warning, azaz figyelmeztetés létére nem éppen feltűnő. Lássuk ugyanezt Firefoxban:

mixed content FF

Megvan?

mixed content FF blocked small

Az Internet Explorer kevésbé finomkodik, azonnal a felhívja a felhasználó figyelmét:

mixed content warning

Bár itt nem egy pajzs ikont kell keresgélnünk (amit egyébként túl sokszor, túl sok mindenre használtak már), hanem rögtön kapunk egy szöveges üzenetet, semennyivel sem jobb a helyzet. Ezt az üzenetet, és úgy általában a problémát, ugyanis egy átlagos felhasználó nem érti. Sőt, nem csak hogy a felhasználók nem értik, de a fejlesztők sincsenek tisztában a biztonsági vonatkozásokkal, különben nem lennének ilyen problémás oldalak.

Pedig arra kellene csak figyelni, hogy ha az oldal https:// protokollon töltődik be, akkor az oldalra betöltődő összes (igen, az összes) tartalom is https-en jöjjön, ne legyen egyetlen http:// link sem az oldal kódjában. Ha külső domainről töltesz be tartalmat, és nem tudsz relatív URL-t használni, akkor kezdd az URL-t “//”-rel, és a böngésző azt a protokollt fogja használni, amit az oldal is használ. Ezt a hívják, hogy “protocol relative”, vagy “scheme relative” vagy “scheme-less relative” URL, és már az URI általános formáját leíró RFC 3986-ban is szerepel (2005. január), és természetesen a böngészők is értik.

Ideje lenne kijavítgatni az oldalainkat, a böngészőknek pedig előbb-utóbb teljesen blokkolni az ilyen defektes oldalakat.

 

Technorati-címkék: ,,

Hány kérés kell egy authentikációhoz?

Adott egy webszolgáltatás, amiről tudjuk, hogy csak Basic hitelesítéssel érhető el, de ez nem gond, hiszen szerencsére .NET-ben a generált proxy osztály Credentials tulajdonságán keresztül könnyű beállítani a szükséges felhasználónevet és jelszót:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" )
};

Az ember azt gondolná, hogy ennek hatására olyan HTTP kérés megy majd a webszolgáltatás felé, amely tartalmazza az authenkációhoz szükséges adatokat, de a valóságban sajnos nem ez történik. Először elmegy egy olyan kérés, amiben nincs Authorization fejléc, azután ha a szerver ezt zokon veszi és 401 Authenticate válasszal tér vissza, akkor a kliens küld egy újabb kérést, ezúttal mellékelve hozzá a felhasználónevet és a jelszót. Az eredmény tehát dupla forgalom. Ha ez nem szimpatikus, és persze miért is lenne az, akkor jól jöhet a PreAuthenticate tulajdonság:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" ),
PreAuthenticate = true };

 

Technorati-címkék: ,