Привет, меня зовут Артём. Я без малого четверть века работаю в IT. За это время у меня как-то сама собой сформировалась так называемая «аура тестировщика». Зачастую мне не приходится прилагать каких бы то ни было усилий, чтобы натыкаться на недоработки, ошибки проектирования и вполне себе конкретные баги в различных продуктах. Это касается не только IT но и повседневных вещей.
Сегодня я хочу рассказать о своём видении причин недопустимости повсеместного SSO с завязкой на номер телефона. Рассказать я хочу не с точки зрения безопасности (атаки с угоном номера и т. д.), а на примере банальной ситуации с которой я столкнулся лично и которую из-за ошибки проектирования невозможно решить никаким приемлемым способом.
Много лет пользовался услугами известной сети аптек Еаптека. Все было хорошо и удобно. Удобный профиль история заказов и рекомендации. Но тут случилось страшное... Их купил Sber и стал бездумно тащить к ним свою экосистему. В том числе и пресловутый SberID.
Одним прекрасным днём я как обычно захожу в свой профиль на Еаптеке по номеру телефона, но вместо привычного окошка авторизации выскакивает авторизация в SberID. Окей... думаю я и авторизуюсь. Но дальше испытываю некоторый диссонанс. В моей учётной записи не мои персональные данные. Не мои, но понятные мне. При этом история заказов и адреса доставки мои. Начинаю изучать вопрос и пытать техподдержку Еаптеки. Выясняю, что теперь персональные данные в профиле берутся исключительно из SberID. Потому что они теперь Sberapteka. Но это пол беды. Чтобы отредактировать данные в профиле теперь надо идти в отделение Sber’а. Дескать «где открывали карточку туда и идите (тм)». Потому что функционал редактирования данных профиля эффективные менеджеры благополучно решили выпилить. Но вот заковыка в том, что у меня нет карточки Sber’а и лично я не являюсь клиентом Sber’a. Но при этом клиентом Sber’а является мой близкий родственник не имеющий телефона. И персональные данные в профиле Еаптеки теперь именно этого родственника, просто потому, что у него указан мой номер в качестве контактного.
Ни одного приемлемого варианта решения этой проблемы мне предложить так и не смогли. Либо «покупайте другой номер» (я пользуюсь этим номером больше 20 лет и менять его естественно не намерен), либо меняйте данные в базе Sber’а, что по понятным причинам дичь несусветная. Казалось бы ситуация не стоит выеденного яйца, но из-за применения SSO она по сути не разрешима ни одним адекватным образом.
А всего-то стоило оставить возможность авторизации старым способом помимо SberID. Или дать возможность привязать / авторизовываться по SberID, не затирая молча уже имеющиеся в профиле персональные данные.
Даже безотносительно моего, не самого очевидного с точки зрения проектирования, пользовательского сценария есть ведь ещё банальная история с перепродажей номеров операторами...
Комментарии (64)
Myz17
03.12.2024 15:32SSO совершенно непричём, вы сами дали свой номер "левому" человеку для привязки его аккаунта. Если при этом номер был подтверждён, например кодом из СМС, то виноваты вы. Если его просто привязали без всякого подтверждения (сомнительно), то просчёт Сбера.
linux_art Автор
03.12.2024 15:32Во-первых не левому. Во-вторых не давал, а регистрировал человека по генеральной доверенности.
Jsxii
03.12.2024 15:32С точки зрения сбера всё валидно, номер == клиент. Косяк в том, что номер представителя должен быть отдельным полем. Но, опять же, вопрос не в SSO, а в схеме данных и в редкости такого кейса, как у вас. Я, как и многие, зашёл не за этим.
linux_art Автор
03.12.2024 15:32Все было валидно пока они две разных учётки не слили в одну :)
Jsxii
03.12.2024 15:32Нет :)
Поле_номер_клиента: <номер клиента> -- правильно.
Поле_номер_клиента: <номер представителя клиента> -- неправильно.
Косяк со стороны сбера, никто не спорит же. Но косяк со стороны архитектора данных, а не со стороны интеграции двух систем.
inkelyad
03.12.2024 15:32Но косяк со стороны архитектора данных, а не со стороны интеграции двух систем.
Нет, косяк интеграции. В смысле - что ее вообще в таком виде сделали. Потому что в процессе должны были сказать "у нас архитектура данных приведет к накладкам, поэтому таким образом сливать не надо"
И, кстати, можно ответ на мой вопрос ниже - а как правильно надо было?
Jsxii
03.12.2024 15:32У интеграторов, наверняка, было тз вида "1. по номеру телефона теперь не проверяем сами, а получаем ответ от внешней системы. 2. Данные пользователя берём не у себя, а от внешней системы", ну и внешняя система, естественно, "чёрный ящик". Сталкивались.
А про правильно - КМК, просто выбор нужного аккаунта из списка аккаунтов, в которых ты клиент или представитель, после входа.
inkelyad
03.12.2024 15:322. Данные пользователя берём не у себя, а от внешней системы"
Вывод - косяк интеграции и интеграторов. Потому что "а наши данные перенести в эту внешнюю систему?" И как-то слить? А разрешить конфликты? Почему вы, вообще, решили, что учетка с именем 1234567890 у нас и с тем же именем у вас - это учетка одного и того же человека?
linux_art Автор
03.12.2024 15:32Следствие порочной практики идентифицировать человека по номеру телефона...
Jsxii
03.12.2024 15:32Данные от внешней системы, по статье, это фио и номер телефона. При валидности обеих записей они идентичны - сливать нечего, конфликты отсутствуют.
А учетки с одинаковым именем - учетки одного человека, т.к. имя - номер телефона. Если обе учетки валидны, опять же.
Исправление невалидности данных в "черном ящике" - вне ЗО интеграторов, обычно.
linux_art Автор
03.12.2024 15:32ФИО, номер телефона и дата рождения (по крайней мере это те данные что я вижу подменённые). Возможно еще что-то.
inkelyad
03.12.2024 15:32А учетки с одинаковым именем - учетки одного человека, т.к. имя - номер телефона. Если обе учетки валидны, опять же.
Да с чего бы? Номер/имя учетке в магазине - означает, во многих случаях, всего лишь, что его можно использовать для входа в сайт. Вон, на тумбочке такой валяется - "семейный", которым все члены семьи для покупок используют. Тут оно вообще даже не "человека".
И сливать такую учетку с учеткой банка ну так себе идея.
Jsxii
03.12.2024 15:32Ну, в первую очередь - так себе идея использовать "семейный" телефон для банка. А если не использовать - то и вопрос не стоит.
В контексте статьи - коллизия как раз в случае учетки на номере, отличном от используемого для сберИд.
linux_art Автор
03.12.2024 15:32В статье как раз учетка на номере используемом для сбер ID. Просто учетка СберID и учетка с которой её объединили - это разные по смыслу учётки разных людей. Суть истории в том, что эффективные менеджеры решили "все же пользуются сбербанком" и не стали думать что могут быть иные сценарии.
linux_art Автор
03.12.2024 15:32А самое неприятное, что если бы на этом номере не было бы учетки в сбере - то по сути для пользования аптекой создаётся учётная запись в банке. Это уже совсем больная тема на мой вкус...
Jsxii
03.12.2024 15:32Вполне логично с точки зрения сбера - интеграция покупаемого в свою экосистему.
inkelyad
03.12.2024 15:32Ну, в первую очередь - так себе идея использовать "семейный" телефон для банка. А если не использовать - то и вопрос не стоит.
Разумеется, его никто и не использует. Но вопрос стоит. Залогинится я в банк. Или что там еще SberID исползует. Потом пошел на сайт магазина. Сработало SSO. И я оказался в учетке с тем именем, которая мне ну совершенно не нужна и мне надо перелогиниваться, чтобы попасть в ту, с которой я обычно покупки делаю.
В статье, конечно, ситуация другая, но пример показывает, что само по себе SSO - мешать может. И имеет смысл учетки для разных сервисов так и оставлять отдельными.
Jsxii
03.12.2024 15:32Неудобно, но плата за использование нескольких учёток одного ССО. У меня с гуглем, яндексом и другими так, ну а что поделаешь?
(Кроме нескольких юзеров в браузере :) )
inkelyad
03.12.2024 15:32Неудобно, но плата за использование нескольких учёток одного ССО.
Так вопрос как про то, почему это SSO и несколько учеток понадобилось принудительно делать. Ну работало бы все как работало. А кому плюшек хочется - можно было бы отдельно попросить "разреши, чтобы авторизация вон того сервиса тоже действовала".
Как у кучи сайтов есть свои учетные записи, куда можно попасть как через локальные артефакты доступа, так и через учетку гугла, если слинкуешь.
Или даже у самого Сбербанка yoomoney есть. Куда можно их родной локальной учеткой, SberID-ом, VK ID-ом, госулугами. И ничего, все отлично живет.
linux_art Автор
03.12.2024 15:32Ну кстати у гугла как раз SSO очень неплохо сделано. Он предлагает выбрать учётку, которую использовать при логине через него.
Jsxii
03.12.2024 15:32У гугла сначала выбор учётки из тех, которые он помнит, потом уже вход в неё.
Про сбер речь о том, что надо бы так - сначала вход, потом выбор аккаунта.
linux_art Автор
03.12.2024 15:32Хотел бы плюсануть, но так скрутили карму, что не могу уже голосовать :))
MrAlone
03.12.2024 15:32Заголовок не соответствует статье. SSO вообще не об этом. Так и пишите - в Сбере проблемы с их авторизацией/профилями, не водите людей в заблуждение по поводу того, что их ждёт в статье.
linux_art Автор
03.12.2024 15:32SSO в данном случае при чём. Смысл в том, что если его тащить во все сервисы бездумно - могут быть неожиданные коллизии.
MrAlone
03.12.2024 15:32Не может быть коллизий, если всё правильно сделано. Номера телефонов/мэйлы должны быть авторизованы. Указал номер телефона? Будь добр код из смс. Нет? И опять же, это вообще не про SSO!
linux_art Автор
03.12.2024 15:32Есть две системы. Есть два различных пользователя. В рамках каждой системы данные пользователь + номер валидны. Но при введении SSO в двух системах получаем коллизию. Почему в данной схеме SSO не при чём?
MrAlone
03.12.2024 15:32Это прикол такой? В двух разных системах при использовании SSO должны быть одни и те же данные, так как используется один источник данных. Это аксиома! Если у Сбер во время объединения двух разных баз случилось, что:
а) они в одной базе не проверяли валидность телефонов/мэйлов/ещё чего-то
б) после объединения случились коллизии
то это полностью косяк Сбера, но никак не принципов SSO.inkelyad
03.12.2024 15:32В двух разных системах при использовании SSO должны быть одни и те же данные, так как используется один источник данных.
Статья как бы про то, что не надо было вводить SSO. Ничего бы страшного не случилось, если бы это и дальше были две разные учетки.
А проблема возникла от того, что его ввели.
Jsxii
03.12.2024 15:32Проблема не в том что его ввели, а в том, что в одной из систем были некоректные данные. В сбере слили две сущности - клиент и представитель клиента, оттуда и коллизия.
linux_art Автор
03.12.2024 15:32Так речь именно об этом. Не о том что SSO плохо само по себе. А о том, что его внедряют бездумно :)
DarthVictor
03.12.2024 15:32Это не Сбер "криво" слил. Это сама идея соединять данные банковских счетов и аптечных или скажем продуктовых заказов бредовая. Продукты / пиццу / суши / нерецептурные лекарства могут заказывать на один аккаунт в семье, а счета у всех быть свои. И наоборот, счета бывают общие на семью, а заказы косметики у жены идти отдельно.
outlingo
03.12.2024 15:32Почему в данной схеме SSO не при чём?
Потому, что объединение учетных записей было сделано по неправильному ключу. Это проблема не SSO, а исключительно в квалификации и добросовестности того, того проектировал и внедрял SSO в соединяемых сервисах. "Убивает не оружие, убивают придурки с автоматами - как вон те двое" (c)
linux_art Автор
03.12.2024 15:32Так об этом и речь. Именно по этому заголовок содержит слова "бездумно использовать SSO" :)
inkelyad
03.12.2024 15:32SSO вообще не об этом.
Об этом. Они слили два разных профиля, в разных сервисах с разными данными в один исключительно по совпадению одного признака. Привычка при покупке сервиса так делать, страшно раздражает - этим вообще все подряд занимаются, не только Сбербанк.
alecx
03.12.2024 15:32Тащите все в SSO. Аунтификацией должны заниматься специализированные под это сервисы. А то, что кто то сделал слияние сервисов через Ж, никак ни подход, ни технологии под капотом не дискредитируют.
И да, заголовок статьи вводит в заблуждение. Когда пишут «SSO» на тех. ресурсе, о сбере я подумаю в последнюю очередь.
linux_art Автор
03.12.2024 15:32Сбер тут как пример из того, что мне попалось на днях буквально. Проблема может быть у кого угодно если SSO внедрять бездумно / не просчитав возможные пользовательские сценарии.
inkelyad
03.12.2024 15:32Тащите все в SSO. Аунтификацией должны заниматься специализированные под это сервисы.
Специализированные сервисы не равно SSO. Можно на одном сервисе авторизировать username@sberbank и username@eapteka. И никак эти учетки не смешивать. И поэтому оно SSO не будет (в каждый сайт надо логинится отдельно, хоть и через один и тот же сервис).
то, что кто то сделал слияние сервисов через Ж
А вот, кстати, как в данном случае сделать правильно? Чтобы желаемое SSO осталось? Т.е. логинимся в Сбербанк (используя юзернейм-он-же-номер-телефона 1234567890) , переходим на сайт Еаптек-и и... в какую учетку попадаем?
BaJIepoH
03.12.2024 15:32Я знаю случаи, когда людям с разными ФИО, но картами одного банка..и сделавшим покупки в плюс-минус одно время - приходили чужие электронные чеки)) И это "особенность системы", и не зависит от банка.
inkelyad
03.12.2024 15:32минус одно время - приходили чужие электронные чеки
Электронные чеки явно были задуманы, чтобы анонимизировать покупателя - в них данных о счете/номере карты, откуда платили, нет. Сама кассовая машинка же все это знает и даже на одном куске бумаги часто печатает. Но в ОФД чек идет без этого.
Это уже потом банки наловчились сопоставлять, какой чек чей по косвенным данным. Что, понятно, приводит к ошибкам.
S1re10k_4f99
03.12.2024 15:32Тоже самое у Сбера и с мегамаркетом, номер поменять не возможно, историю заказов и прочее перенести на другой номер тоже не возможно, за то свои конченые СМС они присылают на номер.
В поддержке операторы уверяют, что всё можно сделать, создают обращение на которое потом мне приходит ответ вида: "мы закрыли ваше обращение, потому что поменять номер нету технической возможности". А заказ получать как бы по коду из СМС, отправленному на бывший мой номер, который сейчас не доступен мне, так-как я закрыл договор давно.
И всё дело опять же в сбер id, в моём случае из него не подтягивает новый номер, похоже потому что "нет технической возможности".
linux_art Автор
03.12.2024 15:32О... это уже проблема посерьёзнее чем в описанной мной ситуации. Если в моём случае это больше похоже на неудобство, то в вашем это уже по сути уязвимость.
pvsam
03.12.2024 15:32Ну везде рассчитано на правильное простое использование. Твой телефон, твоя учётка, твои данные. И не возникает проблем. Согласитесь, что у Вас ситуация "кривая", такие и приводят к неразберихе. Извините, может не стоило вообще писать сюда, но за 25 лет ИТ я насмотрелся на это сполна.
linux_art Автор
03.12.2024 15:32Мой сценарий - не самый очевидный. Факт. Но ведь ещё можно придумать кучу сценариев вида попал на пол года / год в больницу, оператор перепродал номер телефона по причине бездействия. И понеслась... И там последствия уже ощутимо больнее могут быть.
assad77
03.12.2024 15:32Проблема в том, что у вас нет сбер ид. И я думаю когда это все проектировали, то предполагали, что будет конверсия клиентов еаптеки в клиентов Сбера. Так что то что с вами случилось и было задумано.
linux_art Автор
03.12.2024 15:32То что оно так и задумано это как раз понятно. Речь о том, что это бездумно и криво сделано. Есть куча способов сделать это нормально.
assad77
03.12.2024 15:32Но у вас же сейчас самый простой выход получить карту Сбера и сбер ид, так ведь? Если на принцип не идти? Если так, то очень даже правильно, с их стороны.
linux_art Автор
03.12.2024 15:32На этот номер есть карта сбера и она не на моё имя :) Так что даже если гипотетически я решу получить карту сбера - это не решит коллизию и не избавит меня от проблемы.
jason_hunter
03.12.2024 15:32Вот такая же ситуация с Yandex книгами, когда-то это был классный сервис bookmate, после того как их выкупили Yandex с их дебильным yandexpasportoм, они просто выпилили старую систему входа, и теперь я не могу войти в свою учётную запись с компьютера на телефоне сохранилась сессия, но на компе нужно войти с начала в Yandex pasport, а я старый пароль от Yandex помню, а вот пинкод от двухфакторной мать её защиты нет, и восстановить не удаётся никак и я теперь в душе не ...знаю как войти ни в Yandex ни в bookmate, а заводить новую учетку это заново собирать библиотеку, вообще не охота
inkelyad
03.12.2024 15:32Вот такая же ситуация с Yandex книгами, когда-то это был классный сервис bookmate, после того как их выкупили Yandex с их дебильным yandexpasportoм, они просто выпилили старую систему входа
Они слегка одумались. 'иностранный' bookmate.com по старым атрибутам вроде бы стал пускать.
А вот books.yandex.ru и ru.bookmate.com - те да, яндексовская учетка.
scome
В эту же копилку. Для ипотеки мне нужно было открыть эскроу счет в Сбере. Лет 5-6 назад был их клиентом и имел карту, сейчас же нет ничего - ни карт, ни приложения, ни личного кабинета.
Раньше для открытия такого счета было достаточно зайти в офис банка с паспортом и потратить 15 минут времени.
Сейчас:
Прийти в офис
Обновить личные данные (они устарели)
Выслушать все вариации доступных карт
Оформить карту
Установить личный кабинет на свой айфон через их учетку айклауда
Зайти в личный кабинет и подписать наконец документы.
linux_art Автор
Охъ... жесть какая...
salnicoff
А послать на три буквы копро-менеджера и подписать документы на бумаге своей рукой теперь уж нельзя? Просто очень хочется оценить уровень деградации Сберкассы...
linux_art Автор
Кстати интересно, а если вообще не иметь телефона, как такой сценарий должен выглядеть? :-/ Между 4 и 5 шагом добавится шаг "Купите телефон и оформите сим карту"? :-/
Billander
На самом деле там много чего такого и это незаконно, просто что бы убедить нужно самому знать материал как юрист, а упоротые менеджеры будут стоять на своем даже если полиция приедет.