Есть идея по защите сайта. Хотелось проконсультироваться

Pentarh писал:

Я открою тебе секрет Нормальные здесь почти все кроме тех, кто обзывает велосипед квантовым квадроциклом Возможно, даже что то в этом есть. Но есть еще такое святое правило админа "Работает - не трогай". Платник это не полигон. И с интерфейсом биллинга шутки чреваты, охуенно чреваты. Лично я бы рискнул только с подачи биллинга менять такие концептуальные вещи как хранилище логинов и паролей.

Ну вот хоть первый минус услышал ... 1. Проблемы с биллингом, а точнее договорится с ним.

еще ?

Насколько я понял из описания:
1) при оплате я получаю кредентиалы, которые хранятся в базе;
2) когда я ввожу кредентиалы - мне выдается один из 24 ключ и я по этому ключу вижу контент в течении N часов.

Вопрос: а в чем заключается защита?
1) я могу выложить свои кредентиалы, которые хранятся в базе для всеобщего пользования;
2) если я ввожу их не через SSL, они видны всему миру.

Плюс в твоем подходе я вижу один: спорное повышение перфоманса за счет хранения кредентиалов в базе и уменьшения размера файла htpasswd.

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

Simplex писал:

1) я могу выложить свои кредентиалы, которые хранятся в базе для всеобщего пользования;

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

Simplex писал:

2) если я ввожу их не через SSL, они видны всему миру. Плюс в твоем подходе я вижу один: спорное повышение перфоманса за счет хранения кредентиалов в базе и уменьшения размера файла htpasswd. Ну так не проще ли найти/написать модуль к апачу, который загрузит htpasswd в хэш карту в память? Если ты утверждаешь, что проблема поиска в htpasswd давно известна, вероятна она уже каким-то образом пофикшена.

К сожалению нет, для версии апача версии 1.3 , есть впринцепи auth_db он ускоряет процесс поиска, но банить пользоватеелй мы всеравно не сможем так как процессы не идут через скрипт.

Цитата:

Проблемы с биллингом, а точнее договорится с ним.

я в слезах умиления , пиши , пожайлуста еще ! Очень прошу !

p.s.

Цитата:

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

Вася ,у пользователей AOL, адрес сможет меняться и по 100 раз за день , бань их , чтобы неповадно было, неправилным провайдером пользоваться!

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

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

Удачи!

xreload писал:

я в слезах умиления , пиши , пожайлуста еще ! Очень прошу ! p.s. Вася ,у пользователей AOL, адрес сможет меняться и по 100 раз за день , бань их , чтобы неповадно было, неправилным провайдером пользоваться! Ты бы сам из себя клоуна не строил , а послушал что тебе говорят , раз уж на форум вынес обсуждение. А про сферических коней порасказывай сам себе лучше вечером, когда ящик будешь смотреть и посетит очередная мысль, которая перевернет адалт. Удачи!

Понты твои совсем не уместны ... ты хоть один скрипт в своей жизни написал ?

Можно и мне пару копеек вставить?

В общем, идея довольно-таки давняя. Поставить одну точку аутентификации, выдать клиенту (технологически) полномочия через единый ключ авторизации. У меня была такая система лет много назад. Там выдавался динамический ключ через кукисы или урлчик (если кукисы отключены). Ключ менялся раз в 30 минут. Юзер логинился один раз на специальном логин-сервере (SSL). Все остальное для него происходило совершенно прозрачно. Ключ для клиента генерился на основе browser signature без учета IP, что не давало обламываться тем же AOLам, и, что становится заметно сейчас, катающимся в автобусах и электричках вифишникам

Sergio De La Proctollo писал:

К сожалению нет, для версии апача версии 1.3 , есть впринцепи auth_db он ускоряет процесс поиска, но банить пользоватеелй мы всеравно не сможем так как процессы не идут через скрипт.

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

xreload писал:

Вася ,у пользователей AOL, адрес сможет меняться и по 100 раз за день, бань их, чтобы неповадно было, неправилным провайдером пользоваться!

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

зы: Sergio De La Proctollo: я тебя уже спрашивал да и Cibtor тоже, но ответа так и не слышно - что помешает любому другому человеку зная исходные логин пароль залогиниться и получить ключ?

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

Sergio De La Proctollo писал:

ключ поменяется через 30 минут

и что??
я вот никак не могу добиться от тебя простого пояснения...
ладно, опишу на пальцах 2 варианта:
1 - клиент купивший доступ заходит по простому логин-паролю, получает ключ, имеет доступ к контенту.
2 - другой левый чел узнал простой логин-пароль, заходит по ним, получает ключ, имеет _нелегальный_ доступ к контенту.
как твой метод различит эти 2 варианта и какие действия будут по обоим?

Цитата:

а если уж слишком много за день заходит по этому нику забанить весь аккаунт.

это банальный бан по мультилогину который работает и без твоих наворотов.

Kors писал:

и что?? 2 - другой левый чел узнал простой логин-пароль, заходит по ним, получает ключ, имеет _нелегальный_ доступ к контенту. как твой метод различит эти 2 варианта и какие действия будут по обоим?

Метод вынесенной аутентификации позволяет, как минимум, зарегистрировать факт выдачи ключа и отказать в повторной его выдаче ближайшие минут 30 Или тупо выдавать уже зарегистрированный ключ новому посетителю, который не будет принят для авторизации

lega_cobra: это понятно, но это только в случае если два человека логинятся почти одновременно. а если с разницей в неск. часов?

кроме того, можно и без этих наворотов банально заводить сессии для каждого логина и точно также не пускать под ним логиниться повторно (с другого IP) в течении какого то времени...

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

зы: я просто никак не могу понять какие у этого метода преимущества в плане безопасности... единственный плюс - оптимизация работы апача с паролями...

Kors писал:

lega_cobra: это понятно, но это только в случае если два человека логинятся почти одновременно. а если с разницей в неск. часов?

Ничего не будет. Просто будет зафиксирован факт работы с двух разных компьютеров. Обычно, это допускается. Третий заход - уже аларм админу. 6-й заход - автоматический бан. Ну эти критерии просто для примера я написал.

Цитата:

кроме того, можно и без этих наворотов банально заводить сессии для каждого логина и точно также не пускать под ним логиниться повторно (с другого IP) в течении какого то времени...

Можно. Если это единственная цель

Цитата:

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

Нет. Ключ динамический. Это означает не только его временность, но и привязка к клиенту. Оптимальный вариант - сигнатура броузера. Т.е. другой клиент в подавляющем числе случаев, имеет другую сигнатуру, поэтому и ключ ему нужен другой.

Цитата:

зы: я просто никак не могу понять какие у этого метода преимущества в плане безопасности... единственный плюс - оптимизация работы апача с паролями...

Обычно, начинаешь решать эти проблемы с целью устаканить работу с паролями растущего числа клиентов. Затем приходят и другие преимущества. Например, единственная аутентификация избавляет клиента от ввода логин/пароля на группу разных сайтов под разными доменами, или возможность использования разных методов аутентификации - одни вводят логин/пароль, другие получают x509 сетрификатик. Есть еще ряд фишек, но лень просто писать.

lega_cobra: это ты все про свой метод пишешь - или про то что топикстартер предлагает?...

Sergio De La Proctollo писал:

Понты твои совсем не уместны ...

Вася , какие понты ? Я тебе лицом тыкаю уже в этом топике в 3 раз , обосновывая реальными фактами , что ты понятия не имеешь о чем говоришь и идея у тебя мягко говоря неверная.
Ты сам себя читаешь наверно? Так что ты на форуме тогда делаешь?

Sergio De La Proctollo писал:

ты хоть один скрипт в своей жизни написал ?

Извини не умею , научи отец ?Я теоретик по большей части .

Kors писал:

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

Положить пару пассов на отчественной дрочер борде и поверь мне , тебе как овнеру "хватит" , вот такая вот география.

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

Kors писал:

lega_cobra: это ты все про свой метод пишешь - или про то что топикстартер предлагает?...

Вообще-то да Давно делал, лет 7 назад. Система состояла из одного модуля под апач и двух скриптов. Передача клиента между компонентами производилось при помощи ряда редиректов.

В принципе, топикстартер говорит толковую идею, видимо, столкнувшись с ростом htpasswd файла. Когда начинаешь задумываться, что апача реализует полный алгоритм авторизации для каждой какашечки (включая все кнопочки и пимпочки), такая идея приходит первой в голову - сделать какой-либо простой способ проверки пользователя Один из вариантов - динамический ключ. В принципе, большие мегапорталы примерно так и делают, держа отдельный ssl login сервер. Проверили логин, получили куку или токен, и в дальнейшем проходим простую его проверку. В отличие от сессии, токен не надо помнить со стороны сервера.

lega_cobra писал:

Вообще-то да Давно делал, лет 7 назад. Система состояла из одного модуля под апач и двух скриптов.

И что с ней случилось ? Интересует перспективность того о чем ты говорил.

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

ну и куда топикстартер потерялся?...

borz писал:

на самом деле интересно, во что выросло

Вырастало несколько раз в разные конфигурации сети сайтов с разными модификациями. Сейчас работает одна из модификаций.

Цитата:

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

Сам Апач говорит о проблемах начиная с 5 тысяч логинов. Реально, начались проблемы при 20-30 тысячах. Переход на хранение в индексированной базе не дает принципиальное решение.

Kors писал:

ну и куда топикстартер потерялся?...

Забросил эту идею
В техническом плане она интересна и достаточна правильна, с учетом поправок - для мегапорталов, где однм логином доступ на пару десятков платников на десятке серверов дается и все и так уже засинхронизировано
Там не шарахаются вроде awiz'a от малейшего троганья файлов паролей и скриптов биллингов - напротив
В практическом же плане - на этом форуме мало кому реально интересно такое

lega_cobra писал:

Сам Апач говорит о проблемах начиная с 5 тысяч логинов. Реально, начались проблемы при 20-30 тысячах. Переход на хранение в индексированной базе не дает принципиальное решение.

а ни в коем случае не даст
ну что такое пусть даже 50к или 100к логинов в современных терминах ? с ндексами это ну пусть мегабайт, хоть три, хоть 20 - все равно VM любых нынешних *nixes залочат в оперативке и выделят им навсегда эти блоки

Да впринцепи никуда не терялся ... всю нужную информацию я получил ... могу только поблагодарить.

lega_cobra писал:

Можно и мне пару копеек вставить? В общем, идея довольно-таки давняя. Поставить одну точку аутентификации, выдать клиенту (технологически) полномочия через единый ключ авторизации. У меня была такая система лет много назад. Там выдавался динамический ключ через кукисы или урлчик (если кукисы отключены). Ключ менялся раз в 30 минут. Юзер логинился один раз на специальном логин-сервере (SSL). Все остальное для него происходило совершенно прозрачно. Ключ для клиента генерился на основе browser signature без учета IP, что не давало обламываться тем же AOLам, и, что становится заметно сейчас, катающимся в автобусах и электричках вифишникам

Мне интересен вот этот самый "browser signature" у всех ли браузеров он есть (у мобильников, пда ?) и как его получить стандартными средствами.
1. надо ли писать JS для этого или его можно получить в HTTP заголовках?

Sergio De La Proctollo писал:

Мне интересен вот этот самый "browser signature" у всех ли браузеров он есть (у мобильников, пда ?) и как его получить стандартными средствами. 1. надо ли писать JS для этого или его можно получить в HTTP заголовках?

Сигнатуру надо генерировать из набора полей HTTP заголовка. Можно добавить сюда первый разряд IP адреса. Генерить можно, например, как md5 sum, или любым другим методом.