Как передавать пароль от браузера серверу, как его хранить на сервере и проверять корректность?

Привет!

Пароль не должен отправляться в открытом виде по сети.
И также пароль не должен храниться в открытом виде на сервере.

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

Дальше я запутался.

Вот у нас есть хэш и соль принятые от браузера, и хеш с солью хранящиеся на сервере.
И? Что с этим делать?

Как проверить что пароль верный?
  • Вопрос задан
  • 7337 просмотров
Пригласить эксперта
Ответы на вопрос 3
gzhegow
@gzhegow
aka "ОбнимиБизнесмена"
В зависимости от степени безопасности.

Если разбить все это на "по-проще", общий принцип такой:

Клиент:
- в первый раз ввести строку текста
- нажать отправить
- больше не вводить, ибо лентяй, а мы ж ему продавать собрались, не дай бог он сука дискомфорт почувствует

Сервер:
- получить строку текста
- сделать хеш
- проверить - чей это хеш (не угнали ли его по дороге)
- в ответ отправить токен, который будет работать ограниченное время только для этого компьютера
- токен сохранить на компе пользователя, и следующий раз отправлять автоматически для каждого действия без ведома юзера
- при каждом действии обновлять время хранения токена (некоторые особо шизанутые делают новый токен каждое действие)
- при малейшем подозрении на несоответствие токена - предложение вежливо пройти через авторизацию еще раз, но поскольку человек существо забавное - если ему скажут опять пароль вводить - он сука обидится, и потому придумана "двухэтапная" - через телефон или там отпечаток пальца или что угодно еще, да и полезно это - если пароль действительно угнали - отрезать палец и вырвать глаз - это еще можно вместе сделать, а вот замочив человека - попросить его маму ввести пришедший из СМС-код - это уже придется шантажом заниматься.

Локальных хранилищ тоже бывает куча целая:
- кукисы (хранится прямо в браузере указанное время)
- сессии (хранится на сервере, но в кукисах есть ключ к ячейке в "банке", который опять же могут угнать)
- ... еще десятки способов, о которых знают только крутые кодеры, которые считают себя крутыми просто потому, что их знают, на деле с точки зрения создания ценности людям - бесполезные знания

Как ты понимаешь, это иллюзия безопасности, а не гарантия.

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

Вот еще тема, которую василий сказал - шифровать пароль уже на стороне клиента в момент отправки формы яваскриптом. Представьте себя хакером. Вы получили пакеты какого-то чувака, поставили компьютер на расшифровку, подключив десяток видеокарт, расшифровываете пароль, а вместо него видите 64 символьный хеш, ну то есть он прямо от клиента таким вышел. После этого будут маты от того, что теперь массив видюх нужно заставить еще и ключевую фразу из хеша выдрать. Ну то есть еще время декодирования увеличивается. Если загнаться то хеш может быть не просто хешем md5() а например md5 от md5 от развернутой строки прибавленной к md5() прямой строки, прокинутой через побитовый сдвиг на один разряд - ну то есть даже в этом закодировать последовательность действий. При отсутствии https - наиболее надежный способ.

И потом - программисты Yii не рекомендуют использовать фунцию md5(). Почему? Потому что она быстрая очень. И при переборе пароля массивом видеокарт перебирается он шибко быстро. Поэтому рекомендуют использовать hash функцию, которая для создания хеша использует побольше времени, несколько секунд скажем. При написании синхронной программы (сайта на php, например) - это заставит юзера подождать после регистрации секунды 3-4 лишних, но если загнаться то процесс генерации пароля можно запихнуть в асинхронщину, а пользователю сразу токен выдать, то есть пароль ему сгенерируется чуть позже. Таким образом - за счет более длинной хеш-функции по времени хакеру потребуется куда больше времени - то есть юзеру на прямое создание пароля 5 секунд, а хакеру на перебор нескольких миллионов паролей понадобится несколько лет. Никто ему не заплатит 10 косарей баксов, чтобы сломать ваш долбанный пароль ВКонтакте. Если банковская сфера - опять же как писал выше - хеш от хеша, да развернуть пару раз, да трижды порубить, потом постучать в бубен и все это в хеш еще раз и вуаля - декодирование пароля займет 100 лет.

Еще значит, При малейшем намеки на несоответствие токена или внезапное изменение - сервак говорит "тю, дядя, давайка пройди второй этап авторизации, а то я не верю, что это реально ты" и просит приложить палец. Или ввести номер, получив СМС. Или вставить ключ-карту синюю (duke nukem hello). Но и тут есть взлом - ключ карту украсть, смс-ку - попросить телефон, приложить палец = отрубить руку, вырвать глаз и тд

Тут к тебе на помощь приходит https. Https это такая штука, которая в двух словах может быть названа игрой в партизан. На войне играли так - когда радиопереговоры прослушивались, а шифраторов не было - единственным средством защиты - было использовать ошибки в тексте и матерные слова.

Так и тут - данные отправляемые в виде нулей и единиц. Компьютеры их так же легко перекодируют в пароль, как и закодировали. Чтобы этого не было, придумали ШИФРОВАТЬ строку в одну сторону. У сервака есть трафарет, у пользователя другой трафарет. Сервак шифрует своим, но назад можно расшифровать только пользовательским. Вернее можно и сторонним конечно, но современные компьютеры сделают это за много лет, и потому никто не заморачивается особо, производительность не та.

Таким образом сайты, где есть https на текущий момент наиболее надежный способ скрыть нули и единицы от чувака, сидящего на прослушке твоего интернет трафика. А попасть он туда может от самых простых способов типа "друг, дай мне пароль от своего вайфай", до всяческих угадываний, взломов роутеров и на худой конец - под видом электромонтера, установив маааленькую плату тебе в распределительный щит.

Так что авторизация - она простая. Вся надежда на шифрование. А сертификат, на котором пол-мира делает бабло - это средство подтверждения того, что компьютер умеет шифровать. Интересно, что он кончается каждый год, как будто в прошлом году компьютер умел шифровать, а в этом вдруг разучился. На деле конечно - просто гоните бабло, иначе покажем красный крестик вместо зеленого замочка, и в гугле понизим, так что гоните бабки. Вот.
Ответ написан
ThunderCat
@ThunderCat Куратор тега PHP
{PHP, MySql, HTML, JS, CSS} developer
Пароль не должен отправляться в открытом виде по сети.
где вы это прочитали? Пароль нигде не должен светиться при вводе и отправке, по этому парольное поле делают со звездочками, а для отправки используют метод post а не get, чтобы пароль не светился в строке браузера. Для защиты от атак mitm используют https, хотя при верном подходе это тоже не суперзащита, ключи могут перехватить, некоторую защиту дает, но если сессия обмена ключами поймана - уже можно забить на хттпс защиту.
И также пароль не должен храниться в открытом виде на сервере.
Логично, пожалуй единственная логичная строчка в посте )
Получается, мы должны отправить не пароль, а хэш от него и соль, которым был присыпан пароль при хешировании.
Не получается, мы отправляем пароль не зная соли, в этом вся соль )) Сервер принимает пароль от пользователя (открытый), хеширует его с солью(известной только серверу), и сравнивает с хранимым в базе. Если хеши совпали - пароль угадан верно )
Ответ написан
@M-ka
frontend присматривающийся к ror
Использовать шифрование на стороне клиента и сервера для общения, AES + RSA (или что другое но с подобной сутью... ).
Открытый ключ на закрытый и вперед с песней. На каждую сессию генерировать новые ключи или даже на каждую попытку... Поле ввода пароля разборное с кусков, возможно маркеры на каждую попытку передавать вместе с ключом, вводить не с кейборда, а генерить попап с рандомным положением контента, в том числе цифры без возможности прямых ссылок на таковы.... Но это все только затруднит возможность взлома... кому сильно нужно будет, тот это все разберет и получит свою возможность... Все, что на стороне клиента, все уязвимо всегда... Вопрос только в затраченных ресурсах...
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы