Comments 68
При такой авторизации никакой безопасности нет. Подменив куки я войду под любым пользователем, толку от нее тогда?
Я вам скажу из своего опыта, что любой человек, уже привык что-то вводить, нажимать итд. Я недавно делал калькулятор на яваскрипте, и ради эксперимента убрал кнопку рассчитать, завязал функцию за смену содержимого в текстбокс, так вот, прошло пол года, и было очень много людей, которые даже при мне искали эту кнопку.
Я уже писал, напишу еще, на мое мнение нужно требовать от пользователя регистрации/авторизации только в случаях необходимости, как вы писали, например, голосования, комментариев итд. Я бы просто спрашивал логин и пароль, логин это мейл. После ввода данных оно проверяет наличие мейла в базе, если нет, сразу регистрирует (можно спросить, мов, мейл пупкин не найден, зарегистрировать?) и дублировать данные ему на почту (так как пароль введен 1 раз пользователь мог опечатается). Вот и вся процедура, если вам нужен адрес, пожалуйста, спросите его когда скажем пользователь хочет что бы ему доставили товар, спросите, «А куда вам его доставить»? После ввода вы получили данные, а пользователь ожидал этого вопроса, это интуитивно понятно и не сложно. Таким же образом можно получить и другие данные.
Я вам скажу из своего опыта, что любой человек, уже привык что-то вводить, нажимать итд. Я недавно делал калькулятор на яваскрипте, и ради эксперимента убрал кнопку рассчитать, завязал функцию за смену содержимого в текстбокс, так вот, прошло пол года, и было очень много людей, которые даже при мне искали эту кнопку.
Я уже писал, напишу еще, на мое мнение нужно требовать от пользователя регистрации/авторизации только в случаях необходимости, как вы писали, например, голосования, комментариев итд. Я бы просто спрашивал логин и пароль, логин это мейл. После ввода данных оно проверяет наличие мейла в базе, если нет, сразу регистрирует (можно спросить, мов, мейл пупкин не найден, зарегистрировать?) и дублировать данные ему на почту (так как пароль введен 1 раз пользователь мог опечатается). Вот и вся процедура, если вам нужен адрес, пожалуйста, спросите его когда скажем пользователь хочет что бы ему доставили товар, спросите, «А куда вам его доставить»? После ввода вы получили данные, а пользователь ожидал этого вопроса, это интуитивно понятно и не сложно. Таким же образом можно получить и другие данные.
Подменив куки где угодно вы войдете под любым пользователем. Это совершенно естественно. И надо не отказываться от куки а усиливать аутентификацию — например собирать статистику по ip и если вдруг внезапный вход с другого ip — высылать письмо, требовать подтверждения или еще что-то. Кука шифруется, у нее есть таймаут и всякие дополнительные данные о пользователе, но она все равно остается кукой — т.е. неким «секретом» между пользователем и сервером.
И вы вряд ли сможете аутентифицировать (без сложных плясок с бубном в которых все равно возникнет общий секрет) пользователя, который не способен сообщать вам какие-либо «секреты», т.к. он ничем не отличается от произвольного анонимуса — у того тоже нет «секрета»
И вы вряд ли сможете аутентифицировать (без сложных плясок с бубном в которых все равно возникнет общий секрет) пользователя, который не способен сообщать вам какие-либо «секреты», т.к. он ничем не отличается от произвольного анонимуса — у того тоже нет «секрета»
Если про куки вы написали верно, то ваша идея по поводу обслуживания входа с другого IP — бред. Т.е. мобильные пользователи будут постоянно подтверждать новые ip, с которых они входят? :)
Gmail ведь предупреждает о новых непонятных посещениях, но не препятствует. А мобильные браузеры отслеживаются по User-Agent, в конце концов.
Вы в facebook с других компьютеров или в in-private режиме заходили? Каждый раз предлагается дать имя компьютеру и на ваш email высылается письмо — «в ваш аккаунт зашли вот такие-то, если это не вы — перейдите по линку х».
Я не говорю что надо применять все меры и сразу, но защищать авторизацию по куки надо не методом «отказа от авторизации по куки».
Я не говорю что надо применять все меры и сразу, но защищать авторизацию по куки надо не методом «отказа от авторизации по куки».
1. А как Вы куку подмените? На что? Даже зная нужное значение (ведь совсем необязательно хранить id пользователя в чистом виде), в куке лучше хранить хэш. В Kohana куки записываются по интересной схеме — первая часть — хэш (по ключу), а вторая — чистое (исходное) значение куки. Так что прочитать можно, а вот подменить маловероятно.
Опять же, наиболее критичные участки надо все равно прикрывать принудительной авторизацией, об этом я писал.
2. По поводу запроса личных данных — ничего требовать и не надо! Если пользователь захочет, он введет. Мое дело — сообщить ему о том, как и где он это может сделать. Сам не люблю многостраничные портянки, которые надо заполнять при регистрации. Буээ
Опять же, наиболее критичные участки надо все равно прикрывать принудительной авторизацией, об этом я писал.
2. По поводу запроса личных данных — ничего требовать и не надо! Если пользователь захочет, он введет. Мое дело — сообщить ему о том, как и где он это может сделать. Сам не люблю многостраничные портянки, которые надо заполнять при регистрации. Буээ
Хмм. Сейчас в проекте уже реализовали подобное разделение и глянув на ваше описание — увидел все камни которые мы обошли. Итак (сейчас будет не претензия на истину, а немного другой взгляд на вещи):
1. Users — странная таблица. У нас тоже была изначальная идея как и в предложенной схеме, но потом стало понятно, что с реализацией «мультивхода» она выглядит неправильно. Итак у нас это Profile.User и сущность там, на самом деле, профиль пользователя, т.е. то, что касается пользователя у вас на сайте. И email слабо относится к этим данным (подробности позже). Т.к. у нас система распределенная — UserID у нас Guid, но в общем это не сильно относится к делу. ах да, и никакого «главного логина» — это знание логина, а не профиля
2. Auth_data (Credential) — вот самое интересное. У профиля для входа может быть несколько креденшиалов, но вот профиль не знает ничего про сайты или вход, ну не его это дело — знать. Поэтому тут разворачиваем связь в виде Profile->Сredential, т.е. у каждого Credential есть UserId, email (т.к. у каждого сервиса может быть разный email =), fb например позволяет анонимизировать почту при предоставлении аутентификации), еще флаговый признак — IsPrimaryEmail ( понятно для чего — «главный логин» он же «основной email»), тип креденшиала — google, Facebook, twitter, plainpassword, признак верификации (т.к. нам критично получить валидный email — для plainPassword мы высылаем ссылку-подтверждение email) ну и любимый всеми хомячками auth_data в XML формате ( с ней пока не работаем, но планируем).
Ключевой момент при проектировании бд — правильно отделять «мух от котлет», и то, что на первый взгляд «да ну, не страшно что продублируем информацию», потом обернется серьезными переделками. Если вы хотите иметь другую логическую структуру в бд («запросы писать удобней» или «так понятней») — сделайте удобный набор view. Но физическую структуру правильней разделять на независимые и конкретные сущности.
3. При входе через провайдера — мы извлекаем email и ищем совпадения в БД, если есть совпадение с каким-то подтвержденными credential — привязываем новый вход уже к известному юзеру и добро пожаловать. Если совпадения нет — возникает выбор — «создать новый и войти» (одна кнопка) или ввести пароль и привязать с существующему (т.е. пользователю дается возможность привязать к одному профилю разные аккаунты с разными email. И в принципе кука долгожитель тут не нужна — если пользователь хочет завести новый аккаунт — он это всегда сделает — например из того же in-private режима, с этим бороться бесполезно
4.Что еще стоит собирать и использовать — собственно внутренняя Auth_data — и гугл и fb и все остальные передают свой внутренний id пользователя (формат очень разный =)). его надо помнить\хранить и искать по нему пользователей — т.е. если пришел пользователь с FB, зарегался, потом запретил ваше приложение, пришел повторно и отдал анонимный email — его можно определить по внутреннему FB аккаунту. Та же самая ситуация и с гуглом — если привяжете в один аккаунт несколько адресов (удобно при Google apps for your domain например), то можно не парится и не вспоминать — а какой email я в прошлый раз отдавал — googleId для аккаунта будет один и тот же. Да и все сервисы, кто не отдает email ( твиттер) можно авторизовывать только таким способом. Опять же — креденшиалы без email не могут быть Primary ( для нас).
Ну вот как-то так — кратко непонятно и неподробно ;). Будут вопросы — пишите.
1. Users — странная таблица. У нас тоже была изначальная идея как и в предложенной схеме, но потом стало понятно, что с реализацией «мультивхода» она выглядит неправильно. Итак у нас это Profile.User и сущность там, на самом деле, профиль пользователя, т.е. то, что касается пользователя у вас на сайте. И email слабо относится к этим данным (подробности позже). Т.к. у нас система распределенная — UserID у нас Guid, но в общем это не сильно относится к делу. ах да, и никакого «главного логина» — это знание логина, а не профиля
2. Auth_data (Credential) — вот самое интересное. У профиля для входа может быть несколько креденшиалов, но вот профиль не знает ничего про сайты или вход, ну не его это дело — знать. Поэтому тут разворачиваем связь в виде Profile->Сredential, т.е. у каждого Credential есть UserId, email (т.к. у каждого сервиса может быть разный email =), fb например позволяет анонимизировать почту при предоставлении аутентификации), еще флаговый признак — IsPrimaryEmail ( понятно для чего — «главный логин» он же «основной email»), тип креденшиала — google, Facebook, twitter, plainpassword, признак верификации (т.к. нам критично получить валидный email — для plainPassword мы высылаем ссылку-подтверждение email) ну и любимый всеми хомячками auth_data в XML формате ( с ней пока не работаем, но планируем).
Ключевой момент при проектировании бд — правильно отделять «мух от котлет», и то, что на первый взгляд «да ну, не страшно что продублируем информацию», потом обернется серьезными переделками. Если вы хотите иметь другую логическую структуру в бд («запросы писать удобней» или «так понятней») — сделайте удобный набор view. Но физическую структуру правильней разделять на независимые и конкретные сущности.
3. При входе через провайдера — мы извлекаем email и ищем совпадения в БД, если есть совпадение с каким-то подтвержденными credential — привязываем новый вход уже к известному юзеру и добро пожаловать. Если совпадения нет — возникает выбор — «создать новый и войти» (одна кнопка) или ввести пароль и привязать с существующему (т.е. пользователю дается возможность привязать к одному профилю разные аккаунты с разными email. И в принципе кука долгожитель тут не нужна — если пользователь хочет завести новый аккаунт — он это всегда сделает — например из того же in-private режима, с этим бороться бесполезно
4.Что еще стоит собирать и использовать — собственно внутренняя Auth_data — и гугл и fb и все остальные передают свой внутренний id пользователя (формат очень разный =)). его надо помнить\хранить и искать по нему пользователей — т.е. если пришел пользователь с FB, зарегался, потом запретил ваше приложение, пришел повторно и отдал анонимный email — его можно определить по внутреннему FB аккаунту. Та же самая ситуация и с гуглом — если привяжете в один аккаунт несколько адресов (удобно при Google apps for your domain например), то можно не парится и не вспоминать — а какой email я в прошлый раз отдавал — googleId для аккаунта будет один и тот же. Да и все сервисы, кто не отдает email ( твиттер) можно авторизовывать только таким способом. Опять же — креденшиалы без email не могут быть Primary ( для нас).
Ну вот как-то так — кратко непонятно и неподробно ;). Будут вопросы — пишите.
1. Ну, собственно в указанной мной схеме и есть данные, касающиеся пользователя на сайте :) В отличие от auth_data, который нужен для работы с провайдерами. Насчет email немного спорно, имхо. В конце концов, это может быть публичный email, который не жалко показать. Но, в целом, это уже мелочи, поле не сильно на что-то влияет.
Не соглашусь насчет «никакого главного логина». Откуда креденшиал знает, что он главный? И почему профиль об этом не догадывается? Мне кажется более логичной моя структура, хотя и это не сильно критично.
2. А чем Ваша схема отличается от моей? У меня точно также своя сущность (профиль) вынесена в отдельную таблицу (users), а креденшиалы отдельно (в auth_data).
Подтверждения почты? Зачем они нужны при входе через стороннюю службу?
3. Долгожитель нужен для напоминания. Возможность выбрать создание нового аккаунта никто не отменяет :)
4. Да, это нужная вещь. Внутренние IDшники я пока никуда не пристроил, а надо бы. Спасибо, записал в memory.
Разве что не соглашусь с тем, что креденшиалы без мыла не могут стать главными. Хотя бы потому, что может быть ситуация, когда емайл не отдается провайдером, а других привязанных нет. Тут просто становятся невозможными некоторые фичи, завязанные на емайл. Но требовать его от пользователя, я считаю, не стоит. Возможно, у Вас так получается из-за необходимости подтверждать регистрацию по мылу?
Не соглашусь насчет «никакого главного логина». Откуда креденшиал знает, что он главный? И почему профиль об этом не догадывается? Мне кажется более логичной моя структура, хотя и это не сильно критично.
2. А чем Ваша схема отличается от моей? У меня точно также своя сущность (профиль) вынесена в отдельную таблицу (users), а креденшиалы отдельно (в auth_data).
Подтверждения почты? Зачем они нужны при входе через стороннюю службу?
3. Долгожитель нужен для напоминания. Возможность выбрать создание нового аккаунта никто не отменяет :)
4. Да, это нужная вещь. Внутренние IDшники я пока никуда не пристроил, а надо бы. Спасибо, записал в memory.
Разве что не соглашусь с тем, что креденшиалы без мыла не могут стать главными. Хотя бы потому, что может быть ситуация, когда емайл не отдается провайдером, а других привязанных нет. Тут просто становятся невозможными некоторые фичи, завязанные на емайл. Но требовать его от пользователя, я считаю, не стоит. Возможно, у Вас так получается из-за необходимости подтверждать регистрацию по мылу?
1. Мы так и делали сначала, но потом добавили возможность смены email и получили проблемы с обновлениями 2 разных таблиц. Лишнее это
У креденшиала стоит флаг (у нас IsPrimaryEmail). Мы делали по принципу — первый главный, остальные зависимые. Если главный удаляется — следующий становится главным ( по CreateDate)
Главный нам на самом деле нужен только для определения email, куда слать информацию, а так — он не обязательно должен существовать, более того у нас все креденшиалы — равноправны.
2 особо ничем — зависимостей просто меньше и связности — проще рефакторить и понятно как управлять.
подтверждения почты только при регистрации через PlainPassword, в остальных случаях мы естественно доверяем провайдерам.
3.Напоминания чего? что пользователь уже у вас был? Этот долгожитель очень уязвим — ин-приват режим, очистка кукисов, другой браузер, другой компьютер — и все, нету Маклауда…
по поводу креденшиалов без мыла — не вопрос, просто у нас т.к. мыло критично — без мыла нельзя. В остальных случаях — на усмотрение.
У креденшиала стоит флаг (у нас IsPrimaryEmail). Мы делали по принципу — первый главный, остальные зависимые. Если главный удаляется — следующий становится главным ( по CreateDate)
Главный нам на самом деле нужен только для определения email, куда слать информацию, а так — он не обязательно должен существовать, более того у нас все креденшиалы — равноправны.
2 особо ничем — зависимостей просто меньше и связности — проще рефакторить и понятно как управлять.
подтверждения почты только при регистрации через PlainPassword, в остальных случаях мы естественно доверяем провайдерам.
3.Напоминания чего? что пользователь уже у вас был? Этот долгожитель очень уязвим — ин-приват режим, очистка кукисов, другой браузер, другой компьютер — и все, нету Маклауда…
по поводу креденшиалов без мыла — не вопрос, просто у нас т.к. мыло критично — без мыла нельзя. В остальных случаях — на усмотрение.
1. Понимаете, требовать от креденшиала email несколько неправильно. Если Твиттер/Гитхаб Вам не отдаст мыло, что будете делать? Ну и могут быть варианты, что пользователь не хочет использовать мыло креденшиала для получения информации с сайта (мало ли).
Опять же, если дать пользователю возможность поменять мыло, не в креденшиалс же его записывать!
2. Спорить не буду, может и у нас поменяется.
3. Долгожитель — это всего лишь помощник. Если он потеряется, то ничего страшного не происходит. Определить, существует ли этот пользователь в системе, мы можем еще и по емайлу. И не забываем спросить «может быть у Вас есть аккаунт на нашем сайте?».
Опять же, если дать пользователю возможность поменять мыло, не в креденшиалс же его записывать!
2. Спорить не буду, может и у нас поменяется.
3. Долгожитель — это всего лишь помощник. Если он потеряется, то ничего страшного не происходит. Определить, существует ли этот пользователь в системе, мы можем еще и по емайлу. И не забываем спросить «может быть у Вас есть аккаунт на нашем сайте?».
1. Хочет ввести руками — можно в PlainPassword запись. И она становится Primary.
Вы поймите что про мыло я говорю только применительно к своей задаче, нам мыло важно — мы его требуем. Если вам не важно — вы с такими провайдерами будете вынуждены работать по их внутренним Id (т.е. по п.4), как иначе вы отличите один твиттер акк от другого если нету мыла и не пользуетесь внутренним ID?
Мыло в данном случае это общий ID — он удобней чем индивидуальные service-specific, но не более…
PS другие провайдеры, которые не отдают мыло — пока просто не подключены, т.к. нету соответствующей инфраструктуры для затребования мыла у пользователя (те. вошел через твиттер — введи почту руками и провалидируй ее. Тут твиттер сам виноват.)
Вы поймите что про мыло я говорю только применительно к своей задаче, нам мыло важно — мы его требуем. Если вам не важно — вы с такими провайдерами будете вынуждены работать по их внутренним Id (т.е. по п.4), как иначе вы отличите один твиттер акк от другого если нету мыла и не пользуетесь внутренним ID?
Мыло в данном случае это общий ID — он удобней чем индивидуальные service-specific, но не более…
PS другие провайдеры, которые не отдают мыло — пока просто не подключены, т.к. нету соответствующей инфраструктуры для затребования мыла у пользователя (те. вошел через твиттер — введи почту руками и провалидируй ее. Тут твиттер сам виноват.)
UFO just landed and posted this here
Из своего опыта пришёл к тому, что таблицы аутентификации группировать как минимум по типу. Итого в своих проектах у меня:
users
auth_email
auth_openid
auth_twitter
auth_facebook
Считаю этот вариант более удачным и более нормализованным (у вас сущности всё таки разнородные хранятся в одной таблице)
users
auth_email
auth_openid
auth_twitter
auth_facebook
Считаю этот вариант более удачным и более нормализованным (у вас сущности всё таки разнородные хранятся в одной таблице)
Да, где-то раньше в обсуждениях уже видел Вашу схему. Всегда было интересно, ведь OpenID тоже данные по-разному отдает (насколько помню, Гугл возвращает реальные ФИО, если есть).
А для Github'а и Googl'а тоже отдельные таблички делать? А есть ведь еще и Mail.ru, Яндекс, LinkedIn и т.д.
Чем принципиально будут эти таблицы отличаться? Что есть такого в Твиттере, что надо обязательно сохранить, причем в отдельной таблице? Количество фолловеров, сразу оговорюсь, мне не интересно.
И зачем нужен auth_email?
А для Github'а и Googl'а тоже отдельные таблички делать? А есть ведь еще и Mail.ru, Яндекс, LinkedIn и т.д.
Чем принципиально будут эти таблицы отличаться? Что есть такого в Твиттере, что надо обязательно сохранить, причем в отдельной таблице? Количество фолловеров, сразу оговорюсь, мне не интересно.
И зачем нужен auth_email?
Если провайдеры отдают разный набор данных — то разделяем
auth_email — для аутентификации по почтовому адресу, соответственно :-) предполагаем, что у нас могут аутентифицироваться как по всяким openid, так и через обычную форму.
auth_email — для аутентификации по почтовому адресу, соответственно :-) предполагаем, что у нас могут аутентифицироваться как по всяким openid, так и через обычную форму.
А как по мне, так денормализованные таблицы — не есть что-то ужасное. А вообще, NoSQL для таких вещей отлично подходит.
Мне это показалось неудобно, во-первых, тупо напрягает количество однотипных по сути таблиц, во-вторых, считаю это ничем не обусловленной денормализацией (формально да, нормализовано, а вот практически — проще сериализовать «кастомные» поля провайдера, чем предусматривать под каждого таблицу — проще оформить единый для всех провайдеров интерфейс).
Ага. Мне сразу вспомнился пример из жизни — у нас на дипломе парень спроектировал БД для учета оргтехники. И там были отдельно таблицы для принтеров/компов/сканеров и т.д. Его хорошо помариновали вопросами на этот счет, ведь схема получается труднорасширяемая, совсем уж негибкая. Поэтому я сторонник унификации в подобных случаях.
А вот кстати в больших системах типа маркет.яндекс, ебей, амазон вроде как используется такой подход (1 общая таблица и N частных). Об этом можно судить по косвенным признакам: поиск и формы.
Вообще, если на сайте и другая инфа такого же рода, то проще воспользоваться NoSQL, но для одной аутентификации это вероятно будет излишеством, если другие сущности сайта хорошо ложатся на РСУБД.
Нужно сделать авторизацию по отпечаткам пальцев :)
Естественно для этого нужно специальный девайс
Естественно для этого нужно специальный девайс
Если раньше похищали куки, то теперь — пальцы?
UFO just landed and posted this here
Согласитесь, украсть пальцы намного проблематичней :)
А как быть с телефонами/планшетами? Ткнуть подушечкой пальца в глазок камеры, а потом запустить специальную программу для опознавания? :)
Кстати сами телефоны могут использоваться как самостоятельные средства авторизации, поскольку у них есть такие вещи, как пин-код, сим-карты, договор с оператором сотовой связи.
кстати, у меня есть некоторые мысли по поводу того как это можно реализовать в вебе:
см. ниже…
кстати, у меня есть некоторые мысли по поводу того как это можно реализовать в вебе:
см. ниже…
Уж очень специфично получается. Если есть несколько симок — объединяй. Зашел с компьютера — надо придумывать другой способ войти + опять объединяй аккаунты.
А если я с 3G-планшета захожу, который общий для всей семьи?
А если я с 3G-планшета захожу, который общий для всей семьи?
>> А если я с 3G-планшета захожу, который общий для всей семьи?
В таком случае, ваш продвинутый сынишка сможет использовать ваши куки, сохраненные пароли, а еще он может на этот планшет установить сниффер и кей-логгер, а еще он может в блокноте отредактировать файл hosts
ну, или, ваша менее продвинутая в этом плане племянница сможет сделать то же самое, заразив ваш планшет трояном, загруженным из вконтакта
В таком случае, ваш продвинутый сынишка сможет использовать ваши куки, сохраненные пароли, а еще он может на этот планшет установить сниффер и кей-логгер, а еще он может в блокноте отредактировать файл hosts
ну, или, ваша менее продвинутая в этом плане племянница сможет сделать то же самое, заразив ваш планшет трояном, загруженным из вконтакта
На сниффер или кейлогер, а также троян нужны, вроде как, админ. права. Плюс «антивирус»и файервол. На сохранённые пароли — мастер-пароль.
Круто! Значит тот, у кого есть админский пароль от планшета (после описанных выше действий) получает полный контроль над перепиской, а еще и на целой сетью аккаунтов в которых бедные родственники (не имеющие админских прав) имели неосторожность авторизоваться через опен-ид!!!
Странное у Вас представление о семье )))
Моему племяннику 11 лет.
На моем компе седьмая винда
Чтобы поиграть в гонялку/леталку/стрелялку нужны админские права
за неделю племянник умудляется успеть поиграть в 30 (тридцать) разных новых игрушек!
представляете, какой был бы для меня напряг каждый раз отрываться от своих дел (приезжать с работы), чтобы проверить очередную игрульку племянника, инсталлировать ее, удалить все предыдущие, в которые он уже поиграл…
мне гораздо прощее поставить рядышком для себя любимого еще одну такую же винду (на втором разделе) и выбирать нужную при загрузке
На моем компе седьмая винда
Чтобы поиграть в гонялку/леталку/стрелялку нужны админские права
за неделю племянник умудляется успеть поиграть в 30 (тридцать) разных новых игрушек!
представляете, какой был бы для меня напряг каждый раз отрываться от своих дел (приезжать с работы), чтобы проверить очередную игрульку племянника, инсталлировать ее, удалить все предыдущие, в которые он уже поиграл…
мне гораздо прощее поставить рядышком для себя любимого еще одну такую же винду (на втором разделе) и выбирать нужную при загрузке
Вы не поверите, но у кого админский пароль, тот имеет доступ ко всему на компьютере!
Современные сканнеры настолько слабы что сканнеры отпечатков в ноутах — больше дыра в безопасности чем защита. Отпечаток распечатывается на бумаге, а в некоторых случаях можно и по «мусору» аутентифицироваться. Соответствующие статьи легко гуглятся.
Прочтя заголовок, я ожидал нечто большее:
На многие сайты, требующие авторизации я захожу с мобильного телефона,
при этом использую браузер Опера-Мини:
> Кликнули по кнопке «войти через», ввели свой OpenID
> или просто нажали на картинку провайдера.
> Подтвердили/доказали провайдеру, что Вы — это Вы.
такой способ там точно не прокатит!
Зато можно проделать такой финт:
Нажать ссылку «Войти через телефон».
<a href="tel:88003330890">8-800-333-0890</a>
при нажатии на ссылку телефон пытается дозвониться по указанному номеру
дождавшись одного длинного гудка пользователь вешает трубку
(либо после третьего гудка модем на стороне сервера сам сервера вешает трубку)
после этого пользователь нажимает кнопку «Войти», (либо на кнопку «Другой номер» если номер сервера был занят).
в ответ сервер просит ввести последние 2 или 4 цифры своего телефона (в зависимости от числа звонков, поступивших в последние 30-40 секунд)
если все в порядке — входим в закрытую часть сайта
если останутся какие-то сомнения, то сервер может попросить ввести еще например три цифры (в начале номера).
На многие сайты, требующие авторизации я захожу с мобильного телефона,
при этом использую браузер Опера-Мини:
> Кликнули по кнопке «войти через», ввели свой OpenID
> или просто нажали на картинку провайдера.
> Подтвердили/доказали провайдеру, что Вы — это Вы.
такой способ там точно не прокатит!
Зато можно проделать такой финт:
Нажать ссылку «Войти через телефон».
<a href="tel:88003330890">8-800-333-0890</a>
при нажатии на ссылку телефон пытается дозвониться по указанному номеру
дождавшись одного длинного гудка пользователь вешает трубку
(либо после третьего гудка модем на стороне сервера сам сервера вешает трубку)
после этого пользователь нажимает кнопку «Войти», (либо на кнопку «Другой номер» если номер сервера был занят).
в ответ сервер просит ввести последние 2 или 4 цифры своего телефона (в зависимости от числа звонков, поступивших в последние 30-40 секунд)
если все в порядке — входим в закрытую часть сайта
если останутся какие-то сомнения, то сервер может попросить ввести еще например три цифры (в начале номера).
Хм, пошли совсем уже интересные вещи ))
1. Почему не прокатит? Вы же по ссылкам как-то щелкаете?
2. А что это было с телефоном? :) О чем мне скажет Ваш номер сотового?
1. Почему не прокатит? Вы же по ссылкам как-то щелкаете?
2. А что это было с телефоном? :) О чем мне скажет Ваш номер сотового?
>> Почему не прокатит? Вы же по ссылкам как-то щелкаете?
Не прокатит хотя бы потому, что в опере-мини (по крайней мере в версии java2me) нет никакой возможности просмотреть адрес гиперссылки по которой вас направят с сайта.
То есть, вас запросто могут направить на фишинговый сайт, очень похожий по внешнему виду на страницу авторизации вашего любимого опен-ид провайдера, и стыбрить пароль для вашего аккаунта (читай от целой кучи аккаунтов в смежных сетях, на которых вы регистрировались по опен-ид).
Не прокатит хотя бы потому, что в опере-мини (по крайней мере в версии java2me) нет никакой возможности просмотреть адрес гиперссылки по которой вас направят с сайта.
То есть, вас запросто могут направить на фишинговый сайт, очень похожий по внешнему виду на страницу авторизации вашего любимого опен-ид провайдера, и стыбрить пароль для вашего аккаунта (читай от целой кучи аккаунтов в смежных сетях, на которых вы регистрировались по опен-ид).
Примерно понял, о чем Вы. Есть ведь более простые схемы — указываем номер телефона на сайте, в ответ приходит СМСка с кодом подтверждения (4-6 цифр или букаф).
Подтверждение через СМС — хуже не придумаешь!
Потенциальный злоумышленник может иметь
длинный список телефонов своих врагов
и не менее длинный список таких подобных сервисов
по котороым сервисы из второго списка будут регулярно в 3 часа ночи
отправлять сообщения жертвам из первого списка.
Если же злоумышленник просто мелкий хулиган,
то список номер один он может сгенерировать рандомно.
Потенциальный злоумышленник может иметь
длинный список телефонов своих врагов
и не менее длинный список таких подобных сервисов
по котороым сервисы из второго списка будут регулярно в 3 часа ночи
отправлять сообщения жертвам из первого списка.
Если же злоумышленник просто мелкий хулиган,
то список номер один он может сгенерировать рандомно.
Но ведь согласитесь, что специально обрабатывать телефонные звонки — это как-то чересчур для авторизации на обычном сайте?
Уж, поверьте мне — это гораздо проще habrahabr.ru/qa/7323/, чем использовать тот же самый опен-ид консумер на своем сайте.
Вводим номер телефона и ждём его соответствия на АОНе сервера-авторизатора…
По-моему это годится только для сайтов с высокими требованиями к безопасности и только при добровольном выборе такого способа пользователем. Например, пассворд менеджер у меня куда более секурен, чем телефон — прочитать смску на моём телефоне имеют возможность куда большее число знакомых мне людей, чем взломать менеджер, подобрать мастер-пароль или установить кейлоггер или сниффер.
Это небезопасно, скажете Вы, и вероятно будете правы. Поэтому при генерации токена сохраняем также различную информацию о клиенте (IP, User-Agent и т.д. — выбор есть).
В подавляющем большинстве случаев для «расшаренных» компов это информация будет совпадать — мы не можем определить человека, который сидит за компом. Потому, как минимум, нужно предусмотреть поле неявное «чужой компьютер» или явное «запомнить меня», а ещё лучше через этот токен хранить провайдера и ид у него и проводить повторную аутентификацию. Если пользователь залогинен у провайдера, то она пройдёт прозрачно (иногда не совсем, но не сложно в любом случае) для него, если нет — залогинится может с тем же ид, может с другим. Если с другим, то старый токен удаляем и генерим новый, если с тем же — обновляем старый (а можно и не обновлять).
Необходимость примари аккаунта со стороны пользователя не понял.
Я вообще тему не понял: какой смысл обсуждать какие-то таблицы, когда не продумана логика.
Для авторизации через соцсети использую Loginza API
Sign up to leave a comment.
Статья-размышление про вход на сайт без пароля