просто если ты так и так хранишь идентификатор сессии, то зачем нужен hmac

короч весь вопрос - какие у тебя требования к аутентификации

Мне нужны куки/jwt, чтобы каждый раз не долбиться за авторизацией на сервер (оно понятно) . Я предполагаю при попытке логина отправлять pass (захэшированный (пароль + соль)) , и получать в ответ уникальный идентификатор от сервера. На сервере у себя оставляю идентификатор и срок годности. Если задавать срок годности на клиенте, то что мешает зловреду постоянно отодвигать его и пользоваться аккаунтом? А если оставлять только на сервере, то как клиенту понять через сколько ему надо снова логиниться. Чёт запутался. Или это у меня паранойя?

либо тебе это не надо, либо oauth, с access_token/refresh_token

Кто нибуть может по явоскрипту подсказать?

$('#create_order').click(function(){ var check=$('co-notice--danger').is(':empty'); if(check == false){ var docHeight = $(document).height(); $("body").append("<div id='overlay'></div>"); $("#overlay") .height(docHeight) .css({ 'opacity' : 0.4, 'position': 'absolute', 'top': 0, 'left': 0, 'background-color': 'black', 'width': '100%', 'z-index': 5000 }).delay(3000).fadeOut('slow'); $("#popuporder").css("display", "block").delay(3000).fadeOut('slow'); }); $('#overlay').live('click', function() { $(this).fadeOut("slow", function() { $(this).remove(); }); }); }

почему то проскакивает.

Было бы неплохо если бы код на пастбине был :(

Мне нужны куки/jwt, чтобы каждый раз не долбиться за авторизацией на сервер (оно понятно) . Я предполагаю при попытке логина отправлять pass (захэшированный (пароль + соль)) , и получать в ответ уникальный идентификатор от сервера. На сервере у себя оставляю идентификатор и срок годности. Если задавать срок годности на клиенте, то что мешает зловреду постоянно отодвигать его и пользоваться аккаунтом? А если оставлять только на сервере, то как клиенту понять через сколько ему надо снова логиниться. Чёт запутался. Или это у меня паранойя?

а зачем ему еще раз логиниться? зачем тебе expiration вообще?

а зачем ему еще раз логиниться? зачем тебе expiration вообще?

Разве при каждой перезагрузке страницы/браузера ему не нужно было аутентифицироваться заново в течение expiration? оО

Мне нужны куки/jwt, чтобы каждый раз не долбиться за авторизацией на сервер (оно понятно) . Я предполагаю при попытке логина отправлять pass (захэшированный (пароль + соль)) , и получать в ответ уникальный идентификатор от сервера. На сервере у себя оставляю идентификатор и срок годности. Если задавать срок годности на клиенте, то что мешает зловреду постоянно отодвигать его и пользоваться аккаунтом? А если оставлять только на сервере, то как клиенту понять через сколько ему надо снова логиниться. Чёт запутался. Или это у меня паранойя?

> чтобы каждый раз не долбиться за авторизацией на сервер (оно понятно) не, непонятно

> чтобы каждый раз не долбиться за авторизацией на сервер (оно понятно) не, непонятно

Я потому и спрашиваю, мб сам дурак и хочу чего-то нереального. Как у нормальных белых людей реализуются сессии? Я логинюсь на Стак и 24 часа сколько бы браузер не закрывал - на этом компе у меня на Стаке всегда будет мой залогиненный аккаунт. Я полагаю, что он хранит у меня на компе куку с expiration в 24, и эти 24 часа, пока есть эта кука - он НЕ долбится за авторизацией. Или нет? Каждый раз он сверяет мой (допустим там просто уникальный идентификатор) с уникальным идентификатором, записанном на авторизационном сервере? нагрузка же лишняя, нет?

http://php.net/manual/ru/function.setcookie.php

3 параметр

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

Мне нужны куки/jwt, чтобы каждый раз не долбиться за авторизацией на сервер (оно понятно) . Я предполагаю при попытке логина отправлять pass (захэшированный (пароль + соль)) , и получать в ответ уникальный идентификатор от сервера. На сервере у себя оставляю идентификатор и срок годности. Если задавать срок годности на клиенте, то что мешает зловреду постоянно отодвигать его и пользоваться аккаунтом? А если оставлять только на сервере, то как клиенту понять через сколько ему надо снова логиниться. Чёт запутался. Или это у меня паранойя?

> Если задавать срок годности на клиенте, то что мешает зловреду постоянно отодвигать его и пользоваться аккаунтом? Подмешивай дату содания этого токена в хеш, это и будет мешать отодвинуть - если дату изменить, то хеш не сойдется

> он НЕ долбится за авторизацией. ну за авторизацией он и не долбится. А вот процесс аутентификации происходит на КАЖДЫЙ запрос.

а далее ты просто должен для себя решить: хочешь ты на каждую аутентификацию ходить в базу (пускай в рэдис) или же ты хочешь просто хэш проверить + сходить проверить не находится ли токен в блэклисте

вариант с блэклистами хорошо в купе с фильтром блума, тогда в этом есть хоть какой-то смысл

иначе это просто переизобретение сессий на сервере

рефреш токены же и прочее "вроде как" призваны бороться с MITM на случай если у тебя токен уведут. но как бы есть ssl + ssl pinning

а делать инвалидацию сессий по времени - рак

а делать инвалидацию сессий по времени - рак

а это не программистам решать, это должно приходить от бизнеса и СБ в ТЗ

а это не программистам решать, это должно приходить от бизнеса и СБ в ТЗ

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

клиент скажет - это требования СБ

практика показывает что это проще, удобнее и безопаснее нежели придумывать что считать бездействием

клиент скажет - это требования СБ

не ну иногда приходится идти на встречу маразмам)

оно конечно не всегда бывает так как нам хочется

а двуфакторная и время жизни сессии... ну разные вещи

а двуфакторная и время жизни сессии... ну разные вещи

вот скажи мне, зачем ограничивать время жизни сессии?

я понимаю когда "пока браузер открыт" - это нормальная практика

а вот "вот 15 минут мышкой не водил - вылогини"

а это и есть время жизни сессии

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

так что так и или иначе - протухание куки придется реализовать

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

а теперь скажи мне ЗАЧЕМ такие требования? что это дает?

зачем убирать сессию при закрытии браузера?

зачем убирать сессию при закрытии браузера?

хз, тоже можешь попробовать ответить на этот вопрос

как по мне это все "имитация" безопасности

вот скажи мне, зачем ограничивать время жизни сессии?

девайс может юзаться не только одним человеком

и бывают всякие нелепые законы...

ну пассивные операции типа просмотра баланса банковского счета - это уже серьезная проблема

и бывают всякие нелепые законы...

ну это как таможенный контроль в аэропорту

или "воздушные маршалы"

абсолютно юзлес шляпа

но народу спокойнее

девайс может юзаться не только одним человеком

и как от этого спасет вылагинивание при бездействии? я дождусь пока чувак на 5 минут отойдет и поделаю чего захочу

и как от этого спасет вылагинивание при бездействии? я дождусь пока чувак на 5 минут отойдет и поделаю чего захочу

а через 5 минут уже сессия вырубится)

хз, обычно это бесполезно

а через 5 минут уже сессия вырубится)

не, я не буду ждать 5 минут, я подожду пока чувак отойдет, это секунд 30

или оглушишь стальной палкой и отберешь

или пистолетом пригрозишь и скажешь ему наделать шалостей, ну типа того, скорее защита от дурака

да да ... логика на уровне "зачем нужна эта вся двуфакторная аутентификация если в хозяйственном можно купить паяльник" ;)

паяльник пойдет чуть по другой статье

так что разница таки есть

в конце концов придет к тебе сертификация по PCI DSS, а ты будешь стоять и с умным видом рассуждать "ну идиоты, зачем таймаут сессии"

ну как пример - банкоматы

в конце конца концов, сессионная кука не только MITM ом уводится, ты вот можешь быть уверен в отсутствии 0-day в браузере, которые позволят увести куки?

в конце конца концов, сессионная кука не только MITM ом уводится, ты вот можешь быть уверен в отсутствии 0-day в браузере, которые позволят увести куки?

Mitm? А https для кого?

панацея? напомнить как китайцы умудрились выдавать сертификаты на github и тому подобное? ;)

панацея? напомнить как китайцы умудрились выдавать сертификаты на github и тому подобное? ;)

Серебряная пуля блин)

да и гарантий, что не появится новых уязвимостей в библиотеках, позволяющее провести атаку на tls тоже как бы нет... но протухание сессий все же скорее не про mitm, а про более отложенные по времени атаки

просто один из пунктиков выстраивания безопасной системы

тут недавно на форуме человек утверждал, что пароли достаточно md5 хешировать если подмешать секретный ключ - и не подберет никто

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

просто безопасность бывает разных уровней

кому то и мд5 будет норм

а кому то давай двух факторную

если проект дожил до более серьезной безопасноти и готов в нее вкладывать бабло, силы и время то это другой вопрос

короче каждому по потребностям и по возможностям

Есть минимальный уровень, ниже которого разработчик просто не должен подпускаться к коду. В идеале, да....

Еще раз.. основной вопрос это вопрос денег

ты можешь там мутить чо хочешь

А на практике засилье "а чо" и приводит, что у "вконтакте" уводят базу паролей в чистом виде

но владелец бизнеса поставит пароль qwer1234 и привет

вконтакте это другой уровень и другой вообще разговор

люди там те же самые - "обыкновыенные разработчики"

но владелец бизнеса поставит пароль qwer1234 и привет

лайххак - вместо валидации по символам лучше добавить валидацию на присутствие пароля в top 1000 самых популярных

словарики валяются открыто

Есть минимальный уровень, ниже которого разработчик просто не должен подпускаться к коду. В идеале, да....

ожидание - реальность

Владелец захочет простой пароль и ты хоть какие валидации ставь

лайххак - вместо валидации по символам лучше добавить валидацию на присутствие пароля в top 1000 самых популярных

просто не могу не вспомнить, извиняюсь сразу

— Извините, Ваш пароль используется более 30 дней, необходимо выбрать новый! — розы — извините, слишком мало символов в пароле! — розовые розы — Извините, пароль должен содержать хотя бы одну цифру! — 1 розовая роза — Извините, не допускается использование пробелов в пароле! — 1розоваяроза — Извините, необходимо использовать как минимум 10 различных символов в пароле! — 1грёбанаярозоваяроза — Извините, необходимо использовать как минимум одну заглавную букву в пароле! — 1ГРЁБАНАЯрозоваяроза — Извините, не допускается использование нескольких заглавных букв, следующих подряд! — 1ГрёбанаяРозоваяРоза — Извините, пароль должен состоять более чем из 20 символов! — 1ГрёбанаяРозоваяРозаБудетТорчатьИзЗадаЕслиМнеНеДашьДоступПрямоБляСейчас! — Извините, этот пароль уже занят! https://www.inpearls.ru/

> Извините, не допускается использование пробелов в пароле! ненавижу такие сервисы

не нужно путать бизнес требования к безопасности и профессионализм разработчика

> — Извините, этот пароль уже занят! тру стори, я как-то работал с сервисом где сообщение валидации не только говорило что такое пароль занят, но еще и у кого он юзается)

не нужно путать бизнес требования к безопасности и профессионализм разработчика

разве первое не проистекает из второго?

гм... бизнес требования проистекают из профессионализма команды разработки? ;)

гм... бизнес требования проистекают из профессионализма команды разработки? ;)

не совсем так. Есть юридические аспекты вроде "собрался хранить номера карточек - проходи PCI сертификацию", а есть "хочу что бы пользователи думали что у нас секьюрно, замутите секьюрити вопросы плиз для восстановления"

и профессианализм заключается в том что бы подсказать бизнесу компромис между "удобно, дешево, безопасно"

а не в тупую выполнять его волю

ну то есть "Думать что и зачем ты делаешь"

а не просто "мне сказали кнопку добавить, я добавил, мне ж не сказали что она делать должна"

не, я не совсем про то... есть вещи, который бизнес вообще не требует никогда

те же баззворды из топика

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

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

ну это понятно. А еще есть привычки, стериотипы и т.д. Типа "повторить пароль"

и если ты не дно ты должен идти в ногу со временем и уметь задавать вопросы "а зачем?"

короч ладно, я уже не знаю о чем мы