mySQL C API in xCode-Projekt einbinden

  • Ich habe mir die beiden Links angesehen und musste beim ersten folgendes lesen:

    Hinweis: Es existiert keine decrypt Funktion, da crypt() eine Einweg-Verschlüsselung ist.

    Damit hast du eine synchrone Verschlüsselung zwischen PHP <=> Objective-C erstellt? Lt. Beschreibung erstellt crypt() einfach nur einen Hash-Wert, wie man es von MD5 kennt.
    Ich habe gerde noch eines gefunden: mcrypt Das funktioniert in beide Richtungen. Hiermit habe ich vor einiger Zeit auch mal herumexperimentiert. Das Problem war nur, dass PHP für den gleichen Schlüssel und den gleichen Klartext immer andere Ergebnisse brachte und ich es in Objective-C nicht dechiffriert bekam. 8|
    [url]http://www.isolute.de[/url]

  • Hier gibt es kostenlose, valide SSL Zertifikate:
    startssl.com/?app=1
    Sollen auch vernünftig sein. Irgendwo auf heise.de gibs ein Test + Anleitung.

    Was soll blowfish bringen? Entweder, die keys werden nicht ausgetauscht, dann kann ich den Key einfach aus Deiner App auslesen, oder die Keys werden zuvor ausgetauscht, dann kann ich sie aus dem HTTP Stream auslesen. Da kann man genausogut Base64 nehmen oder gar nicht verschlüsseln.
    Ok, zugegeben, man baut eine kleine Hürde ein.

    Wenn Du nur die Login Credentials schützen willst, kannst Du auch auf einen Drittanbieter zurückgreifen. Google Accounts bzw. jeder OpenID Anbieter etwa. Da ist der Login immer HTTPS und sicher. Oder Challange-Response / HMAC anschauen: Server schickt Zufallszahl, Client nimmt Passwort + Zufallszahl, macht ein SHA-2, schickt das Ergebnis zurück. Server kennt ja zufallszahl und Klartext-passwort, und kann den Hash prüfen. Ein Angreifer kann sich nur einloggen, wenn der Server noch einmal genau die gleiche Zufallszahl schickt, was der Server aber "so gut wie nie" tut.
    ♥C++

  • Ich habe mir das recht eifach vorgestellt: Die Keys wären die Logindaten der User. Mit diesen wird die Nachricht verschlüsselt. Auf dem Server liegen die Logindaten in der DB, somit können die Daten entschlüsselt werden. In die andere Richtung funktioniert es entsprechend. Das sollte doch eigentlich kein Problem sein, oder?
    [url]http://www.isolute.de[/url]

  • zerm schrieb:

    Was soll blowfish bringen? Entweder, die keys werden nicht ausgetauscht, dann kann ich den Key einfach aus Deiner App auslesen, oder die Keys werden zuvor ausgetauscht, dann kann ich sie aus dem HTTP Stream auslesen. Da kann man genausogut Base64 nehmen oder gar nicht verschlüsseln.
    Ok, zugegeben, man baut eine kleine Hürde ein.

    Was ist das für eine Frage ??? Natürlich kann man irgendwie alles auslesen, die Frage ist nur wie schwer mach ich es dem Gegenüber. Wie ich den Key sende liegt doch an mir, wenn ich ihn z.B. in einem "zufalls-String" verstecke wirst du ihn nicht so schnell finden. Wie gesasgt knacken läßt sich alles. ich hatte mit der Methode bis jetzt noch nie ein Problem.
    Um ganz sicher zu gehen nimm halt HTTPS + Blowfish oder ne andere Methode.

  • wolf_10de schrieb:

    zerm schrieb:

    Was soll blowfish bringen? Entweder, die keys werden nicht ausgetauscht, dann kann ich den Key einfach aus Deiner App auslesen, oder die Keys werden zuvor ausgetauscht, dann kann ich sie aus dem HTTP Stream auslesen. Da kann man genausogut Base64 nehmen oder gar nicht verschlüsseln.
    Ok, zugegeben, man baut eine kleine Hürde ein.

    Was ist das für eine Frage ??? Natürlich kann man irgendwie alles auslesen, die Frage ist nur wie schwer mach ich es dem Gegenüber. Wie ich den Key sende liegt doch an mir, wenn ich ihn z.B. in einem "zufalls-String" verstecke wirst du ihn nicht so schnell finden. Wie gesasgt knacken läßt sich alles. ich hatte mit der Methode bis jetzt noch nie ein Problem.
    Um ganz sicher zu gehen nimm halt HTTPS + Blowfish oder ne andere Methode.

    Nein, HTTPS/TLS lässt sich nicht knacken. Bzw. nur Brute-Force und dafür fehlen den Meissten die Ressourcen.
    HTTPS+Blowfish ist besonders sinnlos, eine Verschlüsselung wird nicht besser, dadurch, dass man sie noch einmal verschlüsselt (abgesehen von Konstrukten wie 3DES, aber das ist was anderes). HTTPS/TLS nimmt in der Praxis (hab grad mal Sparkasse und Google getestet) RC4, wenn ich mich recht entsinne steht es Dir aber frei, anzubieten/zu fordern, was Du möchtest.

    Und wegen Deinem "Natürlich kann man irgendwie alles auslesen": Wenn Du so an die Sache herangehst, brauchst Du wiegesagt auch gar nicht verschlüsseln. Was willst Du nun? Sicherheit, oder nur scheinbare Sicherheit. Und wenn Du noch nie damit Probleme hattest, ist das schön. Du hättest aber sicherlich auch noch nie Probleme gehabt, wenn Du gar nicht verschlüsselst. Wahrscheinlich hättest Du noch nicht einmal Probleme gehabt, wenn deine EC-Karten-PIN auf einem Klebezettel an Deinem Monitor kleben würde. Und?
    ♥C++

  • zerm schrieb:

    Nein, HTTPS/TLS lässt sich nicht knacken. Bzw. nur Brute-Force und dafür fehlen den Meissten die Ressourcen.
    HTTPS+Blowfish ist besonders sinnlos, eine Verschlüsselung wird nicht besser, dadurch, dass man sie noch einmal verschlüsselt (abgesehen von Konstrukten wie 3DES, aber das ist was anderes). HTTPS/TLS nimmt in der Praxis (hab grad mal Sparkasse und Google getestet) RC4, wenn ich mich recht entsinne steht es Dir aber frei, anzubieten/zu fordern, was Du möchtest.

    Jetzt aber mal langsam,
    ---HTTPS+Blowfish ist besonders sinnlos
    und warum ??
    per HTTP kannst du nach wie vor den Stream auslesen, richtig ?? Das war genau das was ich sagte, wenn du das nicht möchtest nimm HTTPS.
    Wenn du kein HTTPS nehmen willst oder kannst, dann nimm eben irgendeine bestehende (Blowfish) oder eine eigene Verschlüsselung. Damit hatte ich noch nie ein Problem.
    Das war wohl wiederum das was ich sagte.Solange keiner meine Karten-PIN am Bildschirm sehen kann, hab ich auch damit kein Problem, aber es wird aber wohl
    immer ne Möglichkeit geben daran zu kommen.

  • wolf_10de schrieb:

    zerm schrieb:

    Nein, HTTPS/TLS lässt sich nicht knacken. Bzw. nur Brute-Force und dafür fehlen den Meissten die Ressourcen.
    HTTPS+Blowfish ist besonders sinnlos, eine Verschlüsselung wird nicht besser, dadurch, dass man sie noch einmal verschlüsselt (abgesehen von Konstrukten wie 3DES, aber das ist was anderes). HTTPS/TLS nimmt in der Praxis (hab grad mal Sparkasse und Google getestet) RC4, wenn ich mich recht entsinne steht es Dir aber frei, anzubieten/zu fordern, was Du möchtest.

    Jetzt aber mal langsam,
    ---HTTPS+Blowfish ist besonders sinnlos
    und warum ??
    per HTTP kannst du nach wie vor den Stream auslesen, richtig ?? Das war genau das was ich sagte, wenn du das nicht möchtest nimm HTTPS.
    Wenn du kein HTTPS nehmen willst oder kannst, dann nimm eben irgendeine bestehende (Blowfish) oder eine eigene Verschlüsselung. Damit hatte ich noch nie ein Problem.
    Das war wohl wiederum das was ich sagte.Solange keiner meine Karten-PIN am Bildschirm sehen kann, hab ich auch damit kein Problem, aber es wird aber wohl
    immer ne Möglichkeit geben daran zu kommen.

    Weil HTTPS schon verschlüsselt ist. Eine zusätzliche Verschlüsselung bringt da nichts.
    HTTP+Blowfish, meinetwegen, ich sehe aber nicht, was gegen SSL/TLS spricht. Wiegesagt, es gibt kostenlose Zertifikate, man kann Self-Signed Zertifikate verwenden, oder den Log-in auslagern, sofern man nur den schützen will.
    Ich weiss nicht, wo der qualitative Unterschied zwischen "Ich nehme etwas unsicheres" und "ich nehme gar nichts" liegt.
    ♥C++

  • Ich zitiere dich mal eben:

    Was soll blowfish bringen? Entweder, die keys werden nicht ausgetauscht, dann kann ich den Key einfach aus Deiner App auslesen, oder die Keys werden zuvor ausgetauscht, dann kann ich sie aus dem HTTP Stream auslesen.


    Also eine zusätzliche Verschlüsselung via HTTPS bringt dann nix ?? Dann solltest du dich entscheiden was du willst.
    BTW: Ich denke mal wir wollen beide auf das Selbe hinaus, von daher lassen wir das

  • wolf_10de schrieb:

    Ich zitiere dich mal eben:

    Was soll blowfish bringen? Entweder, die keys werden nicht ausgetauscht, dann kann ich den Key einfach aus Deiner App auslesen, oder die Keys werden zuvor ausgetauscht, dann kann ich sie aus dem HTTP Stream auslesen.


    Also eine zusätzliche Verschlüsselung via HTTPS bringt dann nix ?? Dann solltest du dich entscheiden was du willst.
    BTW: Ich denke mal wir wollen beide auf das Selbe hinaus, von daher lassen wir das

    Heh, nein, weil wenn Du schon HTTPS nimmst, ist ja schon alles verschlüsselt ;)
    Aber was auch immer...
    ♥C++