Пытаюсь разобраться с элементарной авторизацией пользователя. Возник ряд вопросов про работу с паролем:
1) Т.к. соединение https, mid man не сможет перехватить пасс и его можно смело отправлять в чистом виде?
2) На сервере пасс шифруется: 3 итерации sha256(пароль + уникальная соль юзера + 'доп. соль строка') и кладется в бд.
-если кто-то получит доступ к чтению базы, то подобрать пасс не сможет, т.к. помимо уникальной соли, есть доп. соль в самом скрипте
-если кто-то получит доступ к ред. базы, то подмена уник. соли и хэша пароля не поможет по той же причине
Здесь мне не понятно, для чего все же используется уникальная соль, ведь у злоумышленника все равно нет доступа к дополнительной?
3) Каких средств защиты не хватает?
Tyranron: выходит: 1) хэшируем пасс, что бы не хранить в исходном виде и в случае утечки базы через злоумышленника/админа, не дать им возможность получить доступ к аккаунтам; 2) подкидываем уникальную соль при хешировании, что бы затруднить брут через радужные таблицы; 3) делаем множество итераций хэширования, что бы увеличить время перебора по словарю. Я правильно понял?
Nwton:
1) Да. Да и нам самим незачем знать пароли пользователей - это их дело.
2) Да, чтобы исключить вариант использования радужных таблиц.
(Немного занудства: термин "брут" происходит от "brute force", под которым имеют в виду полный перебор, то есть даже не по словарю, потому к радужным таблицам этот термин применять немного неуместно)
3) Да, чтобы увеличить вообще время генерации хеша, а значит и любого перебора, в том числе и по словарю.
Ещё, как писалось в моем ответе - самый лучший вариант, когда сами пользователи используют хорошие пароли. Потому можно предпринять какие-то меры дабы их на это образумить. Но это уже зависит от самого приложения, того как оно позиционируется, и соблюдения разумного баланса, чтобы не указывать пользователям слишком многое.
Nwton: и да, используйте уже готовые криптографические примитивы. Минимально - тот же bcrypt. Если речь о PHP: password_hash() для получения хеша, и password_verify() для проверки. Не вздумайте сравнивать хеши через == .
Nwton: опять же, придумывать ничего не нужно. password_verify() все делает как нужно. Для случаев, когда речь идет не о хешировании пароля, есть hash_equals().
Tyranron: хех, прогнал sha256 10 000раз, это заняло всего 152мс. Этого достаточно и на сколько это глупо? Понимаю, что можно использовать более трудоемкие алгоритмы хеширования, но даже если в таком виде.
1)Да, для этого https и создан, чтобы можно было обмениваться данными не боясь перехвата.
2)Ни в коем случае! Пароль на сервере не шифруется и никуда не записывается. он сразу же уничтожается.
Хранится только хэш пароля! На случай утечки хэшей, дабы усложнить подбор методом брутафорса, и радужных таблиц используется соль. Соль можно хранить в базе рядом с хэшем, можно генерировать динамически на основании каких-то данных. Используется соль следующим образом - соль добавляется к паролю, после чего получившуюся строку хэшируют.
3)Что касается паролей - вроде все, непонятно что еще может потребоваться, разве что у вас какая-то хитрая задача.
1. Всё что проходит по сети - лучше шифровать даже, если это идёт внутри SSL.
2. Пасс не шифруется, а хешируется. (если кто-то получит доступ к БД, значит он 99% уже получил доступ к скрипту)
3. Понимания логики функционирования системы аутентификации + знаний.
Средний
Средний
