Was ist der beste Weg zum speichern der Benutzer-Einstellungen in der Android-Anwendung
Ich bin beim erstellen einer Anwendung die Verbindung zu dem server mit Benutzername/Passwort, und ich möchte, aktivieren Sie die option "Kennwort Speichern", damit der Benutzer nicht geben Sie das Kennwort jedes mal, wenn die Anwendung gestartet wird.
Ich versuche zu tun, ist es mit Gemeinsamen Vorlieben, aber bin mir nicht sicher, ob dies die beste Lösung.
Ich wäre dankbar jede Anregung auf, wie Sie zum speichern der Benutzer-Werte/Einstellungen in der Android-Anwendung.
InformationsquelleAutor Niko Gamulin | 2009-04-24
Du musst angemeldet sein, um einen Kommentar abzugeben.
Im Allgemeinen SharedPreferences sind Ihre beste Wette für die Speicherung der Einstellungen, so dass im Allgemeinen würde ich empfehlen, die Vorgehensweise für das speichern von Anwendungs-und Benutzer-Einstellungen.
Der einzige Bereich der Sorge ist hier, was Sie sparen. Passwörter sind immer eine heikle Sache, zu speichern, und wäre ich besonders vorsichtig, speichern Sie Sie als Klartext. Die Android-Architektur ist so, dass Ihre Anwendung SharedPreferences sind Sandbox-um zu verhindern, dass andere Anwendungen nicht in der Lage, auf die Werte zuzugreifen, so gibt es einige Sicherheit gibt, aber physischen Zugriff auf ein Handy Angreifer Zugriff auf die Werte.
Wenn möglich würde ich prüfen, ändern der server für die Verwendung eines ausgehandelten token für den Zugriff, so etwas wie OAuth. Alternativ können Sie brauchen, um zu konstruieren, eine Art von kryptographischen speichern, aber das ist nicht-trivial. Zumindest, stellen Sie sicher, dass die Verschlüsselung das Passwort vor dem schreiben auf die Festplatte.
ein Sandbox-Programm wird jede Anwendung, deren Verlauf und Informationen (wie die shared preferences) bleibt verborgen vor dem rest der Anwendungen. Ein android-Anwendung, die in einem Paket nicht direkt Zugriff auf alles, was in einem anderen Paket. Das ist, warum Anwendungen in der Packung (die sind immer bei Ihnen), könnte den Zugang zu Informationen, die aus anderen
Meier meine Anforderung ist der Schutz der öffentlich zugänglichen web-services für die, die ich bin mit einem token, ist die Speicherung auf gemeinsame Einstellungen, sicher ist? ich habe eine bootup-broadcast-Empfänger in meiner Bewerbung, die sharedpreferences löschen Sie alle Daten, wenn es gefunden Gerät verwurzelt. Ist das genug, um meine token.
Pro android-developers.blogspot.com/2013/02/..., Zugangsdaten gespeichert werden sollen mit der MODE_PRIVATE-flag gesetzt und gespeichert in den internen Speicher (mit der gleichen Vorsichtsmaßnahmen zur Lagerung von jeder Art von Kennwort lokal letztlich offen, Angriff). Das heißt, ist die Verwendung
MODE_PRIVATE
mit SharedPreferences entspricht tut das gleiche mit einer Datei erstellt, die auf internen Speicher, in Bezug auf die Wirksamkeit zu verschleiern lokal gespeicherten Daten?Nicht speichern Sie ein Kennwort in shared preferences. Wenn der Nutzer überhaupt verliert das Telefon, Sie haben das Passwort verloren. Es wird gelesen werden. Wenn Sie das Passwort anderswo, everyplace, die Sie verwendet, es ist kompromittiert. Zusätzlich haben Sie dauerhaft verloren, dieses Konto, weil ein Passwort mit dem Sie Ihr Passwort ändern können. Der richtige Weg dies zu tun ist, das Kennwort zu senden, bis der server einmal, und erhalten eine login-token zurück. Speichern, die in gemeinsamen Präferenz und senden Sie es mit jeder Anforderung. Wenn das token kompromittiert ist, sonst ist nichts verloren.
InformationsquelleAutor Reto Meier
Ich Stimme mit Reto und fiXedd. Objektiv betrachtet ist es nicht sehr sinnvoll, investieren viel Zeit und Aufwand in die Verschlüsselung der Passwörter in SharedPreferences, da jeder Angreifer, der Zugriff auf die preferences-Datei ist ziemlich wahrscheinlich auch Zugriff auf Ihre Anwendung binäre, und daher der Schlüssel zum entschlüsseln das Passwort.
Jedoch, dass gesagt wird, es scheint ein publicity-initiative geht auf die Ermittlung von mobile-Anwendungen, speichern Ihre Passwörter im Klartext in SharedPreferences und glänzend ungünstigen Licht auf diese Anwendungen. Sehen http://blogs.wsj.com/digits/2011/06/08/some-top-apps-put-data-at-risk/ und http://viaforensics.com/appwatchdog für einige Beispiele.
Während wir brauchen mehr Aufmerksamkeit für die Sicherheit im Allgemeinen würde ich behaupten, dass diese Art von Aufmerksamkeit auf diese eine bestimmte Frage nicht wirklich erheblich erhöhen unsere Sicherheit insgesamt. Doch Wahrnehmungen sein, wie Sie sind, hier ist eine Lösung zum verschlüsseln der Daten in SharedPreferences.
Einfach wickeln Sie Ihre eigenen SharedPreferences-Objekt in diese ein, und alle Daten, die Sie Lesen/schreiben, werden automatisch verschlüsselt und entschlüsselt werden. zB.
Hier ist der code für die Klasse:
Ja, ich schrieb diese. Fühlen Sie sich frei zu verwenden, keine Namensnennung notwendig
Ich Stimme mit Ihnen überein. Aber wenn Sie das Passwort nur auf dem server verwendet, warum nicht Public/private key-Verschlüsselung? Öffentlichen Schlüssel auf den client, wenn das Kennwort speichern. Der client wird nie gelesen zu haben das Klartext-Passwort erneut ein, richtig? Der server kann dann entschlüsseln mit dem privaten Schlüssel. Also selbst wenn jemand geht durch Ihre app-source-code, Sie können nicht erhalten Sie das Passwort, außer Sie hacken auf Ihrem server und den privaten Schlüssel bekommen.
Ich habe ein paar Funktionen Hinzugefügt, um diesen code, und legte es auf github unter github.com/RightHandedMonkey/WorxForUs_Library/blob/master/src/.... Es behandelt nun die Migration von einem nicht-verschlüsselten Einstellungen, um die verschlüsselte. Auch er generiert die Schlüssel zur Laufzeit, so dass ein dekompilieren der app nicht, die Taste loslassen.
Späte Ergänzung, aber der Kommentar von @PatrickBoos ist eine tolle Idee. Ein problem mit diesem, obwohl, ist, dass, obwohl, Sie haben verschlüsselt, das Passwort, kann ein Angreifer, der Stahl, die Chiffre wäre noch in der Lage sein, um dich auf deinem Server, denn dein Server die Entschlüsselung. Eine Ergänzung zu diesem Ansatz ist um das Kennwort zu verschlüsseln, zusammen mit einem Zeitstempel. So können Sie beispielsweise festlegen, dass nur Passwörter speichern, die in der jüngsten Vergangenheit (wie das hinzufügen von ein Ablaufdatum für Ihre "token"), oder sogar erfordern bestimmte Benutzer in einem timestamp seit einem bestimmten Datum (lassen Sie "widerrufen" alten "Token").
InformationsquelleAutor emmby
Über die einfachste Möglichkeit, um zu speichern eine einzelne Präferenz in ein Android-Aktivität ist, so etwas zu tun:
Wenn Sie besorgt über die Sicherheit dieser dann könnten Sie immer verschlüsseln Sie das Kennwort, bevor es zu speichern.
Vereinbart wurde, geändert.
Wo würden Sie speichern die Schlüssel, das Kennwort gespeichert? Wenn die freigegebenen Präferenzen von anderen Benutzern zugänglich, so ist der Schlüssel.
haben Sie die Antwort.?
InformationsquelleAutor Jeremy Logan
Mithilfe des snippet zur Verfügung gestellt von Richard, können Sie das Kennwort verschlüsseln, bevor Sie Sie speichern. Die preferences-API jedoch nicht bieten eine einfache Möglichkeit zum abfangen der Wert und verschlüsseln Sie es - Sie werden es blockieren kann gespeichert werden über eine OnPreferenceChange Zuhörer, und Sie theoretisch ändern könnte, es durch eine preferenceChangeListener, aber, dass die Ergebnisse in einer endlos-Schleife.
Ich hatte zuvor vorgeschlagen, das hinzufügen einer "versteckten" Einstellung, um dies zu erreichen. Es ist definitiv nicht der beste Weg. Ich werde an zwei anderen Optionen halte ich für mehr lebensfähig.
Erste, das einfachste ist, in einer preferenceChangeListener, können Sie sich den eingegebenen Wert, verschlüsseln Sie es, und speichern Sie ihn dann auf eine alternative Datei Einstellungen:
Die zweite Möglichkeit, und die Art und Weise, die ich jetzt bevorzugen, erstellen Sie Ihre eigenen benutzerdefinierten Vorlieben, die Ausweitung EditTextPreference, @Override ' Ing der
setText()
undgetText()
Methoden, so dasssetText()
verschlüsselt das Kennwort, undgetText()
null zurück.Never mind, fand ich ein brauchbares Beispiel hier groups.google.com/forum/#!Thema/android-Entwickler/pMYNEVXMa6M und ich habe es jetzt funktioniert. Dank für die Annahme dieses Ansatzes.
InformationsquelleAutor Mark
Ich weiß, das ist ein wenig der Nekromantie, aber Sie sollten die Android -AccountManager. Es ist Zweck-gebaut für dieses Szenario. Es ist ein bisschen umständlich, aber eines der Dinge, die es tut, ist, erlischt die lokalen Anmeldeinformationen, wenn die SIM-Karte verpasst, also wenn jemand klaut dein Handy und wirft eine neue SIM-Karte in es, Ihre Anmeldeinformationen werden nicht beeinträchtigt.
Dies gibt auch dem Benutzer eine schnelle und einfache Möglichkeit für den Zugriff (und möglicherweise löschen) die gespeicherten Anmeldeinformationen für ein Konto haben Sie auf dem Gerät, die alle aus einem Ort.
SampleSyncAdapter ist ein Beispiel, dass die Verwendung von gespeicherten Anmeldeinformationen.
Der use-case für AccountManager ist wenn der account geteilt werden muss zwischen verschiedenen apps und apps von verschiedenen Autoren. Speichern Sie das Passwort und geben Sie es an alle anfordernden app nicht angemessen wäre. Wenn die Verwendung des Benutzer/Kennwort ist nur für eine einzige app nicht benutzen, AccountManager.
das ist nicht ganz richtig. Der AccountManager wird nicht geben Sie das Kennwort des Kontos zu einer app, deren UID entspricht nicht der Authenticator ist. Der name, ja; das auth-token, ja; das Passwort nicht. Wenn Sie versuchen, es werde werfen eine SecurityException. Und der use-case ist viel breiter als das. developer.android.com/training/id-auth/identify.html
InformationsquelleAutor Jon O
Okay; es ist schon eine Weile her, seit die Antwort ist eine Art von gemischten, aber hier ein paar Allgemeine Antworten. Ich recherchierte wie verrückt und es war schwer zu bauen eine gute Antwort
Den MODE_PRIVATE Methode gilt als generell sicher, wenn Sie davon ausgehen, dass der Benutzer nicht root das Gerät. Ihre Daten werden im Klartext gespeichert in einem Teil des Dateisystems, der kann nur zugegriffen werden, das ursprüngliche Programm. Das Zeug packte das Passwort mit einer anderen app auf einem gerooteten Gerät einfach. Dann wieder, wollen Sie Unterstützung gerootete Geräte?
AES ist immer noch die beste Verschlüsselung, die Sie tun können. Achten Sie dies, wenn Sie beginnen eine neue Umsetzung, wenn es schon eine Weile her, seit ich dies geschrieben. Das größte Problem mit diesem ist, "Was zu tun ist mit dem Schlüssel?"
So, jetzt sind wir bei dem "Was zu tun ist mit dem Schlüssel?" Teil. Dies ist der schwierige Teil. Immer der Schlüssel stellt sich heraus, dass Sie nicht schlecht. Sie können eine key derivation function, um einige Passwort und machen es zu einem ziemlich sicheren Schlüssel. Sie erhalten in Fragen wie "wie viele Pässe hast du mit PKFDF2?", aber das ist ein anderes Thema
Idealerweise speichern Sie die AES-Schlüssel aus dem Gerät. Sie haben, um herauszufinden, eine gute Möglichkeit zum abrufen des Schlüssels vom server sicher, zuverlässig, und sicher obwohl
Haben Sie eine login-Sequenz von einer Art (selbst die original-login-Sequenz, die Sie tun, für remote-Zugriff). Sie können zwei Läufe von Ihrem key generator auf dem gleichen Passwort. Wie dies funktioniert, ist, dass Sie daraus den Schlüssel zweimal mit einem neuen Salz-und ein neues, Sicheres Initialisierungsvektor. Speichern Sie eines dieser generierten Passwörter auf dem Gerät, und verwenden Sie das zweite Kennwort als AES-Schlüssel.
Wenn Sie sich anmelden, Sie re-ableiten der Schlüssel auf dem lokalen login und vergleichen Sie es mit dem gespeicherten Schlüssel. Sobald dies geschehen ist, verwenden Sie leiten key #2 für AES.
Können Sie eine Menge von Variationen dieser. Zum Beispiel, statt einer vollständigen login-Sequenz, die Sie tun können, eine schnelle PIN (abgeleitet). Der quick-PIN ist möglicherweise nicht so sicher wie eine vollständige login-Sequenz, aber es ist viele Male sicherer als plain text
InformationsquelleAutor Joe Plante
Werfe ich meinen Hut in den ring zu sprechen, nur über die Sicherung von Passwörtern im Allgemeinen auf Android. Auf Android, das Gerät binäre sollte als kompromittiert betrachtet werden - dies ist die gleiche für jede end-Anwendung, die in der direkten Kontrolle durch die Nutzer. Konzeptionell könnte ein hacker mit dem notwendigen Zugriff auf die Binär-zu dekompilieren und der Wurzel Ihre verschlüsselten Passwörter und etc.
Als solche gibt es zwei Vorschläge, ich würde gerne dort hinauszuwerfen, wenn die Sicherheit ist ein wichtiges Anliegen für Sie:
1) speichern Sie nicht das eigentliche Passwort. Store gewährt, access token und das access token und die Unterschrift des Telefons zu authentifizieren, session-server-Seite. Der Vorteil bei dieser ist, dass Sie die token haben eine begrenzte Laufzeit, sind Sie nicht Kompromisse bei der original-Passwort, und Sie haben eine gute Signatur, die Sie verwenden können, zu korrelieren, um den Verkehr später (um zum Beispiel zu überprüfen, die für Eindringversuche und die Unwirksamkeit der token nutzlos).
2) Nutzen Sie 2-Faktor-Authentifizierung. Dies kann mehr lästig und aufdringlich, sondern für einige compliance-Situationen unvermeidbar.
InformationsquelleAutor dcgregorya
Können Sie auch überprüfen Sie heraus dieses kleine lib, mit der Funktionalität, die Sie erwähnen.
https://github.com/kovmarci86/android-secure-preferences
Es ist ähnlich wie einige der anderen aproaches hier. Hoffe das hilft 🙂
InformationsquelleAutor Marcell
Dies ist eine Ergänzende Antwort für diejenigen, die hier ankommen, basierend auf der Frage-Titel (wie ich) und nicht brauchen, um sich mit den Sicherheitsproblemen im Zusammenhang mit dem speichern von Passwörtern.
, Wie die Verwendung Gemeinsamer Präferenzen
Benutzer-Einstellungen sind in der Regel lokal gespeichert in Android mit
SharedPreferences
mit einem Schlüssel-Wert-paar. Verwenden Sie dieString
Schlüssel zu speichern oder sich den zugehörigen Wert.Schreiben Gemeinsamen Vorlieben
Verwenden
apply()
stattcommit()
zu sparen eher in den hintergrund als sofort.Lesen von Shared-Einstellungen
Den Standard-Wert wird verwendet, wenn der Schlüssel nicht gefunden.
Hinweise
Anstatt mit einem lokalen Schlüssel-Zeichenfolge in mehreren Orten, wie ich oben, es wäre besser, eine Konstante in einem einzigen Standort. Sie könnte so etwas wie das oben bei den Einstellungen Aktivität:
Habe ich ein
int
in meinem Beispiel, aber Sie können auchputString()
,putBoolean()
,getString()
,getBoolean()
usw.InformationsquelleAutor Suragch
Diese Antwort basiert auf einem vorgeschlagenen Ansatz von Mark. Eine benutzerdefinierte version des EditTextPreference Klasse erstellt wird, wandelt hin und her zwischen der plain-text gesehen, in der Ansicht und eine verschlüsselte version des Passwortes gespeichert, in den Einstellungen-Speicher.
Wie hingewiesen wurde von den meisten, die geantwortet hast auf diesen thread, ist dies nicht eine sehr sichere Technik, obwohl der Grad der Sicherheit hängt zum Teil von der Verschlüsselungs - /Entschlüsselungs-code verwendet. Es ist aber ziemlich einfach und bequem, und vereiteln die meisten casual-snooping.
Hier ist der code für die benutzerdefinierte EditTextPreference Klasse:
Dieser zeigt, wie es verwendet werden kann - dies ist der "items" Datei-Laufwerke, die die Einstellungen anzeigen. Hinweis: es enthält drei ordentlichen EditTextPreference Ansichten und eine der benutzerdefinierten EditPasswordPreference Ansichten.
Als für die eigentliche Verschlüsselung/Entschlüsselung, bleibt als übung für den Leser. Ich bin derzeit mit einigen code basiert auf diesem Artikel http://zenu.wordpress.com/2011/09/21/aes-128bit-cross-platform-java-and-c-encryption-compatibility/, obwohl Sie mit verschiedenen Werten für den Schlüssel und den Initialisierungsvektor.
InformationsquelleAutor RenniePet
Zuerst denke ich, dass die Daten des Benutzers sollte nicht gespeichert werden auf dem Handy, und wenn es ist, muss zum speichern von Daten irgendwo auf dem Handy ist es verschlüsselt werden soll mit in die apps, die private Daten. Sicherheit von Benutzer-Anmeldeinformationen sollte die Priorität der Anwendung.
Sensible Daten, sollten sicher gespeichert werden, oder gar nicht. Im Falle eines verlorenen Gerät oder malware-Infektion, die gespeicherten Daten sicher kompromittiert werden kann.
InformationsquelleAutor Gauraw Yadav
Ich benutze den Android KeyStore um das Kennwort zu verschlüsseln mit RSA im ECB-Modus und speichern Sie es dann in die SharedPreferences.
Wenn ich will das Passwort wieder lese ich das verschlüsselt aus den SharedPreferences und entschlüsselt Sie mit dem KeyStore.
Mit dieser Methode generieren Sie ein public/private Key-paar, wo in der Privatwirtschaft sicher gespeichert und verwaltet Android.
Hier ist ein link, wie dies zu tun: Android KeyStore-Tutorial
InformationsquelleAutor Braveblacklion
müssen Sie die Verwendung der sqlite -, Sicherheits-apit zur Speicherung der Passwörter.
hier ist das beste Beispiel, die Kennwörter speichert, -- passwordsafe.
hier ist der link für die Quelle und Erklärung -
http://code.google.com/p/android-passwordsafe/
ich respektvoll widersprechen - ich sehe mindestens 1 andere Verwendung ein Benutzer/Passwörter sqlite-Tabelle. WENN MAN BEDENKT, DAS RISIKO (mit sqlite) AKZEPTABEL ist, neben der einfachen Anwendung login-Authentifizierung, Sie könnte verwenden Sie die Tabelle zum speichern von mehreren ftp-Passwörter (wenn die app über ftp - mir tun Sie manchmal), zum Beispiel. plus, erstellen einer sqlite-adapter-Klasse für diese manipulation ist boilerplate einfach.
Schön Auferstehung eines zwei Jahre alten Kommentar! Um fair zu sein, mein Kommentar war ein Jahr, nachdem die Antwort 🙂 Sogar mit einer Handvoll Passwörter für FTP-Zugänge, der Aufwand ist viel größer mit einer SQLite-Tabelle als mit SharedPreferences sowohl in Bezug auf Raum und Codierung. Sicherlich kann das auch nicht notwendig sein
InformationsquelleAutor
shared preferences ist der einfachste Weg, um die Speicherung von Anwendungsdaten. aber es ist möglich, dass jeder klar unsere gemeinsame Einstellungen, Daten durch Programm-manager.also ich glaube nicht, dass es völlig sicher für unsere Anwendung.
InformationsquelleAutor Rohit Jain