Необходимо выбрать логин: что это, как создать и где лучше хранить

Содержание

Выбираем логин на Яндекс.Почте / Хабр

Много лет назад я зарегистрировал себе несколько трех- и четырехсимвольных адресов на Яндекс.Почте. Они оказались очень удобными, потому что их легко писать и диктовать, особенно вместе с доменом ya.ru.

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

В статье вы найдете все, что вряд ли хотели знать, но теперь имеете отличную возможность узнать, о формате и количестве логинов Яндекса, а также датасет, с помощью которого сможете попробовать разобраться с «6-q» аномалией (у меня не получилось).

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

Подсчет количества логинов

Валидность и неразличимость

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

длина логина от 1 до 30 символов
допустимые символы: буква английского алфавита в любом регистре, арабская цифра, точка и тире
первым символом может быть только буква
последним символом может быть либо цифра, либо буква
две точки и два тире подряд, а также сочетания точек и тире (.-, -.) запрещены

Соответствующие ошибки, которые возвращает валидатор

login.long
login.prohibitedsymbols
login.startswithdot
login.startswithhyphen
login.startswithdigit
login.endwithdot
login.endswithhyphen
login.doubleddot
login.doubledhyphen
login.hyphendot
login.dothyphen

Кроме того, не делается различий между точкой и тире, а сам логин является регистронезависимым. Это написано на странице помощи при регистрации аккаунта.

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

Общая формула

Введем обозначения

где — латинский алфавит, — арабские цифры.

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

Обозначим— количество валидных логинов длины . Согласно условиям,

Начиная с в логине допускаются точки. Посмотрим на возможные расположения точек в логине (в скобках перечислены позиции точек):

1 x         ()
2 xx        ()
3 x•x       (2)
4 x•xx      (2)
4 xx•x      (3)
5 x•xxx     (2)
5 xx•xx     (3)
5 xxx•x     (4)
5 x•x•x     (2, 4)
6 x•xxxx    (2)
...
6 x•x•xx    (2, 4)
6 xx•x•x    (3, 5)
...
8 x•x•x•xx  (2, 4, 6)
8 x•x•xx•x  (2, 4, 7)
8 x•xx•x•x  (2, 5, 7)
8 xx•x•x•x  (3, 5, 7)
. ..

Заметим, что в логине длины может содержаться не более точек. Таким образом, здесь и ниже считаем, что

Также отсюда следует, что для размещения точек, длина логина должна удовлетворять неравенству

Обозначим — количество валидных логинов длины с точками. Пользуясь основными правилами комбинаторики, можно выписать следующее выражение

где — количество вариантов расположения точек в логине длины . В этом случае принимает вид

Под спойлером показано, что

Вывод выражения для P(n, m)

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

Заметим, что . Рассмотрим алгоритм генерации всех возможных конфигураций расположения точек в логине длины :

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

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

Посчитаем

Аналогично,

Пользуясь методом математической индукции покажем, что при

База индукции :

Переход: предположим, что

тогда

что и требовалось доказать. Здесь мы воспользовались свойством биномиальных коэффициентов Hockey-stick identity.

Тогда общее число валидных логинов определяется выражением

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

Генерация логинов и определение доступности

Краткое описание алгоритма:

сначала генерируются первый и последний символы согласно ограничениям
для средней части логина генерируются допустимые конфигурации расположения точек
для каждой из конфигураций точек в свободных местах проставляются числа и буквы

Реализация на Python тут (GitHub). На всякий случай прикладываю под спойлер

from math import ceil
L = 'abcdefghijklmnopqrstuvwxyz'
D = '0123456789'
S = '.'
def get_symbols(n):
  if n > 0:
    for i in L+D:
      g = get_symbols(n-1)
      for item in g:
        yield [i] + item
  else:
    yield []
def get_points_pos(n, m, shift=0):
  if m > 0 and n > 1 and m <= ceil(n/2):
    for i in range(1, n-2*m+1):
      g = get_points_pos(n-1-i, m-1, shift+i+1)
      for item in g:
        yield (i+shift,) + item
  else:
    yield ()
def get_logins_middle_part(n):
  if n > 2:
    for m in range(0, ceil(n/2)):
      for points_pos in get_points_pos(n,m):
        for symbols in get_symbols(n-m-2):
          yield ''. join([
            symbols.pop(0) if i not in points_pos else '.' 
            for i in range(1, n-1)
          ])
  else:
    yield ''
def get_logins(n):
  for first_symbol in L:
    if n > 1:
      for last_symbol in L+D:
        g = get_logins_middle_part(n)
        for item in g:
          yield first_symbol + item + last_symbol
    else:
      yield first_symbol
      
print(len(list(get_logins(4))))

Определение доступности сводится к генерации всех логинов и проверке каждого через POST-запрос. В итоге была собрана текстовая таблица с данными.

Результаты анализа доступности логинов

В качестве инструмента для работы с датасетом был выбран R (Tidyverse). Файл с данными и код для обработки можно найти в репозитории. Результаты анализа ниже.

Всего имеется 1 280 448 валидных четырехсимвольных логинов. Из них на момент проверки было свободно 213 895, то есть 16.7%.

Зависимость между доступностью логина и его символами

Это первое, что приходит в голову посмотреть:

Как читать: 92% для символа «a» означает, что среди всех логинов длины 4, содержащих символ «a», занято 92%Как читать: 97 на пересечении «а» и «b» означает, что среди всех логинов длины 4, содержащих комбинацию «ab», занято 97% (чем темнее, тем свободней)Как читать: 90 на пересечении «1» и «a» означает, что среди всех логинов длины 4, содержащих символ «a» на первой позиции, занято 90% (чем темнее, тем свободней)

Самый заметный и интересный факт — высокая доступность логинов, содержащих символы q и 6. Кроме этого, заняты почти все логины, содержащие точку. Но в целом создается впечатление, что зарегистрировать логин со своими инициалами или днем рождения по-прежнему можно.

Распределение логинов по форматам

Разобьем логины на группы по форматам. Например, к группе a.11 отнесем все логины, у которых на первом месте буква, на втором — точка, а на третьем и четвертом — цифры.

Распределение логинов по форматам

Формат  Свободно /   Всего     Доля
  a.11         1 /   2 600 ( 0.04%)
  a111       121 /  26 000 ( 0.47%)
  a.aa       157 /  17 576 ( 0.89%)
  aa.1        94 /   6 760 ( 1.39%)
  aa.a       269 /  17 576 ( 1.53%)
  aaaa     9 924 / 456 976 ( 2.17%)
  a.a1       244 /   6 760 ( 3.61%)
  a1.1        98 /   2 600 ( 3.77%)
  a1.a       274 /   6 760 ( 4.05%)
  aa11     2 909 /  67 600 ( 4.30%)
  a.1a       559 /   6 760 ( 8.27%)
  aaa1    37 969 / 175 760 (21.60%)
  a11a    19 769 /  67 600 (29.24%)
  a1aa    55 858 / 175 760 (31.78%)
  a1a1    22 589 /  67 600 (33.42%)
  aa1a    63 060 / 175 760 (35.88%)

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

Удобные логины

На этом этапе возникло желание определить понятие «удобного» логина и посмотреть, сколько из них остается свободными. В первую очередь установим дополнительные ограничения для таких логинов:

Перечислю буквы, которые, как мне кажется, не подходят для email:

i и l похожи друг на друга
o похожа на 0
q, j, w, e, r, y, u, g, h, c, v, s, z собеседник может не узнать или перепутать на слух (цэ как русская эс, и как русская е и тд)

Таким образом, «удобный» логин должен состоять из легкопроизносимых, узнаваемых на слух и однозначночитаемых букв t, p ,a, d, f, k, x, b, n, m. Заметим, что среди них есть только одна гласная буква. Таких логинов 10 000. Но среди них есть логины вида namp, anam, dpdb, которые сами по себе произносятся сложно. Красивое произношение, на мой взгляд, имеют логины вида ppdk, tpda, fdkx, mnpd, fdpa, и тп. Впрочем, эту тему развивать не имеет смысла, так как выбирать особо не из чего. Ниже приведен список всех свободных «удобных» логинов, всего 84 штуки:

bfpm btxb bxpm dnta 
dxkb dxkf dxna dxpn 
fdtp fmtm fmxt fnpt 
fnxp fpdm fpdx fpnf 
ftxn kbpx kkdx kmdp 
knxp knxt kpbf ktbp 
ktbx ktpx kxpb mbxf 
mfpx mpxf mtxp nbtd 
nbtm ndxt nfbp nffp 
nfpb nkbp nkdd nkdp 
npbn npxt nxbk nxkf 
nxkt pbfn pdtx pfnx 
pfxn pmxf pnkd pxfk 
pxpm pxtp pxxf tdxn 
tfkx tkmm ttxk txbf 
txkt txna txpb xbpf 
xdnp xdpn xfbp xfpd 
xfpn xfpt xkbf xkpn 
xmbf xnnp xpbb xpkf 
xpkt xpmf xpnp xptd 
xtba xtdm xtdp xtkt

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

Зависимость между доступностью логина и числами, которые он содержит

Можно разбить логины на группы согласно числам, которые они содержат. Например, aa11 содержит одно число 11. Логин a0a1 содержит числа 0 и 1 и войдет в соответствующие этим числам группы. Отдельно будем учитывать номера с ведущими нулями вида 01. Всего таких групп будет 1 110.

В 894 из них ни один логин уже не доступен для регистрации. Можно найти свободные адреса для 107 трехзначных номеров (для большинства номеров остался только 1 логин из 26, максимум 3). Статистику по двухзначным номерам можно увидеть на диаграмме с комбинациями символов. Доступность логинов с числами от 0 до 10 визуально аналогична диаграмме с доступностью по отдельным символам.

Трехзначные номера, четырехсимвольные логины с которыми еще доступны

028 032 048 052 065 073 
075 079 081 082 083 084 
092 152 165 207 236 259 
260 261 263 267 268 271 
276 283 295 296 299 304 
317 329 346 347 376 379 
392 396 425 439 462 470 
486 493 533 539 546 570 
581 582 584 594 596 602 
604 608 614 615 616 618 
622 624 627 629 630 634 
641 651 658 659 661 680 
681 682 685 687 692 699 
719 733 738 756 771 796 
804 805 806 807 812 817 
835 836 861 871 872 874 
879 883 886 894 914 927 
940 943 955 957 958

Группы занятых и свободных логинов, идущих подряд

Если отсортировать все логины в алфавитном порядке, то будет интересно посмотреть на группы непрерывно идущих друг за другом свободных и занятых адресов.

Количество таких групп примерно в 5.7 раз меньше, чем количество логинов. Самый большой непрерывный блок занятых логинов — 1 401 логин с fkzi по fm0e. Самая большая группа свободных логинов — 45 адресов с q6nf по q6on.

Напоследок отмечу, что отношение средних размеров свободных и занятых блоков равно отношению количества свободных и занятых логинов с точностью до 5 знака и составляет 0.20054

Заключение

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

Как выбрать логин и пароль?

Содержание:

Быстрая навигация по этой странице:

Как корабль назывешь, так он и поплывет, или выбираем имя
Выбираем пароль
Нет секретным вопросам

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

Как корабль назывешь, так он и поплывет, или выбираем имя

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

Анонимность против узнаваемости

Выбирая себе логин, подумайте над тем, чего бы вы хотели бы добиться — полной уникальность и узнаваемости, или, напротив, анонимности?

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

Если же у вас прямо противоположные цели, то нужно, наоборот, брать самые распространенные имена и никнеймы.

Безопасность

Как создать логин особенно надёжный. В основном, этот пункт актуален, если вы выбираете себе логин для админ-панели на своем сайте или на каком-нибудь блоге/форуме/сервисе, где всем пользователям показывается одно имя (например, Маша Петрова), а логинитесь вы при этом как masha_petrova.

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

Этого не случилось бы, если бы я задумался о безопасности при выборе логина. А именно, у меня стоял логин admin, и именно на него рассчитано большинство скриптов, занимающихся брутфорсом — перебором паролей.

Достаточно было бы выбрать другой логин — и перебор паролей уже был бы не страшен.

В этой связи, для админок нельзя выбирать такие имена, как admin, administrator или имена, совпадающие с названием либо доменом сайта.

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

Выбираем пароль

Как известно, пароли пользователей в базах данных хранятся в зашифрованном виде (обычно используется алгоритм MD5 и его модификации). Это значит, что если кто-то получит доступ к базе данных, то у него не будет вашего пароля, а будет последовательность символов — что-то наподобие 1a1dc91c907325c69271ddf0c944bc72 (приведенный пример — md-5 хэш от слова «pass»).

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

Таким образом, например, можно подобрать пароль к админке большинства блогов wordpress (имея хэш и если в самом блоге не использовано дополнительных методов защиты, чего практически никогда не бывает).

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

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

Вывод, который следует из этого — пароль должен быть как можно длиннее и включать в себя все возможные варианты символов. Как правило, рекомендуемая длина — от 12 символов, но здесь четкого правила не существует — никто не запрещает взять 11 символов или 20 символов — нужно соотносить значимость пароля, количество раз, которое вам придется набирать его в день, вероятность попытки его взлома.

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

Нет секретным вопросам

Секретные вопросы — это одна из уязвимостей, которую часто используют злоумышленники при взломе аккаунтов. Бывает, что человек выбрал сложный логин, еще более сложный пароль, но в качестве ответа на секретный вопрос указал реальную девичью фамилию матери, которая часто к тому же входит в топ-20 самых популярных фамилий России. Результат — аккаунт взломан.

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

Дизайн входа в приложение: выбор правильного варианта входа пользователя для вашего приложения —

Взвешивание вариантов дизайна входа в приложение

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

Разработчики могут выбирать из множества способов входа в систему. У каждого есть свои плюсы и минусы. Ниже мы перечисляем наиболее распространенные и передовые варианты входа в систему и взвешиваем их относительные достоинства.

Вход по паролю

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

Плюсы:

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

Регистрация учетной записи в приложении Smiling Mind

Еще один плюс заключается в регистрации. Как правило, пользователи должны указать действующий адрес электронной почты, с которого они нажимают ссылку для подтверждения. Некоторые могут рассматривать это как дополнительный барьер для входа, но это дает разработчикам подтвержденный адрес электронной почты. Разработчики могут использовать это как маркетинговый ход для платных услуг и будущих предложений. Поскольку поставщики услуг электронной почты становятся все более агрессивными в фильтрации спама, требование, чтобы пользователь открывал и действовал по электронной почте, также поможет вам в белом списке.

Минусы:

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

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

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

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

Вход через социальные сети и сторонние входы

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

Дизайн входа в мобильное приложение Hubspot UX (щелкните изображение, чтобы увеличить)

Плюсы:

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

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

Интерфейсы прикладного программирования (API), необходимые для доступа к таким платформам, как Facebook, Google, Apple или LinkedIn, в основном бесплатны. Некоторые взимают плату в зависимости от того, сколько данных необходимо. Еще одним плюсом является то, что вход через социальные сети очень удобен для мобильных устройств и идеально подходит для мира мультимедийных устройств с сенсорным экраном.

Минусы:

Но с большими данными приходит и большая ответственность. Использование социальных сетей обязывает разработчиков соблюдать требования GDPR. Они также должны ознакомиться с конкретной практикой каждой третьей стороны. Аналогичным образом, использование исключительно социальных сетей или сторонних логинов может оттолкнуть ваше приложение от постоянно растущего числа людей, которые не используют социальные сети из-за проблем с доверием.

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

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

Разработчики должны знать, что опция входа в стороннее приложение Apple для iOS — Sign In with Apple — является обязательной для приложений в Apple Store при определенных условиях. Любое приложение с Facebook, Google или любыми другими вариантами входа через социальные сети также должно предлагать вход через Apple, чтобы иметь право на продажу в Apple Store.

Вход через социальные сети и регистрация

Коротко о сравнении:

Быстрее и проще для пользователей, чем регистрация и вход по электронной почте
Повышение конверсии при регистрации
Упрощенная регистрация учетной записи UX
Потенциальные обязательства по соблюдению GDPR
Использование сторонних технологий
Меньшее количество адресов электронной почты пользователей в маркетинговых целях Lyft и WhatsApp, мобильный вход имеет смысл в мире, который стал мобильным. Это простой и эффективный способ быстрой аутентификации пользователей без необходимости использования длинных регистрационных форм или форм входа.
Вход в Uber UX
Плюсы:
Вход по мобильному номеру имеет явное преимущество перед электронной почтой и паролем, потому что телефон, как правило, является гораздо более уникальным идентификатором. Пользователи могут — и делают — настроить несколько адресов электронной почты, но логин, для которого требуется подтвержденный номер телефона, сложнее, но не невозможно злоупотребить.
Одним из самых больших преимуществ является то, что вход по мобильному номеру не требует от пользователя запоминать пароль. Пока они могут получать SMS, они всегда смогут войти в систему.
Если данные о геолокации необходимы для работы вашего приложения, удобно использовать вход с мобильного телефона.
Минусы:
Номера телефонов меняются. Люди уходят с работы, отрасли или страны и меняют свои цифры. Если это единственный метод входа в систему, миграция учетных записей становится более сложной, чем должна быть. Адрес электронной почты или учетная запись в социальной сети — это более постоянные приспособления, которые пользователи, как правило, сохраняют, несмотря на изменение обстоятельств.
По этим причинам мобильный вход в систему, скорее всего, найдет наилучшее применение в качестве вторичного или дополнительного параметра безопасности. Но он не совсем герметичен. Одна из проблем с мобильным входом в систему заключается в том, что иногда хакерам удавалось нарушить этот уровень безопасности, перенаправив службу на другой телефон и перехватив SMS-сообщения для получения доступа к учетным записям.
Многофакторная проверка подлинности
Многофакторная проверка подлинности (MFA) требует более одного отдельного метода входа для успешного доступа. Чаще всего это происходит в форме двухфакторной аутентификации, также известной как 2FA. Примером 2FA является случай, когда пользователь входит на платформу с адресом электронной почты и должен перекрестно подтвердить личность с помощью кода, отправленного на второе устройство, такое как мобильный телефон.
Поток многофакторной авторизации
Плюсы:
Основным преимуществом MFA является безопасность. Второй уровень безопасности обеспечивает защиту от слабых или скомпрометированных паролей, а также дополнительную защиту в случае потери устройства.
В зависимости от рынка, который вы хотите обслуживать, соответствие требованиям MFA может подпадать под действие Директивы ЕС о платежных услугах 2 (PSD2) для британских и европейских компаний. Статья 4 (30) предписывает строгой аутентификации клиентов (SCA) к декабрю 2020 года для продавцов электронной коммерции.
Это привело к принятию различных методов MFA, таких как отправка ссылки или временного PIN-кода по SMS или push-уведомлений, предупреждающих пользователей об активности учетной записи. Сторонние приложения для проверки подлинности также можно использовать для предоставления временных паролей или QR-кодов, которые предоставляют доступ к платформам.
Другие доступные MFA: сетчатка глаза, биометрия или отпечаток пальца; однако некоторые считают стоимость этих методов непомерно высокой.
Минусы:
Часто для MFA требуется второе устройство. Это может создать проблему для некоторых пользователей, если они заблокированы из-за потерянного, неуместного или сломанного устройства.
Взаимодействие с пользователем может усложниться из-за дополнительных факторов MFA. Помимо дополнительного времени и шагов, связанных с этим методом входа, восстановление зависит от второго поставщика удостоверений. Однако если пользователь забудет или потеряет доступ к этому второму поставщику удостоверений, он может вообще потерять доступ к платформе в случае атаки или подозрительной активности.
Существуют уязвимости, которые следует учитывать при использовании MFA в отношении второго уровня идентификации. Устройства, аппаратные токены могут быть украдены вместе с другими взломами, которые воспроизводят такие факторы, как голос, глаза и отпечатки пальцев. Для более сложной безопасности рекомендуется чередование нескольких различных факторов.
Хотя MFA обеспечивает дополнительный уровень защиты, как это обычно делается, это не надежное решение.
Как оформить страницу регистрации UX
Существует бесконечное количество способов оформления страницы регистрации и регистрации учетной записи приложения. Тем не менее, большинство приложений, как правило, придерживаются нескольких общих логинов и регистрируют стандарты пользовательского интерфейса. Вот некоторые моменты, которые следует учитывать при разработке экрана входа в приложение:
Электронное письмо с паролем для входа и регистрации UX
- Попросите пользователя подтвердить свой пароль (введите его дважды), чтобы уменьшить вероятность опечаток.
- Не забудьте попросить пользователя согласиться с вашими условиями
- Не забудьте функцию восстановления/сброса пароля
- Прервите длинную регистрацию/формы регистрации в несколько шагов
- Вместо того, чтобы требовать от пользователя запомнить пароль , вы можете просто отправить им одноразовую ссылку для входа по электронной почте каждый раз, когда им нужно войти в систему
- Оставьте место для клавиатуры, в идеале без необходимости перемещать предметы на экране, чтобы разместить ее.
- Не запрашивайте информацию о пользователе, которая вам абсолютно не нужна. Чем больше полей вы включите, тем ниже вероятность завершения
Регистрация учетной записи приложения Puntshare
Вход через социальные сети и сторонние интерфейсы UX
- Придерживайтесь основ, таких как Facebook, Google и Apple. Включение тонны непонятных опций будет стоить больше, чем оно того стоит изначально.
- Убедитесь, что вход в систему действительно осуществляется одним щелчком мыши (плюс вход в социальную сеть, если требуется). Включение входа через социальные сети направлено на снижение входных барьеров и повышение конверсии.
- Убедитесь, что пользователь автоматически перенаправляет пользователя на вход через социальную сеть, если он пытается войти по электронной почте вместо использования адреса электронной почты для входа в социальную сеть.
- При использовании сторонних параметров входа в систему очень важно поддерживать приложение в актуальном состоянии с помощью последних версий сторонних SDK для входа.
Мобильный вход и регистрация UX
- Убедитесь, что пользователь может повторно отправить SMS с PIN-кодом, если он его не получил
- Когда пользователь вводит последнюю цифру своего PIN-кода, вы можете автоматически подтвердить PIN-код, не запрашивая пользователя чтобы нажать кнопку «Далее» или «Продолжить».
- Убедитесь, что вы корректно обрабатываете коды стран и форматирование номеров мобильных телефонов, чтобы пользователю не приходилось гадать, как ему следует вводить свой номер телефона.
Дизайн входа в приложение Snackr ux
Многофакторный вход и регистрация UX
- Убедитесь, что сложность входа пропорциональна требованиям безопасности приложения. Требование PIN-кода, номера мобильного телефона, отпечатка пальца и аутентификации в стороннем приложении только для входа в приложение для создания заметок является излишним, и пользователи этого не потерпят.
- Предоставьте варианты восстановления для пользователей, которые переключают номера телефонов или забывают PIN-коды и т. д.
Выбор правильного метода входа в приложение зависит от нескольких факторов, характерных для вашей ниши, и от того, какую пользовательскую информацию вы планируете хранить или использовать. Более строгая безопасность может привести к более сложному взаимодействию с пользователем. Тем не менее, с соблюдением законодательства для всех требований по обработке платежей, некоторая комбинация вышеуказанных методов, вероятно, станет очень знакомой для большинства пользователей.
Нужно ли заставлять пользователей входить в систему?
Большую часть времени в блоге Auth0 мы говорим о входе в систему и регистрации, как будто очевидно, что все это сделают. Однако просить пользователей подписаться на ваш продукт не всегда легко. Некоторые люди беспокоятся о трениях, которые это вызывает, или о том, необходимо ли это для их продукта. Иногда из-за беспокойства по поводу обеспечения безопасности входа в систему запрос на регистрацию кажется более проблематичным, чем полное отсутствие запроса на регистрацию.
Как эксперты по регистрации и входу в систему, мы думали и сталкивались с вариантами использования за вариантами использования и обнаружили, что просьба к пользователям войти в систему почти всегда приносит пользу как бизнесу, так и пользователю. От безопасности до корпоративных проблем и поддержки клиентов, возможность входа в систему для улучшения вашего продукта — это то, что вы должны серьезно учитывать при создании и развитии своего бизнеса.
Это не исчерпывающий список всех причин, по которым вы должны просить пользователей войти в систему. Скорее, это обзор того, почему вы должны предлагать пользователям создавать учетные записи, почему вход в систему является взаимовыгодным, и очень немногие исключения, когда это не так. т дело.
Основы входа в систему
Независимо от того, используете ли вы имя пользователя и пароль или сложную многофакторную настройку, основные принципы входа остаются неизменными:
- Для входа в систему требуется регистрация для вашего продукта. Это означает, что есть только определенная группа пользователей, которым разрешен доступ к вашему продукту, хотя вход в систему не обязательно означает, что ваш продукт является «эксклюзивным». Например, любой может подписаться на игровое приложение, но платить клиентам только за аналитическое программное обеспечение.
- Логин создает учетную запись пользователя. Это означает, что пользователи однозначно идентифицируются в вашем продукте.
  - Для пользователей это часто означает, что они могут просматривать свой собственный профиль и информацию, изменять эту информацию и отслеживать идентификаторы своей учетной записи (изображение профиля, имя пользователя и т. д.)
  - Для компаний это означает, что данные пользователя могут быть привязаны к индивидуальному профилю. Этот профиль, вероятно, содержит всю информацию, которую вводит пользователь, а также может быть домом для любых других данных, которые компания решит прикрепить к этому профилю (например, тип устройства).
Безопасность и подотчетность
Учетные записи пользователей
Предоставление пользователю возможности создать учетную запись и войти в систему обеспечивает ему безопасность и контроль над его информацией.
Когда пользователь может видеть информацию, которую он предоставил вам в своем профиле пользователя, он понимает, что вы используете для связи с ним. Поэтому, когда пользователь получает, например, рекламное электронное письмо, он знает, откуда оно пришло. Они могут просто зайти в свои настройки, изменить свою электронную почту, проверить и отписаться от рекламных акций.
В противном случае пользователям может быть интересно, что случилось с адресом электронной почты, который они использовали для совершения покупки в приложении.
При желании они также могут изменить настройки конфиденциальности, обновить личную информацию и удалить свои проекты и профиль, не оставляя вопросов о том, что висит в вашем продукте.
Для ваших пользователей: Учетные записи помогают пользователям управлять своими данными.
Для вашей компании: Предоставление пользователям возможности просматривать и контролировать свои данные укрепляет доверие пользователей, что помогает повысить прозрачность информации, хранящейся в компании (особенно когда никто не читает условия и положения).
Корпоративные проблемы
Логин также невероятно важен для корпоративных клиентов по ряду причин.
- Безопасность. Корпоративные клиенты хотят, чтобы все в их системе было защищено, что означает предоставление регистрации, которая соответствует требованиям корпоративного входа.
- Управление ролями. Поскольку доступ к вашему продукту требуется сотням сотрудников, корпоративные клиенты хотят иметь возможность назначать роли и управлять ими. Главе отдела маркетинга может потребоваться административный доступ к аналитической платформе, но продавцу точно не нужен.
- Отслеживание данных сотрудников. Когда у каждого сотрудника есть учетная запись, легко отслеживать, кто вносит изменения, кто над какими проектами работает и как команды работают вместе. Корпоративные компании особенно заинтересованы в том, чтобы отслеживать, кто чем занимается, поэтому все, что происходит в будущем, будь то ошибка или победа, может быть правильно объяснено.
Для ваших пользователей: Учетные записи и логин помогают корпоративным клиентам доверять вашему продукту и интегрировать его со своими существующими инструментами.
Для вашей компании: Если вы планируете работать с корпоративными клиентами, вам потребуется реализовать функцию входа в систему. По правде говоря, мы только коснулись того, что корпоративные клиенты ожидают от своего входа в систему — для вас может быть решающим, если у вас нет входа в систему, соответствующего их потребностям, независимо от вашего продукта.
Клиентский опыт
Вход в систему может быть мощным инструментом для формирования клиентского опыта. Помимо простого вовлечения кого-либо в продукт, вход в систему может быть способом управления данными о пользователе и помочь ему получить максимальную отдачу от вашего продукта.
- Улучшенная поддержка. Когда клиент обращается в службу поддержки с проблемой, представьте, если бы он мог получить приветливую, индивидуальную поддержку — например, если бы его приветствовали по имени, и ему не нужно было бы отвечать на длинный список вопросов об истории их продуктов или о том, какие устройства они используют. Если у вас нет учетной записи пользователя для хранения таких данных, как имя и тип устройства, это просто невозможно. Ведение внутреннего профиля каждого клиента через ваш логин — отличный способ персонализировать вашу поддержку.
- Обслуживание мира с множеством устройств. Если нет входа в систему, у пользователя нет простого способа использовать ваш продукт на нескольких устройствах, не начав заново. Даже если вы представляете собой простое игровое приложение, предоставление людям возможности сохранять свой прогресс и доступ с разных устройств может поддерживать привычное взаимодействие пользователей с вашим продуктом.
- Предлагая социальный компонент . Независимо от того, хотят ли люди поделиться своими любимыми песнями, фотографиями и видео, своими рекордами или данными о продажах, любой социальный компонент или компонент обмена в продукте может выиграть от входа в систему. Предоставляя людям учетную запись и профиль при входе в систему, вы упрощаете для кого-то поиск нужного человека для связи, будь то для бизнеса или дружбы. Без входа в систему поиск и обмен вещами с избранной группой затруднен.
Если вы все еще беспокоитесь о том, что вход в систему может стать барьером между потенциальными пользователями и вашим продуктом, подумайте о том, чтобы предложить такие варианты, как вход без пароля и вход через социальные сети, которые требуют от пользователей меньшего количества запросов, чем традиционная или многофакторная аутентификация.
Исключения из правила
Итак, мы рассмотрели множество причин, по которым использование логина является хорошей идеей. Но всегда есть исключения из правил — вот три самых больших.
- Демонстрации продукта: Хотя некоторые компании требуют создания учетной записи для доступа к демонстрации продукта, большинству требуется только адрес электронной почты, а иногда и вообще ничего. Когда вы даете людям возможность опробовать ваш продукт, не всегда имеет смысл заставлять их проходить процесс создания учетной записи, особенно если это короткая демонстрация, а не бесплатная пробная версия. Если пользователь просто хочет узнать, о чем вы, иногда лучше дать ему немного времени на изучение без необходимости регистрироваться.
- Оформление заказа: Пользователи, совершающие покупки в Интернете, с опаской относятся к регистрации, чтобы оформить заказ, особенно если они новые покупатели и еще не уверены, нравится ли им ваш продукт. Отмена обязательной регистрации и разрешение гостевого оформления заказа может повысить конверсию при оформлении заказа. Ритейлер одежды ASOS вдвое сократил количество отказов, добавив гостевую кассу.
- Мобильный : Кажется, что почти каждое мобильное приложение требует входа в систему, за исключением приложений погоды и нескольких игр. Одна из причин этого может заключаться в том, что загрузка является реальным источником трений на пути к использованию мобильного приложения — после того, как вы столкнулись с проблемой фактического получения приложения из магазина приложений, время, необходимое для регистрации, становится незначительным. . Тем не менее, если вы предлагаете простую мобильную услугу без каких-либо социальных функций, возможно, стоит пропустить дополнительный шаг.
Эти исключения приходят с глубоким пониманием вашего продукта и того, как пользователи перемещаются по нему. Когда вход в систему становится серьезным источником трений, имеет смысл удалить его. Возьмем «сдачу в размере 300 миллионов долларов», которую произвела одна крупная компания электронной коммерции.
Они не рассматривали свой запрос пользователей на вход как проблему, но их пользователи точно видели. Во время интервью они сказали, что необходимость входа в систему перед оформлением заказа была огромной неприятностью, и когда они посмотрели на свою аналитику, они увидели 160 000 запросов на забытый пароль в день — очевидно, что вход в систему мешал их клиентам в оформлении заказа, а не помогал им.
Когда они отказались от входа в систему, они сразу же увидели огромный рост продаж.
Итак, если вы думаете об отказе от входа в систему, проведите некоторую исследовательскую работу и посмотрите, что сбивает людей с толку, когда они пытаются использовать ваш продукт. Если это похоже на логин, возможно, стоит попытаться удалить его и посмотреть, как идут дела.
Пусть ваш логин покажет путь
Если вы пытаетесь решить, добавлять ли функцию входа в свой продукт, не думайте, что все входы в систему — это поля для имени пользователя и пароля, которые только создает трения для ваших пользователей. Когда вы на самом деле думаете о том, что вход в систему может сделать для вас, становится ясно, что есть множество преимуществ для вас обоих.