/ Регистрация

сессии

Тема в разделе "Работа форума", создана пользователем luka, 28.07.03.

Статус темы:
Закрыта.
Страница 1 из 2
  1. 28.07.03 #1
    luka

    luka Активный участник

    704
    1
    А разработчики форума здесь или форум чей-то? Расскажите в мыло, пожалуйста, как сессии реализованы. Просто необходимо для одного сайта делать сейчас, а текущий вариант с cookie не особо нравится.
     
  2. 29.07.03 #2
    VL

    VL Участник

    1.695
    0
    luka
    Сессии на чем? Если механизм PHP - это одно, если самому организовать - выглядит иначе и сложней.
     
  3. 29.07.03 #3
    luka

    luka Активный участник

    704
    1
    Самому реализовать. Без куки и ip-адресов, и временных идентификаторов.

    зыж perl
     
  4. 29.07.03 #4
    VL

    VL Участник

    1.695
    0
    Ну без куки можно, а вот каким образом идентифицировать пользователя?
    Вообще в ПХП встроены сессии уже...
     
  5. 29.07.03 #5
    Nekto_guest

    Nekto_guest Гость

    И шо, что это перл?
    Все сессии основанны на временных индификаторах.

    Исключение - базовая авторизация. Хотя, вполне вероятно я ошибаюсь :)

    Сколько будет пользователей, требующих авторизацию в системы?
    Может есть смысл сделать связку SSL+базовая авторизация. Надежней я не знаю этой авторизации.

    Зы. Лучше уж временные индификаторы, чем передача пароля в открытом виде, как поступают некоторые. :)
     
  6. 29.07.03 #6
    VL

    VL Участник

    1.695
    0
    А при чем здесь авторизация вообще? Речь то о сессиях идет.

    Правильнее сказать что так поступают большинство.
     
  7. 30.07.03 #7
    luka

    luka Активный участник

    704
    1
    Временные id нельзя, можно перехватить. Cookie подменить (также почти никто не очищает их). По ip нельзя из-за nat и proxy. Вариантов больше нет? СКЗИ единственный выход?
     
  8. 30.07.03 #8
    VL

    VL Участник

    1.695
    0
    HTTPS спасет отца...
    Срок жизни куки устанавливается хоть на год, хоть на минуту, хоть на сессию.
    Читай адрес прокси (провайдера) и клиента. Вероятность совпадения при таком раскладе ничтожна (если только ты не предпологаешь посещаемость яндекса).
    Это что?
    Вообще объясни в каком контексте тебе нужны эти сессии, а то тут тебе одну теорию пишут.
     
  9. 30.07.03 #9
    Nekto

    Nekto Почётный

    5.709
    0
    luka
    Ну... Это смотря как их передовать, даже без HTTPS.
    если на каждый запрос будет присваиваться свой id-номер, с предвариельной проверкой старой, то фиг перехватишь... Но в этом случае одновремено нельзя делать более одого действия за раз.

    Куки, кстати, гораздо удобнее. Поставил сессию на куки с Id и все. Перехватить довольно затруднительно, хотя и не исключено, особенно если учесть огромное количество дыр в браузераз (см. http://securitylab.ru )

    Ну... Можно просто забить на тех, кто сидит через анаонимные прокси...
    Первый раз встречаю эту абривиатуру... Разшифруй, плиз.

    Кстати, я вполне серьезно говорю - лучший способ защиты - HTTPS и Id или базовая авторизация.
     
  10. 30.07.03 #10
    VL

    VL Участник

    1.695
    0
    Базовая авторизация через апач несколько портит внешний вид сайта (это тебе как дизайнеру)
     
  11. 30.07.03 #11
    luka

    luka Активный участник

    704
    1
    Не в том кругу начал изворачиваться. СКЗИ - система криптографической защиты информации.
    Во-вторых, не будем забывать про nat.
    А сессии нужны для доступа клиентов к предлагаемой им информации. Т.к. очень много конфиденциальных данных, которые и так хранятся в зашифрованном виде, то передавать их по незащищённому протоколу совсем нельзя. Какой смысл, если в соседнем офисе сидит ксакеп и сниффером слушает траффик? Я вижу выход только в ssl.

    Вот бы всем unix и ssh ;)
     
  12. 31.07.03 #12
    VL

    VL Участник

    1.695
    0
    luka
    Ну блин, каков вопрос, таков и ответ.
    При чем тут сесии вообще? В классическом понимании сессии в веб это система сохранения информации на сеанс работы пользователя с сайтом.
    Каким боком они касаются твоей задачи?
    Тебе нужна авторизация по нттрs и работа с сокетами на низком уровне. А уж инфу свою гоняй по сети шифрованную и открывай на строне клиента закрытыми ключами.
     
  13. 31.07.03 #13
    Nekto

    Nekto Почётный

    5.709
    0
    VL
    Первый раз слышу... Интересно...
     
  14. 31.07.03 #14
    VL

    VL Участник

    1.695
    0
    Nekto
    Ну так окошечко всплывет над твоим сайтом. Смотрится как то оторвано.
     
  15. 31.07.03 #15
    luka

    luka Активный участник

    704
    1
    А в каком виде хранятся пароли в бд на форуме? В том же, что и в cookie?
     
  16. 31.07.03 #16
    luka

    luka Активный участник

    704
    1
    Да, насчёт авторизации. Разработчики браузеров сделали одну дебильную вещь - автозаполнение форм. Всё правильно, конечно, user friendly...
     
  17. 01.08.03 #17
    Гость

    Гость Гость

    Они должны хранится в закриптованном виде. Отличном от ключиков.
     
  18. 01.08.03 #18
    luka

    luka Активный участник

    704
    1
    Я не спрашиваю как они должны храниться. Читай внимательно вопрос.
     
  19. 01.08.03 #19
    Матохин Роман

    Матохин Роман Активный участник

    3.212
    0
    luka
    Какой ты любопытный..;) Тебе зачем?
     
  20. 01.08.03 #20
    Nekto

    Nekto Почётный

    5.709
    0
    luka, хорошо, я не верно выразился. Теоретически они хранятся.
    Теоретически - если Микрон ничего не изменил.
    То собщение было моим.
     
  21. 01.08.03 #21
    VL

    VL Участник

    1.695
    0
    Зашифрованы по МД5. Есно в куках ИД пользователя и пароль. Только не надо говорить что ты сможешь расшифровать такой пароль...
     
  22. 01.08.03 #22
    luka

    luka Активный участник

    704
    1
    Md5 - однонаправленная хэш-функция. Я к тому, что если перехватить чужую cookie и записать хэш в свою, то я получу доступ под тем участником.

    Я вот тут подумал. Можно сделать таблицу, в неё записывать логин, ид, пароль и временный идентификатор полученный, к примеру, по
    my @chars = ("A" .. "Z", "a" .. "z", 0 .. 9);
    my $id = join("", @chars[map{rand @chars}(1..18)]);
    Имхо будет безопаснее, т.к. не передаются ид, логин, пароль, а идентификатор постоянно изменяется. Если кто-то перехватит его, то только на одну сессию. Можно даже к сгенеренному id приклеивать хэш ip.

    Так, мысли вслух. Бред, конечно.

    2Матохин Роман: Ты что ещё не понял? Я хочу взломать форум и стереть его.
     
  23. 01.08.03 #23
    Гость

    Гость Гость

    Нет, не бред. Имеено так и стоит делать. Нужно всегда стараться сводить к минимуму фигурирование пароля пользователя. И так поступают большинство опытных программеров.
    А если ты имел ввиду еще и связку с ip - не вижу смысла.
     
  24. 01.08.03 #24
    luka

    luka Активный участник

    704
    1
    Да, да, да. Всё и так известно.
    Смысл в том, что у тебя адрес 1.1.2.3, который хэшируется в zzz. Ксакеп перехватил твой ид (полностью строку) и подставил в cookie, но у него ip 1.1.2.4, который хэшируется в afb. Что будет на сервере понятно?
     
  25. 01.08.03 #25
    Гость

    Гость Гость

    Одно НО.
    А если человека - диалапщика выкинуло?
    Что будет на сервере когда он захочет войти под новым ip понятно?

    Nekto
     
  26. 01.08.03 #26
    luka

    luka Активный участник

    704
    1
    Когда он заходит на форум, через кнопку войти с главной страницы, то данные изменяются. В чём проблема?
     
  27. 01.08.03 #27
    VL

    VL Участник

    1.695
    0
    luka
    В общем бестолковый разговор. Если ты серьезно занимаешься безопасностью, то должен знать что система безопасности это есть комплекс технических и ОРГАНИЗАЦИОННЫХ мер.
    Просто, поверь, проще пистолет к башке приставить и ... все. Очень часто сталкивался с такими случаями. Человеческий фактор, блин.
    А пароль любой мона сломать, по крайней мере методом подбора.
     
  28. 01.08.03 #28
    luka

    luka Активный участник

    704
    1
    К примеру, приходит человек на форум регистрироваться, а его зовут в оффлайне ознакомиться и подписать правила пользования форумом, сохраняют паспортные данные, предупреждают об ответственности, которую он понесёт в случае нарушения правил и пр. Вот это организационные меры. И много таких сайтов вы видели?
     
  29. 01.08.03 #29
    micron

    micron Участник Команда форума

    15.766
    1.324
    luka, если что, то в силу вступают другие методы воздействия, особенно на желающих что-то сломать. В данном случае, защищать особо нечего. Поэтому вводить дополнительные меры безопасности на форуме, нет смысла.
     
  30. 01.08.03 #30
    luka

    luka Активный участник

    704
    1
    Я приводил форум для примера. Понимай под словом форум что-нибудь серьёзнее. Факт в том, что применять меры придётся после взлома, а оно нужно до крайности доводить?
     
Страница 1 из 2
Статус темы:
Закрыта.