Ну обычно только мошенники мнутся, когда их спрашивают о целях хостинга.
Что за проект-то? Ссылка есть?
Не в вашей компетенции проверять fake это данные или нет, для этого есть отдельная процедура через http://www.icann.org/en/resources/compliance/complaints/whois/inaccuracy-form и согласно http://www.icann.org/en/resources/registrars/consensus-policies/wdrp. Авторизованный контакт, согласно регламенту ICANN, это e-mail контактных данных домена. Если запрос был с авторизованного контакта, то остальное - непонятные фантазии и передергивания.
Вопрос клиента возник, когда запросили код авторизации на трансфер. Поэтому не нужно подменять понятия. Тут как минимум нарушение прав потребителя, договора с регистратором и transfer policy. Вероятно, если бы у клиента подходил очередной платеж, хостер бы не вдавался в вопросы, "а не злоумышленник ли мне платит, убив моего клиента и отжав активы".
Если хостинг включает режим одуванчика, которым так часто грешат совковые конторы, совет клиенту один - действовать предельно жестко. Был бы назван регистратор - были бы даны конкретные рекомендации, и дальше уже начали бы разбираться с регистратором и излагать свои юридические познания, почему вы так поступили. Только наверняка режим дурака был бы мигом выключен, а покупателю выдан код авторизации.
P.S. А вообще это наглядная иллюстрация главной рекомендации - никогда не регистрируйте свои домены через хостера. И что более печально, следует и другая рекомендация - по возможности постарайтесь избегать работы с российскими хостингами, что несколько несправедливо из-за единичной ситуации неадеквата какого-то игрока рынка.
Извините, что вас прерываю, но вижу здесь логические противоречия.
Т.е. запостил знакомый, а потом отдал вам аккаунт и вы сейчас уже от своего лица к нам обращаетесь?
Или речь о том, что вы якобы передаете свои фразы знакомому, а он сразу же постит их сюда, выступая в качестве прокси-сервера? Тогда резонно предположить, что де-факто правило о "клоноводстве" нарушается, т.к. выступаете здесь именно вы и именно от своего лица, несмотря на бан первого аккаунта, фактически вы являетесь клоном, даже если выступаете через прокси-сервер.
Я не спорю. Я наоборот выступаю за максимальную простоту для пользователей, но это решение настолько же оправдано, насколько и решение ТС, если разговор идет об эффективности. К тому же, не нужно смотреть на вопрос в лоб. Решение необязательно должно строиться на одной технологии. Опять подниму вопрос об антифроде - там все системы "флажковые". И т.к. речь идет в основном об онлайн-шоппинге, здесь невозможно возразить, что владельцы могут плевать на потерю клиентов, а значит продаж, а значит просаживать свои бюджеты на маркетинг с наихудшим конвертом.
Именно эта система реализована в онлайнах некоторых банков, называется virtual keyboard. Если речь идет именно о капче, то еще в 2009 году было соотв. исследование гугла - http://www.richgossweiler.com/projects/rotcaptcha/rotcaptcha.pdf
Еще более простые проекты:
http://identipic.com/
http://research.microsoft.com/en-us/um/redmond/projects/asirra/
Имхо, капча - довольно таки эффективное решение. Разработчикам никогда не нужно ее отметать. Тем более, что если идти в шаг разработки своей системы, то ее можно опять же выставлять пользователю не всегда, а при определенных признаках, что делает тот же вконтач.
P.S. Сорри за оффтоп.
Готов поспорить. Пользователь к ней уже приучен большими проектами. Тем более есть огромное количество реализаций, посмотрите ссылку в моем предыдущем посте, там довольно таки объемно рассмотрена ситуация, не вижу смысла здесь повторяться.
Вы не читаете, о чем я пишу. Речь идет о комплексном решении против:
1. Прокси.
2. Аномального поведения, свойственного автоматическому софту, но не человеку. Т.е. формировании признаков и соотв. флажковой системе, кого пускаем, а кого нет.
Мне кажется задачу вообще можно еще больше упростить. Вряд ли мы ведем здесь речь о взломе конкретного акка. Если мы как раз ведем речь о:
То речь идет о массовом брутфорсе по словарям, причем очень часто конкретным софтом.
Поэтому возвращаемся к тому, с чего я начал - не нужно изобретать велосипед, а просто воспользуемся наработками антифрод-индустрии.
P.S. Ни в коем случае не умоляю вашей инициативы, возможно на каких-то проектах это и будет оптимальным решением. Просто я не вижу в данный момент на каких.
Объясните, зачем "заставлять" пользователя что-то делать? Проблема взлома - проблема сервиса. Т.к. пользователи - это наши коровы, которых мы доим. И сокращая их количество, мы сокращаем свою прибыль. Поэтому для начала нужно понять цели, которые мы преследуем.
Скажем так, цель - защитить пользователя от взлома. Окей. Каким образом без использования двойной аутентификации решить этот вопрос, если речь о кейлоггере? Пока пропускаю ответ.
Более реальный кейс - брутфорс аккаунтов по словарям. Почему не пойти по другому пути? Зачем мучить пользователей с паролями, если можно мучить брутфорсеров. Самые простые решения:
1. Evercookie.
2. Geo-ip.
3. Лимиты на запросы.
4. Captcha.
Да, реализация уже становится сложнее, НО, пользователя мы избавляем от всяческих мучений (ну кроме п.4). Другой плюс, если ваше решение только в противодействии брута по словарям, здесь мы можем (особенно с решением 1.) защитить аккаунты в принципе и от других решений (кейлоггер). Если сайт на ру-трафик, может разумней вообще запретить авторизацию с других айпи (здравствуй geo ip и прощайте соксы!), сделать признаки "провайдеров". Если речь идет о том, чтобы избежать "автоматические решения", то мы должны выделить признаки этих "автоматических решений". В конце концов, даже софт большинства script-kiddies - конечен.
Это мысли тезисами, но я бы подходил к решению задачи именно с учетом опыта антифрода. А не потери трафика с регистраций как в вашем решении, т.к. может существенно снизиться количество регистраций, а т.е. конверт (датинг - супер актуально).
Вероятно ТС тролль, либо бп делает для Webhost1, но нарушу здесь ваше уютное буквоедство и вернусь к тем самым правилам ICANN, которые почему-то упоминают, но не цитируют.
Читаем http://www.icann.org/en/resources/registrars/transfers/policy:
Т.е. если реселлер не дает Auth Code, то он подставляет своего регистратора, т.к. это нарушение transfer policy, которое регистратор подписывал.
По поводу "идентификации клиента".
Т.е. вариант трансфера со сканами существует и носит название "physical authorization process", но им должен заниматься ПРИНИМАЮЩИЙ домен РЕГИСТРАТОР. А не реселлер регистратора домена.
И это никоим образом не касается передачи трансфер кода, который необходим для любого FOA.
Подведем итоги.
1. Любой ICANN-аккредитованный регистратор (мы же тут речь о gtld ведем, конкретно об .org) обязан предоставить AUTH-код по первому требованию владельца домена. И никаких причин для отказа нет в принципе.
2. Запрос на трасфер инциируется новым регистратором методом FOA - электронным запросом или хардкорным "физическим" с предоставлением сканов айди.
3. Список, по которому текущий регистратор может отказать в трансфере конечен:
4. Роль реселлера в этом процессе - информировать клиента о действиях регистратора, а не создавать "свои" бюрократические препоны, которые идут вразрез с вышестоящими инстанциями. На мой взгляд, это вообще нарушение договора реселлера с регистратором, было бы забавно клиенту стать причином его расторжения.
5. Никакие местные законы не могут идти вразрез с законами юрисдикции международной организации, которая управляет доменной системой. Это как законы Калмыкии не могут идти супротив законам федеральным. Оно конечно бывает, но, слава богу, решается.
Пишите в Роспотребнадзор. Штрафанут, проверено на личном опыте.
Все "лоховские темы" - они же темы "менеджерские", т.е. по которым им идет высокий процент вознаграждения, т.к. они высокоприбыльные для компании. Отсюда суета и желание впарить. Т.е. фактически это инициатива самого менеджера, который всеми силами хочет вам это предложение впихнуть. Но глупо думать, что руководство этого не предполагает. Просто тема высокоприбыльная, а значит риски того стоят.
В банках равнозначная тема по страховкам к кредитам. В большинстве случаев вы можете от нее отказаться и получить кредит, но менеджер будет заверять вам, что кредит вы не получите. Более того, если страховка действительно так необходима, то банк должен предложить несколько страховых на выбор, а не свою прикормленную. Решается также штрафом банку через Роспотребнадзор. По судам, к сожалению, неоднозначная практика по регионам, где-то возвращают, а где-то нет.
В сетевых магазинах бытовой техники это будет тема с доп. гарантией. Точно также менеджерам с нее платится большой процент, и они будут впаривать ее, заверяя что через год, если товар ёкнется, то будет ПОПОДАЛОВА, но это не правда. Если поломка не по вашей вине, и даже если товар технически сложный, его точно также можно сдать назад в магазин и получить с магазина равнозначный. А если это будет ремонт, то на время ремонта товар на замену. Безусловно, в случае отказа магазина будут претензии, суды и экспертизы, но все оно, как правило, выйгрышное.
Вот такие вот пирожки с капусткой.
Имхо, надо играть на опережение. Какой у вас оборот? Вы можете заказать серверсайда? Данные легко гуглятся. Что вы знаете о курдах? Что вы знаете о Гомеле?
Ответите на эти вопросы - переходите к советам ниже.
Юридические советы.
1. Зарегистрируйте свой сайт как СМИ.
2. Заверьте все нотариальными скриншотами, потому что серверсайд тоже может сыграть на опережение и предоставить свои нотарильно заверенные скриншоты, которые будут говорить не в вашу пользу.
3. Наймите юристов в Турции, покажите им свои заранее апостилированные документы из п.1 и 2., включая переписку и угрозы, и узнайте о шансах дела.
4. Даже если шансы малы, дело принципа - подайте иск в Турции первым.
5. Если подключаете турецких копов, попробуйте узнать у них (аккуратно) по международному сотрудничеству с Белорусией. Запрос нужно сделать в Гомель.
6. Как вариант, узнайте - возможно ли подтвердить документально оборот серверсайда по фирме путем официальных выписок? Если да, то возможно нужно отправить эти документы в Налоговую Гомеля.
Если на п.4 серверсайд не будет визжать как маленькая беспомощная девчонка, предлагая вам "выкуп", то я право буду удивлен. В любом случае - информируйте нас, это очень важно.
А если отбросить шутки, то варианта всего два.
Практические советы.
1. Удалить листинг.
2. Продать проект (т.к. очевидно, что дело не в яичках хостера, а в ваших собственных).
P.S. Кстати, чем все закончилось с Amaroko? Я так полагаю, что ничем?
