Android：存储用户名和密码？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1925486/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Android: Storing username and password?
提问by Legend
If I want to store the username and password to be used inside an Android application, what is the best way to do it? Is it through the preferences screen (but what if the user misses this?), or pop up a dialog box and ask the user for the credentials? If so, I do have to maintain state for the application. How would I do this?
如果我想存储要在 Android 应用程序中使用的用户名和密码，最好的方法是什么？是通过首选项屏幕（但如果用户错过了这个怎么办？），还是弹出一个对话框并要求用户提供凭据？如果是这样，我必须维护应用程序的状态。我该怎么做？
采纳答案by Eric Levine
Most Android and iPhone apps I have seen use an initial screen or dialog box to ask for credentials. I think it is cumbersome for the user to have to re-enter their name/password often, so storing that info makes sense from a usability perspective.
我见过的大多数 Android 和 iPhone 应用程序都使用初始屏幕或对话框来询问凭据。我认为用户必须经常重新输入他们的名称/密码很麻烦，因此从可用性的角度存储这些信息是有意义的。
The advice from the (Android dev guide) is:
（Android 开发指南）的建议是：
In general, we recommend minimizing the frequency of asking for user credentials -- to make phishing attacks more conspicuous, and less likely to be successful. Instead use an authorization token and refresh it.
Where possible, username and password should not be stored on the device. Instead, perform initial authentication using the username and password supplied by the user, and then use a short-lived, service-specific authorization token.
一般而言，我们建议尽量减少要求用户凭据的频率 - 使网络钓鱼攻击更加引人注目，并且不太可能成功。而是使用授权令牌并刷新它。
在可能的情况下，用户名和密码不应存储在设备上。相反，使用用户提供的用户名和密码执行初始身份验证，然后使用短期的、特定于服务的授权令牌。
Using the AccountMangeris the best option for storing credentials. The SampleSyncAdapterprovides an example of how to use it.
使用AccountManger是存储凭证的最佳选择。该SampleSyncAdapter提供了如何使用它的一个例子。
If this is not an option to you for some reason, you can fall back to persisting credentials using the Preferencesmechanism. Other applications won't be able to access your preferences, so the user's information is not easily exposed.
如果由于某种原因这不是您的选择，您可以使用Preferences机制回退到持久化凭据。其他应用程序将无法访问您的首选项，因此用户的信息不容易暴露。
回答by Jon O
You should use the Android AccountManager. It's purpose-built for this scenario. It's a little bit cumbersome but one of the things it does is invalidate the local credentials if the SIM card changes, so if somebody swipes your phone and throws a new SIM in it, your credentials won't be compromised.
您应该使用 Android AccountManager。它是专门为此场景构建的。这有点麻烦，但是如果 SIM 卡发生变化，它所做的一件事就是使本地凭据无效，因此如果有人刷您的手机并将新的 SIM 卡放入其中，您的凭据不会受到损害。
This also gives the user a quick and easy way to access (and potentially delete) the stored credentials for any account they have on the device, all from one place.
这也为用户提供了一种快速简便的方法来访问（并可能删除）他们在设备上拥有的任何帐户的存储凭据，所有这些都可以从一个地方进行。
SampleSyncAdapter (like @Miguel mentioned) is an example that makes use of stored account credentials.
SampleSyncAdapter（如提到的@Miguel）是一个使用存储帐户凭据的示例。
回答by Riz
I think the best way to secure your credential is to first think of storing the Password with encryption in the account.db file which couldn't be easily available in non rooted devices and in case of rooted device the hacker must need the key to decrypt it.
我认为保护您的凭据的最佳方法是首先考虑将密码加密存储在 account.db 文件中，该文件在非 root 设备中不容易获得，并且在 root 设备的情况下，黑客必须需要密钥才能解密它。
Other option is do all your authentication like the way Gmail is doing. after the first authentication with the Gmail server . you got the Auth Token that would be use in case of your password . that token would be store in plain text.this token could be false in case you change the password from Server.
其他选项是像 Gmail 一样进行所有身份验证。第一次与 Gmail 服务器进行身份验证后。你得到了 Auth Token 可以在你的密码的情况下使用。该令牌将以纯文本形式存储。如果您从服务器更改密码，该令牌可能为假。
the last option I'd recommend you to enable 2-Factor Authentication & create Device Specific Password for your device. After losing device, all you need is to disable that device.
最后一个选项我建议您启用 2-Factor Authentication 并为您的设备创建设备特定密码。丢失设备后，您只需要禁用该设备即可。
回答by emmby
Take a look at What is the most appropriate way to store user settings in Android applicationif you're concerned about storing passwords as clear text in SharedPreferences.
如果您担心在 SharedPreferences 中将密码存储为明文，请查看在 Android 应用程序中存储用户设置的最合适方法是什么。
回答by dwbrito
Take a look at this this post from android-developers, that might help increasing the security on the stored data in your Android app.
看看这篇来自 android-developers 的帖子，它可能有助于提高 Android 应用程序中存储数据的安全性。
回答by Zlatko
回答by Dmytro Melnychuk
These are ranked in order of difficulty to break your hidden info.
这些按难度排序，以破解您的隐藏信息。
Store in cleartext
Store encrypted using a symmetric key
Using the Android Keystore
Store encrypted using asymmetric keys
以明文形式存储
使用对称密钥加密存储
使用 Android 密钥库
使用非对称密钥加密存储
source: Where is the best place to store a password in your Android app
来源：在您的 Android 应用程序中存储密码的最佳位置在哪里
The Keystore itself is encrypted using the user's own lockscreen pin/password, hence, when the device screen is locked the Keystore is unavailable. Keep this in mind if you have a background service that could need to access your application secrets.
Keystore 本身是使用用户自己的锁屏密码/密码加密的，因此，当设备屏幕被锁定时，Keystore 不可用。如果您的后台服务可能需要访问您的应用程序机密，请记住这一点。
source: Simple use the Android Keystore to store passwords and other sensitive information
回答by miguelv
You can also look at the SampleSyncAdaptersample from the SDK. It may help you.
您还可以查看SDK中的SampleSyncAdapter示例。它可能会帮助你。
回答by kbs
The info at http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.htmlis a fairly pragmatic, but "uses-hidden-android-apis" based approach. It's something to consider when you really can't get around storing credentials/passwords locally on the device.
http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html上的信息是一种相当务实的方法，但基于“uses-hidden-android-apis”。当您真的无法在设备上本地存储凭据/密码时，需要考虑这一点。
I've also created a cleaned up gist of that idea at https://gist.github.com/kbsriram/5503519which might be helpful.
我还在https://gist.github.com/kbsriram/5503519 上创建了该想法的清理要点，这可能会有所帮助。
