shared secret für REST API in flash / AS3 einbinden = sicherheitsloch?

[Janoscharlipp]

Sobald der Client den key auch nur einmal in Rohform haben muss (und das muss er, wenn er direkt mit deren Service kommunizieren soll) ist das Problem unlösbar. Egal wie du es anstellst, was meine Client-Anwendung an Daten zur Verfügung hat, habe ich auch zur Verfügung, du kannst es mir nur schwer machen, dran zu kommen.

[Omega Psi]

Das ist klar. Aber sollte nicht auch jeder der Nutzer einen eigenen Key für die API haben?

[chrrillo]

das api system ist leider so aufgebaut dass des pro developer/app nur einen key gibt. der user authorisiert dann noch einen token für sich der den eigentlichen zugang zu den daten des users ermöglicht. die daten des users sind also sogesehen nicht in gefahr, man könnte eben nur den developerkey klauen.

[Nico B.]

[QUOTE=Omega Psi;1846896]Wieso sollte man es nicht können? Was kann man nicht dekompilieren?

Da haste sicherlich recht. Hätte mich nur interessiert, ob es bei -air Files eine ähnlich simple Möglichkeit wie bei "normalen" swf's gibt. (SwfDec....)

Falls ja, nein ich will sie gar nicht kennen, nur wissen, ob es sowas gibt. :-)

nico

[Janoscharlipp]

chrrillo, muss der User denn später den Key verwenden, oder reicht dann das Token? Sonst könnte ja dein Server einmal das Token holen, und dem User geben, und der Key würde nie zum Client wandern.

[chrrillo]

ich dachte kurz das wäre die lösung, aber leider zu früh gefreut, es muss ja jeder request vor dem senden mittels des geheimen keys signiert werden damit ihn der webservice als echt erkennt. ala

PHP-Code:

request --> method=setName&name=newName&token=12345&signatur=sig
sig --> md5(geheimKey+"methode=setName&name=newName&token=12345") 


also der key muss einfach im client sein. geht nicht anders

[Omega Psi]

Es wird nicht mit dem geheimen Key signiert?! Das macht doch kein Sinn. Der Client sollte mit dem öffentlichen Schlüssel signieren und der Service mit dem privaten Schlüssel, den nur er kennt, verifizieren. Oder verstehe ich was falsch?

[Janoscharlipp]

In seinem Code wird doch mit dem geheimen Schlüssel signiert.

Jedenfalls ist damit die Sache in meinen Augen klar: es gibt keine Lösung

[Omega Psi]

Nein, hatte mich vertippt:

Es wird mit dem geheimen Key signiert?! Das macht doch kein Sinn. Der Client sollte mit dem öffentlichen Schlüssel signieren und der Service mit dem privaten Schlüssel, den nur er kennt, verifizieren. Oder verstehe ich was falsch?

[Janoscharlipp]

Signieren muss man doch immer mit dem geheimen Key (sonst könnte ja jeder für einen Signieren), verschlüsseln kannst du mit dem öffentlichen Schlüssel des anderen (so dass es nur er mit seinem geheimen entschlüsseln kann).
Wobei ein Hash mit dem geheimenKey als "Salt" wohl kaum funktioniert, das kann ja nie wieder jemand überprüfen (Besser wäre irgendein Salt (z.B.das Token), dann hashen, und dann den Hash mit dem geheimen Schlüssel verschlüsseln)

[Omega Psi]

Stimmt.

[chrrillo]

ich glaub das problem ist dass diese api architektur eigentlich für andere web applicationen gedacht ist wo der geheim key kein problem ist weil er auf dem server bleibt. für den user ist die sache ja eigentlich auch komplett sicher weil er ja den spezifischen token authorisieren muss, dh es kann nie jemand auf seine daten zugreifen, auch mit geheimen key nicht. das einzige risiko ist dass jemand meinen geheimen key und für sein programm verwendet, wo bei die genau so leicht zu bekommen sind wie eine email addresse. Im Grunde ist das Risiko also nicht wirklich groß.