WebScript.Ru
C:\   главная  ::   о сайте  ::  каталог скриптов  ::  гнездо  ::  форум  ::   авторам  :: Новостройки ::   ХОСТИНГ  ::

|| разделы::
|| поиск по сайту::

|| реклама::
|| новости почтой::
Рассылки Subscribe.Ru ::



Новости сайта WebScript.Ru
Популярные статьи

Hot 5 Stories

|| рекомендуем::




Аутентификация пользователей через Веб-интерфейс


Прислал: Alexander Suhhinin [ 18.06.2001 @ 08:58 ]
Раздел:: [ Статьи по Perl ]


Аутентификация пользователей через Web интерфейс.

Про аутентификацию пользователей написано масса статей и для оной процедуры изготовлено сотни скриптов.
Однако, в большинстве своем все эти методы рассчитаны на хранение логинов/паролей в отдельном файле, или на аутентификацию пользователей с помошью апачесвкого .htaccess.
Здесь же речь пойдет про аутентификацию реальных пользователей Unix сервера через веб-интерфейс.
Есть довольно много методов для решения этой задачи, но используют в основном два способа:
  • шифруют пароль, введенный в веб-форме и сравнивают его с паролем в файле passwd или shadow
  • используют pop3 аутентификацию.
Первый метод весьма скользкий, ибо его реализация требует прав суперпользователя (root) для открытия файла зашифрованных паролей (shadow), и, как следствие, является дырой в безопасности сервера. Он реализуется путем исполнения cgi-скрипта с правами root (suid).
Вообщем, алгоритм простой:
  • взять пару логин/пароль с Web-формы;
  • зашифровать пароль тем же алгоритмом, что и на сервере;
  • открыть файл shadow для сравнения пароля, там хранящегося с полученным с web-формы.
  • Ежели результат сравнения положителен, аутентификация прошла успешна и увы в противном случае.
  • Не забыть позакрывать все файлы.
Все вообщем-то довольно просто.
Открыли файл, прочитали в буфер, нашли нужную нам строчку, закриптовали пароль, сравнили с тем, что в файле и по делам ихним воздаем аутентифицирующемуся юзеру.
В Unix системах шифрование происходит в одну сторону - к зашифрованному паролю добаваляется хорошая порция избыточной информации (salt - соли), и выдернуть пароль назад оттуда не представляется возможным. Так что, "взлом" паролей возможен лишь методом подбора оного. Ну, а если пользователь легальный и пароль действительный, то зашифруя его, мы сразу же успешно проходим аутентификацию.
За что мне нравится Perl, так это ненужность изобретать велосипеды.
проверка пароля сводится к вызову стандартной системной функции crypt($text,$salt). Действует она так :
в качестве параметров подается пароль в "чистом" виде и зашифрованный, на выходе она должна выдать тот же зашифрованный пароль. Если этого не произошло, значит пароль в виде простого текста был неправильный.
В общем вся процедура выглядит все где-то так:
#!/usr/bin/suidperl
#
# читаем форму
.........
&check_passwd;
sub check_passwd {
my $shadow = "/etc/shadow";
# ниже две строчки = переданные из формы пароль/логин
$plaintext = $form{'password'};
$username = $form{'login'};
# пытаемся открыть файл зашифрованных паролей (на нормальной системе
# он доступен только для чтения только root-ом.)
# и заодно попытаемся его залочить.
open (SHADOW, "<$shadow") or die "Internal system error: $!";
flock (SHADOW, 2) or die "Internal lock error: $!";
@shadows=;
flock SHADOW, 8;
# закроем shadow
close SHADOW;

foreach  $line(@shadows) {
chomp($line);
($currentuser, $currentpass, $restofline) = split /:/, $line, 3;
if ($currentuser eq $username)
#       Выдергиваем зашифрованный пароль из shadow
$saltedpass = $currentpass;
# 		Проверяем его стандартной функцией crypt
if ( crypt ($plaintext, $saltedpass) eq $saltedpass) {
print "Authentification for $username success!\n";
} else {
print "Authentification for $username failure!\n";
}
}
}
}
Файлу, содержащему сей "шедевр" программистского искусства следует в целях безопасности установить атрибуты:
Владелец - root
Взведенный бит установки ID пользователя при исполнении режим доступа r-sr-xr-x
грубо говоря, в восьмеричном отображении оно будет выглядеть как 104555
В этом suid-e и кроется опасность, - если кто-то умудрится всунуть кусок своего кода в вашу программу, то сможет получить доступ к вашей системе.
(Для неверующих - прочитайте что-нибудь про Ramen - он еще и не то делает/делал).

А посему сей метод, как небезопасный, лучше не использовать.
Лучше взять готовую Perl-библиотеку: Net.

2. POP3 Аутентификация.

Простой и безопасный метод проверки подлинности пользователя.
Берется библиотека Net::POP3 и стандартными методами пытаемся влогиниться в почтовый ящик. Если нам это удалось, то логин/пароль верны, и обратный результат в ином случае.

Модуль Net::POP3 дает пользователю создать объект и 14 методов к нему.
Все методы изучать нет смысла - они довольно-таки неподробно описаны в документации к модулю, нас более интересует метод login($user,$passwd).
Он возвращает значение undef в случае неудачной аутентификации, или, в случае удачного входа в почтовый ящик, количество писем в оном, или строку "0E0", если писем нет , т.е. "пишут".

Порядок работы с ним следующий:
use Net::POP3;
&parse_form # Читаем из формы переданные пароль/логин
# Создаем объект
$pop = Net::POP3->new('popserver') || print "Cannot create connection\n";
# пробуем влогиниться
# в $res будет возвращен результат логина
$res = $pop->login($form{'login'},$form{'password'});
if ($res == undef) {
# неудача
print "Incorrect username or password!\n";
} else {
# влогинились
# делаем, что надо
#
# следующий код нарисован для того, чтобы хоть что-то
# делалось.
if ($res eq "0E0") {
# писем нет
print "You have $res messages in mailbox.\n";
} else {
# письма есть
print "You have $res messages in mailbox.\n";
}
}
#закрываем  соединение.
$pop->quit();
Намного проще и безопаснее, чем лезть в святая святых безопасности Unix систем- файл shadow.
Да и не нужно просить сисадмина сервера установить на ваш скрипт setuid bit, хотя заранее можно сказать, что любой нормальный сисадмин вам в этом откажет, и будет на все сто прав.
А библиотека Net есть практически на любом Web-сервере, где есть доступ к perl интерпретатору.

А.Сухинин. (shurick31@yahoo.com)


 :::::  podlom пишет 24.06.2001 @ 08:02 
Спасибо за хорошую статью!
 :::::  Dicr пишет 13.07.2001 @ 07:23 
Кое-что есть.....
 :::::  VorteX пишет 01.01.2002 @ 05:48 
Полезная фишка!
 :::::  ThE0ReTiC пишет 07.01.2002 @ 15:47 
Вообще интересно, кто пытается сделать аутентификацию при помощи учетных записей сервера? Тот же Apache никогда не полезет в /etc/passwd | /etc/shadow для проверки валидности пользователя. У него просто на это прав нету. Есть же специальный механизм авторизации, встроенный в Apache, который позволяет создать достаточно надежную схему авторизации без обращения с системным файлам. Да простит меня Автор, но первый спсоб авторизации я просто не понял.
 :::::  noname пишет 12.03.2002 @ 22:39 
Чушь полная!
Давать suid-ные права левому скрипту НЕЛЬЗЯ!
POP3 - здесь вообще не к месту... tcpdump никто не отменял, а кричать свои пароли на лево и на право для системы безопасности - плохой тон!

 :::::  Goody пишет 22.03.2002 @ 01:15 
Отличная идея насчет POP3. Никакие пароли никто не сопрет никаким сниффером, если юзать POP3 на localhost. А иначе и смысла нет, проверять юзеров с другого сервака. Насчет SUID конечно гон, ну ничего.. главное информация к размышлению, а остальное пусть каждый сам решает.
А вот что мешает, сохранить криптованные пароли в свой файл, а не в shadow? Главное чтоб пароли были корректно выбраны и тогда, даже если сопрут файл с паролями, то долго будут его раскриптовывать.
 :::::  Прохожий пишет 09.11.2002 @ 04:43 
Статья нормальная
2-ой способ (РОР3) хорош (я вот не допер), если просто
проверять пароль, но 1-ый все равно нужен, если надо
менять пароль в автоматическом режиме.
Предложение хранить пароли в какой-то БД - глупое.
Зачем городить огород, если есть стандартные средства.
А если им не доверять, то как же господа Вы оберегаете
пароль root
А те кто ругают, либо ничего не поняли, либо не являются
админами. Все эти операции делаются на самом сервере
и сниферы тут ничего не разнюхают. Трафика то сетевого нет
 :::::  HTML2k пишет 04.12.2002 @ 02:41 
Хорошее средство для взлома pop3 ящиков на серваке где установлен такой скрипт
 :::::  Тима пишет 13.01.2003 @ 05:36 
ИМХО, бесполезняк. Более того, опасный бесполезняк. Ну кто согласится делать /etc/shadow читабельным для юзера, который ПО ОПРЕДЕЛЕНИЮ должен иметь права минимальные! Жуть. И второй способ бред собачий. Представь, что ты пишешь прогу для интернет-магазина. И что, каждому клиенту e-mail заводить? Заболел, что ли? Сорри за резкий тон, но такое не часто увидишь, тем более на столь уважаемом сервере. Это все равно что Google порнушной рекламой облепить...
 :::::  shurik пишет 13.01.2003 @ 10:48 
IMHO, ты бредишь. Читай внимательно статью.
Речь идет об аутентификации РЕАЛЬНЫХ пользователей сервера, а для инет магазина, сайта и проч. используй .htaccess, ТвойСиКвеЛ и проч.
 :::::  Канат пишет 08.03.2003 @ 10:04 
Статья отличная, написано достаточно подробно чтобы любой смог попробовать.
Непонятны возмущения некоторых читателей - кажется они статью читают кусками и не представляют что такое SUID.
Эти скрипты для админов серверов (1 способ) и юзеров (2 способ) которым необходима идентификация реальных пользователей сервера, а не "левых" (для сервера) пользователей сайтов.
От себя хочу добавить что аутентифицировать можно так же не только через POP3, но и FTP, возможно через еще что-то.

2 Alexander Suhhinin: respect
 :::::  DIMAS пишет 28.03.2003 @ 07:50 
скажите пожалуйста в каком файле сервера хранится пароль системного администратора.Пишите на combattt@mail.ru
 :::::  henady пишет 18.04.2003 @ 21:07 
Первый скрипт можно сильно упростить используя getpwnam вместо чтения /etc/shadow. Правда всё равно нужны root привелегии.
 :::::  Syrius пишет 25.04.2003 @ 13:40 
Статья класс. Второй вариант реальный способ авторизации при смене паролей почтовых юзеров через web. Неделю назад мучался с этой проблемой, пытался решить проблему первым способом, но до авторизации через pop3 не допер. Спасибо за статью.
 :::::  triptyl пишет 07.06.2003 @ 22:31 
Хорошо, когда автор говорит, что предложенный им способ плохой! Сразу ясно, что писано для объёма. Зачем лезть в etc/shadow, если ни один нормальный хостер не даст полезть туда? Или мы не для Web? Ах, да, аутентификация через Web... Логин через POP3-объект выглядит экзотично, ещё бы через посылку письма на адрес admin@yourhost.com сделано было! ИМХО, в trash. Где здесь здесь кнопка помещения в trash?
 :::::  PHOENIX пишет 18.09.2003 @ 14:40 
Оба способа неудобны. Кто-то уже сказал, что в самом Apache есть система контроля доступа. Она легко настраивается, т.к. не требует написания специальных скриптов. Все элементарно контролируется файлами .htacces! Сделайте запрос на Яндексе - получите исчерпывающие данные по этому вопросу.
 :::::  Druid пишет 26.09.2003 @ 10:39 
Такое впечателение, что ребятя, ругающие статью и считающие себя "гуру", просто её не читали (нифига не поняли).
Написано же, для авторизации РЕАЛЬНЫХ ПОЛЬЗОВАТЕЛЕЙ!!!
Если это интернет-магазин, то делайте свою (берите чужую) систему авторизации и эта статья не для вас!
Простите, что перевел дискусию на уровень - "сам дурак", но других мыслей после прочтения некоторых комментариев не возникло.
 :::::  shurick31 пишет 27.09.2003 @ 16:55 
Да, народ не умеет ЧИТАТЬ.
Тима, PHOENIX см. 3-й абзац статьи.
Вы вероятно не видите разницы между клиентом инет-лабаза и РЕАЛЬНЫМ пользователем.
Эта статья, собственно написана не для web-кодеров, а для людей, которые работают под *NIX системами, и доступаются удаленно к оным. (читай - для админов всех уровней).
Для аутентификации пользователей веб-сайта достаточно использовать встроенные средства апача, но если вы считаете, что лучше и реальных пользователей аутентифицировать через эту систему, то я снимаю шляпу , но не перед вами, а перед "гробом" вашей системы, которая невдолге почнет в бозе.

 :::::  dimar пишет 14.10.2003 @ 17:41 
Каким образом можно обнаружить разрыв пользователя через Web интерфейс (при разрешении доступа через локальную сеть на сервер выхода в Интернет необходимо знать когда он оторвется)
 :::::  alexander пишет 16.10.2003 @ 10:56 
Обычно разрыв отслеживают с помощью cookie.
Как оно работает - посмотри в исходниках любого движка форума веб-почты.


 :::::  Роман пишет 20.01.2004 @ 01:55 
Неплохая статейка
 :::::  kav пишет 30.04.2004 @ 07:30 
А как тоже сделать с помощью PHP
 :::::  shurick31 пишет 30.04.2004 @ 22:09 
На PHP этого делать не надо. Появилась куча библиотек для Perl и PHP, чтобы проводить аутентификацию реальных юзеров системы. Вдумчиво изучаем http://www.cpan.org/modules/by-category/14_Security_and_Encryption/ для perl, или используем IMAP,POP,LDAP функции для проверки логина/пароля в случае PHP (возможно, есть классы типа Authen::PAM).
 :::::  Brat пишет 06.12.2007 @ 23:08 
Ны вы блин даете. Половину не понял. А главное что брат мой в меня- умный. Молодец Саня.
Знай наших.
Имя:
Email:
URL

Введите сумму двух чисел девять и шесть (девять+шесть=?)
Запомнить мою информацию

* Html запрещен* Ваш E-mail опубликован не будет.

Copyright © 2000-2001 WebScript.Ru nas@webscript.ru
Design © 2001 by Parallax Design Studio (aka Spectator.ru)
Все торговые марки и авторские права на эту страницу принадлежат их соответствующим владельцам.
Сгенерировано за: 0.0246389