24

Я разрабатываю приложение, в котором пользователю необходимо выполнить вход, чтобы выполнять операции ... но в основном на телефоне android phone ppl использовать «держать меня подписанным» ... и в этом случае Мне нужно будет поддерживать значение имени пользователя и пароля в моем приложении. Должен ли я использовать настройки или SQLite Db или есть что-то еще и как я могу сделать его безопасным? Plz Помощь ... Заранее спасибо ..Лучший способ сохранить имя пользователя и пароль в приложении для Android

+0

это работает правильно: http://stackoverflow.com/a/19629701/5733853 – HPbyP

ответ

4

По крайней мере, сохранить его в SharedPreferences (частный режим) и не забудьте хэш пароль. Хотя это не будет иметь никакого отношения к вредоносному пользователю (или корневому устройству), это что-то.

+0

Любой учебник, пожалуйста, как хешировать пароль? Меня интересует эта идея. И никто не может восстановить сохраненный пароль с помощью этой техники? – androniennn

+1

@androniennn Существует несколько советов по использованию хэш-паролей, поэтому я дам вам Google. Единственное, что нужно иметь в виду, это то, что хеширование предназначено только для того, чтобы помешать _casual_ snooper. Этот метод ** не действует **, когда устройство коренится (например), а злоумышленник также имеет доступ к вашему двоичному файлу. Подумайте об этом, если кто-то сможет перепроектировать вашу программу, тогда они могут легко понять, как вы хэшировали пароль. Вам просто нужно знать о возможностях все :) –

+0

Хороший метод/техничность, но не 100% уверенно и безопасно: \ – androniennn

25

Да, это сложно для Android. Вы не хотите хранить пароль открытого текста в настройках, потому что любой, у кого есть корневое устройство, будет в основном показывать свой пароль миру. С другой стороны, вы не можете использовать зашифрованный пароль, потому что вам нужно будет хранить ключ шифрования/дешифрования где-то на устройстве, снова подверженный корневой атаке.

Одно из решений, которые я использовал некоторое время назад, - это заставить сервер генерировать «билет», который он передает обратно на устройство, что хорошо в течение определенного периода времени. Этот билет используется устройством для всей коммуникации, используя SSL, поэтому люди не могут украсть ваш билет. Таким образом, пользователь аутентифицирует свой пароль на сервере один раз, сервер отправляет обратно истекающий билет, а пароль никогда не хранится нигде на устройстве.

Этот механизм используется несколькими механизмами аутентификации с тремя ногами, такими как OpenID, Facebook, даже API Google. Недостатки в том, что время от времени, когда истекает срок действия билета, пользователь должен заново войти в систему.

В конечном счете, это зависит от того, насколько безопасно вы хотите, чтобы ваше приложение было. Если это просто для того, чтобы отличать пользователей, и никакая сверхсекретная информация не хранится, как банковские счета или типы крови, то, возможно, сохранение pwd в открытом тексте на устройстве просто прекрасное :)

Удачи, какой бы метод вы ни выбрали лучше всего подходит для вашей конкретной ситуации!

Редактировать: Следует отметить, что этот метод передает ответственность безопасности серверу - вы захотите использовать засоленные хэши для сравнения паролей на сервере, идею, которую вы увидите в некоторых других комментариях для этого вопрос. Это предотвращает появление незашифрованного пароля в любом месте, кроме EditText View на устройстве, связь SSL с сервером и оперативную память сервера, когда он солит и хеширует пароль. Он никогда не хранится на диске, что является хорошей вещью (tm).

+3

Я согласен с тем, что вы сказали технически. Но я чувствую, что чем больше вы публикуете свой тип крови, тем больше вероятность того, что вы можете быть спасены в случае чрезвычайной ситуации;) –

+2

Не имеет значения, не являются ли данные сверхсекретными, пользователи могут использовать один и тот же пользователь/пароль во многих местах и злоумышленник может получить их и попробовать разные службы. –

22

Как утверждают другие, нет надежного способа хранения пароля на Android, который полностью защищает данные. Хеширование/шифрование пароля - отличная идея, но все, что он сделает, это замедлить «взломщик».

С учетом сказанного, это то, что я сделал:

1) Я использовал этот simplecryto.java class, которая принимает семя и текст и шифрует его. 2) Я использовал SharedPreferences в приватном режиме, который защищает сохраненный файл в ненагруженных устройствах. 3) Семя, которое я использовал для simplecryto, представляет собой массив байтов, который немного сложнее найти декомпиляторами, чем String.

Приложение было недавно рассмотрено группой безопасности «белой шляпы», нанятой моей компанией. Они отметили эту проблему и указали, что я должен использовать OAUTH, но они также перечисляли ее как проблему с низким уровнем риска, что означает, что она не велика, но не настолько эффективна, чтобы предотвратить выпуск.

Помните, что «взломщик» должен иметь физический доступ к устройству и корни его И заботиться достаточно, чтобы найти семя.

Если вы действительно заботитесь о безопасности, не имеете опции «Запомнить меня».

+0

Ссылка на учебное пособие сломана, поэтому я не уверен, что это то же самое, но Google сразу же дал мне статью, которая выглядела довольно похоже: http://www.androidsnippets.com/encryptdecrypt-strings, но это происходит для меня, что вы можете использовать случайно сгенерированное семя, которое хранится у устройства для дополнительной безопасности. Этот общий секрет/семя будет генерироваться случайным образом для каждого пользователя, а хранилище вне устройства будет содержать сопоставление. До тех пор, пока вы надежно обмениваетесь информацией с этим местоположением безопасно и что хранилище безопасно, не будет ли это работать лучше? – batbrat

+1

@batbrat Если вы собираетесь иметь постоянное пользовательское состояние на стороне сервера, рекомендуйте oauth2, а не что-то самодельное. В моем примере нет пользовательского состояния, поэтому у меня не было ничего, что можно было бы вызвать. – knaak

+0

Благодарим вас за разъяснение. Теперь я понимаю, и соглашусь. – batbrat

1

Самый безопасный способ сделать это без ущерба для безопасности, чтобы использовать общие предпочтения хранить только имя пользователя последнего человека, чтобы войти в систему.

Кроме того, в таблице пользователей, ввести столбец, который содержит числовые boolean (1 или 0), чтобы указать, проверил ли человек человека флажок «запомнить меня» или нет.

При запуске приложения введите имя пользователя, используя функцию getSharedPreferences(), и используйте его для запроса вашей размещенной базы данных, чтобы увидеть, является ли столбец signedin равным 1 или 0, где 1 указывает, что человек установил флажок «запомнить меня».

1
//encode password 
pass_word_et = (EditText) v.findViewById(R.id.password_et); 
String pwd = pass_word_et.getText().toString(); 
       byte[] data = new byte[0]; 
       try { 
        data = pwd.getBytes("UTF-8"); 
       } catch (UnsupportedEncodingException e) { 
        e.printStackTrace(); 
       } 
       String base64 = Base64.encodeToString(data, Base64.DEFAULT); 
       hbha_pref_helper.saveStringValue("pass_word", base64); 

//decode password 
String base64=hbha_pref_helper.getStringValue("pass_word"); 
      byte[] data = Base64.decode(base64, Base64.DEFAULT); 
      String decrypt_pwd=""; 
      try { 
       decrypt_pwd = new String(data, "UTF-8"); 
      } catch (UnsupportedEncodingException e) { 
       e.printStackTrace(); 
      } 
+1

Добро пожаловать в StackOverflow! Можете ли вы также дать объяснение, чтобы помочь ПО понять ваш ответ? – FrankS101

+6

Base64 не шифрует, это алгоритм кодирования, который очень легко распознать и декодировать. –

0

Использование NDK для шифрования и дешифрования наряду с определением ключа переменного типа String есть вместо того, чтобы сохранить его в общих настройках или определив его Ins строки XML поможет предотвратить секретный ключ угона против большинства деточек подлинника. Приведенный шифрованный текст будет затем сохранен в общих предпочтениях. This link may help about the sample code