Согласен с вами, что этот вопрос надо исследовать с учетом недостатков и существующей системы.
Т.к. идентификатор пользователя нам известен, а пароль может быть 111111. И вероятность того, что пароль будет таким очень большая. Но этот вопрос скорее будет зависеть от того, сколько слов в кодовой фразе нужно использовать, что б стойкость авторизации Раскина была на нужном уровне.
Спасибо за ссылку на книжку. Глава сама по себе плохо воспринимается без контекста. До нее Раскин приводит методики оценки интерфейсов пользователя, и все свои интерфейсы согласно этим методикам обосновываем. Показывает, почему и насколько один вариант интерфейса лучше другого.
1) Цит.: «Утверждение, что ввод двух разных цепочек символов увеличивает надежность, ошибочно» и далее доказательство. Это кто так утверждает, местная школота? Любой ребенок знает, что секрет в пароле, и только в нем.
Примерно, то же самое, только другими словами Раскин в главе и написал.
2) Проблема восстановления пароля — как решать? В вариате регистарции email+пароль (красиво сделано на dropbox.com, а недавно и на twitter.com красиво стало) такой проблемы нет.
Ничего не мешает востанавливать пароль через емейл или телефон, если пользователь снабдил систему данными о телефоне или емейле. Если не снабдил — то он сам себе злобный буратино. Не вижу проблемы.
3) Проблема смены идентификатора.
А зачем менять идентификатор? Если вы о проблеме смены пароля — то ее нет. Если мы храним в базе — у пользователя есть свой user_id и хеш пароля, хеш пароля — легко меняется.
Раскин говорит о том, что пользователь не должен сообщать системе ничего кроме пароля, а не о том, как это должно быть реализовано.
4) Проблема криптоустойчивости — как сгенерированный системой «запоминающийся пароль» может быть безопасным?! Раз уж система генерирует, то нужно криптографически стойкий делать.
Пояснил в коменте ниже по тексту. И 5 там же объяснил.
Скорее мы войдем в систему подбирая пароль 111111 к известным логинам. :)
Возможно, исследую вопрос безопастности и напишу статью. Уверен, что при правильной реализации авторизации Раскина, безопастность ее будет по крайней мере не хуже, чем у традиционного пароля. Даже без учета того, что в традиционной очень маленький процент пользователей выбирает хоть минимально безопастные пароли.
Смысл примерно такой:
предположим, что в аутентификации Раскины мы используем фразу из трех слов — это примено 300000 ^ 3 вариантов — уменьшим до (10 ^ 5) ^ 3 — получаем 10 ^ 15 вариантов
с другой стороны используем крутой пароль в котором используется 100 символов со всем значаками большими-маленькими буквами и цифра (100 выбрано для удобства оценки количества вариантов) пароль будет состоять и 7-ми символов — получаем (10 ^ 2) ^ 7 итого 10 ^ 14 вариантов.
В этом случае брут форс по 10^6 паролей в секунду займет примерно 10^9 секунд — что около 100 лет. Это еще раз напомню — миллион паролей в секунду и всего 3 слова или 7 символов.
Если мы возьмем авторизацию Раскина с 4-мя и более словами, то брутфорс это сделает абсолютно безсмысленным, и это будет равносильно паролю из 10-ти символов.
На самом деле в оценки используются некоторые упрощения, но смысл думаю примерно понятен. Оценивать вероятность взлома системы брутфорсом по всем паролям — уже надо комплексно с учетом недостатков обоих систем, но стойкость паролей при этом сопоставимая.
Читайте Раскина! Умный мужик был, макинтош придумал. ( Википедия о Джефе Раскине ) Пока не умер был первым в мире человеком по теме пользовательских интерфейсов. Думаю, он знал как аутентификация должна быть реализована.
Мне больше всего нравится вариант регистрации предложенный Джефом Раскиным в книге «Интерфейс». Логины, телефоны и почты совершенно не нужны для аутентификации. Достаточно одного пароля. При этом пользователю система генерирует заведомо безопасный и уникальный пароль и предлагает ему выбрать из нескольких вариантов. В качестве пароля Раскин предлагает использовать кодовую фразу, некое легкозапоминаемое человеком словосочетание или предложение. Главный недостаток, этого варианта, как раз не безопастность, а скорее сложность реализации, но должно ли это заботить пользователя. Хотя вариант довольно-таки известный и правилный, я не видел еще не одной реализации в Интернет.
Я как раз тоже чем-то подобным занимаюсь, в смысле «иерархических алгоритмов самообучения». У нас что-то похожее на HTM, правда про них я еще не дочитал, но смысл такой же.
Джеф Раскин реально крут! Он приложил руку ко многим продуктам Apple. Так же могу рекомендовать его книгу с названием «Интерфейс» — очень познавательно. Так же считаю, что многим русским «гуру» пользовательских интерфейсов стоило бы почитать Раскина для общего развития, что б не нести чушь.
> Стоит думать над тем, как можно сеть научить думать. И выдавать именно то, что нам надо.
Люди уже много лет над этим думают. Даже название придумали для очередных стандартов — Semantic Web. Штука тоже не идеальная, но какой-то шаг в будущее.
2) Распознавание всего того, что может быть введено в пункте 1, но с фотографии (набросал схему на листике, сфоткал — вуаля)
Реально крутая идея! Причем вполне реализуемая. Есть, конечно, огромное количество деталей. Почему-то подумал про Evernote в котором большая часть возможностей по вводу информации уже реализована. Далее, нужно данные из Evernote загружать в «мозг» для обработки.
Рисовать, если диаграммы, то вполне реализуемо. Набирать текст в белом поле — тоже реализуемо. Вот хотелось бы что б можно было рисовать и писать «как на бумаге», но пальцем на тачскрине это, думаю, будет не очень удобно. Вот с дигитайзером поключенным к ПК очень неплохо может получиться. Но пока это далекое будущее. Хотелось бы сделать что-то простое и функциональное.
Как раз ведем разработку подобного «мозга». Примерно с похожими требованиями. Ожидал в статье увидеть какие-то интересные идеи по интерфейсу пользователя. Или придумать их самому вдохновившись вашей формулировкой требований. Есть вероятность, что скоро наш проект увидит мир.
По сути у меня нет, ни объектов, ни классов. Моя модель совпадает с моделью RDF триплетов: субъект предикат объект. Триплеты в свою очередь образуют узлы гиперграфа. Некоторые узлы в нашей модели мы называем сущностями (аналог объекта, но не совсем объект, поскольку нет понятных границ объекта, а сущность слово хорошее, которое к тому же не создает в нашей системе многозначности). Например, какой-то конкретный человек (например клиент) Вася Пупкин — это сущность, в то время, как число 42 будет являться узлом, но при этом не будет являться сущностью. И, получается, что у некоторых сущностей долны быть, какие-то связи, а у других нет, и должны быть какие-то другие сущности, которые описывают какие связи у каких сущностей должны быть (аналог классов и метаклассов). Если использовать пример с Васей Пупкиным, нужен способ сказать что Вася клиент, а поскольку Вася клиент, он должен был что-то у нас купить. На основе этих сущностей-классов, например, можно строить форму для ввода данных.
Т.к. идентификатор пользователя нам известен, а пароль может быть 111111. И вероятность того, что пароль будет таким очень большая. Но этот вопрос скорее будет зависеть от того, сколько слов в кодовой фразе нужно использовать, что б стойкость авторизации Раскина была на нужном уровне.
Логин: vanfukov
Пароль: nfg#56G
Вариант Раскина
Кодовая фраза: Бешенный кролик аттакует
Как я показал выше — криптостойкость обоих паролей одинакова. При этом что удобнее для пользователя?
1) Цит.: «Утверждение, что ввод двух разных цепочек символов увеличивает надежность, ошибочно» и далее доказательство. Это кто так утверждает, местная школота? Любой ребенок знает, что секрет в пароле, и только в нем.
Примерно, то же самое, только другими словами Раскин в главе и написал.
2) Проблема восстановления пароля — как решать? В вариате регистарции email+пароль (красиво сделано на dropbox.com, а недавно и на twitter.com красиво стало) такой проблемы нет.
Ничего не мешает востанавливать пароль через емейл или телефон, если пользователь снабдил систему данными о телефоне или емейле. Если не снабдил — то он сам себе злобный буратино. Не вижу проблемы.
3) Проблема смены идентификатора.
А зачем менять идентификатор? Если вы о проблеме смены пароля — то ее нет. Если мы храним в базе — у пользователя есть свой user_id и хеш пароля, хеш пароля — легко меняется.
Раскин говорит о том, что пользователь не должен сообщать системе ничего кроме пароля, а не о том, как это должно быть реализовано.
4) Проблема криптоустойчивости — как сгенерированный системой «запоминающийся пароль» может быть безопасным?! Раз уж система генерирует, то нужно криптографически стойкий делать.
Пояснил в коменте ниже по тексту. И 5 там же объяснил.
Возможно, исследую вопрос безопастности и напишу статью. Уверен, что при правильной реализации авторизации Раскина, безопастность ее будет по крайней мере не хуже, чем у традиционного пароля. Даже без учета того, что в традиционной очень маленький процент пользователей выбирает хоть минимально безопастные пароли.
Смысл примерно такой:
предположим, что в аутентификации Раскины мы используем фразу из трех слов — это примено 300000 ^ 3 вариантов — уменьшим до (10 ^ 5) ^ 3 — получаем 10 ^ 15 вариантов
с другой стороны используем крутой пароль в котором используется 100 символов со всем значаками большими-маленькими буквами и цифра (100 выбрано для удобства оценки количества вариантов) пароль будет состоять и 7-ми символов — получаем (10 ^ 2) ^ 7 итого 10 ^ 14 вариантов.
В этом случае брут форс по 10^6 паролей в секунду займет примерно 10^9 секунд — что около 100 лет. Это еще раз напомню — миллион паролей в секунду и всего 3 слова или 7 символов.
Если мы возьмем авторизацию Раскина с 4-мя и более словами, то брутфорс это сделает абсолютно безсмысленным, и это будет равносильно паролю из 10-ти символов.
На самом деле в оценки используются некоторые упрощения, но смысл думаю примерно понятен. Оценивать вероятность взлома системы брутфорсом по всем паролям — уже надо комплексно с учетом недостатков обоих систем, но стойкость паролей при этом сопоставимая.
Люди уже много лет над этим думают. Даже название придумали для очередных стандартов — Semantic Web. Штука тоже не идеальная, но какой-то шаг в будущее.
Реально крутая идея! Причем вполне реализуемая. Есть, конечно, огромное количество деталей. Почему-то подумал про Evernote в котором большая часть возможностей по вводу информации уже реализована. Далее, нужно данные из Evernote загружать в «мозг» для обработки.