在 Android 中存储用户登录凭据的最佳位置 [英] Best place for storing user login credentials in Android

问题描述

我正在创建一个 android 应用程序，但我无法(?)在 Google App Engine 上找到有关验证应用程序用户身份的任何信息(不使用用户的 Google 帐户).将用户名和密码存储在android 设备，然后将应用程序使用的数据存储在 Google App Engine 上?

I am creating an android app, and i cannot(?) find any information on authenticating a user of the app on Google App Engine (without using the user's Google Account).Is it good practice to store username and password on the android device and then store the data used by the app on Google App Engine?

推荐答案

你不应该使用 SharedPreferences，尽管谷歌会告诉你它们是多么安全，因为简单的事实是生根习惯权力和想成为权力的用户都广泛使用.

You should NOT use SharedPreferences, despite how secure Google will tell you they are, for the simple fact that rooting habits are widespread by both power and wannabe-power users.

在root系统中，授权应用将能够访问内部存储/system分区，从而访问Android存储SharedPreferences的root拥有的加密XML文件，成为ROOT的CLEARTEXT- 授权应用程序.因此，如果受感染的手机碰巧有一个应用程序存储此类数据，并且用户习惯于为不同的服务滥用相同的电子邮件/密码，则攻击媒介很容易破坏多项服务的凭据，尽管用户在以下情况下解除了任何警告扎根他的手机或授予应用此类权限，因为那些警告不够清楚.

In rooted systems, authorized apps will be able to access the internal storage /system partition, thus access the root-owned encrypted XML files where Android stores SharedPreferences, WHICH BECOME CLEARTEXT FOR ROOT-AUTHORIZED APPS. So if a compromised phone happens to have an app that stores such data and the user has a habit of abusing same email/password for different services, the attack vector is pretty straightforward to compromise credentials for multiple services, despite whatever warnings the user dismissed when rooting his phone or giving the app such permissions, because, well, those warnings just aren't clear enough.

替代方法是使用自定义、可变种子、加盐算法对凭证的持久存储进行手动加密.secure-preferences lib 是一个很好的替代方案，它几乎以透明的方式为您完成所有工作，并具有实施的额外好处Android 的 SharedPreferences 接口，保留默认 spref 的大部分功能，并稍作调整(查看他们的示例).

Alternatives are manual encryption of persistent storage for credentials, using custom, variable seed, salted algorithms. secure-preferences lib is a great alternative which pretty much does everything for you in a transparent way, with the added benefit of implementing Android's SharedPreferences interface, keeping most functionality of default sprefs with minor tweaking (look at their samples).

2016 年我只是觉得我需要在 2016 年回到这个问题并添加对 Apple vs FBI 戏剧 的一个很好的参考，以改变操作系统圣贝纳迪诺袭击者的电话.所以，想象一下你有一部很容易 root 的手机，就像大多数 Android 手机一样，它甚至可能在默认情况下被 root 或者不需要擦除数据到 root.如果 FBI 不想获得您的凭据，他们不必向 Google 或您的公司提出任何要求.通过使用secure-preferences 之类的东西，您将承担与 Apple 决定承担的相同类型的责任，只需让您自己的系统(在本例中为您的应用程序)能够访问这些凭据.如果 FBI 愿意，您确实会被他们惹恼，但是让您的用户感觉到您，而不是底层操作系统，是唯一可以直接控制这些凭据的机构，这是我希望在我的产品中拥有的东西.

2016 I just felt I needed to come back to this question in 2016 and add a nice reference to the Apple vs FBI drama to alter the OS in the San Bernardino assailant's phone. So, imagine you have a phone that is easily rootable, like most Android's, and that might even be rooted by default or doesn't need to wipe data to root. The FBI doesn't have to demand anything from Google or your company if they wan't to get your credentials. By using stuff like secure-preferences, you place the same type of responsibility Apple decided to undertake by only making your own system (in this case, your app) able to access those credentials. You do get to be annoyed by the FBI if they so desire, but giving your users the sense that you, not the underlying OS, is the only authority having direct control over those credentials, is something I'd rather have in my product.

这篇关于在 Android 中存储用户登录凭据的最佳位置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！