Mac App mit Passwort schützen - Wo und wie das Passwort speichern?

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

  • Mac App mit Passwort schützen - Wo und wie das Passwort speichern?

    Hallo,

    ich starte gerade mit einer neuen Mac App die per Passwort geschützt werden soll. Die Frage hierbei ist, wie und wo die App am besten das Passwort speichert um dieses dann mit der Nutzereingabe beim Login vergleichen zu können.

    Die einfachste Lösung wären natürlich das Speichern in den NSUserDefaults. Die kann aber natürlich jeder auslesen, darum sollte man das Passwort dort nicht im Klartext speichern. Aber auch wenn man z.B. nur den MD5 Wert hinterlegt kann man diesen einfach löschen und das Passwort somit auf "leer" zurücksetzten. Man kann natürlich zusätzliche die Information speichern, dass ein Passwort vorhanden ist. Löscht man aber die NSUserDefaults ist auch diese Information weg und die App weiß somit nicht mehr, dass diese nach einem Passwort fragen muss.

    Man kann natürlich auch die KeyChain verwenden um das Passwort dort zu hinterlegen. Der Wert dort kann aber auch von außerhalb der der App gelöscht werden. Man hat also quasi dasselbe Problem wie bei den NSUserDefaults.

    Wie speichert man also die Information "App braucht Passwort" so ab, dass man diese nicht von außen manipulieren und die Passwort abfrage so deaktivieren kann?

  • Folgendes Dilemma:

    1. Eigentlich ist es unsinnig die App einzeln zu schützen. Stattdessen sollte lieber das komplette Nutzerkonto geschützt werden.
    2. Die Kunden wünschen sich aber oft und deutlich die Funktion die App schützen zu können. Deswegen gab es auch schon negative Bewertungen.
    3. Die Funktion schadet auch nicht, also bekommt der Kunden was er braucht um sich sicher zu fühlen.
    4. Wenn die Funktion eingeführt wird, dann aber auch richtig: Die Funktion ist optional, wer kein Kennwort setzen will muss das auch nicht. Die Funktion soll sich nicht aushebeln lassen.

    5. Speicher ich das Passwort "unsicher" ist die Funktion kein Problem. Wird das Kennwort gelöscht (in den Defaults oder der KeyChain) gibt es kein Kennwort und die App startet ohne. Aber das ist natürlich eine "unglaubliche" Sicherheitslücke. Um an die Daten zu kommen muss man ja nur das Kennwort löschen und die App starten.
    6. Ich Speicher das Passwort sicher. Wird dieses manuell gelöscht ist die App gesperrt, die Daten sind also sicher. Aber wie kommt der Nutzer in diesem Fall wieder zurück in die App? Wie erkennt die App den Fall "Kein Kennwort gewünscht"?

    Natürlich kann nur der Nutzer den Schlüssel aus der KeyChain löschen der ihn auch dort abgelegt hat. Aber wenn das Nutzerkonto sicher wäre bräuchte man kein Kennwort für die App.

  • wo speicherst du die ganzen daten die zur app gehören?
    speicher es dort auch da rein. denn das muss ja auch alles verschlüsselt sein, sosnt kanns ja jeder kopieren und auf seinem rechner ansehen.
    oder um was geht der schutz denn? (das programm nicht verwenden zu dürfen oder nicht zu sehen was im programm gespeichert ist?)

  • Agenor schrieb:


    1. Eigentlich ist es unsinnig die App einzeln zu schützen.


    Problem gelöst. :D

    Agenor schrieb:


    2. Die Kunden wünschen sich aber oft und deutlich die Funktion die App schützen zu können. Deswegen gab es auch schon negative Bewertungen.


    Offenbar ein Fehler in der Dokumentation - das sollte den Kunden besser erklärt werden.

    Agenor schrieb:


    Aber wenn das Nutzerkonto sicher wäre bräuchte man kein Kennwort für die App.


    Na, dann. Viel Lärm um Nichts. :thumbup:

    gritsch schrieb:


    oder um was geht der schutz denn?


    Ich glaube hier liegt das Problem. Poste doch mal einen Link zu der App...

  • Oh Mann! Willkommen im Jahr 2014.

    1. Du willst kein MD5 benutzen.
    2. Du willst die Keychain benutzen.
    3. Du willst die Daten der App verschlüsseln und das Passwort als Schlüssel verwenden.

    Wenn ich mir Deine Ausführungen so ansehe, habe ich aber meine Zweifel, dass das Ergebnis vernünftig (==sicher) sein wird.

  • kmr schrieb:

    1. Du willst kein MD5 benutzen.
    2. Du willst die Keychain benutzen.
    3. Du willst die Daten der App verschlüsseln und das Passwort als Schlüssel verwenden.


    Habe ich alles nicht gesagt. Ich habe nur welche Wege wo zu welchem Problem führen. Das es wenig Sinn macht die App mit einem Passwort zu versehen und die Daten unverschlüsselt daneben liegen zu lassen ist klar. Meine Fragt geht aber nicht darum wie ich die Daten verschlüssle sonder nur darum wie man die App durch ein Passwort schützen kann oder genauer: Wie man das Passwort und die Information, dass ein Passwort benötigt wird sicher auf einem unsicheren System speichern kann.

  • Wie wäre folgendes: Dier App nutzt immer eine Autorisierung über ein Passwort, das der Kunde beim ersten Start selber festlegen muss und welches in der Key-Chain gespeichert wird. Allerdings bietest Du die Funktion eines Auto-Logins an. Wer es unsicher möchte, aktiviert eben diese Option und wird nur ein Mal (beim ersten Start) aufgefordert, ein Passwort festzulegen. Wer mehr Sicherheit möchte, wird bei jedem App-Start nach dem Passwort gefragt ... wie auch, wenn dieses aus der Key-Chain gelöscht wurde.

    Mattes

    Edit: Ein gelöschtes Passwort müsste allerdings die App-Daten zurücksetzen ... Möglicher Datenverlust wie von Claus richtig bemerkt.
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Wie willst du etwas vor dem Admin schützen? Das Problem hatten wir doch letztens erst. Es geht nicht. Der Admin darf nunmal alles. Das einzige was du machen könntest wäre ein gecryptetes Passwort und gecrypteten Code und der das gecryptete Passwort wird übers INET bei dir gespeichert. Wenn der User dann sein Passwort vergisst oder verliert kann er ihn nur bei Dir wieder anfordern oder er kommt nie wieder an seine Daten. Aber ob das einer machen wird?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

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

  • gritsch schrieb:

    tschuldigung aber das macht doch alles keinen sinn.


    Das sehe ich anders: Wenn man das o.g., in der KeyChain hinterlegte Passwort zur Verschlüsselung der App-Daten nutzen würde, wäre es durchaus ein Sicherheitsgewinn. Dieser wäre aufgrund des Autologins eben "optional". Bleibt das Problem des Datenverlustes bei vergessenem Passwort ... systemimmanent, wenn nicht Recovery-Keys an geschützten Stellen gehalten werden.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • scheiß qute-funktion geht mal wieder nicht also einfach so:

    klar, würde das so sein, dann wäre es ok. aber das kling so als würden das nur die wenigesten in der app verwenden.
    auch gibt es immer wieder blöde die das passwort vergessen und dann sind alle daten weg... dann bekommt man eben aus anderen gründen die schlechte bewertung ;)

  • Agenor schrieb:


    Habe ich alles nicht gesagt.



    Habe ich auch nicht behauptet. Ich habe lediglich versucht aufzuzeigen, was die Eckpunkte für ein vernünftiges Vorgehen ist sind. Das Ansinnen, Daten zu schützen, ist kein unsinniges. Du gehst aber sehr flappsig ran, und wenn ich Sachen wie MD5 lese, möchte ich nicht der arme Tropf sein, der Deine App benutzt. ;)

  • Thallius schrieb:

    Wie willst du etwas vor dem Admin schützen? Das Problem hatten wir doch letztens erst. Es geht nicht. Der Admin darf nunmal alles. Das einzige was du machen könntest wäre ein gecryptetes Passwort und gecrypteten Code und der das gecryptete Passwort wird übers INET bei dir gespeichert. Wenn der User dann sein Passwort vergisst oder verliert kann er ihn nur bei Dir wieder anfordern oder er kommt nie wieder an seine Daten. Aber ob das einer machen wird?


    Was kann denn der Admin ausrichten, wenn das Passwort vernünftig in der Keychain liegt? Vernünftig heisst: starker Hash-Algorithmus, Salz und ausreichend PBKDF2. Dann muss der Admin, der die Keychain ausliest, sich schon etwas Gutes einfallen lassen, um an die Daten zu kommen. Das ist doch alles nicht so schwer und tut auch alles nicht weh.

  • MyMattes schrieb:


    Das sehe ich anders: Wenn man das o.g., in der KeyChain hinterlegte Passwort zur Verschlüsselung der App-Daten nutzen würde, wäre es durchaus ein Sicherheitsgewinn. Dieser wäre aufgrund des Autologins eben "optional". Bleibt das Problem des Datenverlustes bei vergessenem Passwort ... systemimmanent, wenn nicht Recovery-Keys an geschützten Stellen gehalten werden.

    Mattes


    Ack. Bewährte Regel der sicheren Entwicklung: secure by default. Wenn der Benutzer es lieber bequem, dafür aber unsicher(er) haben will, kann er das tun. Auf eigene Gefahr und selbst initiiert.