The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"пароли"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы WEB технологии (Public)
Изначальное сообщение [Проследить за развитием треда]

"пароли"
Сообщение от asdfgf emailИскать по авторуВ закладки(ok) on 14-Апр-04, 13:50  (MSK)
Существует необходимость в предоставлении пользователям возможности смены своих системных паролей через web интерфейс на хосте под управлением *nix подобный OS.
Про реализацию сей задачи в сети есть несколько статей, но все они не удовлетворяют моим критериям безопасности :-)

Во-первых, должна производится проверка наличия в системе пользователя для которого хотят поменять пароль, ну это очевидно.
Во-вторых, дабы никто-то, а имеено владелец аккаунта мог сменить себе пароль, нужно производить проверку по старому паролю, до запроса нового. Это тоже само собой разумеется. (по аналогии утилиты passwd, если она запускается от имени простого не привилигированного пользователя).
В-третьих, если возможно (к сожалению это не совсем возможно) все должно запускаться и работать без всяких там suid битов на срипты и остальные программы.
(к сожалению без этого не обойтись, imho, но нужно постараться свисти к минимуму возможные такие изьяны).
На данный момент (я не один из первых) сделано все очень просто:
html страница с формой, где пользователь будет вводить свой логин, старый пароль, новый пароль и подтверждение нового пароля.
Далее данные из формы передаются в perl-скрипт, который делает проверку данных из форм, на наличие не допустимых символов, затем проверяет наличие "такого" пользователя в системе, потом делает проверку верности старого пароля (берется зашифрованый пароль из файла (тогоже /etc/shadow), шифруется взятый из формы (шифруется при помощи функции unix_md5_crypt() взятой из модуля Crypt-PasswdMD5 (есть на cpan.org, рекомендую использовать версию 1.2 а не 1.3 она не правильно работает, или поправить чтоб заработала)
и сравнивается с паролем из файла. Если все пучком, тогда просто вызывается внешняя утилитка chpasswd которой отдается логин и новый пароль.
Все бы ничего да есть свои тонкости:
Во-первых, не так то просто вытащить зашифрованый пароль из /etc/shadow.
Во-вторых, не так то просто запустить chpasswd(в нашем случае, она может выполняться только от пользователя с привилегиями соответсвующми, делать эту тузлу суидной я бы не рекомендовал), это утилита только для человека с мозгами - тобишь root (жаль не у всех есть мозги :-)), потому что эта тулза меняет пароли без всяких там проверок (возможно она как раз и существует для написания человеком с мозгами shell сценариев).
Кароче, присвоения suid бита на скприт который все это будет делать - не есть гуд, изменение пирмишенов на /etc/shadow, об этом даже и речи быть не можеть, хранить пароли в другом месте? а смысл? :-), про chpasswd я уже сказал...
Так вот я в раздумии, может быть благородные доны что-то посоветуют?
Да, и еще, есть другой вариант, когда данные с формы будут просто кладываться в файлик, а затем(например по crond) будет запускаться скрипт уже от root'a и делать нужные проверки, и замены... Но это не удобно, тем что меняться пароль будет не сразу, да и сообщать об ошибках(например старый пароль не подходит) пользователю как? отсылать потом е-майлом?! согласитесь это не удобно....

  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "пароли"
Сообщение от uldus Искать по авторуВ закладки(ok) on 14-Апр-04, 21:32  (MSK)
>Да, и еще, есть другой вариант, когда данные с формы будут просто
>кладываться в файлик, а затем(например по crond) будет запускаться скрипт уже
>от root'a и делать нужные проверки, и замены...

Так и делай, только основные проверки вынеси в CGI, а в файлик кидай инструкцию для смены пароля, т.е. login, старый и новый пароль. Валидность старого пароля лишний раз проверь перед обновлением, так сказать лишняя перестраховка. Предусмотри ситуацию двойной смены, т.е. пока cron раз в минуту не запустить root-овый скрипт для обновления, на попытки пользователя еще раз поменять пароль должнв вываливаться ошибка. На 30 cекунд (в среднем) до реальной смены пароля пользователя можно отвлечь страничкой с правилами и прочей чепухой.

Из CGI проверить валидность старого пароля можно  используя chkpassword из daemon-tools или даже через POP3.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "пароли"
Сообщение от asdfgf emailИскать по авторуВ закладки(ok) on 15-Апр-04, 08:04  (MSK)
>>Да, и еще, есть другой вариант, когда данные с формы будут просто
>>кладываться в файлик, а затем(например по crond) будет запускаться скрипт уже
>>от root'a и делать нужные проверки, и замены...
>
>Так и делай, только основные проверки вынеси в CGI, а в файлик
>кидай инструкцию для смены пароля, т.е. login, старый и новый пароль.
>Валидность старого пароля лишний раз проверь перед обновлением, так сказать лишняя
>перестраховка. Предусмотри ситуацию двойной смены, т.е. пока cron раз в минуту
>не запустить root-овый скрипт для обновления, на попытки пользователя еще раз
>поменять пароль должнв вываливаться ошибка. На 30 cекунд (в среднем) до
>реальной смены пароля пользователя можно отвлечь страничкой с правилами и прочей
>чепухой.

Все это здорово, но я еще раз повторюсь: как сообщать пользователю об ошибках? Например, если старый пароль не подходит? отсылать е-майл(как я уже писал)? ну это тоже вариант... но жто немного не то, чего бы я хотел...
Дело в том, что не так то просто взять пароль из /etc/shadow для проверки. Я даж ене уверен что suexec от apache поможет - хотя стоит попробовать.
Ладно будем дальше думать.
Спасибо


  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "пароли"
Сообщение от uldus Искать по авторуВ закладки(ok) on 15-Апр-04, 11:14  (MSK)
>Все это здорово, но я еще раз повторюсь: как сообщать пользователю об
>ошибках? Например, если старый пароль не подходит? отсылать е-майл(как я

Я же говорю - все проверки производятся на стадии CGI скрипта, проверить наличие пользователя рутовых прав не нужно. Для проверки пароля от обычного пользователя - самое простое решение использование проверенного изделия от djb или еще проще через USER/PASS запрос по POP3.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "пароли"
Сообщение от asdfgf emailИскать по авторуВ закладки(ok) on 15-Апр-04, 11:58  (MSK)
>>Все это здорово, но я еще раз повторюсь: как сообщать пользователю об
>>ошибках? Например, если старый пароль не подходит? отсылать е-майл(как я
>
>Я же говорю - все проверки производятся на стадии CGI скрипта, проверить
>наличие пользователя рутовых прав не нужно. Для проверки пароля от обычного
>пользователя - самое простое решение использование проверенного изделия от djb или
>еще проще через USER/PASS запрос по POP3.


Про user/pass по pop3 - интересная мысль, нада попробовать.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "пароли"
Сообщение от MK emailИскать по авторуВ закладки on 15-Апр-04, 00:25  (MSK)
Как вариант:
Напиши программу демон открывающую локальный сокет(Unix-socket)и
запусти ее с правами рута, а web-приложение будет обращаться к этому
демону через локальный сокет.
  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "пароли"
Сообщение от asdfgf emailИскать по авторуВ закладки(ok) on 15-Апр-04, 08:12  (MSK)
>Как вариант:
>Напиши программу демон открывающую локальный сокет(Unix-socket)и
>запусти ее с правами рута, а web-приложение будет обращаться к этому
>демону через локальный сокет.


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

В общем, будем думать дальше.
Спасибо.

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру