Verschlüsselung Webservice

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

  • Verschlüsselung Webservice

    Bin gerade dabei ein Problem zu lösen finde aber im Netz bis jetzt nicht die richtige Lösung.

    Problem: Habe ein Login in einer App, und will diese mittels Webservice machen. dh. es wird dann eine URL zb. deineUrl.at/login.php?username…t=asjkdbhasdjbasdkasd1231

    Also das Passwort md5 verschlüsselt dachte ich, problem, wenn jemand die URL abfangt hat er immer zugriff weil md5 hash verschlüsselt immer gleich. Wie kann ich es also machen, dass das sicher ist? Das sich der hash immer ändert oder mit welcher verschlüsqelungsmethode kann ich das machen? Wie mache ich die Authentifizierung ?
  • Https verwenden
    Certificate pinning
    Parameter nicht in der URL mit übergeben
    Passwort verschlüsselt in der DB speichern
    Nicht md5 verwenden !!
    .... gibt noch einiges mehr

    In diesem Thread hast du schon ein paar Hinweise erhalten:

    JSON Webservice Verschlüsselung

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von 99s99m ()

  • Warum fängst Du denn einen neuen Thread an?

    Sinngemäß würde ich wie folgt vorgehen:
    1. Transportverschlüsselung via TLS zwingend
    2. Usernamen und Passwort im HTTP-Body (nicht als Parameter) und damit verschlüsselt übertragen
    3. Verwendung einer hinreichend langen und einmaligen SessionID nach Authorisieren des Benutzers für die weitere Kommunikation
    Wie @gritsch sagte: Kein triviales Thema, wenn es sicher sein soll. Du solltest abwägen, welchen Sicherheitsanspruch Deine App erfüllen muss, vielleicht gibt es auch simplere (weniger sichere) Lösungsansätze.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Es sind keine Bankdaten die da übertragen werden aber es sollte schon halbwegs sicher sein.

    Wie erfülle ich den Punkte 2? Also das ich Ufernamen und Passwort im Body nicht als parameter mitgab?


    Derzeit habe ich es so:

    Quellcode

    1. //send userdata to server
    2. let url = NSURL(string: "http://Webseite.at/userLogin.php");
    3. let request = NSMutableURLRequest(URL: url!);
    4. request.HTTPMethod = "POST";
    5. let postString = "email=\(userEmailText!)&password=\(userPasswordText!)";
    6. request.HTTPBody = postString.dataUsingEncoding(NSUTF8StringEncoding);
  • fabian1302 schrieb:

    gritsch schrieb:

    und punkt 1 ist dir sicherlich auch nicht klar oder wie hast du das cert-pinning umgesetzt?

    und wie speicherst du die daten in der db?

    was wolltest du nochmal mit md5 machen?
    ich meinte Punkt 1 von myMattes ist mir klar
    dort gehört aber cert pinning dazu und das denke ist dir eben nicht klar.

    so einen sicheren webservice aufbauen enthällt vielleicht 20 wichtige punkte, wenn du nur einen davon nicht oder falsch implementierst ist das ganze wirkungslos.
  • fabian1302 schrieb:

    und wie mache ich cert pinning ?
    Dir ist aber klar, was cert pinning ist, oder? Wenn nicht, findest Du hier eine m. E. ganz gute Einführung. Wenn ja, bezieht sich Deine Frage wohl auf das Extrahieren des Public Keys aus dem SSL Zertifikat, oder? Auch dafür ist nicht wirklich Google-fu nötig.

    Bei Deinen vielen Fragen zu diesem Themenbereich würde ich Dir von einer eigenen Implementierung abraten. Lass das jemanden machen, der sich auskennt: Die Wahrscheinlichkeit eines Fehlers ist recht hoch und dann ist das ganze Konzept kompromittiert und wertlos. Scheinsicherheit ist noch gefährlicher als bekannte Schwächen.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • fabian1302 schrieb:

    ok, und was würdest du zB. für eine sichere Implementierung verlangen? Also das alles verschlüsselt zu einer DB übertragen wird und wieder zurück? Weil ich bin Schüler und kann dafür nicht sehr viel zahlen deswegen wollte ich es selbst machen
    da du schüler bist und dich dafür interessierst, solltest du doch zeit finden ein buch dazu zu lesen. vielleicht findest du es auch in eurer bibliothek, ansonsten lass dir ein aktuelles schenken (weihnachten steht doch vor der tür).
  • Die Frage ist, wie wichtig die Daten sind und ob er selbst verschlüsselt oder gegen Missbrauch schützen meint.

    Da kann man ja um Erfahrungen zu sammeln erst mal Halbgas fahren:

    - UNIX-Zeitstempel abfragen
    - Passphrase mit Zeitstempel zu String zusammenfügen
    - MD5 von diesem String
    - Request an den Server mit dem Token und Zeitstempel

    Der Server baut dann genau das gleiche zusammen und schaut, ob der Token identisch ist und somit ist klar, ob der Token valid ist.
    Zudem kann der Request nur einmal ausgeführt werden, da Du ihn nur einmal erlaubst und zum Beispiel nur eine Existenz von wenigen Sekunden zuschreibst.

    Das hat nichts mit Verschlüsselung zutun, aber vielleicht reicht Dir das schon, um Deine Schnittstelle rudimentär abzusichern.
    Last.fm etc. machen das so, da es einfach aber dennoch effektiv ist.

    Zumal das eine Grundaufgabe ist um eben Erfshrung zu sammeln.

    Viele Grüße
  • fabian1302 schrieb:

    ok, und was würdest du zB. für eine sichere Implementierung verlangen?
    Ich programmiere nicht für andere Leute, aber ich glaube auch nicht, dass hier die Lösung Deines Problems liegt: Auch vor Beauftragung eines Dritten solltest Du genau wissen, was Du brauchst und welche Techniken dafür in Frage kommen. Wenn das nicht so ist, hängst Du auf Gedeih und Verderb an Deinem Dienstleister und es haben schon viele erleben müssen, dass das nicht wirklich clever ist.

    BTT: Wie @little_pixel und ich schon sagten: Überlege Dir, welchen Schutz Du wirklich brauchst. Am Anfang direkt die 100% Lösung implementieren zu wollen, ist eben ein dickes Brett. Vielleicht reicht anfangs ein Pre-Shared Key aus ... wenn er ausreichend im Code versteckt wird m. E. durchaus ein gangbarer Weg. Und vergiss bei den ganzen Überlegungen Deinen Web-Server nicht: Was hilft die tollste App-Kommunikation, wenn der Server übernommen werden kann und z. B. die Scripte manipuliert werden etc. pp.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.