Комментарии 16
двухэтапная аутентификация
двухэтапной авторизации
Так что вы всё-таки имеете в виду - аутенфикацию или авторизацию?
Спасибо за внимательность! Да, аутентификация. Поправили
Поясните, пожалуйста, разницу в этих двух понятиях
Аутентификация - это про пароль. Пользователь действительно тот, кем представился.
Авторизация - это про права. Какие действия в приложении может выполнять пользователь (read, read-write, full access).
Самый простой пример на пальцах — КПП со шлагбаумом: Проверка пропуска или иных документов охранником — это аутентификация. Подъем шлагбаума и указание маршрута внутри охраняемой зоны это авторизация
Недопустимо использовать в качестве алгоритмов хэширования md5, SHA-1/SHA-256.
А что с SHA-256 не так?
Да, пояснение бы не помешало.
Вероятно, дело в том, что данная хеш-функция стоит кандидатом на взлом в ближайшие годы. Для её взлома за разумное время, оценочно (по алгоритму SQIF), потребуется 372 кубитов. Сейчас уже имеется квантовый компьютер (IBM Osprey) c 433 кубитами. А в этом или в следующем году будет представлен квантовый компьютер (новыйIBM Osprey) с 1100 кубитами, а цель на ближайшие годы - это 4100 кубита. Маловероятно, что SHA-256 устоит уже в следующем году. Да, это пока речь про топовые квантовые компьютеры, существующие чуть ли не в единичном экземпляре, ценой миллиарды долларов. Но - это лишь говорит о том, что до взлома SHA-256 алгоритма уже рукой подать - ну, а когда уже в недалёком будущем, квантовые компьютеры, условно, прошлого десятилетия станут куда более доступными - SHA-256 превратится в мусор. Но думать об это стоит уже сейчас.
Сейчас пока наиболее стойкими на ближайшие десятилетия считаются хеш-ключи длиной в 2048бит (RSA). Но не известно как долго они продержатся.
Но это лишь моё виденье и мнение, как стороннего наблюдателя, не судите строго, возможно автор статьи имел в виду что-то другое
Я так понял не рекомендуется любой хэш в чистом виде, а только с солью
Соль спасает от брутфорс перебора по таблице хешей.
Взлом хеш ключа сейчас делают даже если есть соль - это сложнее, но возможно. SHA-256 пока не взломали даже без соли, но посыл то на будущее - сейчас квантовые компьютеры могут рвануть так сильно в своём развитии, что к концу века может вообще уже никакое шифрование не спасёт, выполняема за разумное время, ведь даже сейчас шифрование 2048 битным ключём идёт весьма медленно, хотя для не особо длинных паролей это не критично (ну разве что не научат квантовые компьютеры не только взламывать, но и ещё более эффективно шифровать). Квантовая криптография в наши дни хороша - но это не совсем шифрование, и используется только при передаче информации, а не при её хранении
...пробелов в начале или конце строки, невидимых символов (табуляция, перенос строки и др.). Предупредите пользователя о наличии таких символов в полях ввода
Если эти символы недопустимы в логине/пароле - почему просто молча их не обрезать? Тут с банками и их кодами подтверждения хороший пример. Из СМСок они у меня копируются именно что с пробелом на конце, в 3DSecure формы части банков можно вставить с ними - и это удобно, но для другой части это проблема.
Пароль не должен включать в себя... контекстно-зависимые слова (имя службы, имя пользователя и производные от него).
Вот из-за этого благого пожелания у меня изрядное количество сайтов не принимают любой пароль, содержащий букву A. Просто у меня электронная почта - a@мой_домен, а правило применяется в лоб :) Впрочем, есть несколько сайтов, которые, наоборот, считают, что если в адресе почты до собаки меньше 3 символов - она невалидная.
А у меня бывает проблема даже с логином-почтовый адресом - у меня адрес _Z@домен и не все формы регистрации готовы принимать такой вот логин :-(
Так что с валидностью надо быть поаккуратнее!
Если эти символы недопустимы в логине/пароле - почему просто молча их не обрезать?
Что бы потом пользователь безуспешно пытался войти по логину/паролю с этими символами?
От -ться на картинках про служебные символы вытекли глаза
Базовые требования к парольной аутентификации