Jelszóvédelem megbízhatósága

Security-all

Azt szeretném ellenőrizni, hogy mennyire megbízható a fájlok jelszóvédelme ebben a programban:

http://sign-el-soft.hu

A cél az lenne, hogy bármilyen érzékeny adatokat nyugodtan lehessen tárolni olyan gépen, amihez mások is hozzáférnek. (Például bérelt tárhelyen vagy VPS-en is.)

A következőket próbáltam:

1. Megnéztem, hogy a védett fájlokat az ismert tömörítőkkel bepakolva csökken-e a méret. (Nem csökken.)

2. Írtam egy kis programot, ami megszámolja, hogy a lehetséges 256 byte-érték egyenként hányszor fordul elő. Az eredmény egyenletes eloszlás. Ehhez hasonlóan vizsgáltam a 16 bites értékek előfordulását is. Az is egyenletes.

Ismer valaki jobb ellenőrzési módszert?

  • 1282 megtekintés

( NevemTeve | 2023. 01. 17., k – 18:43 )

Két kérdés jut eszembe: használsz egy egyéni fejlesztésű algoritmust? A biztonság azon alapul-e, hogy ez az algoritmus titkos?

Ha a válaszok között van 'igen', akkor nem biztonságos a rendszer.

( kroozo v | 2023. 01. 17., k – 21:36 )

Hát, egyrészt leginkább mondják el, hogy szerintük mit használnak. Ha in-house, én nem kockáztatnék, ha meg nem, akkor tesztelés helyett lehet olvasni a konkrét dolgokról. Ha "titok" akkor szintén inkább elengedném.

Másrészt olyasmiket lehet érdemes nézni, hogy lehet-e felfedezni egyértelmű mappolásokat inputra, vagyis kapsz-e szép patternt mondjuk egy vödör nullára. ECBvel pl ez volt a baj. Mondjuk abból, hogy egyenletes a kimenete, arra szavaznék, hogy ilyen baja nincs.

Tehát tömörítést is alkalmaz, ahogy az illik, illetve az általad vizsgált bemenetekből (közel) egyenletes eloszlású outputot generál. Ez szép és jó, de mondhatnám úgy is, hogy a jó titkosítás n+1 szükséges feltételéből tud kettőt, de hogy az "elégséges" feltételek mik... Ugye nem mindegy, hogy mennyire "értékes" adatokat kell milyen időtávra megvédeni (mennyi erőforrásra van szükség (matematikailag megalapozva az állítást) adott titkosított adathalmaz visszaállításához...), mert nagyon nem mindegy, hogy a családi receptgyűjteményt akarod így tárolni (értéket nem jelent/kimutatható anyagi és reputációs veszteséget nem okoz annak, aki elhelyezte benne a mákos bableves (kettőt lapozott a szakácskönyvben) receptjét), vagy épp a házipornót a kecskével :-)

A tömörítés titkosítással kombinálása egy borzasztóan kétélű fegyver.

Egyrészt persze jó, hogy titkosítás előtt már megnöveli a plaintext entrópiáját, eltünteti belőle a könnyen kitalálható inputokat.

Másrészt viszont ad a támadónak egy side-channelt. Ha a támadó bárhogy rá tud venni téged arra, hogy tőle származó adatot is tegyél bele a plaintext inputba, akkor egyszerűen a ciphertext méretének figyelésével ellenőrizni tudja, hogy amit küldött, az előfordul-e a saját plaintext-ed részeként (a tömörítő deduplikálta-e). Ez volt a CRIME és a BREACH exploitok működési elve és az egyetlen megoldás az volt, hogy a tömörítést le kell tiltani a HTTP és a TLS layerben is.

Nyilván hogy a konkrét használati esetben a másodiknak fennáll-e a veszélye, azt alaposan végig kell gondolni.

Régóta vágyok én, az androidok mezonkincsére már!

( zeller | 2023. 01. 17., k – 22:47 )

Szerkesztve: 2023. 01. 17., k – 22:51

Bárki tud olyan megbízható titkosítást írni, amit ő nem tud feltörni...

Kérdés, hogy:

-"mennyit ér" az így titkosított adat
-meddig kell garantáltan titokban tartani.

Az utóbbi azért lényeges, mert a "quantum safe" vonal azért még eléggé... Hogy is mondjam csak, nem kiforrott - miközben azért elég komoly erőforrások vannak a kvantumszámítógépek fejlesztése mögött.

 

"Bárki tud olyan megbízható titkosítást írni, amit ő nem tud feltörni.."

Igen, de a mi van a többiekkel kérdés még foglalkoztat :)

 

A mennyit ér és meddig kell kérdés nem válaszolható meg. Egy olyan megoldás kell, amiről bátran állítható, hogy egy megosztott tárhelyre felmásolt tartalmakat sem a többi felhasználó, sem a rendszergazda nem tudja értelmezni.

Nagy Gábor   https://sign-el-soft.hu

"A mennyit ér és meddig kell kérdés nem válaszolható meg. " - akkor semmit sem ér és nem kell tárolni. :-)

De másképp kérdezem. A tárolt adat nyilvánosságra kerülése mekkora anyagi és erkölcsi kárt tud okozni az érintetteknek? Illetve legalább meddig kell ezeknek a harmadik fél által elérhető titkosított tartalmaknak titokban maradni? Ne abból indulj ki, hogy felmásolod, szólsz pistanéninek, hogy letöltheti, és utána törlöd, azaz fent van 2-3-5 percig, mert az alatt a 2-3-5 perc alatt lemásolható a fájl, és utána annak, aki birtokolja, kvázi tetszőleges ideje erőforrása lehet ahhoz, hogy a pistanéninek szánt adataidat kibontsa.

 

Én elsőre is értettem a felvetésedet, csak sajnos nem sikerült elég érthetően megfogalmaznom a válaszomat.

1. A programot bárki letöltheti, és használhatja, ezért nem tudom megmondani, hogy ki és mire fogja használni.

2. Ha csinálok valamit, akkor azt igyekszem jól megcsinálni. Jelen esetben a jó azt jelenti, hogy SOHA, SENKI nem tudja feltörni a jelszó ismerete nélkül.

3. Amit én másolnék: szoftvereim, bankszámláim, számláim, személyes iratok, telefonkönyvem, fényképek, kedvenc zenék és filmek. Jelenleg a biztonsági másolatokhoz USB-s eszközöket használok. Ezeken jelszóvédett (LUKS) partíció van. Bérelek ugyanakkor egy VPS-t és egy webtárhelyet. Egyszerűbb lenne az élet, ha a fájljaimat ide, és a telefonra közvetlenül, titkosított formában tudnám felmásolni. Ha ez jól működik, akkor megkérhetek bárki családtagot, vagy ismerőst, hogy a legfontosabb dolgaimat az ő telefonjára/laptopjára is felmásoljam (anélkül, hogy ő el tudná olvasni).

2018. augusztusában egy olyan élményben volt részem, amit valószínűleg senki más nem élt át az olvasók közül. Egy földszint+tetőtérből álló ház alsó szintjén voltam amikor a villám belecsapott az épületbe. A vihar nagyon ijesztően közeledett, ezért már percekkel korábban mindent kihúztam a konnektorból. Előttem a laptop akkumulátorról működöt. Volt még két PC a házban. Mind a három gép tönkrement. Azóta foglalkoztat a gondolat, jó lenne rendszeresen házon kívülre is menteni adatokat.

Nagy Gábor   https://sign-el-soft.hu

1. Ha valaki egy ennek a használatával "titkosított" adathalmazt akar feltörni, az is le fogja tölteni, és ha kellően értékes az ominózus adat/információ a számára, akkor megkeresi a gyengeségeit, és ki is fogja azt használni.

2. "SOHA, SENKI nem tudja feltörni a jelszó ismerete nélkül" - híres "utolsó" mondatok... Nincs olyan, hogy "soha", mert bár a kibontáshoz szükséges adathalmaz méretével a törés erőforrásigénye is nő, de ha az algoritmus hibás/hibásan lett implementálva, akkor megette a fene. Ha nem quantum-safe algoritmusod van jól implementálva, akkor a véleményem szerint az a "soha" bőven a belátható időtartományon belül ér véget - és itt nem több évtizedre gondolok.

3. Saját tartalom sem mindegy, hogy micsoda, illetve hogy adott fájlokat meddig kell megvédeni illetéktelenektől, mennyi idő múlva "avulnak el" annyira, hogy a nyilvánosságra kerülésük sem reputációs, sem anyagi veszteséget nem okoz neked. Ilyen célra egyébként vannak igen jól kitalált és implementált algoritmusok, olyanok, amelyeknek ezen képességeit matematikai oldalról sem cáfolták még meg. (Pedig igen sokan dolgoznak rajta).

 

Ebben az esetben a feltörhetőségre vonatkozik, hogy "nincs olyan, hogy soha", mert a számítási kapacitások, eszközök rettenet tempóban fejlődnek - oké, a quantum-safe algoritmusok (amíg nem találnak benne a matek oldaláról hibát vagy sérülékenységet) jelen tudásunk szerint elégségesen hosszú ideig ellenállóak lehetnek - de ez sem a "soha", csak az emberi számítások szerint elégséges ideig (unokáink se...). De ez csak az algoritmus, és ha az rosszul van implementálva, akkor mindegy...
Keresztkérdés: a titkosítás/kicsomagolás során hogyan viszed be a jelszót, azt a lefordított kód(!) hogyan tárolja a memóriában, van-e valamilyen memóriadump-ból adatbányászással kinyerés elleni védelme  kódodnak? Nem, a "berakom egy változóba" nem jó válasz... És ez csak egy apróság a teljes biztonságát tekintve a kódodnak...

Most kezd összeállni: ez egy in house algoritmus, amit te írsz? Mert akkor a következőt kéne csinálni: elfelejteni, és tenni a helyére valami publikusan elérhetőt.

Ha játszani akarsz, akkor persze lehet egész sokat olvasgatni, de én akkor is azzal kezdeném, hogy szépen megnézném, hogy az elérhetőek kb mit csinálnak, elkezdenék utánaolvasni a különböző támadási faktoroknak, részleteiben elolvasnám, hogy amit törtek, azt hogyan törték, aztán az alapján játszanék.

( Raynes v | 2023. 01. 18., sze – 22:12 )

Szerkesztve: 2023. 01. 18., sze – 22:17

Ez a te oldalad? Rémlik valakinek az aláírásából ez az oldal. Azt sem értem, hogy konkrétan melyik programról beszélünk, van több is feltüntetve az oldalon, ráadásul egyiknél sem látok titkosítási funkciót.

Nem világos, hogy ilyen multimédiás programokba minek kéne egyáltalán titkosítási funkció. Azt a unixos filozófia miatt érdemes rábízni inkább egy erre specializált, auditált modulra, pl. fájlrendszer titkosítása, LUKS, veracrypt, OpenPGP, stb. vagy esetleg hardverre (pl. SSD öntitkosítása), meg a felhasználóra, hogy melyiket alkalmazza, ha egyáltalán alkalmazza valamelyiket is.

Mindenesetre két problémát is látok. Az oldalon lévő programok forrása nem nyílt, így nem tudjuk, hogy milyen algoritmussal titkosít. Így nem mondható meg, hogy kriptográfiai szempontból mennyire megbízható, persze ez nem jelenti egyenesen azt, hogy objektíve megbízhatatlan, csak azt hogy semmit nem tudunk róla, így csak találgatni lehet, hogy mi lett volna, ha öreganyám villamos lett volna. A másik probléma szintén a forráskód hiánya, ami különösen az ng-xim esetén tűnik leginkább licencsértésnek, ugyanis a leírás alapján az egy grafikus frontend ImageMagick converthez, meg FFmpeg-hez. Az előbbi saját licences (bár azt is írja, hogy GPL3 kompatibilis, a GPL-t meg sérti), azt csak azzal sérted, ahogy nézem, hogy az ImageMagick licencleírását nem mellékelted a csomagokban, az FFmpeg viszont GPL2 (meg a LAME is, amire szintén épül), azt sérti, az arra épülő kódnak GPL-esnek kéne maradni, forráskódnak elérhetőnek kéne lenni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

"egyiknél sem látok titkosítási funkciót"

Jelenleg a másolás,áthelyezés, ... menüben választható két új lehetőség: pack/unpack. (A későbbiekben ez több szolgáltatásba is beépül.)

http://sign-el-soft.hu/cgi/ng-xim.html#filecopy

 

"Azt sem értem, hogy konkrétan melyik programról beszélünk"

Az ng-xim és az ng-dvb eredetileg külön ág volt, de néhány éve egyesült, és ugyanaz az ng-xim bináris kód van bennük. A két csomag azért maradt meg, hogy törlés nélkül frissíthető legyen, bármelyik is lett telepítve.

Az ng-xim létezik LINUX-32 LINUX-64 és WINDOWS változatban. A tudásuk megegyezik, kivéve a DVB tunerek kezelését, amit a WINDOWS-os nem tud.

A pavc-server csak LINUX-64 változatban létezik. Ez is ugyanazt tudja mint az ng-xim, de a helyi grafikus kezelő felület egy titkosított átvitelen keresztüli távoli eléréssel lett lecserélve.

Az ANDROID-os változat is döntő részben ugyan abból a forráskódból készül, és így a tudása is hasonló. Ez egyben egy kísérlet is arra, hogy egy PC-re írt programot mennyire lehet áttenni ANDROID-ra.

 

(A többi felvetésedre később reagálok.)

Nagy Gábor   https://sign-el-soft.hu

"a helyi grafikus kezelő felület egy titkosított átvitelen keresztüli távoli eléréssel lett lecserélve" - Aha. És az az adatcsatorna milyen módon (algoritmus, implementáció, MITM védelem van-e vagy nincs, authentikációs információ tárolása/kezelése...) lett megvalósítva?

Nem muszáj reagálni, tájékoztatásnak írtam csak. Engem nem zavar, nem vagyok szerzői jogi ügyvéd vagy ilyesmi, csak megjegyeztem. Valószínű az érintett projekteket nem érdekelné, mert bár licencsértés, de mivel nem pénzért árulod, ezért nem foglalkoznának vele úgy se.

Azt viszont még mindig tartom, hogy a titkosítást szedd ki a funkciók közül. Bízd rá a felhasználóra. Ha titkosítani akar, akkor másolja a fájlt titkosított meghajtóra, partícióra, konténerbe, vagy becsomagolja valami olyan tömörítővel, ami tud titkosítani. Ezt nem kell neked támogatni. Neked is könnyebb, egyel kevesebb funkció, a szoftver soványabb lesz, egyel kevesebb fejfájás, biztonsági rések lehetősége is csökken. Nem jó taktika, ha a programod mindenek, túl sok mindent tud, mindent magad implementálsz, megnő csak a hibák, sérülékenységek lehetősége. Amire lehet, használd mások kódját, libjét, és ne találd fel újra a kereket.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Amit a licenc sértésről írtál az tévedésen alapul. Valaki már reagált rá, amit köszönök:

https://hup.hu/comment/2878015#comment-2878015

Mivel ismét megemlíted, reagálnom kell nekem is.

A program és az ffmpeg nem alkot közös bináris kódot. Ha veszed a fáradtságot és elindítod a programot, az ffmpeg megfelelő verziójának telepítése nélkül, akkor láthatod, hogy a funkciók jelentős része zavartalanul működik. Ha videó vagy hang lejátszására lenne szükség, akkor megjelenik egy üzenet, hogy a funkcióhoz telepítened kéne az ffmpeg könyvtárakat. Az oldalról ezek letölthetők, de azok a csomagok, amik tartalmazzák az ffmpeg kódját, tartalmazzák a hozzá tartozó valamennyi licencet is.

A program és az imagemagic kapcsolata még távolabbi. Ebből csak a convert parancsot használom ritkán előforduló képformátumok átváltására. A Linux esetén a convert alapból feltelepül, ezért az én csomagjaim ezt nem tartalmazzák. A licencet a Linux telepító lemezén kell keresni. A Windowshoz található egy convert_dcraw.zip csomag az oldalon, ami természetesen a licencet is tartalmazza.

Nagy Gábor   https://sign-el-soft.hu

"Azt viszont még mindig tartom, hogy a titkosítást szedd ki a funkciók közül. Bízd rá a felhasználóra."

Most rá van bízva a felhasználóra, ha akarja használja, ha mást akar, akkor azt használja, ha mást is használ, és ezt is, akkor dupla biztonságot kap. Ha kivenném, akkor nem bíznám rá, mert már csak mást használhatna. :)

Szerintem ez a titkosítás a legbiztonságosabb, és a leggyorsabb módszer, de a programmal a más módon titkosított fájlok is kezelhetők, továbbíthatók az eszközök között.

Nagy Gábor   https://sign-el-soft.hu

Szerintem ez a titkosítás a legbiztonságosabb, és a leggyorsabb módszer, de a programmal a más módon titkosított fájlok is kezelhetők, továbbíthatók az eszközök között.

Nyílt forrású? Átesett valamilyen audit folyamaton? Matematikailag bizonyított?

https://iotguru.cloud

Az első kettőre már kiderült, hogy "nem" a válasz, és esélyes, hogy a harmadikra is (bár ott egy "az micsida" jellegű válaszon sem csodálkoznák...), de ahogy írja: "Jelen esetben a jó azt jelenti, hogy SOHA, SENKI nem tudja feltörni a jelszó ismerete nélkül." - szóval önbizalom, az van bőven...

A nyílt forráskódot általában windowsos gépek mögött ülő felhasználók szokták feszegetni, akiknek még a nevük is titok. Remélem te nem ilyen vagy. Elárulod nekünk:

Mi a neved? Hol dolgozol? Melyik projektben milyen nyílt forrású modul a te alkotásod?

Nagy Gábor   https://sign-el-soft.hu

Én nem követeltem semmit! ( Ha hiányos a szövegértésem, és segítesz továbbfejlődnöm, akkor megköszönöm. )

Kérdeztem valamit "Raynes"-től.

Most tőled kérdeznék:

 1. Raynes==kisbetű ?

 2. Van-e erkölcsi alapja annak  aki még semmit nem publikált nyílt forrásként, ez ügyben kifogásolni mások munkáját?

Nagy Gábor   https://sign-el-soft.hu

Te nem követeltél, ez igaz, csak kérdeztél jelszóvédelem megbízhatósága kapcsán. Megmondtuk, hogy nagyjából nulla az esélye annak, hogy az, akinél ez a kérdés így felmerül, saját kútfőből az elvárt szintet megütő algoritmust találjon, azt megfelelően implementálja, és a futtatható kód is úgy álljon elő, hogy az az elvárt biztonsági szintet megüsse. Ezek közül elég ha egyben hibázol, máris kuka az egész, vagy inkább látszat biztonság...

Egy nick mögötti kóder egyedi, forráskód szinten nem vizsgálható/auditálható fejlesztését, már ne is haragudj meg, de épeszű ember nem fogadja el biztonsági célra készült alkalmazásként. Bizalom a szó, amit keresel egyébként, azt meg ilyen területen nem a titkolózással lehet elérni... Elcsépelt dolog, de egy újszülöttnek minden vicc új alapon azt is hozzáteszem, hogy egy titkosítás nem attól lesz jó, hogy titkos, hogy hogyan készül.

Android-os app esetén nem látom a Google Play áruházban - nem merted vagy nem tudtad betolni, vagy csak szimplán nem engedték...?
Update: Aki 2016-tól 2043-ig érvényes self signed certet használ app aláírására... Mondjuk a fine location-t nem értem, miért kell... És ez csak egy gyors ránézés volt

Ha belegondolok, hogy a 2000 táján kiadott certekhez milyen kulcsok, milyen aláíró- és kivonatoló algoritmusok tartoztak... Nos, a 25 év az k... mocskosul hosszú idő egy kulcs+certificate életében...
Ezek szerint az app aláírására használt cert egy "jó ha van, de..." lehetőség...

"Mondjuk a fine location-t nem értem, miért kell.."

Ezzel mi a baj? Ha egy app bejelöli az igényét valamire azt nem kapja meg automatikusan. A felhasználó egyenként hagyhatja jóvá, vagy elutasíthatja ezeket.

Mivel az app tud videó telefonálást, ezért kezeli a kamerát.

További lépés a fénykép készítés, amihez logikusan kapcsolódik a GPS adat is.

A fénykép készítés a letölthető app-ban még nem működik, ezért a "fine location" jelenleg még nincs használva.

Nagy Gábor   https://sign-el-soft.hu

"Android-os app esetén nem látom a Google Play áruházban - nem merted vagy nem tudtad betolni, vagy csak szimplán nem engedték...?"

Meg sem próbáltam!

A google szerintem már túl nagyra nőtt. Ezért mindenkinek azt ajánlom, ha tud más megoldást, akkor használja inkább azt. (Ezt az oldalamon is olvashattad volna.)

Mi lenne az ok arra, hogy "ne merjem, ne tudjam..., ne engedjék" ?

Nagy Gábor   https://sign-el-soft.hu

"Ezért mindenkinek azt ajánlom, ha tud más megoldást, akkor használja inkább azt" - Például olyan alkalmazásokat, aminek az alkotói legalább a minimumot tudják hozni megbízhatóság terén. na a te motyód az pont nem ilyen. Attól, hogy a Google szerinted "túl nagyra nőtt", még az áruházba bekerülés kapcsán elvárt dolgokat mindenkinek minimum "illik" megugrani. A te motyód pont nem ilyen...

A "meg sem próbáltad" nekem azt jelenti, hogy nem is akarod megtudni, hogy a Google play-be kerülés feltételeit megugorja-e az alkalmazásod (jelen formájában nem). Pedig nem a sátán, nem a mumus ilyen szempontból a Google... Nagyon hasznos tud lenni a play konzolon visszaadott infó.

Szerintem csak a linkelt oldalának akart/csinált némi plusz forgalmat - szerintem akik innen megnéztük, a büdös életben nem találtunk volna rá - ahogy a gugli is erősen a futottak még kategóriába rakja a hasonló tartalmakat - kivéve, ha egy nagyobb forgalmú/reputációjú oldal meghivatkozza...

( zeller | 2023. 03. 06., h – 18:43 )

Egy kérdés még felmerült bennem, amit nem értek... Miért vannak a .so fájlokban az elnevezések vegyesen, azaz többségében szépen, egységesen angolul (ráadásul CamelCase), és kisebb részben magyarul? (jellemzően végig kisbetűs, bár mintha láttam CamelCase magyar nevet is) Ha a teljes kód saját, akkor mi indokolja a kétnyelvűséget? Vagy netán egy bezárható forráskód lett picit továbbhekkelve úgy, hogy erről az apróságról megfeledkeztél?