"и правим зону mydomain.ru, добавляя в нее запись username" - а если подумать? (безотносительно к тому, что про настройку субдоменов никто не спрашивал)
У нас в голове всегда должно быть два вектора атаки - на сервер и на канал передачи. Собственно, вся эта дискуссия - попытка защитить одно, чтобы не оголить другое. В данном случае, как мне кажется, при компрометации сервера мы отдаем злоумышленнику ключ шиврования и зашиврованные хэши - то есть хэши без соли, которые пробиваются по радужным таблицам. В общем, думаю, что передача соли - меньшее из зол.
Всегда приятно, тупанув самому, увидеть соринку в глазах собеседника :) 1. Смысл соли совсем не в этом. Соль заранее считается скомпрометированной и поэтому-то и хранится в открытом виде. Задача соли - защита от прекомпилированного поиска АКА радужных таблиц. Главное, чтобы она была всегда разной. А известна она или нет - должно быть не важно. 2. Хранение пароля в обратимо зашиврованном виде - это новое слово в безопасности. Правда, боюсь, слишком новое. Не поймут-с :) (в данном случае мы выходим опять на дерибасовскую, в которой ash(pass) выступает в роли открыто хранящегося пароля)
Suntechnic: все верно, карета не поедет, поскольку если мы авторизуемся по хэшу, то этот хэш превращается в пароль, лежащий в открытом виде, со всеми вытекающими. А насчет асимметричной схемы согласен. Я имел в виду попытку применить digest авторизацию, описанную в принятом ответе.
Suntechnic: При том, что если на сервере пароь захэширован, то этап "сервак со своей стороны так же солит пароль" превращается в тыкву. По сути, здесь обсуждается такая передовая технология, как digest авторизация. Которая, при всех своих плюсах, не получила распространения. По причине, которую я изложил выше.
Кто ж тебе не даёт? получать дату из метки времени учат еще в первом классе. дальше по полученной дате сгруппировать, как показано в примере выше? Ты хоть пытался?
