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

Когда только начал заниматься программингом для адалта долго размышлял зачем к одному и тому же контенту разные логины и пароли которые без палева лежат в заголовках страницах (Если вы не используете SSL конечно), Сидел смотрел ящик, думал как же решить эту проблему, и тут увидел в фильме чел подходит на ресепшене к админу дает ему свои данные и только после проверки охранник выдает ему его ключи. Тут же подумал, а почему бы такой способ не реализовать на сайте.

Смысл: дрочер регится ему как обычно выдается логин и пароль после удачной транзакции информация заносится в БД. дальше когда он заходит на сайт в мемберку, проходит авторизацию и если все хорошо попадает в рай для дрочера. Но как же тогда реализовать доступ к файлам ведь логин и пароль были в базе. Тут то как раз и приходит на помощь наш админ из ресепшена, он ему выдает ключик (ключик само собой из .htaccess) доступа к сайту произвольной длинны, ключик будем менять каждый день чтоб пользователь не смог сделать копию и раздать кому угодно или пресечь саму возможность подбора пароля.

Плюсы такой идеалогии:
1. Быстрый доступ .htpasswd апачем т.к. кол-во ключей мало, а проверка происходит с помощь БД.
2. Сложность подбора такого пароля.
3. Защита файлов.
4. Отпадает надобность использования SSL (опять же снижение нагрузки)
5. Контроль доступа т.к. все процессы происходят через скрипт.

Минусы:
1. Пароль хранится ограниченное кол-во времени, обрывание доступа при прохождения 24 часов (пользователь может не скачать файл если качает более чем 24 часа) В принципе это легко решается посредством увеличения длины пароля и периода его обновления.

Что думаете по этому поводу может есть какие то минусы которые я не учел или это вобще старая идея и придумал велосипед?

так защита .htpasswdом каталога давно уже используется

Проще говоря пароль периодически меняется и высылается только тому, кто реально зарегистрировался на сайте? Т.е. это должно исключить так сказать просмотр порно по очереди под одним логином?

что то нифига не понятно... похоже на "велосипед, но с квадратными колесами" ;)

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

все это лишнее усложнение для клиента, которое может привести к жалобам и т.д...

Не совсем.

проблема htaccess'a заключается в том что апач очень сильно начинает прогибатся когда кол-во пользователей в htpasswd достигает уже 200 пользователей (апач никак не индексирует htpasswd и каждый раз как кто-то обращается в мемберс он сканирует весь файл причем не сказал бы что поиск идеальный) это раз + всякие придурки с легкостью взламывают такие сайты либо потому что пароли короткие, либо потому что сидят на ноде через которую ваш трафик идет и просто вылавливают нужные загаловки страниц

вот схемка может так понятнее будет:

Для пользователя ничего не меняется в авторизации он вводит привычный логин и пароль (он хранится в БД, так мы быстро проверим тот или не тот пользователь) который ему выслали на мыло при сигнапе, пароль для .htaccess выдается автоматически (это уже чтобы его не выловили даже если выловят он никому не нужен на след. же день). Можно так же послать людей на гугл даже если они заходит под одним логином с разных Ипников за день (так мы сможем предотвратить нелегальный доступ теми кто покупает доступ).

Kors писал:

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

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

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

что такое "пароль для .htaccess"?
ты хочешь в .htpasswd только 24 ключа для всех сразу юзеров хранить?
или для каждого отдельный .htpasswd файл держать?

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

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

Так проголосуй ))) раз ты хоть понял (кстате начто и расчитывал)

Kors писал:

Sergio De La Proctollo: ну так ты объясни подоступнее в чем идея ;) главное - что помешает другому человеку зайти с тем же логин-паролем и получить новый ключ? что такое "пароль для .htaccess"? ты хочешь в .htpasswd только 24 ключа для всех сразу юзеров хранить? или для каждого отдельный .htpasswd файл держать? и в чем (кроме сложности) преимущество такого подхода перед другими? например простая авто-блокировка при мультилогине или логине из разных сетей?

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

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

Белин ... я так и не услышал ответа на свой вопрос ... может где есть дыры ? Может что-то я не учел ?

Sergio De La Proctollo писал:

Белин ... я так и не услышал ответа на свой вопрос ... может где есть дыры ? Может что-то я не учел ?

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

Как минимум апач не оборвёт соединение при смене пароля в .htpasswd
Я немножко не понял фразу "отдаёт пароль для .htpasswd" ты можешь расписать HTTP сессию, чтобы всем стало понятно? Ну или сделать Proof Of Concept, то есть демоверсию, которая доказывает, что твоя идея работает.

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

Про Апач, нагрузку и SSL вообще прорыдал , у меня сразу вопрос возник... ты платник хоть раз видел ?
Могу показать

Ты пойми дронам нужно дрочить , а овнерам деньги получать , а не в Штирлецов играть.

Последний раз редактировалось: xreload (20/11/06 в 06:55), всего редактировалось 2 раз(а)

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

Вообще автор пытался решить проблему производительности апача с большим кол-вом юзеров в .htpasswd

Этих юзеров он решил снести в базу, а в .htpasswd оставить 24 юзера.

Вот мне только не понятен путь где связывается (не заметно для пользователя) авторизация в базе и авторизация HTTP-заголовками из .htpasswd

Проблема еще как грицца, в главном - биллинг лично ложит (насколько мне известно) логины и пароли в .htpasswd при сигнупе.

Короче идея хороша, реализация гавно Имхо, в морг, сори

Цитата:

Проблема еще как грицца, в главном - биллинг лично ложит (насколько мне известно) логины и пароли в .htpasswd при сигнупе.

Ты прав бро, а он будет затирать новых\ребильных\старых юзеров , потом на биллинг пару абузов придет и на утро лавочка закроется.

Последний раз редактировалось: xreload (20/11/06 в 07:05), всего редактировалось 1 раз

Pentarh писал:

Короче идея хороша, реализация гавно :) Имхо, в морг, сори :)

Ещё нужно добавить
Ничего личного (С)
:)

xreload писал:

Ты прав бро, а он будет затирать новых\ребильных\старых юзеров , потом на биллинг пару абузов придет и на утро лавочка закроется.

Господа ничего личного, если вы не знает каким образом передаются пароли для .htaccess по http не надо гнать ... топик уже разросся до нефозможных размеров, только из-за того что половина пишет ничего не понятно это гавно, не понятно ???? просто прочтите это несколько раз, я иногда не понимаю какой толк сидеть на форумах и отвечать, при этом топик читать через строчку ... внимательно прочтите строчечку от stek'a у него-то опыта в программинге куда больше чем у меня.

во так сказать RTFM
http://www.ietf.org/rfc/rfc2617.txt

читаем и понимаем что с помощь скрипта мы можем отправить пользователю любой заголовок страницы в т.ч. и с заранее приготовленным паролем. кто не знает header().

Pentarh писал:

Вообще автор пытался решить проблему производительности апача с большим кол-вом юзеров в .htpasswd Этих юзеров он решил снести в базу, а в .htpasswd оставить 24 юзера. Вот мне только не понятен путь где связывается (не заметно для пользователя) авторизация в базе и авторизация HTTP-заголовками из .htpasswd Проблема еще как грицца, в главном - биллинг лично ложит (насколько мне известно) логины и пароли в .htpasswd при сигнупе. Короче идея хороша, реализация гавно Имхо, в морг, сори

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

PS. тут на мастере только один толковый прогер ? который способен что-то ответить ?

Последний раз редактировалось: Sergio De La Proctollo (20/11/06 в 07:59), всего редактировалось 1 раз

Да бля, мы поюзаем и воздадим тебе хвалу, о великий нехочуха. Па любому.

Ложили наши адалтовые биллинги на твои соображения понимаешь? )

Pentarh писал:

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

Ржунемогу

Я открою тебе секрет Нормальные здесь почти все кроме тех, кто обзывает велосипед квантовым квадроциклом

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