Используя Swift .хэш для хранения/проверки пароля

ProgramBox

Используя Swift .хэш для хранения/проверки пароля

Post author:admin
Запись опубликована:15 января, 2022
Post category:Вопросы по программированию

#ios #swift #hash

Вопрос:

Редактировать

Я провел больше исследований по этой теме, и ответы ниже были ОЧЕНЬ полезны! Но я также просто хотел добавить это всем, кто может наткнуться на эту страницу, кто, как и я, все еще пытается понять, как установить аутентификацию в ваше приложение. (Конечно, OAuth и локальная аутентификация-очень хорошие маршруты, но если по какой-то причине вы не можете этого сделать, взгляните на ссылку:)

https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side

Мой первоначальный вопрос приведен ниже

Я ОЧЕНЬ новичок в части безопасности приложений в разработке iOS. У меня есть приложение, которое должно быть заблокировано паролем, и я хотел увидеть лучший способ его защиты. Итак, вот о чем я думал:

пользователь создает (или получает) пароль
```
  let password = "password"
 
```
Я пользуюсь этим .хэш этого пароля для его хранения на сервере
Когда и если пользователю нужно снова войти в систему, он вводит пароль, и приложение извлекает хэш-номер с сервера и сверяет его с .хэш того, что они только что ввели
```
  let passwordString = textbook.text

 if passwordString.hash == hashPulledFromServer {
     //log in
 } else {
     //failed
 }
 
```

Это лучший способ сделать это? Я читал, что значение hash не всегда дает одно и то же значение, что, конечно, не сделало бы это возможным для этого смысла. Но является ли это безопасным способом передачи данных на сервер и использования его для проверки пароля позже?

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

2. Это создаст проблему. Если ваш также доступен для Android и веб-приложения.

3. @luk2302 хорошо, тогда лучше использовать такой фрагмент кода: func MD5(строка: Строка) -> Строка { пусть дайджест = Небезопасный.MD5.хэш(данные: строка.данные(с использованием: .utf8))?? Данные()) возвращают digest.map { Строка(формат: «hhx», $0) }.присоединено() }. Чтобы создать хэш, сохраните его в таблице SQL и позвольте PHP-скрипту выполнить работу?

4. Нет, хеширование в клиенте не имеет никакого смысла, в этот момент хэш становится паролем, хеширование с MD5 вообще плохо, а хеширование без соли еще хуже. Вам нужно отправить имя пользователя и пароль на сервер, который затем выполняет посолку (и перчение), хэширование и хранение.

5. Я ОЧЕНЬ новичок в части безопасности приложений в разработке iOS и …вот о чем я подумал , это две фразы, которые создают проблемы, когда они появляются в одном и том же абзаце. У вас есть правильная идея, но дьявол кроется в деталях. Вам нужна система, которая была проверена экспертами и доказала свою надежность, и которая исключает все, что вы готовите сами. Используйте существующее решение.

Ответ №1:

Слишком сложно дать подробный ответ на ваш вопрос. Информационная безопасность-это огромная тема.

Везде, где это возможно, вы должны полагаться на существующие решения и реализации. например, можете ли вы использовать OAuth или OpenID, чтобы вашему приложению никогда не приходилось иметь дело с паролями? Можете ли вы использовать локальную систему аутентификации, если вы просто хотите обеспечить локальный доступ к приложению?

Короткий ответ на ваш вопрос «Можете ли вы использовать .hash ?» — НЕТ

.hash используется для создания хэша для объекта, который можно использовать для облегчения поиска в коллекциях, таких как словари и наборы.

Это вычислительно просто, так что его можно быстро вычислить. Он не прилагает никаких усилий для предотвращения коллизий хэшей (два разных объекта хэшируют одно и то же значение). Он обладает этими характеристиками, потому что ожидается, что функция будет часто использоваться (например, каждый доступ к словарю), и конфликты на самом деле не имеют значения; коллекции в памяти довольно малы, и конфликты можно легко обрабатывать.

Это противоположно тому, что вы хотите в криптографическом хэше пароля, таком как scrypt:

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