Mobil app Webservice kapcsolat biztonság, CLIENT SSL vs TOKEN

Web, mail, IRC, IM, hálózatok

Sziasztok!

Érdekelne pár ember véleménye.

Mobil applikációt fejlesztetünk külsős céggel. Az applikációnak hozzá kell férnie egy halom szenzitív adathoz, pl ügyfél adatokhoz. (az applikációban belépett ügyfél saját adataihoz).
A szerverünkön egy webservice adja meg ennek a lehetőséget.
Eddig ezekhez a WS-ekhez csak szerver oldalról lehetett kapcsolódni (pl egy másik php-s rendszerből), azok is saját rendszerek voltak. Ergó ott megoldottuk egyszerűen. Csak 443-as porton van nyitva a domain és csak valid kliens cert-el lehet túljutni a webszerveren, azon belül pedig username/jelszó amit már a rendszer csekkol (php).

Most ugyanezt kéne megoldani, de a mobil applikációval, ami kb azt jelenti, hogy kitesszük a netre free2play módba az api elérést. Természetesen bármilyen védelmet is építünk bele a mobil app-ba, azt ki tudja szedni az aki visszafejti. A cél természetesen az, hogy az aki belép az app-ba, az csak a saját adataihoz férjen hozzá, tehát ha fel is töri az app-ot, akkor csak az adott ügyfél adataihoz férhet hozzá.

Két lehetőség van:
Client ssl vagy token.

A tokent nem kell magyaráznom, beépítünk pl oauth2-t és az adott generált tokennel tud belépni. Ha feltörik a telót, akkor lelopják a tokent és azzal tudnak baromkodni az adott ügyfélnél, amíg le nem tiltjuk.

Én az ssl felé vonzódom jobban:
Amikor az app-on belül a user sikeresen bejelentkezik, akkor (az app) generál egy rsa privát kulcsot. A user jelszavával le is védi (a jelszót előtte salt-ozza), a jelszót letárolja a telefon egy biztonságosabb storage-jában, vagy a memóriában.
A kulcs segítségével generál egy certificate request-et és beküldi a WS-nek aki generál neki egy cert-et. A cert-be belepakol egy adag adatot ami az ügyfélre utal (név, email, valami egyedi azonosító hash).
Utána ezzel a cert-el tudja az app azonosítani magát a WS felé. A cert-nek beállítható lejárati idő is, olyankor újat kell igényelni.
Természetesen a telefon feltörésével kinyerhető a privát kulcsot feloldó jelszó hash, kinyerhető a kulcs és a cert is. Utána az app-on kívül is meg tudja hívni az ember a WS-t. A cert-ben ott lesz a neve és mail címe is, ami egyértelműen megmondja, hogy az az övé.

A cert-es megoldás nekem sokkal jobban tetszik. Szerintem az átlag script kiddie kevésbé tudja használni, és ha valaki mégis kiszedi, akkor is 2x meggondolja, hogy kiadja e bárkinek, hisz az ő adataihoz van hozzáfűzve az egész. Még jogilag is jobban védhető az egész, hogy nem egy kódsort loptak el vagy generáltak le, hanem a készülékből nyerték ki az adatot.

A tokenes megoldásban az a jó, hogy egyszerűbb. És persze mostanában az a trendi.
Nem utolsó sorban, ha jól tudom, akkor a tokeneknél a szerver adja a secret-et is, az ssl esetében viszont csak a telefonon lesz meg a privát kulcs, sehol máshol. Az is lejelszavazva. Beállítható akár az app-ban, hogy x idő után kérje újra a jelszót a feloldáshoz.

Mit gondoltok?

  • 1407 megtekintés

( Aadaam v | 2017. 05. 21., v – 21:23 )

gondold végig: a nap végén akinek van usere hozzáfér a cuccairokhoz és kész.

Ezt a szolgáltatást most ki kell nyitnotok az internet felé.

Mi a titok? Adat vagy API?

Lehet külön privátkulcsos SSL nyilván, az OAuth (ahogy a nevében is van) csak jogosultságot ellenőriz, de nincs Trusted Platform minden telón, ha minden telót kell támogatni akkor tulképp előbb-utóbb mindig ott vagy, hogy a telót meg lehet szerezni és az adott user nevében bármit csinálni.

Ha nem kell minden telót akkor egy SAM modulos célkészülék, esetleg belépteted VPN-be vagy kérez egy saját APN-t a T-től.

A privátkulcsot kb ugyannannyi energia megszerezni mint az access token-t cserébe nem triviális a hálózati infrastruktúrád, bármikor bővíteni kell akkor para van hogy kitaláltad ezt a custom cuccot.

Igazából ezzel egyszerűen nagyobb hozzáférést kérnek a userek, nyílt internetről akarják használni a szoftvert, at the end of the day, ez mindenképp nyílt internet felőli, user authentikáció alapú hozzáférést jelent.

Köszi a választ!

Az adat és az api is titok. Az adat szenzitív.
Telefonok között mindenképpen kell a támogatás minden eszközre ami futtatni tudja az app-ot. VPN nem játszik semmiképp se.

A cert esetében azért több energia a kinyerés mint a token esetében. Tokennél csak a token kell és ennyi.
Cert-nél kell a kulcs, a cert, és a jelszó is hozzá.

Nagyobb cégről van szó, sok ügyfélről és ha valamelyik panaszt tesz egy felsőbb szervnél, akkor meg kell tudni védeni magunkat. A token esetében ez nehezebb dolog. A cert esetében sokkal könnyebb, benne vannak a user adatok, mint egy kiadott útlevélben, plusz a cert nem érvényes a telefonon tárolt kulcs nélkül. A végére tutira levezethető, hogy a user a hibás ha valaki lenyúlja a hozzáférését.

De a token is egy cert kb...

Mit feltételezel, mi törhető fel?

Ha a telefon adattárát feltételezed feltörhetőnek, onnan a token meg a cert is ugyanúgy kijön. Nem tudom, a Google ad-e valami safe storage API-t, a kínai vackokon tuti nem lesz.

A token mindig userhez köthető.

A hálózati forgalomban HTTPS esetén a kliens és a szerver megegyeznek egy session kulcsban, szerintem az access token-t nem tudják lenyúlni sima MITM-mel.

Nem látom hogy mi lenne a logikai különbség a cert meg a token közt, nem tudom hogy szimmetrikus-e az access token OAuth2-ben de szerintem nem, az nem megy át a hálózaton csak úgy.

Azt viszont látom hogy amint be kell rakni egy load balancert vagy bármit át kell állítani az infrastruktúrán akkor az utódod a custom megoldás szerint vagy rábeszéli a céget hogy ezt hagyják így és a plusz szolgáltatások menjenek valami máson, vagy nem nyúlnak semmihez évekig mert nem mernek, vagy szenvednek.

Azt tudom, hogy a telefon feltörhető. Abból indulok ki, hogy fel is fogják és kiszedik belőle az autentikálást.
Csak annyit tudunk tenni, hogy nehezítjük a feltörést, illetve védjük magunkat.

Azt nem tudom, hogy fiddler-el kiszedhető e az api hívásokból a token, talán nem, mert https-en megy. Az tuti, hogy a token könnyebben lopható.

Eléggé szélsőséges példa, de ha teszem azt, jogilag meg kéne védeni magunkat, akkor a cert jobb. A magyar szervek nem értenék meg, hogy mi az a karaktersor amivel full azonosítható a user. A cert esetében már más, mert tényleg útlevélnek tekinthető, plusz a privát kulcs soha nem kerül ki a telefonról a mi szerverünkre. A token esetében ha jól tudom, a secretet nekünk kell küldeni amikor igényli a kliens. Plusz tleg a token minden request alkalmával utazgat az éterben. A cert esetében azért ennyire nem fekete-fehér, nem repked plain/text-ként a kliens-szerver között.

Nem látok problémát az utólagos változtatásokon. Azért nem beszélünk itt most egy nagyon nagy fejlesztésről :) A webszerver beállítás nem nagy cucc, a php része se para.

Ha egyszer lesz utódom, akkor őt minősíti ha nem merne ehhez hozzányúlni :)
Amúgy itt komplexebb rendszerről van szó, ez a rész csak egy kisebb része az egésznek. Ez csak az autentikálás, abból is csak a mobilos rész. Ha kellenek új részek a WS-be, akkor az autentikálás közelébe se kell menni.

Egyelőre úgy néz ki, hogy az ssl nyer (több munkatársam is beállt már a feature mögé).

Most érted, kitaláltatok valamit, ami nem standard, ha azért jöttél ide hogy valaki confirmálja hogy jó ötlet, csináld csak...

Ha a telefont feltörik, akkor a privát kulcsot is feltörik. A HTTPS-t nem lehet nézegetni, az a kliens privát kulcsával megy (amit ha nagyon akarsz akkor random legenerálhatsz per kliens, na nem mintha az OS nem tenné meg neked magától), az meg hogy hányszor megy át a hálózaton, édesmindegy, nem plaintext megy ugyanis.

Nem tudom te mivel látsz bele a fiddlerrel, gyakori megoldás hogy a szerver publikus kulcsa lemegy a kliensre telepítéskor, az appstore/playstore úgyis ellenőrzi a csomagintegritást meg intézi a frissítést, aztán meg nem engedi a publikus CA-kat, csak a telepítéskor/frissítéskor rögzített speckó CA-t (android: TrustManager) . Innentől ha a kliensed elhiszi a fiddlerről hogy ő a valid szerver akkor azért máshol lesz a gond. De ez mindig macera, mondjuk ezekhez amúgyis hozzá kell nyúlnod ha bele akarsz nyúlni a hitelesítésbe.

Szóval arra lehet érdemes időt szánni hogy ne lehessen könnyen MITM-et csinálni, de arra apellálni hogy egy aszimetrikus kulcs van a kliensen a sima access token helyett szerintem teljesen felesleges, ha törik a klienst akkor az asszimetrikus kulcsot is viszik.

Megnéztem amúgy, az OAuth 1a még mindent aláírt, olyan adatokkal amit soha nem küldött el senkinek (a diplomámban ezt még a két pici kezemmel leimplementáltam, erre határozottan emlékszem), de ezt valahogy aztán mindenki dobta.

Szerintem is jobban járnátok standard Oauth alapú megoldással. Ráadásul azt nem nektek kell leimplementálni se kliens, se szerver oldalon. Azért írjatok a főnökségnek 1-1 becsült óraszámot a két megoldás mellé (kész Oauth libek vs. saját tákolás). A saját SSL-es verzió becslését nyugodtan szorozzátok 3-mal, hacsak másodállásban nem vagytok crypto / security szakértők. Szerintem a főnök megmondja, hogy melyiket válasszátok. :)

A főnökség is a certet támogatja a tokennel szemben.

De segítsetek már, miért gondoljátok ezt akkora tákolásnak?
A client ssl -es azonosítás egy tök egyszerű dolog. Oké amikor elsőnek csináltam ilyet akkor nem ment elsőre, de legutóbb 10 perc alatt összeraktam egy teszt felületet hozzá.

Miből is áll?
Szerver alatt generálsz kulcsot és certet, belövöd apache alá, beállítod, hogy csak cert-el engedje be a usert és azt is, hogy lője ki a cert tartalmát a php-nak a $_SERVER változóba.

A kliensnek azaz a mobil appnak kell generálnia a saját kulcsot és cert requestet.

PHP-val kb 10 perc alatt írtam meg egy scriptet amivel a cert request-ből tudtam előállítani a kliens cert-et.

Ennyi a webszerver része nagy vonalakban. A kiadott certtel tud a user belépni az oldalra. A többi pedig már csak php scriptezés, hogy a $_SERVER változóból kikapja az infókat és eldöntse, hogy a user valid e v sem.

A mobil appot fejlesztőknek persze kicsit több meló lesz mint a token, de nem horribilisan nehéz dologról van szó. Az a plusz meló nekik, hogy eltárolgassák a kulcsokat certeket a megfelelő helyre és adminisztrálják, pl ha lejár, akkor újat tudjanak kérni. (de mondjuk a letiltott token helyett is kell tudni újat igényelni, ergó ez se plusz meló)

Itt nem a Spanyol viaszt találtuk meg. Nem mi lennénk az elsők akik cert-el autentikálnak és authorizálnak egyszerre.

Elég csak a megboldogult startssl oldalt megnézni. A regisztráció után kapsz egy certet és a böngésződbe letárolva azzal tudsz belépni.

Nem lehet, hogy valami nagyon másra gondoltatok?

Az OAUTH nem csak azt biztosítja, hogy ha már megvan a tokened, akkor azzal tudj authentikálni, hanem magának a token megszerzésének a folyamatára is megvan a protokoll. Ezt (ahogy te is írod), neked kell összetákolnod a certes megoldásod esetén, még ha maga az auth már a normál SSL cert kezelésen alapszik.

Van még egy dolog, amit érdemes lenne figyelembe venni: azzal, hogy client certtel autholsz, gyakorlatilag a transport layerbe lenyomsz olyan feladatot (alkalmazásspecifikus auth), ami az alkalmazásrétegbe tartozna. Ennek pl. olyan esetekben is van szerepe, hogy nehezebb standard eszközökkel load balance infrastruktúrát kiépíteni, ahol mondjuk az SSL terminálást egy külső réteg csinálja, de azért az auth információt továbbküldi a belső rétegek / app szerverek felé.

Lehetne azzal érvelni, hogy mennyivel jobb, hogy már a transport layer eldobja a kapcsolatot, ha nincs valid cert, de a fenti leírás alapján, mégiscsak kell engedni a valid cert nélküli kapcsolatot, amikor először létrejön a userhez / device-hoz kapcsolódó cert, ahol valamilyen custom authentikációs folyamat részeként átadja a cert reqestet a kliens a szervernek, és visszaadja a certet - ami így kb. az OAUTH tokennek fog megfelelni.

Az OAUTH előnye szerintem az, hogy egy sok éve kiforrott, szabványos technológiáról van szó, olyan use case-eket is támogat, amikre lehet, hogy ti most nem is gondoltok, hogy szükség lehet majd rá. Van több kiforrott implementációja, nem nektek kell újra feltalálni a melegvizet. Függetlenül attól, hogy meg tudjátok-e írni elég jóra (én magammal szemben inkább gyakorlok önkritikát ha a biztonságról van szó), minden perc, amit ezzel töltötök a rendszeretek valódi funkcióinak fejlesztésétől vonják el az időt. És a vevők nem azért fognak titeket választani, mert ti írtatok egy custom auth megoldást, hanem mert a számukra fontos feature-ök megvannak és jól működnek.

Arról nem beszélve, ha egy nagy ügyfeletek azt találja mondani, hogy "XYZ rendszerből kell authentikálnunk", akkor ha OAUTH-ot használtok, akkor jó eséllyel nem kell semmit kódolnotok, mert a másik rendszer alapból fogja támogatni, vagy van hozzá külső modulként. A custom megoldásotokra ez nem igaz, ott az illesztés költségét nektek kell majd fizetnetek (nyilván adott esetben az ügyfélnek, de ő meg nem fog örülni a magasabb költségeknek).

Lehetne ezt még folytatni, de szerintem a _legvégső_ érv, hogy feltörhetetlen rendszert csinálni nem tudsz (túl sok olyan komponens van, amit nem te kontrollálsz + senki sem tökéletes). Innentől kezdve két feladatunk van: (1) a betörés valószinűségének csökkentése és (2) a betörés káros következményeinek csökkentése. A második pontba beletartozik a te saját feneked védelme is. Ugyanis ha egy súlyos betörés van, és jönnek a külső szakértők, akkor bizony ki fogják emelni, hogy nem szabványos, nem auditált megoldások voltak használva, amik "hozzájárulhattak" a betöréshez, akkor is, ha a konkrét esetben nem bizonyítható, hogy azon mentek be. Nagyon kellemetlen lenne magyarázkodni a vezetőségnek egy ilyen helyzetben, amikor éppen bűnbakkereső üzemmódban vannak...

Ha szabványos megoldásokat használtok, akkor ráadásul az audit is olcsóbb, mert el fogja fogadni a szabványos megoldást "iparági best practice"-nek, és csak azt ellenőrzi, hogy helyesen van integrálva + megvannak-e a folyamatok a standard komponensek megadott időn belüli frissítésére biztonsági bejelentések esetén.

A custom komponensnél csak azt fogja mondani, hogy _ha_ jól működik, akkor akár még jó is lehet, a custom komponens külön auditálására meg kössetek egy külön (nem olcsó) szerződést...

Azért írtam ki a kérdést, mert érdekelt mások véleménye.

Egyelőre olyan véleményt nem sikerült megformálnotok ami miatt lemondanék a cert-ről.
Lényegében te is azzal kezdted, hogy a kettő ugyanaz alapjaiban.

Az nem érv, hogy a telefont fel lehet törni, mert ezzel a topic nyitása óta tisztában vagyok.
Az sem igaz, hogy ez a megoldás nem standard, lent írtam a startssl példáját is.

A token generálás egyszerűbb és trendibb. Ez igaz.

U.I.:
A fiddler-t este amúgy kipróbáltam.
Belövök rajta egy proxy-t, akkor a saját kis cert-jét teszi be az alagút végére. Böngésző esetén ez piros certet jelent, amit ha elfogadok, akkor tudom monitorozni az adatfolyamot a beküldött POST-os username/password -ot is plain/text -ben.
1-2 app-on belül már más a sztori, amit próbáltam, ott megakadt a folyamat, mert nem fogadta el az invalid certet automatikusan, tehát mondhatjuk, hogy jól vizsgázott.

az ugyanaz alapjaibant én inkább úgy fogalmaznám meg, a te megoldásod nem nyújt lényegi plusz védelmet a standarddel szemben.

A letárolt kliens cert helyett a random cert (mert ugye ez történik ha nincs saját) biztonságosabb bizonyos szempontból, hisz egy frissen kitalált certet elég nehéz megszerezni.

A költségek számításakor a mobilkliens fejlesztési árát is be kéne venni, más az hogy TrustManager-rel kicsit erősebbre veszed az ellenőrzést meg hogy akkor most minden kérést megvariálunk. Lehet inkább tőlük kéne két árajánlatot kérni, OAuth meg strict CA kezelés vs certek.

Az appban nem tudsz elfogadni kézzel fabrikált certet, az oprendszer nem engedi alapból, hacsak explicit ki nem iktatod (ugyanazzal a módszerrel kb amivel közlöd hogy nem bízol a publikus CA-kban, mert az egyetlen reális támadási felület a fiddlerre hogy valaki szerez egy legális SSL certet a fiddleréhez)

Van mind az Apple-nek, mind a Google-nek leírása meg jött ki pár O'Reilly könyv is a témában, lehet érdemes lenne belenézni, a dev doksik úgyis kellenek ahhoz is amit te akarsz.

https://developer.android.com/training/articles/security-ssl.html
https://developer.apple.com/library/content/documentation/NetworkingInt…
http://shop.oreilly.com/product/mobile/0636920022596.do

( st3v3 v | 2017. 05. 22., h – 09:49 )

a) Let's state the obvious: Ha az adatokhoz való hozzáférést szeretnéd nehezíteni az a user-re is kihat: a biztonság és az ease of use egymást nehezítő célok.

" pl oauth2-t és az adott generált tokennel tud belépni. Ha feltörik a telót, akkor lelopják a tokent és azzal tudnak baromkodni az adott ügyfélnél, amíg le nem tiltjuk."

b) Tehát a kiadott token érvényességét vedd le a minimálisra amennyit egy átlag user egy alkalommal használja bejelentkezve az alkalmazást, utána kérj újra-hitelesítés.

A kliens oldali tanusítvány + oauth token is használható egyidejűleg, én a helyetekben inkább arra figyelnék hogy pl az alkalmazás mindig csak olyan adatokhoz férjen hozzá amire mindenképp szüksége van ( oauth scope-ok, ha további adatra is szükség van -> új token több scope-hoz való hozzáférés )

Ha a user elveszti a telefonját, arra meg legyen lehetősége a webes felületen hogy letiltsa az eszközt, a mobilra meg ne mentsetek érzékeny adatot.

( Mico v | 2017. 05. 22., h – 10:09 )

Jesszus...

Rendezd sorba egy általad választott területen, a 10 legnépszerűbb alkalmazást (nem magyar), nézd meg, hogy csinálják, pont úgy kell neked is csinálni. :)

( flimo | 2017. 05. 27., szo – 01:02 )

Úgy érzem még utána kellene olvasni, hogy mi is az az oauth2. Az nem úgy megy, hogy legenerálsz neki egy tokent, amit majd lement a telefon, és az küldözgeti. Eleve oauth2-re ugyan építettek authentikációs megoldásokat, de az alapvetően authorizációra van. Szerepel benne egy kliens (telefon), egy resource server (a webservice), és egy authorizációs szerver, ami kiadja a tokent, miután a user authentikált nála. Amitek most nincs. Ergo nem megoldjátok, csak kiszervezitek a problémát, mert valahogy authentikálnia kell az appnak, hogy legyen tokene.

( blr v | 2017. 05. 27., szo – 12:54 )

Egyértelműen token. Oauthtal generálsz tokent, amit aztán egy JWT payloadjában utaztatsz, a requestet pedig aláírod a user jelszavából a szerveroldallal azonos módon képzett hash-sel.
A tokent ha nagyon akarod lementheted, de a jelszót úgyis csak memóriában tartod, ha a telefon idegen kézbe kerül, a token önmagában értéktelen. Az egész nagyon hasonló a certes megoldáshoz, viszont a transport layertől független, így könnyen hordozható megoldásod lesz, amely tetszőleges böngészőben is futtatható akár, nem vagy mobilhoz kötve.

"Oauthtal generálsz tokent"

Az oauth nem szinoníma a tokenre, az egy token szerzési eljárás. Amit leírtál, abban nincs szerepe.

"egy JWT payloadjában utaztatsz"

A jwt maga a token, annak a payloadjában a user azonosításához szükséges információ megy.

"a requestet pedig aláírod a user jelszavából a szerveroldallal azonos módon képzett hash-sel"

Mármint a tokent kellene aláírni, pontosabban a header + payloadot, majd hozzácsapni az aláírást, hogy jwt-ről beszélhessünk. Itt az a gond, a jelszót titkosítva + salt illene tárolni a szerveren, hirtelen nem tudom, hogy így lehetne-e aláírást ellenőrizni a szerveren, de lehet, hogy van rá megoldás. További gond ezzel az, hogy az out-of-the-box oauth megoldások egy (vagy több) authorizációs szerver privát kulcsával aláírt tokent validálnak, itt pedig minden userre más lenne a kulcs, tehát egyéni megoldást kell gyártani a resource serverre is.

Az oauth flow erre az lenne, hogy csinálnak egy authorizációs szervert, ahol authentikál a user, cserébe kap egy tokent a mobil kliens, és utána azt a tokent küldözgeti a szervernek, de ezzel csak újabb komponenst felvéve a rendszerbe, és nem megoldva, hanem áthelyezve az authentikáció problémáját. Szerintem ez ide nem kell, hiába "menő".

Ha mindenáron tokenezni akartok, akkor private+public kulcs generálás az eszközön, a public felküldése és userhez kötése, utána küldözgetheti az ezzel aláírt tokent. Payloadba bekerül a usernév, a rendszer az alapján kikeresi a public kulcsot, és azzal validál. De ezt újra el kellene játszani minden eszközzel, és kell külön utat nyitni a kulcs felküldésére, ami ha nincs "megfelelően" túlbonyolítva, akkor a gyenge pont lesz. Kérdés, hogy kik az ügyfelek, meg lehet-e játszani velük. (pl: OTP generálás weboldalon, user bepötyögi app regisztrációs felületébe, ami visszaküldi a publikus kulcsával együtt, és onnantól regisztrálva van).

Sokkal egyszerűbb megoldás lenne csinálni egy mobil gateway-t, ami hagyományos certes módszerrel kommunikál a rendszerrel, így ahhoz nem kell nyúlni. Hogy ő hogy autentikálja a klienseket, az szerintem tetszőleges, akár még basic auth is lehet. Ugyan a mobil gateway is egy újabb komponens a rendszerben, de ez nem csak authentikáció miatt lenne jó, egy mobil kliens valószínűleg más api-t igényel, bár látatlanban nehéz megmondani, mennyi hasznot hozna.

( sj | 2017. 05. 27., szo – 20:38 )

csak valid kliens cert-el lehet túljutni a webszerveren, azon belül pedig username/jelszó amit már a rendszer csekkol (php).

ennek mi ertelme van igy? :-) A certificate onalloan kepes az authentikaciora, hiszen benne van, hogy kicsoda az adott kliens*. Mi szukseg van ezutan meg login nev jelszora? Mert szerintem ha a telefonra el tudod juttatni valahogy a certificate-et (+a kulcsot ill. a jelszot), akkor kb. megoldottad a feladatot.

*: sot, akar az authorizacio sem lehetetlen certificate extenstion hasznalataval: https://tools.ietf.org/html/rfc5280#section-4.2

username/jelszó nem az említett feladathoz volt, hanem egy példa egy másik esetre. Ott a cert-nek csak az autentikáció a lényege, az authorizációt egy username és hozzátartozó jelszó segíti. Ott a cert-nek csak annyi a lényege, hogy ne nyissuk meg a netre szabadon az api-t. De ez más, nem kapcsolódik az app-hoz.

( denton | 2017. 05. 28., v – 22:25 )

Sziasztok, Mindenki!

Köszönöm a válaszokat, ha nem is értek egyet, akkor is köszönöm, hogy időt áldoztatok a kérdésre.

Mindenki más irányból közelíti meg a kérdést, plusz vannak félreértések is, bár több esetben is definiáltam az okokat.

1. Nem akarom feltörhetetlenné tenni az aplikációt, mert az lehetetlen
2. Attól, hogy van egy trendi, sokak által használt megoldás, nem jelenti azt, hogy nekünk is az lesz a megfelelő
3. Nem vagyunk bank, de nagyobb cégről van szó, sok ügyféllel és a felsőbb szervek 10 milkós büntiket tolnak be ha csak nem tetszik az arcunk. Ha jogi oldalról kell megvédenünk magunkat, akkor egy magyar hivatal k.ra nem érti meg mi a pöccsenet az a token, de azt felfogja, hogy ott egy kulcs a telefonon amit én soha nem fogok látni, a certben pedig a user adatai vannak amivel azonosítja magát.
4. OTP sms-t küld, CIB mobil app-ja sms-ben adja meg az aktiváló kódot a regisztrációnál. Emlékeim szerint a telekom is küld sms-t. Nekem most még sms szerver nélkül kell dolgoznom. Ha lenne sms szerver, akkor már jobban védhető a dolog, mert lehet adatot küldeni ami valóban a telefonra érkezik meg.
5. Nekem és az app fejlesztőknek is egyszerűbb lenne a token, saját app-hoz azt használnék.

Security through obscurity, gondolom nem kell tovább fejtegetnem :)
Amúgy ha ennyire fontos és kritikus akkor tároljátok a kulcsokat mondjuk egy smart card-on, szigorúan személyesen átadva az ügyfélnek és minden platformra adtatok egy egész kényelmes és biztonságos módot az autentikációra. Mobilhoz mondjuk ez egész barátságosnak néz ki: https://www.vasco.com/products/two-factor-authenticators/hardware/card-…

de azt felfogja, hogy ott egy kulcs a telefonon amit én soha nem fogok látni

ezt mire fel jelented ki? Nekem vicces, hogy a kepzeletbeli apparatcsik azt nem tudja, mi a hw token, de azt igen, mi az a kulcs, meg a certificate.

és a felsőbb szervek 10 milkós büntiket tolnak be ha csak nem tetszik az arcunk.

ez nyilvan igy szokott menni. Beszelnetek kene egy ugyveddel, jogi tanacsadoval, ... aki felvilagosit titeket, hogy a szuper titkos projektnek milyen muszaki parametereknek, eloirasoknak kell megfelelni, stb. Mert vagy nincs kiforrott szabalyozas, vagy ti vagytok tajekozatlanok.

Btw. en a helyetekben megrendelnek egy biztonsagi auditot, sot a kivalasztott ceggel meg azelott egyeztetnem az elkepzelest, mielott sok zset belefeccoltok a fejlesztesbe...