Авторизация без возможности передать логин / пароль другому

Question

[dizzoid]

Подскажите пожалуйста как можно реализовать примерно следующее.
Есть некая база, доступ через веб-интерфейс. Задача: авторизоваться только, грубо говоря, «подписанных» пользователей, те если один пользователь захочет передать пароль другому, то тот уже не сможет им воспользоваться. Привязка по IP нереально, ибо динам. Отправление клиенту кода подтверждения смской, как с уникальным кодом так и с неким идентификатором клиента (грубо куска иднт. сессии), тоже не вариант, так же можно переслать. Напрашивается только один вариант авторизация через etoken. Но неужели все на столько параноидально?

Answer 1

[binom248]

Может достаточно запретить одновременную работу нескольких пользователей под одним логином? Тогда «умники», отдающие доступ, могут оказаться без доступа сами. Часто такого хватает.

Answer 2

[Павло Пономаренко]

Все варианты можно обойти. Насколько защищённой должна быть эта система?

Answer 3

[ITLav]

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

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

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

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

Comments

[pietrovich]

Да-да, регистрируясь предоставь сервису немножко горячего компромата на себя любимого :))))

Answer 4

[Иван Трофимов]

Использовать сертификаты. Как на light.webmoney.ru/login.aspx?ReturnUrl=/default.aspx сертификат X.509.

Comments

[Ruslan_Y]

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

Answer 5

[Sergey]

И токен тоже можно передать. Можно выдавать сертификаты, помеченные как неэкспортируемые (win only), но также никто не мешает клонировать систему на блочном уровне.

Answer 6

[consumer]

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

Comments

[xRay]

угу с учетом того что mac-адрес меняется без проблем

[consumer]

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

[pietrovich]

Пользователи модемов с недоумением перечитывают «привязка по mac-адресу».

[iStyx]

У пользователей модемов тоже есть mac-адрес.

Answer 7

[dizzoid]

Система — это некий «черный список», с покупкой конечными пользователями ключа на время ее использования, с возможностью добавления элементов списка.

Answer 8

[Ruslan_Y]

Вариант самый простой: при каждом обновлении страницы, менять пользовательскую cookie со значением, это же значение оставлять в свойствах объекта юзер на сервере. То есть в один момент времени только у одного человека валидная cookie и только он может получить следующую валидную. При логине в систему можно сбрасывать значение, чтобы не было подвисших сессий, которые невозможно завершить.

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

Вариант можно комбинировать с одноразовым паролем на почту или СМС, что затруднит жизнь передающему свой логин кому-то еще (постоянно придется что-то делать).

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

Еще вариант: за деньги и/или на какой-то срок выдавать пакет одноразовых паролей, чтобы человеку было просто влом передавать их кому-то еще, Особенно, если реализован метод когда он вылетает после захода другого человека и вынужден использовать новый одноразовый пароль, а их и так впритык.

Comments

[dizzoid]

Вариант передачи одноразового пароля, нельзя не исключать т.к. ключ для доступа могут купить сообща некоторые пользователи, а это необходимо исключить. Хотя против телефонного звонка вида:
— Вася а глянь есть ли в базе вот этот…
— Да, есть такой!
Ничего придумать не получится (

[Ruslan_Y]

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

Answer 9

[Alexander]

Не уверен на счет веба, но в корпоративной сети у нас есть возможность вытягивать еще и мак-адрес — он ведь не динамический :)

Если такое не получится, то предлагаю использовать систему сравнения характеристик ОС, как в Google Analytics: браузер и операционные системы, цвета экрана, разрешения экрана, версия Java, версия Flash и т.д. Конечно версии ПО меняются, но не все сразу, поэтому можно сделать погрешность в сторону увеличения версий 1-2 программ. При первой авторизации будет производиться подобный слепок системы, а при последующих просто сравниваться.

Answer 10

[Марк]

Отправлять пользователю смской некий токен сессии, в который зашит его (текущий) IP. Сменился IP — нужно перезайти.

Comments

[dizzoid]

Заходит нежелательный юзер, владельцу приходит смс — он ее пересылает нежелательному… Все доступ есть. Думали так, не подходит (

[Александр]

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

[dizzoid]

Идея замечательная, согласен. Просто привязки к IP нет ( по понятным причинам (разные провайдеры без статики)

[Ruslan_Y]

Тут ситуация 2-е в сговоре, купили доступ на 2-х. В таком случае ну пришла СМС-ка когда зашел сам, пришла вторая — официальный владелец скинул её своему товарищу и оба работают.

[dizzoid]

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

[pietrovich]

>Тут ситуация 2-е в сговоре, купили доступ на 2-х. В таком случае ну пришла СМС-ка когда зашел сам,
>пришла вторая — официальный владелец скинул её своему товарищу и оба работают.

Пишите свой просмотрщик к базе, по сути форму с веб-броузером, которая будет к каждому отправляемому на сервер дорисовывать идентификатор «железа». Номера винтов, проца, мамки и т.д. Добавьте активацию привязывающую конкретную машину к пользователю. Как только поломают (отснифают кода и начнут слать такие-же), перехватывайте запросы отправляемые контролом-броузером и применяйте собственное шифрование, придумайте несколько схем шифрования которые бы менялись в зависимости от положения звезд, усложняйте жизнь тем кто захочет разобраться с системой защиты. Жестоко карайте (баньте) уличенных в «сливе доступа налево».
Некотрое время продержитесь, потом вас опять поломают и придется придумывать что-нибудь еще…

Answer 11

[Влад Животнев]

OpenID, ограниченный Гуглом, фейсбуком. Ни один человек в здравом уме такой акк передавать не будет.

Comments

[Дмитрий Рублёв]

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

Answer 12

[Robotex]

Enum использовать никак?