Authentifizierungproblem

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Authentifizierungproblem

    Hallo Leute,

    ich hab folgende Situation, ich hab ein Backend Service, mit welchem sich Nutzer meiner App später verbinden sollen.
    Ich will aber vermeiden, dass sich Nutzer irgendwo registrieren müssen (Anmelde Prozedur).
    Des weiteren will ich jedoch auch, dass nur Leute, welche die App Nutzen, valide Daten an meinen Server schicken dürfen.

    Meine erste Idee war nun einfach ein "Passwort" innerhalb der Binärdaten zu verstecken, damit wäre natürlich sichergestellt das nur "meine" Software mit dem Server reden kann (Symmetrische Verschlüsselung).

    Allerdings halte ich das für keine schöne Lösung, da ja der Angreifer vllt. doch irgendwie an das Passwort kommen könnte.
    Hat jemand von euch vllt. eine Idee wie man das lösen könnte?

    Sind die IPA Files eigentlich verschlüsselt? Wie aufwändig wäre es einen Schlüssel aus dem Sourcecode oder RAM rauszubekommen?

    Viele Grüße und Danke für euere Hilfe
    in Bearbeitung
  • da gibts nichts wirklich sicheres. du kannst es den angreifern nur erschweren.
    du musst dich halt selbst fragen wieviel aufwand du in die "absicherung" des webservices legen willst um es jemandem zu erschweren den auch direkt zu verwenden.
    sind die daten die du lieferst wirklich so einzigartig dass man die sonst nirgends bekommt?
    wenn es persänliche daten sind dann sollte man darauf ja eh nur mit einem persönlichen passwort zugriff haben...
  • Eine 100% sichere Lösung wirst du nicht hinbekommen. Der Angreifer hat die App und dadurch immer auch alle Daten, die er für den Angriff benötigt. Die IPA-Files sind auch nicht verschlüsselt sondern nur signiert. (BTW: Hier ist im Prinzip genau das gleiche Problem: Der Angreifer hat das System, das die App entschlüsseln kann, und somit alle Daten, die er zum entschlüsseln braucht – auch wenn es einem der Hardware- und Betriebssystemhersteller ereblich schwieriger machen kann.)

    Ich würde einen Hash über einen generierten String als Passwort verwenden. Der Server muss den String aus den Daten irgendwie rekonstruiert bekommen, damit er unabhängig den Hash berechnen und vergleichen kann.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    gritsch schrieb:

    sind die daten die du lieferst wirklich so einzigartig dass man die sonst nirgends bekommt?
    In der Regel lassen sich solche Angreifer bzw. Datensauger anders ermitteln, da sie meistens ein anderes Zugriffsprofil haben. Beispielsweise kann man die Anzahl der erlaubten Anfragen pro Minute und IP begrenzen.
    Ich brauche aber nur eine einzige anfrage um alle daten abzuschnorcheln (wenn es die API hergibt. falls nicht braucht auch eine app mehrere anfragen dafür).
    Und da wir noch kein flächendeckendes IPv6 haben ist es mit bestimmten IPs limitieren eher schlecht weil ja viele verschiedene nutzer hinter dem gleichen NAT sitzen können (oder sogar ein mobilfunkprovider all seine kunden NATet und somit die selbe IPv4 haben...)
  • gritsch schrieb:

    macmoonshine schrieb:

    Die IPA-Files sind auch nicht verschlüsselt sondern nur signiert.
    Die IPA files sind weder verschlüsselt noch signiert (einfache zip files), die binaries bzw der ausführbare code sind signiert UND verschlüsselt (signed + encrypted). Du kannst also nicht zb einfach einen classdump erstellen!
    Der Inhalt ist doch signiert, d. h. du kannst keine einzige Datei im IPA ändern, ohne die Signatur(en) zu brechen, oder? Das meine ich mit signiert. Das gesamte IPA zu signieren geht natürlich nicht, weil ZIP das ja nicht unterstützt.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    gritsch schrieb:

    macmoonshine schrieb:

    Die IPA-Files sind auch nicht verschlüsselt sondern nur signiert.
    Die IPA files sind weder verschlüsselt noch signiert (einfache zip files), die binaries bzw der ausführbare code sind signiert UND verschlüsselt (signed + encrypted). Du kannst also nicht zb einfach einen classdump erstellen!
    Der Inhalt ist doch signiert, d. h. du kannst keine einzige Datei im IPA ändern, ohne die Signatur(en) zu brechen, oder? Das meine ich mit signiert. Das gesamte IPA zu signieren geht natürlich nicht, weil ZIP das ja nicht unterstützt.
    es geht aber nicht drum was zu ändern sondern etwas auszulesen und dagegen schützt die signatur nicht aber eben die verschlüsselung.
  • NAT ist genau das Problem, dadurch können wir natürlich nicht unterscheiden ob es ein valider Request ist oder nur viele SmartPhones in nem Mobilfunknetz.

    Ich hatte ja noch die Idee einen Token via silent Push an die App zu senden, das heißt die App stellt ohne Verschlüsselung eine Anfrage, der Token jedoch wird über den Push Server von Apple an das SmartPhone geschickt, dadurch bräuchte der Angreifer viele Apple Accounts um meinen Server anzugreifen oder zu zu Spamen.

    Allerdings bin ich damit auch nicht zufrieden, da es sein kann das später auch andere Apps auf den Service zugreifen werden. Und dann müsste uns der Entwickler sein Zertifikat zur verfügung stellen.
    in Bearbeitung
  • predator747 schrieb:

    Ich hatte ja noch die Idee einen Token via silent Push an die App zu senden, das heißt die App stellt ohne Verschlüsselung eine Anfrage, der Token jedoch wird über den Push Server von Apple an das SmartPhone geschickt, dadurch bräuchte der Angreifer viele Apple Accounts um meinen Server anzugreifen oder zu zu Spamen.
    Welche Informationen stellt denn euer Server bereit?
    „Meine Komplikation hatte eine Komplikation.“
  • Es ist ein Backend Service für echtzeit Mulitplayer Games und wir wollen vermeiden, dass sich sich irgendwelche Scriptkiddys nen Clienten schreiben und damit das Spiel "übernehmen". Gleichzeitig hätten wir natürlich gern, dass der Spieler nach dem Download sofort los spielen kann, ohne sich irgendwo umständlich Registrieren zu müssen.

    Das mit dem Token über den Push Service wäre ja schon Trick 17, somit könnten nur Leute mit ner echten Apple ID spielen. Allerdings könnte auch keiner spielen, der Push ausgestellt hat...
    in Bearbeitung
  • predator747 schrieb:

    Das mit dem Token über den Push Service wäre ja schon Trick 17, somit könnten nur Leute mit ner echten Apple ID spielen. Allerdings könnte auch keiner spielen, der Push ausgestellt hat...
    Die Idee finde ich auch ganz interessant.

    Die Kommunikation bekommst du wahrscheinlich aber nie ganz sicher. Du kannst es dem Angreifer noch etwas schwerer machen, indem du falsche Anfragen nicht als solche kennzeichnest; also du gibst keinen Fehler zurück sondern eine Antwort mit falschen, aber realistisch aussehenden Daten. Da kann man auch mit Steigerungen arbeiten: Bei der ersten Anfrage sind die Daten noch fast richtig und bei der hundertsten totaler Blödsinn. Beispielsweise stimmt der Highscore bei den ersten 10 Anfragen und bei der hundertsten gibst du -12345 zurück.
    „Meine Komplikation hatte eine Komplikation.“
  • Ich habe von Spieleprogrammierung 0 Ahnung aber das was du da machen willst, machen doch quasi alle games. Du lädst es down und kannst spielen und wirst dann automatisch mit dem Gamecenter Account gekoppelt.

    Damit hast du alle Deine Probleme gelöst und der User kann sogar auf beliebigen Devices spielen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)