Nemate nahodou nekdo pristup k 5.0.2 zarizeni na debug appky? Mam nejake error reporty a nemam kde zreplikovat...

Používá někdo Spoon k instrumentačnímu testování? Pořád mi to nějak špatně bere screenshoty, když vynucuju orientace obrazovky.

Díky

Jinak návod třeba zde http://au.ibtimes.com/...-flash-player-android-41-42-43-jelly-bean-android-44-kitkat-devices-1328874

2SDPERCY: Teda kromě toho že jsi ve špatném auditku a s tím jak píšeš se asi hůře googli. Odpověď není jednoduchá. Je to náročná operace kdy musíš lehce hacknou prohlížeč (starou verzi). Nahrát Flash player a modlit se že to na tvém zařízení pojede. A pokud ano tak nejspíše pekelně pomalu. TL;DR Odpověď je ze to nejde.

Ano Falco

2SDPERCY: flash player?

PISKVOR: Díky, to je přesně ono :)

PISKVOR: Díky, to jsem si myslel...úplně jako nyx to dělat nemůžu (předpokládejme, že není k mob.appce webové rozhraní). Když bych měl app-user-specific token, tak bude problém s distribucí, nebo se mýlím?

K tomu bych měl ještě jednu otázku, která s tím nepřímo souvisí (sorry za OT) - použití na serveru generovaného tokenu pro requesty je určitě lepší než použití ID uživatele, že? Pokud by se útočník snažil request podvrhnout, tak token cizího uživatele nemá prakticky šanci získat, kdežto u ID by mohl zkoušet zvyšovat/snižovat o 1 - samozřejmě se nabízí varianta Stringových ID v DB, ale to bych teď neuvažoval. Díky moc!

KEVIN182: Physical access = game over, root = taky game over, s tim nic nenadelas. No, a nebo to muzes resit trochu podobne jako nyx (byt ten ma jen token, ne klice), udelat private key app-user-specific, takze pokud si ho uzivatel vytahne, tak ... congratulations, muze sam delat ty samy requesty, ktery za nej dela appka.

Zdravím, chtěl jsem se zeptat, jak uchováváte Private Key potřebný pro API komunikaci. Vemu-li v potaz následující odkaz, který se návrhem API zabývá:
Designing a Secure REST (Web) API without OAuth
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

tak tam zmiňuje:
What about the scenario where you are writing a public-facing API like Twitter, where you might have a mobile app deployed on thousands of phones and you have your public and private keys embedded in the app?

On a rooted device, those users could likely decompile your app and pull your private key out, doesn’t that leave the private key open to being compromised?

Yes, yes it does.

So what’s the solution?

Taking a hint from Twitter, it looks like to some degree you cannot avoid this. Your app needs to have its private key (they call it a secret key) and that means you are open to getting your private key compromised.

What you can do though is to issue private keys on a per-application-basis, instead of on a per-user-account basis. That way if the private key is compromised, that version of the application can be banned from your API until new private keys are generated, put into an updated version of the app and re-released.

What if the new set of keys get compromised again?

Well yes, that is very possible. You would have to combat this in some way on your own, like encrypting the keys with another private key… or praying to god people will stop hacking your software.

Regardless, you would have to come up with some 2nd layer of security to protect that new private key, but at least there is a way to get the apps deployed in the wild working again (new version) instead of the root account being locked and NONE of the apps being able to access the service again.

REDTIME: Teoreticky by mohl byt v telefonu nejaky HW AES-on-chip, ale...

DATEL: Imho na posunovani bytu neni moc co optimalizovat. A co znamena pomale? Dnesni CPU v telefonech zase nejsou orezavatka a da se pouzit castecne i GPU... i kdyz to je problematicke. Ale obecne, co pomuze, tak je paralelni zpracovani.

PISKVOR: no, to jsme se jim taky snažili vysvětlit, že to je prostě náročné na CPU a že nějaké urychlení bude znamenat úplné přepsání systému šifrování a dešifrování těch datových kontejnerů, tak jestli by jim opravdu nestačil zaheslovaný ZIP, ale ne, prostě to je málo bezpečné.

Existuje nějaká možnost, jak rychleji provádět tu změnu bajtů? V PHP jsem si udělal nástroj pro dešifrování, lze z toho vyčíst použitý algoritmus:

// $key je pole bytů
while (!feof($in)) {
    $buffer = fread($in, 8192);
    $len = strlen($buffer);
    $position = ftell($in) - $len;
    for ($i = 0; $i < $len; $i++) {
        $key_idx = ($position + $i) % $key_count;
        $delta = $key[$key_idx];
        $buffer[$i] = chr((ord($buffer[$i]) - $delta));
    }
    fwrite($out, $buffer);
} 

(ono samozřejmě zákazník by momentálně nerad předělával serverovou implementaci, takže tlačí na optimalizaci toho, jak to je teď, ale já se obávám, že to prostě nepůjde a bude se muset zvolit opravdu jiné řešení, akorát že s tímhle nemám vůbec zkušenost, tak v tom trochu tápu)

MRAKY: Díky, podívám se na to, akorát to teda vypadá dost robustně, tak nevím, jestli to dám :)

Ještě dodám, potřebuju, aby z takto šifrovaného kontejneru šlo vytvořit "on the fly" stream pro obsažené video a audio soubory.

Ono ta implementace skrz ZIP archiv není úplně špatná myšlenka, odpadá nutnost implementovat právě nějaký kontejner, akorát teda to dešifrování a šifrování je takhle dost pomalé - nevím, jestli by pomohlo, kdyby to bylo jako binární knihovna v NDK.

Případně, nemáte někdo tip na popis nějakých algoritmů pro šifrování velkého objemu dat, které je třeba číst / zapisovat živě, a aby to bylo alespoň trochu svižnější, ikdyž to bude napsané v Javě a ne jako nativní knihovna?