Comments 128
Привязка к времени будет странна тем, что времени много и оно разное. Можно смотреть время дома у юзера, на сервере или же там, откуда аккаунт регистрировался.
Об этом можно «договориться» с сервером при регистрации или смене пароля — в общем, это не проблема.
Да и вообще: все гениальное — просто. У вас есть идея, но юзабилити этой идеи слишком «сложное» для пользователей.
Вы учтите одно, психологи говорят: 60% людей вообще не дружит с головой.
А теперь представьте как вы их «напрягете».
Вы учтите одно, психологи говорят: 60% людей вообще не дружит с головой.
А теперь представьте как вы их «напрягете».
Правильно ли я понимаю, что в качестве пароля вы предлагаете использовать общедоступную информацию, обработанную заранее известным способом?
Информация, которая будет входить в динамическую часть трудно назвать общедоступной.
То, что использует пользователь в динамической части знает лишь он и почтовый сервер.
Например, никто не знает, в каком месте у меня стоит время в пароле, а может там не время, а день недели указан? А может у меня и нет динамической части в пароле?
Все это обговаривается на этапе регистрации или смены пароля.
Нет шаблона, все индивидуально.
То, что использует пользователь в динамической части знает лишь он и почтовый сервер.
Например, никто не знает, в каком месте у меня стоит время в пароле, а может там не время, а день недели указан? А может у меня и нет динамической части в пароле?
Все это обговаривается на этапе регистрации или смены пароля.
Нет шаблона, все индивидуально.
Поскольку пользователи бывают очень ленивыми, то большинство из них не будут делать сложную динамическую часть (а, значит, теряется смысл всей идеи). +Обычному пользователю сложно объяснить, как написать «шаблон» своего пароля.
Эта идея не для всех пользователей, а лишь для тех, кто захочет воспользоваться динамической частью пароля.
Обращаемся к мат. части. Психологи уже давно вывели, что более 60% не дружат с башкой совсем и еще 20% — дружат на уровне эмоций.
Оставшиеся 20% — не приемлимое правило, слишком большой процент отказов.
Оставшиеся 20% — не приемлимое правило, слишком большой процент отказов.
Я помню — правило 80/20.
Динамический пароль не является обязательным — он только для тех, кто хочет его использовать.
У меня была мысль, что пароль при входе в аккаунт может быть не просто постоянным набором символов. Значения элементов этого набора могут изменяться с течением времени и при совершении каких-то событий, имеющихся в списке динамического пароля.
Динамический пароль не является обязательным — он только для тех, кто хочет его использовать.
У меня была мысль, что пароль при входе в аккаунт может быть не просто постоянным набором символов. Значения элементов этого набора могут изменяться с течением времени и при совершении каких-то событий, имеющихся в списке динамического пароля.
На какое исследование психологов (?) вы ссылаетесь, не поделитесь ли ссылкой на источники?
Насколько я понял автора, способов создания «динамического» пароля очень много. И, после регистрации, пользователю будет предложено выбрать, скажем, один из трех доступных способов (во-первых, чтобы пользователю было легче запомнить; во-вторых, чтобы не раскрывать список всех возможных способов злоумышленникам).
Зачем такие сложности?
Стойкость такого пароля равна стойкости обычного статического. Знаешь алгоритм — знаешь пароль. А запомнить его в разы сложнее.
К перебору он может быть даже менее стоек, так как тяжело использовать специальные символы, а «динамическая часть» может случайно оказаться тривиальной.
Стойкость такого пароля равна стойкости обычного статического. Знаешь алгоритм — знаешь пароль. А запомнить его в разы сложнее.
К перебору он может быть даже менее стоек, так как тяжело использовать специальные символы, а «динамическая часть» может случайно оказаться тривиальной.
Можно же использовать сложную статическую часть, и не сложную динамическую — тогда подобрать пароль за определенный промежуток времени будет невозможно, если злоумышленник конечно не узнает по какой маске создавался пароль. Вобщем данная технология, при правильном применении, была бы очень интересна для определенных задач
Сложной статической части будет недостаточно?
Да и создание такого пароля сопряжено с гораздо большими сложностями — нужно городить какие-то конструкторы паролей.
Да и создание такого пароля сопряжено с гораздо большими сложностями — нужно городить какие-то конструкторы паролей.
Согласен.
Я не понимаю фразу «тогда подобрать пароль за определенный промежуток времени будет невозможно».
То, что пароль чуть-чуть меняется во времени мешает перебору не так уж и серьёзно. Какая разница, который из паролей подберёт злодей? Важно, что на какое-то время он получит доступ к аккаунту.
Да и от подсматривания таким образом сгенерированные пароли защищают слабо, так как за несколько «подсматриваний» уже можно будет с немалой вероятностью угадать алгоритм.
Другими словами, стойкость повышается чуть-чуть, а сложность — очень существенно. Раз так, то эффективнее использовать столь же сложное, но гораздо более повышающее стойкость решение (коих хватает). Или надо придумать, как в этом подходе упростить организацию, не потеряв прирост прочности.
То, что пароль чуть-чуть меняется во времени мешает перебору не так уж и серьёзно. Какая разница, который из паролей подберёт злодей? Важно, что на какое-то время он получит доступ к аккаунту.
Да и от подсматривания таким образом сгенерированные пароли защищают слабо, так как за несколько «подсматриваний» уже можно будет с немалой вероятностью угадать алгоритм.
Другими словами, стойкость повышается чуть-чуть, а сложность — очень существенно. Раз так, то эффективнее использовать столь же сложное, но гораздо более повышающее стойкость решение (коих хватает). Или надо придумать, как в этом подходе упростить организацию, не потеряв прирост прочности.
А в чем проблема злоумышленнику, «украв» этот динамический пароль, переделать его в соответствии с текущим временем/другими параметрами? В алгоритме изменения пароля, всё равно должно быть что-то (хоть сам алгоритм, или еще один пароль), что знает только пользователь.
хорошая идея, но сложная. для юзеров.
ведь пароли и блондинки вводят, а вы им прелагаете помнить еще и про время…
но вообще ввести такую усиленную защиту как опцию — было бы не лишним.
НО большинство будут использовать минуты, чтобы не путаться с часовыми поясами. а значит смысл доп.симполов отпадёт.
ведь пароли и блондинки вводят, а вы им прелагаете помнить еще и про время…
но вообще ввести такую усиленную защиту как опцию — было бы не лишним.
НО большинство будут использовать минуты, чтобы не путаться с часовыми поясами. а значит смысл доп.симполов отпадёт.
флешки-ключи, всякие аутентификаторы, смски, приходящие для подтверждения транзакций — чем не тоже самое?
заранее скажу — без техники можно, но муторно, сложно и врядли актуально.
СМС-ки сложны тем, что нужен телефон, связь с оператором, время и лишние телодвижения.
Флешки может и удобны, но их нужно носить с собой.
Флешки может и удобны, но их нужно носить с собой.
это всегда альтернатива — либо мы пользуемся техникой (кто-как, а со своим музыкомобилем даже в душе не расстаюсь), либо мы что-то делаем вручную. проще и безопасней 5 рандомных цифирок с тлф набить, чем пытаться запомнить алгоритм пароля, который, не дай боже, кто-нибудь подберет/взломает/просечет.
Привязка к физическим предметам, которые отчуждаемы против воли владельца (потерял/украли).
Совсем недавно столкнулся — хотел купить телефон взаменпрое утраченного, заплатив из Qiwi кошелька. А там отключение подтверждения через СМС. Пришлось переться к метро, восстанавливать симку и клянчить у соседей телефон на 5 минут, чтобы получить код. Хотя хотел по другому — сначала телефон купить, потом симку восстановить.
Совсем недавно столкнулся — хотел купить телефон взамен
Подбор это не усложнит. Если мы будем перебирать пароли не последовательно, а случайно (для ускорения можно, например, после 10к попыток брать случайный и продолжать с него), то никакие изменения не повлияют на ожидание времени перебора (хотя конечно при неизменном пароле при последовательном переборе есть гарантированное ограничение сверху).
Не совсем.
В обычном случае для каждого следующего пароля вероятность угадывания увеличивается.
В случае если пасс меняется — для каждой попытки одна и та же маленькая вероятность угадать.
В обычном случае для каждого следующего пароля вероятность угадывания увеличивается.
В случае если пасс меняется — для каждой попытки одна и та же маленькая вероятность угадать.
Если всего существует N возможных паролей, то за a*N попыток вероятность угадать будет экспоненциально близка к a (для a <= 1, конечно).
А то, что за время подбора достаточно сложного пароля он изменился разве не повысит степень надежности пароля?
И разве нормальные сайты позволяют производить подбор паролей?
И разве нормальные сайты позволяют производить подбор паролей?
Если пробовать случайные пароли, а не все подряд — то не повысит. Ибо вероятность успеха каждой попытки будет одна и та же, вне зависимости от того, сменился пароль или нет. И успех каждой попытки не зависит от результата остальных.
А сама возможность подбора в данном случае не обсуждается. Её не упоминал автор статьи — он лишь сказал, что динамическая генерация пароля затруднит подбор. Да, затруднит (стандартный метод полного перебора не пройдет), но не очень сильно.
А сама возможность подбора в данном случае не обсуждается. Её не упоминал автор статьи — он лишь сказал, что динамическая генерация пароля затруднит подбор. Да, затруднит (стандартный метод полного перебора не пройдет), но не очень сильно.
Тут есть небольшой прикол. Если тыкаться случайными комбинациями, а пароль после каждой попытки (промежутка времени) меняется, то получится так, что брутфорсер уже «прошел» некий набор X, а уже после этого пароль на него поменялся. То есть подбор будет почти бесконечными.
Вероятность успеха одинакова для каждый попытки только если брутфорсер не будет запоминать уже введенные пароли. А если их исключать из подбора, то будет ситуация, описанная мной выше и пароль подобран не будет вообще.
Вероятность успеха одинакова для каждый попытки только если брутфорсер не будет запоминать уже введенные пароли. А если их исключать из подбора, то будет ситуация, описанная мной выше и пароль подобран не будет вообще.
Пароль изменился, а его сложность — нет. Вы привели сколько? С полтора десятка паттернов. Учитывая что юзер вряд ли будет использовать больше трех (запоминанием шаблонов и их порядка — сродни запоминанию пароля) то задача весьма простая. Тем более, что каждый шаблон — это несколько символов (то есть длинный пароль в данном случае не означает сложность и чем шаблоны длинее, не гарантирует их сложность взлома). Идея в целом интересная, мне кажется она требует доработки, пока не слишком жизнеспособна
Подбором не занимался, но может вы и правы.
Все же верно сказали, плохая идея.
С точки зрения защиты информации — вы добавляете к паролю совершенно общеизвестную часть, что никак не влияет на сложность перебора пароля, разве что помешает пользоваться уже готовыми брутфорсерами (пока в них не добавят этот функционал).
С точки зрения пользователя — увеличивается сложность набора пароля (без увеличения его стойкости, повторюсь). Это может быть критично для мобильных устройств к примеру; пока вы набираете первую часть изменится минута (или президент).
С точки зрения архитектора серверной части — хранить динамическую часть в хешированном виде не представляется возможным. Конечно всегда можно использовать что-то вроде sha1(sha1(static_part) + dynamic_part()), но в базе будут все так же записаны sha1(static_part), что при угоне базы не повлияет на сложность расшифровки.
С точки зрения защиты информации — вы добавляете к паролю совершенно общеизвестную часть, что никак не влияет на сложность перебора пароля, разве что помешает пользоваться уже готовыми брутфорсерами (пока в них не добавят этот функционал).
С точки зрения пользователя — увеличивается сложность набора пароля (без увеличения его стойкости, повторюсь). Это может быть критично для мобильных устройств к примеру; пока вы набираете первую часть изменится минута (или президент).
С точки зрения архитектора серверной части — хранить динамическую часть в хешированном виде не представляется возможным. Конечно всегда можно использовать что-то вроде sha1(sha1(static_part) + dynamic_part()), но в базе будут все так же записаны sha1(static_part), что при угоне базы не повлияет на сложность расшифровки.
Это не совсем общеизвестная часть. Нет строгого правила, что на определенном месте будет стоять время.
Там может быть что угодно.
Насчет хранения динамической части в хешированном виде не знаю, может вы и правы.
Там может быть что угодно.
Насчет хранения динамической части в хешированном виде не знаю, может вы и правы.
Что вы все прицепились ОБЩЕИЗВЕСТНА ОБЩЕИЗВЕСТНА! Говорят же правило можно самому придумать. Сделаю вот например имя попугая inokentii + (День недели+3)*2 + round(year/2) и что тут общеизвестно?
Я например Пин код от карт банковских зашифрованно пишу сзади карты и совершенно не боюсь
Я например Пин код от карт банковских зашифрованно пишу сзади карты и совершенно не боюсь
Получается вы хотите хранить пароль на сервере чуть ли не в открытом виде.
Украл БД сайта — получил доступы всех пользователей, т.к. алгоритм шифровки паролей известен всем
Украл БД сайта — получил доступы всех пользователей, т.к. алгоритм шифровки паролей известен всем
Идея не очень. Разве что пользователь сам выбирает способ формирования открытой части пароля, т.н. Security by Obscurity.
Гораздо интереснее что-нибудь типа одноразовых шифроблокнотов, все жду, когда их гугл будет присылать мне домой. Или передавать в условленном месте?;-)
Гораздо интереснее что-нибудь типа одноразовых шифроблокнотов, все жду, когда их гугл будет присылать мне домой. Или передавать в условленном месте?;-)
Когда я хочу зайти на какой-то сайт, то ввести логин-пароль для меня дело нескольких секунд. И мне это нравится. Если же мне для этого потребуется зайти на какой-то сайт с погодой в каком-то городе, правильно преобразовать эти данные (вспомнить как именно нужно вводить эту погоду в пароле), вспомнить статическую часть пароля, вспомнить как именно их комбинировать, то это затянется на несколько минут. И это плохо. К тому же сейчас брутфорсом взломать пароли довольно сложно (имеется ввиду, что необходимо затратить гораздо больше усилий чем будет получено выгоды).
Только не аудентификации, а аутентификации. Так будет правильно.
То что вы сказали реализовано давно
Вот например
Видел на практике. У каждого сотредника пароль и брелок, на брелке цифры, меняются каждую минуту. Алгоритм каждого зашит ещё и на сервере. Логинятся по тройке, имя, пароль, ключ с брелка. Брелок устроен так что даже имею последовательность выданных им кодом не удастся узнать что будет следующим, т.к. там скорее всего применена криптографически стойкая хеш функция.
Вот например
Видел на практике. У каждого сотредника пароль и брелок, на брелке цифры, меняются каждую минуту. Алгоритм каждого зашит ещё и на сервере. Логинятся по тройке, имя, пароль, ключ с брелка. Брелок устроен так что даже имею последовательность выданных им кодом не удастся узнать что будет следующим, т.к. там скорее всего применена криптографически стойкая хеш функция.
Вот, в живую видел именно такой artvart.mirpokera.com/notes/bezopasnosti-mnogo-ne-byivaet-token-bezopasnosti-rsa
en.wikipedia.org/wiki/SecurID
вот ещё по теме
вот ещё по теме
UFO just landed and posted this here
В универе на парах защиты информации тоже рассматривали такой способ с теоретической стороны. Так что идея не новая…
Вообще-то это совсем другое, потому что там используется не общеизвестная информация, а секретная (алгоритм и, что важнее, его параметры). А в случае, предложенном автором поста, секретен только алгоритм.
Не понимаю, что вы говорите про двухфакторную авторизацию: сам пользуюсь двухфакторной авторизацией на основе Google Authenticator в LastPass, пароль меняется каждые 30 секунд. А если почитать, как оно работает, совсем на душе тепло становится.
Прочитал. Интересно, но там же используется телефон, а в случае динамического пароля он не нужен.
Например у меня очень простенький телефон без всяких наворотов и Интернета.
Например у меня очень простенький телефон без всяких наворотов и Интернета.
Если развить эту идею, то будет очень здорово!
Спасибо за отличный пост, теперь у меня есть о чем думать в ближайшие пару дней.
Спасибо за отличный пост, теперь у меня есть о чем думать в ближайшие пару дней.
Хм…
Я так понимаю, что идея можеть быть жизнеспособной, если пользователь может собирать динамическую часть как конструктор, самостоятельно. Тогда он формирует пароль по сути из открытых данных, но с закрытым алгоритмом шифрования.
Я не специалист, но хрен его знает, может и рабочая идея.
Если алгоритм жесткий (фиксированный), то идея дохлая изначально.
Я так понимаю, что идея можеть быть жизнеспособной, если пользователь может собирать динамическую часть как конструктор, самостоятельно. Тогда он формирует пароль по сути из открытых данных, но с закрытым алгоритмом шифрования.
Я не специалист, но хрен его знает, может и рабочая идея.
Если алгоритм жесткий (фиксированный), то идея дохлая изначально.
Все правильно! Видимо я не смог точно объяснить в тексте то, что динамическая часть собирается самостоятельно и не привязана ни к какому месту (хотя пытался в комментариях).
Конструктор — хорошее сравнение.
Конструктор — хорошее сравнение.
Вот и реализовали эту мысль.
Перебор динамической части пароля можно заменить перебором алгоритма формирования. А его сложность будет сильно зависеть от конкретной реализации (сколько различных правил знает серверная часть) и количества компонент выбранных пользователем.
Мне слабо верится, что пользователи будут выбирать достаточно много компонент (хотя бы десяток), чтобы стойкость к подбору алгоритма формирования приблизилась к стойкости символьных паролей.
Мне слабо верится, что пользователи будут выбирать достаточно много компонент (хотя бы десяток), чтобы стойкость к подбору алгоритма формирования приблизилась к стойкости символьных паролей.
В текущем описании не вижу превосходства этого алгоритма перед капчей. Большинство предлагаемых законов вроде:
можно вычислять автоматически. Капчу подобрать сложнее. Хотя капча будет напрягать пользователя (не всегда верно вводит, часто появляется). Но и предложенные методы будут тяготить пользователя. Да к тому же окажутся мало эффективными
Текущий час в одном из часовых поясов.
можно вычислять автоматически. Капчу подобрать сложнее. Хотя капча будет напрягать пользователя (не всегда верно вводит, часто появляется). Но и предложенные методы будут тяготить пользователя. Да к тому же окажутся мало эффективными
Авторизация по телефону имеет серьёзные доводы, которым сложно что-либо противопоставить:
1. Защита от массовой регистрации => снижает требования к нагрузке серверов (если пользователь позаводил 20 аккаунтов, а использует только 1-2 что ж тут хорошего?). Сама рассылка смс в автоматическом режиме не стоит дорого.
2. Проще восстановить, уменьшает нагрузку на саппорт => можно сэкономить на количестве нанятых сотрудников.
3. Порой помогает найти негодника, который пользуется прокси и думает, что он неуловим… но наивно использует свой телефон при регистрации (да, этим занимается не саппорт почтовика… но они и не для себя это делают. Фактами не владею. Но почему бы не помочь силовикам и не наладить с ними хорошие отношения?).
4. Как вариант — использование таргетированной рассылки смс спама (фактами не владею, чисто мои размышления).
1. Защита от массовой регистрации => снижает требования к нагрузке серверов (если пользователь позаводил 20 аккаунтов, а использует только 1-2 что ж тут хорошего?). Сама рассылка смс в автоматическом режиме не стоит дорого.
2. Проще восстановить, уменьшает нагрузку на саппорт => можно сэкономить на количестве нанятых сотрудников.
3. Порой помогает найти негодника, который пользуется прокси и думает, что он неуловим… но наивно использует свой телефон при регистрации (да, этим занимается не саппорт почтовика… но они и не для себя это делают. Фактами не владею. Но почему бы не помочь силовикам и не наладить с ними хорошие отношения?).
4. Как вариант — использование таргетированной рассылки смс спама (фактами не владею, чисто мои размышления).
Потерял телефон и остался без доступа к сайту. А если ещё и симка не на твое имя и восстановить не представляется возможным, то навсегда.
Если потерял телефон — тогда к саппорту уже. Но это не так часто бывает, как «я забыл пароль». Поэтому нагрузка на саппорт снижается.
Симка не на имя пользователя — это тоже редкость и обычно его проблемы. Стимулирует на свою симку заводить. А искать чисто «левую» симку для регистрации ящика и использование его для чёрных дел — далеко не все с этим заморачиваются. Лень во всяком человеке живёт
Симка не на имя пользователя — это тоже редкость и обычно его проблемы. Стимулирует на свою симку заводить. А искать чисто «левую» симку для регистрации ящика и использование его для чёрных дел — далеко не все с этим заморачиваются. Лень во всяком человеке живёт
Выше правильно привели пример с RSA токенами. Но у вашей идеи есть существенный недостаток по сравнению с ними: RSA показывает готовый код, пользователю нужно только вбить его куда надо. И даже это заметно усложняет процесс логина (знаю по собственному опыту). А у вас нужно сконфигурировать динамическую часть, понять и запомнить, как что делать, а потом еще и каждый раз в голове просчитывать результат. Если сделать это опциональным, 99% пользователей просто откажутся. Если обязательным — проклянут изобретателя.
Если уж на то пошло, в критических местах лучше использовать хорошо защищенный ключ типа смарт-карты (в простейшем случае флешка с ключом). Но для простых сервисов типа е-мыла даже это уже слишком сложно.
Если уж на то пошло, в критических местах лучше использовать хорошо защищенный ключ типа смарт-карты (в простейшем случае флешка с ключом). Но для простых сервисов типа е-мыла даже это уже слишком сложно.
Если бы еще при наборе пароля выскакивали подсказки по словам, цены бы не было, а то представляю каждый раз после такого как машина залочилась набирать такой пароль. А так абсолютно согласен должно быть 2 пароля: короткий (4 буквы) и длинный (4 слова), тогда после длинной паузы запрашивает длинный или со странного IP, в других случаях короткий.
Сорок тысяч обезьян в жопу сунули банан (С)
Мне тоже приходила эта идея в голову полтора года назад. Идея как бы летает в воздухе. Хотел написать статью на хабре, но задал себе кучу вопросов, которые уже прозвучали в комментариях. Поэтому я не стал ничего писать. Возникает вопрос удобства. До сих находится достаточно количество пользователей, которые открыли для себя интернет буквально вчера. Среди моих знакомых есть такие, которых бесит само требование пароля. А тут еще какая-то динамическая часть. Эта система подойдет только для очень опытных пользователей и не для общественного сервиса. Но все равно остается слабое место, если злоумышленнику известен принцип динамической части, а вы сами предложили 14 вариантов.
Я столкнулся с более продуманной защитой, которую реализовали некоторые банки. Если банку уже известен ваш ip, то вы вводите пароль. Если ip поменялся, то помимо пароля нужно ответить еще на 2 сугубо личных вопросов. Показывается только два вопроса. А их в db всего 10. Если ip опять сменился, то нужно снова ответить еще на 2 вопроса, но уже других. Каждый раз показывает 2 вопроса, которые не показывались в предыдущий раз.
Эта система хороша тем, что если на компе пользователя завелся кейлогер, то злоумышленник знает пароль и возможно знает ответ на 2 вопроса. А когда пытается сам зайти, то он не знает ответы на остальные 8 вопросов. И жертва ему уже не поможет, так как у нее не меняется ip, и ей не приходится водить ответы на новые вопросы. Конечно, эта система идеально работает там, где у пользователей статический ip, а таких стран предостаточно.
Я столкнулся с более продуманной защитой, которую реализовали некоторые банки. Если банку уже известен ваш ip, то вы вводите пароль. Если ip поменялся, то помимо пароля нужно ответить еще на 2 сугубо личных вопросов. Показывается только два вопроса. А их в db всего 10. Если ip опять сменился, то нужно снова ответить еще на 2 вопроса, но уже других. Каждый раз показывает 2 вопроса, которые не показывались в предыдущий раз.
Эта система хороша тем, что если на компе пользователя завелся кейлогер, то злоумышленник знает пароль и возможно знает ответ на 2 вопроса. А когда пытается сам зайти, то он не знает ответы на остальные 8 вопросов. И жертва ему уже не поможет, так как у нее не меняется ip, и ей не приходится водить ответы на новые вопросы. Конечно, эта система идеально работает там, где у пользователей статический ip, а таких стран предостаточно.
Плюс, для защиты от фишинга при вводе пароля показывают выбранную пользователем картинку и ключевое слово — с надписью, «никогда не вводите свой пароль если нету картинки и слова»
Лично я 30-40% переводов делаю с мобильного телефона. Правда через специальное приложение.
За такое вот надоедание убил бы :)
Поэтому надо дальше думать :)
За такое вот надоедание убил бы :)
Поэтому надо дальше думать :)
Как-то вошел в какую-то из социальных сетей из другого города. Она пожаловалась, что слишком левый ip и предлоджила из многих фотографий выбрать на которых изображены мои друзья (не аватарки, а разные фото из альбомов). Эффективно, для случая подбора или кражи пароля.
Нужно дать возможность использовать пользовательскую хэш функцию. Тогда при регистрации пользователь указывает её, после чего во время авторизации сервер посылает юзеру 3 случайных последовательности, а браузер исполняет функцию, пропуская их через неё и даёт на сервер ответ. Если сошлось, то всё верно. Не обязательно писать сложную хэш функцию, можно дать выбрать вариант проверочных последовательностей только из цифр и написать что-то вроде:
function hash( num ){
return Math.max( num.toString().split(0,5), num.toString().split(5,10) ) * 2;
}
Пожалуй я повторюсь: это именно то, что делает 2-step auth гугля с их приложением (смс — это запасная опция), только там динамическая часть считается автоматом и гораздо надежнее, а вы, почему то, хотите заставить юзера считать это самому.
Кстати, алгоритм и имплементация Google Authenticator открытая, можно прикрутить к любому своему сервису, и даже не надо устанавливать отдельное приложение — оно уже поддерживает несколько эккаунтов. Подробности и код здесь: code.google.com/p/google-authenticator/
Кстати, алгоритм и имплементация Google Authenticator открытая, можно прикрутить к любому своему сервису, и даже не надо устанавливать отдельное приложение — оно уже поддерживает несколько эккаунтов. Подробности и код здесь: code.google.com/p/google-authenticator/
Направление и ход мыслей абсолютно правильный.
Существенным минусом, однако, является то, что в базе данных пароль будет по сути хранится в открытом виде. Ну точней ключ-алгоритм. А учитывая часту взлова даже корпоративных серверов это не айс.
Существенным минусом, однако, является то, что в базе данных пароль будет по сути хранится в открытом виде. Ну точней ключ-алгоритм. А учитывая часту взлова даже корпоративных серверов это не айс.
WTF? Если пользователь может составить динамическую часть, то ее так же составит и бот. А вот секурность у вас пострадает, ибо парольчик придется хранить в открытую.
Простите, бред несу. Можно вырезать эту часть и сверять сначала ее, а потом хэш остатка. Но преград для ботов все равно не вижу. Получится брут двух паролей, увеличивает комбинации, но не более того.
Вот чего реально не хватает в сервисах гугля так это передача доступа сторонним сервисам и аппликациям используя api key с ограниченными правами, а не вводя свои мэйл и пароль. Вдруг кейлоггер или еще какая дрянь стоит в сервисе или аппликации. Всех же не проверишь.
Уж думал будет что-то вроде ru.wikipedia.org/wiki/KeeLoq, но с реализацией к паролю.
При каждом правильном вводе пароля сообщается следующий пароль, который будет использован для входа в систему. Преимущество — можно вводить пароль не опасаясь кейлоггеров, следующий пароль будет другим.
Имея с десяток паролей вида habrah370, habrah481, habrah592, можно заходить лишь по одному из них, только при условии что помнишь какой вводил в предыдуший раз. Дважды подряд по одному паролю войти нельзя. При вводе верного пароля не в свой черед (при засвете пароля в кейлоггере) формируется отчет, обязательно выводимый на экран после ввода правильного пароля.
Будет информация о попытке несанкционированного входа по «украденному» паролю, будет повод сменить последовательность на новую.
При каждом правильном вводе пароля сообщается следующий пароль, который будет использован для входа в систему. Преимущество — можно вводить пароль не опасаясь кейлоггеров, следующий пароль будет другим.
Имея с десяток паролей вида habrah370, habrah481, habrah592, можно заходить лишь по одному из них, только при условии что помнишь какой вводил в предыдуший раз. Дважды подряд по одному паролю войти нельзя. При вводе верного пароля не в свой черед (при засвете пароля в кейлоггере) формируется отчет, обязательно выводимый на экран после ввода правильного пароля.
Будет информация о попытке несанкционированного входа по «украденному» паролю, будет повод сменить последовательность на новую.
Почему-то статья мне напомнила известную книгу Аллена Карра…
а чем плоха идея?
а кто мешает пользоваться специальными софтинами генераторами паролей, которые устанавливаются на комп? это если речь идет о пользователях, которые хотят себя защищать.
Что касается сервисов, тот же гугл, то их задача сделать максимально просто, но при этом надежно! телефон, всме же, пока не плохой способ защиты.
Что касается сервисов, тот же гугл, то их задача сделать максимально просто, но при этом надежно! телефон, всме же, пока не плохой способ защиты.
Идея мегко говоря так себе. Мне кажется в гугле вполне правильно поступили.
1. Брутфорсом по моему уже никто не пользуется.
2. В примере с конструктором пусть у вас будет 10 вариантов (день дедели, число итд). Вы знаете это. Злоумышленик тоже знает все возможные варианты. Если вариантов 10, то ваш вариант является ни чем иным, как просто расширением алфавита пароля. То есть день года (трехзначный) на самом деле еявляется всего лишь одним символом в алфавите пароля. Он всем известен.
То есть, ваш вариант 415Med125 ничем не лучше варианта uIlk — у вас используются 4ре параметра известные обоим сторонам (естественно полный набр динамичных параметрах — величина известная и доступна при конструировании конструктора).
Мой вывод: стойкость к перебору у вашего варианта, при условии, что злоумышленник знает о динамических частях, ниже, чем у обычного пароля. Вы увеличиваете количество символов вводимыз пользователем, при этом сокращаете реальное кол-во символов пароля (в вашем примере это 1, 15, Med, 125).
Сравнивать ваш метод с RSA токенами или с карточкой представленой Муртазиным (оригиналу анонса уже недела вчера была, кстати) просто смешно и нелепо. Все равно, что сравнивать шифрование «пляшущими человечками» из Холмса и AES :)
1. Брутфорсом по моему уже никто не пользуется.
2. В примере с конструктором пусть у вас будет 10 вариантов (день дедели, число итд). Вы знаете это. Злоумышленик тоже знает все возможные варианты. Если вариантов 10, то ваш вариант является ни чем иным, как просто расширением алфавита пароля. То есть день года (трехзначный) на самом деле еявляется всего лишь одним символом в алфавите пароля. Он всем известен.
То есть, ваш вариант 415Med125 ничем не лучше варианта uIlk — у вас используются 4ре параметра известные обоим сторонам (естественно полный набр динамичных параметрах — величина известная и доступна при конструировании конструктора).
Мой вывод: стойкость к перебору у вашего варианта, при условии, что злоумышленник знает о динамических частях, ниже, чем у обычного пароля. Вы увеличиваете количество символов вводимыз пользователем, при этом сокращаете реальное кол-во символов пароля (в вашем примере это 1, 15, Med, 125).
Сравнивать ваш метод с RSA токенами или с карточкой представленой Муртазиным (оригиналу анонса уже недела вчера была, кстати) просто смешно и нелепо. Все равно, что сравнивать шифрование «пляшущими человечками» из Холмса и AES :)
И в каком месте статья относится к Google? Тогда-уж в блог «Информационная безопасность»
В том, что предложил ее сотруднику Гугля и он разобрался в этой идее.
Мой уровень знаний не позволяет разобраться со всеми нюансами.
Когда думаешь, к какому блогу отнести статью, возможно много вариантов.
Что-то подходит больше, что-то нет.
Это тот случай, когда возможны разные варианты, я решил так — Google.
Мой уровень знаний не позволяет разобраться со всеми нюансами.
Когда думаешь, к какому блогу отнести статью, возможно много вариантов.
Что-то подходит больше, что-то нет.
Это тот случай, когда возможны разные варианты, я решил так — Google.
Вспомнилась Capcha по средствам youtube — показывается видео и надо пару тройку слов описывающих видео написать, например, мотоцикл, дорого, гонка. А Алгоритм капает комментарии и ищет эти слова. Робот вряд ли сможет выдать ассоциации и описывающие видео слова. Вроде это был чей то дипломный проект в штатах.
Автор, мне приходила та же идея. Думаю, если сделать удобный конструктор, это может быть полезным для продвинутых пользователей. Предлагаю сделать простой веб-сервис для тестирования, пусть люди попробуют!
Я тут пас, не умею, но если кто-то сможет, то буду рад.
Rozzy17 января 2012, 21:55 собирался подумать, может что-нибудь сделает?
Rozzy17 января 2012, 21:55 собирался подумать, может что-нибудь сделает?
реализовать бы ее в LastPass
Если алгоритм динамической части задает сам пользователь — то да, тогда перебор не будет иметь смысла. Другое дело — удобство и т.п. Но как вариант — неплохо.
У blizzard похожая штука есть.
Battle.net authentificator — приложение для iPhone и девайс-брелок. Он генерирует новый код (~10 цифр) каждые секунд 10. Если включить у себя на аккаунте поддержу, то кроме пароля при авторизации надо будет вводить еще и этот код.
Battle.net authentificator — приложение для iPhone и девайс-брелок. Он генерирует новый код (~10 цифр) каждые секунд 10. Если включить у себя на аккаунте поддержу, то кроме пароля при авторизации надо будет вводить еще и этот код.
Мой брат-параноик будучи некогда сис. админом использовал, а быть и может и продолжает использовать, похожий алгоритм для входа то ли на сервак, то ли в Убунту — я не помню. Суть в том, что есть некий базовый пароль, который модифицируется в зависимости от дня недели. Скажем, добавляются между символами пароля цифры из числа равного нну… номеру дня недели умноженного на возраст пользователя.
Таких алгоритмов можно выдумать миллион, а быт ьможет и два. А также задействовать больше переменных, что, на мой взгляд, позволит добиться достаточно высокой криптоустойчивости.
Таких алгоритмов можно выдумать миллион, а быт ьможет и два. А также задействовать больше переменных, что, на мой взгляд, позволит добиться достаточно высокой криптоустойчивости.
Честно говоря, не могу представить себе практическое применение этой идеи.
Для обычного сервиса это слишком сложно и на это никто не пойдёт(Тем более гугл с его аудиторией). Даже такие мелочи, как требования в пароле одновременно наличия заглавных, прописных и цифр сильно нервирует пользователей.
Если вы параноик или вам нужна повышенная секретность пароля — периодически меняйте пароль вручную. Алгоритма смены пароля не будет, защита будет лучше.
Для обычного сервиса это слишком сложно и на это никто не пойдёт(Тем более гугл с его аудиторией). Даже такие мелочи, как требования в пароле одновременно наличия заглавных, прописных и цифр сильно нервирует пользователей.
Если вы параноик или вам нужна повышенная секретность пароля — периодически меняйте пароль вручную. Алгоритма смены пароля не будет, защита будет лучше.
провокация — может по соотношению простота/защищенность круче будет отпечаток пальца?
по моему в той же вики давно применяются динамические пароли
Пароль каждый раз новый, отправляемый СМСкой… вот более безопастный (совместно со статическим паролем) способ!
Sign up to leave a comment.
Динамический пароль