A crypto okosok szerint próbálkozni sem érdemes. A Browserben futó JS egyszerűen nem alkalmas crypto-ra.
OK. elfogadtuk. De vajon ez érv-e arra, hogy minden magán cuccomat felöntsem tőlem távoli szerverekre titkosítás nélkül? Ez olyan mint a secure levelezés problémája, illetve ez ugyanaz.
Szóval a kérdés hogy mit lehetne konkrétan tenni is a gyakorlatban. Elfogadva azt, hogy igen, a dolog függ a böngésző biztonságától, És vajon milyen szintű biztonságot lehet ígérni a felhasználóknak?
- Public Domain
- Az elsődleges szempont az egyszerű használhatóság.
- A második a könnyű implementálhatóság (crypto-t beleértve) (ez a transzparencia miatt érdekes, illetve, hogy akár születhessenek natív app-ok később)
- harmadik a biztonság
Megvédeni a kódot valóban lehetetlen, de mondjuk az feltétel, hogy ha a titkosítás pillanatában minden rendben volt, akkor utána azért ne lehessen a kulcs nélkül hozzáférni. (tehát az algoritmusnak jónak kell lennie)
Végezem némi kutatást, és ismerem e legtöbb triviálisabb problémát. Kezdve onnan, hogy egy megfelelően megcsinált extension a legkisebb nehézség nélkül kihalászik bármit a böngészőből.
http://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1014&context=ism
És igen tudom, hogy a biztonság illúziója kérdés itt is adott. Mégis, ha nagyjából tudható a biztonság tényleges mértéke, akkor úgy gondolom, hogy működőképes dologról van szó.
Szóval, ti mit használnátok, és hogyan?
Egyáltalán élhető ötlet ez?
Hozzászólások
Az egyszerűség és a valódi biztonság igen ritkán jár kéz a kézben. Tetszőleges brózeren futó appnál a brózerek hibáival is szembesülsz, ahogy már írtad is. Ha már end2end crypto, akkor lehet jobban megéri saját klienst fejleszteni https alapon. Az is egy külön probléma, hogy hogyan azonosítod a felhasználókat, ha több felhasználó van, illetve az azonosítás mindíg kérdés. Ez is működhet kulcspárral, de akkor minimum a juzernév és a titkosított adat kell. A GPG/PGP duettet is érdemes lenne megnézned, mielőtt feltalálod újra. :)
Igen tudom, de a saját kliens nem opció. https szintén nem játszik. Mivel titkosítva szeretném tárolni a szerveren az adatokat. Lehet nem fogalmaztam elég tisztán, de a lényeg az, hogy a szerveren se olvasgassa senki a cuccokat.
A saját kliensel az a probléma, hogy a fejlesztés elején WIN+MAC+LINUX+ANDROID+IOS+FxOS+BB+WinPhone Stb. egyszerre. Nincs ilyen erőforrás a birtokomban.
GPG/PGP, OpenSSL, PolarSSL .. stb ugyanemiatt nem játszik.
A cél az, hogy a jelenlegi clear-text megoldásoknál biztonságosabb legyen.
Természetesen ha a későbbiekben lesznek fejlesztők akik natív app-ot irnának, az jó lenne. De mivel az egész sikeréhez alapvető fontosságú, hogy mindenen működjön a kezdetektől fogva, ezért a JS a logikus választás.
### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch
Ez egy kicsit túlzott önbizalomként hangzik, erősen kétlem, hogy valóban fel tudod mérni a biztonság tényleges mértékét.
Amúgy szerintem jó ötlet, legalább by default nem kerül bele a tartalom mindenféle adatbázisokba (mint mondjuk pl ez a hozzászólás: a hup szereven + NSA full capture + akit meg erdekel.) Ha valaki tőled akar valamit, legalább vegye a fáradtságot, hogy téged személy szerint figyeljen meg. Ha így lenne, az ellen meg egy katonai szervezet erőforrásai sem elegek.
Tehát szerintem emiatt meg az általad felsorolt pontok miatt is fölösleges túl magasra rakni a lécet, válassz vmi aktívan fejlesztett/népszerű js crypto libet, és használd jól az implementált algoritmusokat. Mondjuk ez utóbbi már nem triviális (ld ps3 törés), de ha elolvasod az algoritmushoz tartozó wikipedia oldalt, akkor talán leírják, hogy mikor mit kell frissen generálni, ellenőrizni, stb.
Nem gondolom, hogy én fel tudnám mérni, de reménykedem, hogy nálam hozzáértőbbek tudnak egy megfelelően pesszimista becslést tenni.
Egyértelműen valamilyen bevált és sokféle nyelvben leimplementált algoritmusra gondolok. Körül kell néznem még pontosan, hogy mi az ami 100% public domain. Belülre pedig értelem szerűen valamilyen symetric-key cuccot. Abból pedig valamit ami kellően gyors, és jól bevált.
Ami előnyt egy ilyen rendszer biztosít, hogy a megfigyelést konkrétan a te gépeden kell, hogy csinálják, nem elég a szolgáltatóval jóban lenni.
Persze pont emiatt nem reménykedhetek benne, hogy sokan adoptálnák a szerver oldalt, de hátha akad 1-2 ember/cég.
### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch
Régebben én is gondolkoztam ilyenen, és szerintem az a kézenfekvő megoldás, hogy a szervert csak a titkosított blokkok tárolására használod, minden más js-ben a kliensen van implementálva, ilyenkor akár gmail is lehet a backend. Mondjuk épp ezért nem is vágtam bele, mert rengeteg meló.
Arra azért újra nyomatékosan felhívnám a figyelmet, hogy nem triviális feladat az algoritmusok helyes használata, és biztonsági szempontból helyes összekombinálása. Magyarul a választást ne egy fel órás wikipédia túrás, hanem legalább pár hét irodalomkutatás után ejtsd meg. truecrypt, luks, openssl, gpg, ki milyen hibákat csinált, hogyan lettek kijavítva, milyen támadásokkal számoltak, neked milyen új támadási felületeid vannak stb.
Egyet értek, hogy a backend feladata kimerül a tárolásban és a továbbításban. De nem szívesen használnék gmail-t erre a célra. Mivel evvel alapvetően korlátoznám a jogosultságok kezelésének lehetőségeit.
És teljesen igazad van, hogy komoly utánagondolást igényel az ilyesmi, és már túl vagyok azért némi kutatáson a témában.
Sajnos sok olyan új támadási felületet jelent a JS maga, ami nem igazán orvosolható. De valahol meg kell húzni a határt.
Azt hiszem lassan ideje konkrét tervet készítenem, talán valamilyen wiki jellegű rendszeren, hogy mások is bele tudjanak nyúlni. Mert több agy többet tud.
### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch