Комментарии 48
пароль из 11 букв и чисел различного регистра — на его взлом потребуются три года. А если в нём будут ещё и спецсимволы
Извините, если я глупость спрошу, но чем пароль из "символы+цифры+спецсимволы" надёжнее пароля только из символов такой же длины как "символы+цифры+спецсимволы"?
ну как минимум большим числом вариантов на каждый символ в пароле. Это если мы говорим про случайные пароли.
Если там какая-то осмысленная фраза, то разбавив её спецсимволами мы усложняем атаку по словарю
Если взять пароль из 11 символов английского алфавита то количество разных вариаций для перебора составит 26^11, каждый символ из 11 может быть выбран 26-ю разными способами. С учетом регистра это будет уже 52^11, с добавлением цифр это будет 62^11, ну и со спецсимволами еще больше.
Если взять количество спецсимволов за 26 то это уже будет 88^11. Что сильно больше чем 26^11.
Но, достаточно всего одного спецсимвола (желательно редкого) и весь перебор по словарю станет бесполезным, не понадобится никакая роза в зад.
против этого придуманы атаки по словарю с перестановками. пароль bestpassword получается по сложности примерно как bestpassword#
Это все равно увеличивает сложность на количество спецсимволов. И символ может появится в любом месте, если только пользователь не тупой.
Нет.
например в этой первой попавшейся программе для брутфорса паролей можно задать правило
которое означает создать из слова pаssword ~password p~assword итд
Неграмотный пользователь с кучей ошибок в написании создаст лучший пароль. И с генетическими алгоритмами будет проблематично сбрутфорсить такой пароль :) Ну это чисто эмпирически :)
В то же время по порядку величины 52^11 примерно равен 26^13. То есть рандомная заглавная экономит пару букв длины пароля.
88^11 соответствуют 26^15, то есть цена вопроса - ещё пара букв.
Поэтому за расширением алфавита как самоцелью гнаться необязательно - удлинение работать будет не хуже. Выбирайте то, что вам кажется более удобным.
Если коротко, то для взлома нужно перебрать больше комбинаций
Если не коротко, то как пример можно взять брутфорс
В латинском алфавите 26 букв. Если пароль из 11 символов будет содержать только буквы, то взломщику в худшем случае потребуется перебрать 26^11 комбинаций символов (считаем, что на месте каждого символа может быть любая буква), то есть, 3670344486987776 комбинаций
Если добавляем цифры (ещё 10 символов) и спецсимволы (ещё +-30), то нужно перебрать уже 66^11 комбинаций, то есть 103510234140112521216 комбинаций
Теперь делим одно на другое и получаем, что для взлома пароля только из букв нам потребуется в 28201 раз меньше операций, чем для пароля из букв+цифр+спецсимволов, соответственно, времени тоже сильно меньше уйдёт
Во всех беспарольных технологиях есть один большой минус, их защита базируется на самом слабом звене, чаще всего это возможность восстановления доступа к аккаунту. Если человек потерял резервные коды и устройство, то часто ему достаточно просто "получить смс на номер" и перепривязать всё что угодно обратно. Такие проблемы были у Сбера, например, когда клон симки по сути сбрасывал все настройки безопасности в ноль. Идеал это "поход с паспортом в центры Госуслуг", но мы же говорим о массовом продукте, там приходится идти на компромисс между безопасностью/удобством.
Очень хотелось бы узнать детали того, как будет в ВК реализовано восстановление доступа в случае утери возможности входа без пароля.
>наиболее надёжным видом беспарольной аутентификации считается вход с помощью биометрических технологий
Есть два нюанса.
1. Нельзя пошарить доступ к сервису. Нельзя завести учётку для всей семьи, не сканируя биометрию каждого члена семьи. Нельзя завести общую корпоративную readonly-учётку на весь отдел. При авторизации по паролю я могу дать доверенному лицу логин и пароль. А при авторизации по биометрии что делать? Палец отсылать почтой? А что будет с моими данными после моей смерти? При авторизации по паролю доверенные люди могут получить список моих критичных логинов и паролей.
2. Пароль в случае утечки можно сменить. Биометрию сменить не получится. Если какой-то сервис сольёт информацию, из которой можно будет слепить правдоподобный запрос на аутентификацию, пользователи окажутся беззащитными на множестве других сервисов, использующих такой же метод аутентификации.
Из чувства брезгливости не хочется сливать биометрию кому попало.
В данной технологии биометрия, по идее, дальше устройства с ключами не уходит. Сам сервис про нее ничего не знает.
Если устройство хранит у себя ключ, доступ к которому есть только по биометрии — это один сценарий. Утеря устройства в таком случае приведёт к утере доступа, как уже писали в соседнем комменте.
А вот если устройство на своей стороне без каких-либо дополнительных данных преобразует биометрию в какую-то строку, которую потом передаёт сервису аутентификации, то безопасность такого решения получается даже хуже, чем авторизация по паролю. Даже если строка уникальна для каждого запроса, это не решит проблему — в таком случае в бд скорее всего придётся хранить строку, по которой можно сгенерировать такую строку для авторизации для любого запроса на любом другом сервисе, использующем тот же механизм. И подделать такой запрос, минуя само устройство, вычисляющее такую строку.
Утеря устройства в таком случае приведёт к утере доступа, как уже писали в соседнем комменте.
Если сервис не совсем дурной с точки зрения внедрения этого всего - не приводит. Потому что, во первых, в нормальной системе предусмотрена возможность добавлять несколько ключевых пар для входа в учетку. Берем другое устройство и логинимся через него. После чего потерянное устройство из учетки выкидываем, а новое добавляем.
Во вторых - резервные способы входа должны таки быть. Достаем бумажку из сейфа с резервными кодами и логинимся ими, например.
В третьих - ключевые пары синхронизируются между устройствами. Точно так же как база данных менеджера паролей может между устройствами синхронизироваться.
А биометрия - это для открытия базы данных парольного менеджера на конкретном устройстве. Что умеют приблизительно все из них, что на смартфонах работают.
Ну это примерно похоже на авторизацию в приложениях банков, да и многих других приложениях. Аутентификация в самом приложении создаёт токен, сохраняемый на клиенте, но без биометрии (или ввода пин-кода) нельзя этим токеном воспользоваться.
Впрочем, повторная аутентификация в таком приложении всё равно потребует ввода пароля и/или кода из смс и ещё 2fa-кода. Например, при смене устройства и невозможности переноса данных с прошлого.
Однако я процитирую статью:
>Если устройство или биометрия соответствуют информации в базе данных, то пользователь получает разрешение на доступ.
Если я правильно понимаю автора, речь о том, что биометрия хранится в базе данных. На стороне сервиса. И тогда получается, что сервис аутентификации будет сверять какие-то данные от устройства, считывающего биометрию, с той биометрией, что он хранит у себя в базе. Таким образом, получается, что для аутентификации нужна вовсе не строка, созданная с использование ключевой пары, а именно строка, созданная с помощью биометрии.
В приличном сервисе данные в открытом виде не хранятся. Только хэш. Ещё и с солью.
Т.е. для проверки его использовать можно, а для генерации - нет.
Это касается не только паролей, но и всего.
Да, с паролями и хэшами велосипед изобретать не надо — нехэшированный пароль отправляется сервису, сервис хэширует его (предварительно добавив соль, конечно же) и сверяет с имеющимся в базе хэшем. Ключевой момент — пароль не хэшируется на стороне клиента. Иначе, если клиент сделает один хэш с одной солью, а сервис другой хэш с другой солью — хэши, ожидаемо, не сойдутся. А если хэшироваться пароли будут одинаково — модификация клиента может позволить подставлять условно слитый хэш, не генерируя его из пароля.
В случае компрометации пароля, в т.ч. при выявлении подозрительной попытки входа, пользователь меняет пароль. Иногда и сервис может сделать это принудительно. Поэтому нехэшированный пароль можно смело слать, доверяя только https. Ибо одно из главных правил: один сервис — один пароль. Даже если пароль утечёт, он будет критичен для одного сервиса (если пользователь молодец)
А что делать, если внезапно обнаружится утечка логов, в которых оказались нехэшированные биометрические клиентские данные? Мы ведь в таком случае вынуждены слать строку без хэша. Или сервис сообщит, что стал жертвой атаки, в ходе которой запросы перехватывались и отправлялись злоумышленникам? Или клиент станет жертвой атаки MitM-атаки с подменой сертификата (Минсвязи Казахстана и Минцифры РФ передают приветы и напоминают о своих корневых сертах), и биометрия будет сохранена на стороне посредника? Что в таком случае делать?
Альтернатива — хэшированные на клиенте данные вида "биометрия+timestamp", дабы запрос нельзя было повторить. Но в таком случае придётся хранить сырые данные на стороне сервиса.
И тут появляется второй вопрос. Чтобы ключи попали на устройство с биометрией, надо на нём пройти аутентификацию хотя бы раз. Сейчас это решается логином с паролем и/или теми же SMS-кодами. То есть либо один фактор, либо старые-добрые пароли.
Чтобы ключи попали на устройство с биометрией, надо на нём пройти аутентификацию хотя бы раз.
Для одной учетки - которая для устройства. Для всех остальных учеток (для сайтов), которые в кейсторе хранятся - регистрируются стразу ключевая пара.
И оно не совсем верно. Не знаю, как оно с менеджером паролей взаимодействует (в смысле, что именно нужно, чтобы скачанную копию кейстора расшифровать), но на новые андроиды можно залогинится, подтвердив, что 'да, это я новое устройство добавляю' на каком-нибудь уже залогиненном устройстве (причем именно устройстве - сессии в десктопном браузере не спрашивают)
Сделайте пожалуйста поддержку U2F. И чтоб несколько ключей можно было добавить.
Когда слышу все эти истории вспоминаю, как в отпуске почему-то отказал роуминг данных, и пришлось заказывать билеты с публичного компьютера в холле гостиницы. Парольный менеджер на смартфоне с локальной базой и входящие SMS таки работали, так что самой большой сложностью был ручной перенабор пароля.
Пока ни один более модный способ такого теста не прошёл бы. И да, 2FA я стараюсь везде перевести с SMS на TOTP (с оффлайн бэкапом базы опять же) с готовым набором запасных одноразовых кодов на бумажке.
Почему компании не переходят на беспарольную аутентификацию?
А это в реальности кому-то настолько жизненно необходимо кроме как производителям устройств для био/2F-аутентификации?
Ещё как! Возможность дать сотруднику доступ к данным по отпечатку пальца, а не по какому-то 24-символьному паролю, который в идеале нужно вводить от руки и каждые 30 дней менять (а в реальности листочек с паролем под клавиатурой и пароль не меняется годами).
впереди уже проглядывается будущее, в котором заходить в любой сервис можно будет, например, с помощью отпечатка пальца или скана лица. А пароли навсегда уйдут в прошлое.
Совсем хреновое будущее какое то, при первом же сливе — пожизненная компрометация с невозможностью что либо исправить. Уж лучше пароли с недостатками.
Аналитики выяснили, что относительно высокий уровень безопасности обеспечивает пароль из 11 букв и чисел различного регистра — на его взлом потребуются три года.
А если добавить блокировку аккаунта на 1-2 часа в случае 5 неправильно введеных паролей?
Я уж молчу, что твориться сейчас, что купив новую симку можно спокойно восстановить данные аккаунтов в разного рода соцсети. Пол года назад по крайней мере отлично получалось.
Ну а про то что рано или поздно данные биометрии будут слиты, и тогда придётся вместо смены пароля пластическую операцию делать, ну это вообще шикарно.
Достаточно ограничить частоту попыток авторизации на уровне 1...5 попыток в секунду. Человек это не заметит — за секунду новый вариант пароля не набрать, а программы брутфорса даже PIN из 4 цифр будут подбирать больше часа, а пароль из 7...8 цифр станет невзламываемым.
Я работал над авторизацией в одной торговой сети. Брутфорсить начали через неделю после запуска личного кабинета. И долбились настолько интенсивно, что брутфорс превращался в DDoS.
Так что ограничения сделали действительно жёсткими, примерно как выше @VBKesha предлагает, в том числе и чтобы мамкиных дудосеров отвадить.
(прочитав возражения против биометрии выше) Товарищи авторы. Вы бы написали, как именно и где тут биометрия работает и что сервис совершенно не знает, как именно ключики защищаются. А то у народа рефлекс уже сделали попытками ее использовать на стороне сервиса.
Замена аутентификации на основании "я знаю что-то" на "я владею чем-то" (крипто-ключом) не выглядит как улучшение безопасности. Украсть ключ у меня можно незаметно, а вот украсть незаметно пароль из головы - сложнее. Ну естественно, пока я этот пароль не запишу никуда.
Давно придумана такая вещь, как кодовые таблицы. При регистрации система выдаёт пользователю несколько таблиц, где по вертикали a-b-c-d-e-..., по горизонтали 1-2-3-4-5-... и в ячейках - 2-3 символа. При логине эти таблицы могут быть вторым фактором авторизации вместо фундаментально ненадёжных SMS. После ввода пароля система спрашивает: "Таблица №4, d2", "Таблица №2, a7" и "Таблица №1, c3", и три текстбокса. Ввёл правильно - пустили. Таблицы могут быть с ограниченным сроком жизни.
Когда-то давно такой способ авторизации немного использовали Яндекс.деньги, но видимо из-за каких-то лицензионных причин перестали. А зря. Это - надёжно и оставляет безопасность пользователя в его руках (в отличие от дырявого SMS с кучей векторов атаки - MITM, перевыпуск SIM и пр). Я вот не хочу никаких SMS и вообще привязку номера, это фундаментально ненадёжно, и тем не менее это по недомыслию сделали стандартом аутентификации. Дайте мне кодовые таблицы!
То что вы описали, это по смыслу старый добрый ОТP = one time password. Такие бумажки с кодами, они называются iTAN до 2019 еще можно было повстречать в банковских системах. На смену им пришел ChipTAN, где нужно вставлять банковскую карту в устройство для генерации TAN-ов. А потом и PhotoTAN и QR-TAN. Особенность в банковском секторе, это то что там необходим не только вход в систему, но и заверение каждой транзакции. И для этого используется дополнительная система авторизации. Отличная от той что используется для входа в учетную запись.
Вне банковского сектора уже все перешли на TOTP (time based one time password) и вариации. Такие системы вам знакомы. Это например Google Authenticator, Microsoft Authenticator и иже с ними. Причем стандарт открытый. И не надо никаких SMS. Смена телефона тоже перестала быть большой проблемой, потому что большинство таких приложений научились создавать бэкапы настроек. Перезашел в учетку с нового телефона, восстановил приложения-аутнтификаторы из бэкапа и они работают как раньше.
Если конечно нет смартфона, то тут уже да, посложнее будет.
В 2023 заметная часть набранного текста это пароли. Это уже вымораживает
Какой страшный хоррор вы написали… Нет ничего лучше хорошего пароля в менеджере паролей. Разграничение зон ответственности одних аутентификационных данных, возможность поделиться аутентификацией на одном сервисе, не трогая все остальные. Сложно атаковать пачку критических сервисов фишингом и легко поменять пароль в случае успешной атаки.
Единственный кейс, когда «войдите с помощью ВК» работает ‒ когда приложение взаимодействует с аккаунтом сервиса, выдавшего ID. Допустим, GitHub и GitKraken. А в остальных случаях ‒ лишние данные, отданные корпорации, и лишняя дырка в безопасности.
Опять идёт подмена понятий.
В общем, пока такие "эффективные менеджеры" будут путать понятия идентификации, авторизации и аутентификации - ничего хорошего нас не ждёт.
Я бы ещё согласился использовать биометрию для идентификации - когда подставляется логин.
Но никак не пароль. Пароль должен знать только я. Я должен иметь возможность легко его поменять в любой момент времени. И много ещё разных требований.
А что делать если "утечет" биометрия? Как мне сменить пальцы, лицо, сетчатку? Тем более что их относительно несложно украсть и подделать!
Видел ролик как по нескольким фото слепили манекена и разблокировали им телефон. Аутентификации по биометрии это вообще никакая не безопасность. Это профанация, дилетантство и вредительство
В марте 2023 года ИБ-компания Hive Systems подсчитала, сколько времени потребуется хакеру
Если пройти по ссылочке, то окажется, что вся статья про сложность подбора MD5 хэша пароля без соли. В 2023 году не иначе как диванные эксперты "исследуют" перебор 20-лет как устаревшего хэш алгоритма.
И вообще у меня большой вопрос, VK сами не могут оценить сложность подбора пароля, исходя из того, какой алгоритм хэширования используется? Или внутри VK тоже испольузется md5 без соли?
Технология единого входа удобная штука.
финансовые потери компаний из-за утечек данных в среднем по миру достигли $4,35 млн, при этом дороже всего такие взломы обходятся медицинским ($10,10 млн) и финансовым ($5,97 млн) организациям.
странная арифметика
«Это ключ? Нет, кое-что получше»: будущее беспарольной аутентификации