«Плавающий» пароль

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

Цель – создание простой и надежной системы идентификации пользователя с использованием постоянно меняющегося пароля.

Одним из основных условий однозначного подтверждения личности или ее полномочий в системе является качественный пароль, который должен обладать следующими характеристиками:
  1. высокой сложностью;
  2. периодической сменностью;
  3. надежностью хранения.

Все эти требования можно выполнить, применив описанную ниже схему.

Пример 1. Генерация пароля на стороне пользователя с периодичностью 1 год:


2014 год — текущий пароль: 12@i4Wednesday
2015 год — текущий пароль: 12@i4Thursday
2016 год — текущий пароль: 12@i4Friday

где:
  • 12@i4 – «базовая» часть, придумывается самим пользователем;
  • Wednesday, Thursday, Friday – «плавающая» часть, которая соответствует названию первого дня недели текущего года.

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

Пример 2. Генерация пароля с периодичностью 1 день (усложним алгоритм):


Дата: 12.04.14 — текущий пароль: 12@i4Wednesday335704
Дата: 13.04.14 — текущий пароль: 12@i4Thursday334152
Дата: 14.04.14 — текущий пароль: 12@i4Friday334152

где:
  • 12@i4 – «базовая» часть;
  • Wednesday, Thursday, Friday – «плавающая»» часть, которая соответствует названию первого дня недели текущего года;
  • 335704, 334152, 334152 – официальный курс австралийского доллара на предыдущую дату без запятой.

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

Возможное развитие системы плавающего пароля:
  • отказ от базовой части пароля;
  • отказ от логина.

Преимущества «плавающего» пароля:
  1. относительная простота реализации;
  2. пользователь не обязан помнить пароль, достаточно знать механизм его генерации;
  3. гарантированная периодическая сменность;
  4. средняя/высокая надежность.

Дополнительные ограничения:
  1. необходимость реализации дополнительной службы на стороне сервера;
  2. возможно, потребуется создание источника сводной информации для генерации пароля (страницы/сайта/службы), помогающего пользователю самостоятельно генерировать пароль, а не искать данные по всему Интернету. Например: начальная страница экрана на которой отображена погода в различных городах, курсы валют, календарь, суммы кассовых сборов по кинофильмам и т.д.

Потенциальные риски:
  1. сложный пользовательский интерфейс конструктора для создания «плавающего» пароля на стороне сервера;
  2. дополнительная вычислительная нагрузка на сервер.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 14

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

    «12@i4Wednesday» буквально провоцирует злоумышленника в случае неудачи попробовать другие дни недели =)
      0
      И вообще тогда лучше не 12@i4Wednesday а 12@i44 так менее очевидно
      +11
      Если это публичный сервис, с общедоступным конструктором (т.е. алгоритм злоумышленнику известен), то в чем проявляется повышенная защищенность пароля? Сложнее подобрать перебором? Нет. Невозможно восстановить пароль по хэшу? Нет.

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

      Есть стойкое ощущение «ложной безопасности». Когда мы вроде все сильно усложнили, но секьюрности не добавилось. Наоборот уменьшилась, т.к. вводя срок действия пароля, скажем, месяц мы вынуждаем пользователя в пароле хоть что-то менять (ну хотя бы одну цифру в конце дописать qwerty1 -> qwerty2 -> ...), а тут вроде как все защищено, но стоит злоумышленнику хотя бы один раз утащить ваш пароль, он, обратившись к вашему списку источников данных в конструкторе (публичный же сервис?), моментально восстановит его сигнатуру и будет пользоваться бесконечно. А мы будем сидеть и радоваться какой у нас секьюрный пароль.
        +3
        Только если пользователь сам создает такой генератор. Если он будет предлагаться сервисом, то надежнее не будет.
          0
          Еще один недостаток — перестанут работать сервисы сохранения паролей и автоматической аутентификации (в том числе и чисто браузерные фичи).

          upd. И периодической сменностью тут, ИМХО, не пахнет. В качестве пароля теперь выступает не фиксированный набор символов, а некий алгоритм его формирования. Он-то не будет меняться, и, узнай его злоумышленник из древнего потерянного email, все проблемы «не менял пароль пять лет» тут же всплывут.
            +1
            Если алгоритм не будет сверхуникальным для кажного пользователя и параметров генерации over9000, то идея — ниочем. Достаточно создать несколько десятков акков, проанализировать варианты… и вот вам готовые словари для добавления к топ100 самых популярных паролей.
              +1
              Эта идея имеет смысл для чего-то самодельного и нестандартного. Т.е. вы сами пишете какую-то программу или сервис, предназначенный для исключительно личного использования, и ваша цель — повысить секретность. Тогда часть пароля можно запомнить или хранить в криптоконтейнере, вторую часть — рассчитывать, используя обычный калькулятор на основе общедоступных данных типа дня недели или официального курса австралийского доллара. Смысл в том что рассчитывать желательно в уме, так как тут секретным является алгоритм расчета. Для публичных сервисов идея разумеется не годится.
              +1
              Всё-таки пароли уже изжили себя как надёжное средство аутентификации. Ведь чем круче пароль, тем больше вероятность того, что бухгалтерша его на листочке запишет и на обратную сторону клавиатуры приклеит. Нельзя в этом плане на пользователей полагаться и требовать от них этого тоже нельзя. Поэтому, мне кажется, пора уже заканчивать выдумывать сложные схемы генерации и вводить одноразовые пароли и двухфакторную аутентификацию.
                0
                Если вы уже подключаете сервер таким образом и заставляете пользователя держать в голове правила генерации новых паролей, то тогда можно тупо использовать двухфакторную авторизацию: любой пароль, выбираемый пользователем, + при каждой аутентификации происходит проверка на обладание секретом (секретным ключом, с помощью которого генерируется одноразовый пароль для текущей минуты; или телефоном, на который прилетает СМС от сервера с текущим одноразовым паролем).
                  +1
                  Уже разбирал эту тему 2 года назад habrahabr.ru/post/136580/
                    +2
                    Как решается проблема различия серверного времени и времени пользователя?
                      0
                      А как вы идентифицируете пользователя по паролю? И зачем вам знать, с каким именно паролем зашел пользователей, или у вас их (паролей) много для каждого?
                      Я вижу смысл таких алгоритмов только в случае, если пользователь в корпоративке и админу неохото возиться с постоянно забывающимися паролями. Они помогут пользователю запомнить свой пароль. Но для этого уже придуманы более эффективные вещи. А для публичных сервисов вообще нефиг придумывать такие алгоритмы, пусть пользователь сам думает.
                        0
                        Доморощенный TOTP?
                          0
                          Пароль будет действительно «Плавающим» только если не знаешь алгоритм генерации, что не совсем правильно в криптографии.

                          Only users with full accounts can post comments. Log in, please.