Мы в FIDO Alliance как раз-таки пришли сообщить вам о том, что пароли все-таки вымрут… в аутентификации.
Прежде чем мы начнем разговор о массовом уничтожении многословных гадов, давайте вернемся к нашему самому популярному протоколу FIDO U2F о коем я писал ранее.
То есть сценарий аутентификации с U2F таков:
Регистрация:
— Пользователь регистрируется, используя логин и пароль
— Сервер хеширует пароль с использованием scrypt, argon2, bcrypt и сохраняет в БД
— Пользователь добавляет свое устройство, храня на сервере публичный ключ и id пары ключей на устройстве
Аутентификация:
— Пользователь вводит логин и пароль
— Сервер хеширует пароль и сравнивает с хешем в базе данных
— Сервер генерирует случайный «вызов» и отправляет клиенту вместе с ID
— Клиент передает вызов, id, token binding, и origin сессии U2F токену
— Аутентификатор все это подписывает приватным ключом и отправляет клиенту, а тот серверу
— Профит
На сегодняшний день мультифакторная аутентификация с использованием U2F является самым легким, фишинг устойчивым и безопасным методом аутентификации. Но даже у этого метода есть свои недостатки.
Какие же?
Пароли!
Пароли все еще можно украсть на всех стадиях аутентификации:
— Можно украсть с помощью кейлоггера;
— Можно украсть при проблемах с TLS(см Heartbleed);
— Можно украсть если сервер уязвим к инъекции кода, или при ошибках в коде(см Twitter)
— Можно украсть если пароли слабо хешированы или не были хешированы вовсе.
Пока есть пароль, его можно украсть
А что если убрать пароль вообще?
Собственно, так подумали мы в FIDO Alliance (мы не имеем ничего общего с гипертекстовым фидонетом, хотя потенциально можем быть там использованы) и сделали FIDO2
Для тех, кто о нас не слышал, FIDO Alliance — это консорциум, разрабатывающий открытые стандарты безопасной аутентификации. Выше на картинке вы можете видеть наших членов совета, которые собственно и разрабатывают стандарты.
FIDO2 — это наш последний проект, который мы разрабатывали более трех лет. Он состоит из двух частей:
— WebAuthn — JS API для менеджмента учетных записей на публичных ключах. Это W3C стандарт, так что будет обязателен для всех браузеров. Собственно Chrome, Firefox и Edge уже публично заявили о работе над его поддержкой.
— CTAP2 — Client-to-Authenticator 2 — это стандарт, описывающий CBOR протокол для общения с аутентификатором по USB, NFC и BLE.
Пользователь
Для пользователя это просто:
— Пользователь вводит имя
— Проходит верификацию
— Профит!
Собственно, демонстрация:
Протокол
FIDO2 — это член семейства вызов-ответ протоколов FIDO. В протоколе есть шесть основных механизмов безопасности:
1. Вызов-ответ
Первый механизм это вызов-ответ. Сервер генерирует случайный вызов и отправляет его клиенту. Клиент передает данный вызов аутентификатору, который подписывает вызов и возвращает его клиенту, а тот в свою очередь серверу. Сервер, зная вызов, подпись и публичный ключ, может подтвердить подпись и таким образом аутентифицировать клиента.
2. Фишинг-защита
Второй механизм это сессионно-зависимая транзакция. Когда клиент получает вызов от сервера, он добавляет к вызову информацию о сессии: origin (прим: example.com), token binding. Эта информация подписывается аутентификатором и возвращается серверу. Сервер декодирует ответ и смотрит или в источником был он сам, и если пользователь подвергся фишинг атаке то сервер сможет увидеть что источником был на пример attacker.com а не example.com и таким образом предотвратить атаку.
3. Защита от атаки повторного воспроизведения
Чтобы защитить от атаки повторного воспроизведения, в транзакции присутствует счетчик, который увеличивается на единицу при каждой операции. Если сервер получил ответ со счетчиком, значение которого меньше или равно последнему сохраненному значению, то сервер может точно сказать что это атака повторного воспроизведения.
4. Приватность
Четвертый механизм защиты это регистрационно-уникальные пары ключей. При каждой регистрации аутентификатор генерирует случайную пару ключей со случайным идентификатором. Таким образом даже если вы и ваш партнер будете использовать один аутентификатор для обоих аккаунтов, то сервер не сможет узнать этого.
При аутентификации идентификатор пары ключей передается аутентификатору, и тот, используя origin и идентификатор, найдет вашу пару ключей в своей защищенной БД и вернет подпись.
Альтернатива к передаче идентификатора это использование резидентных ключей (RK, resident keys). При аутентификации аутентификатор вернет подписи для всех RK пар ключей. Клиент предоставляет пользователю выбор пары и вернет подпись серверу. Более подробно RK я распишу ниже.
5. Аттестация
Пятый механизм это аттестация. Иногда сайту нужно узнать тип устройства у пользователя. Так например в США все государственные учреждения обязаны использовать только FIPS (Federal Information Processing Standards) сертифицированные устройства. Подобные требования есть во Франции, Израиле, России и других странах. Для всего этого и существует аттестация.
При производстве аутентификаторов, на каждые сто тысяч устройств компания генерирует «сертификат партии» и ключи к нему и устанавливает их на каждое устройство. При регистрации устройство подписывает всю информацию приватным ключом партийного сертификата и возвращает сертификат вместо публичного ключа. В сертификате содержится информация о аутентификаторе, и его AAGUID(Authenticator Attestation GUID). Также при получении FIDO сертификации компания выпускает специальный документ метадаты, или просто метадату, и помещает в наше хранилище метадаты доступное всем. В метадате содержится информация о аутентификаторе, включая его криптографические характеристики, биометрические характеристики если он поддерживает биометрику, алгоритмы, уровни безопасности, базовое описание и много другой информации. а основе имеющейся информации сервер может судить о том, стоит ли ему принимать аутентификатор или нет.
Аттестация бывает разная. Существует полная версия аттестации, в которой сервер возвращает сертификат. Есть само-аттестация, при которой устройство не поддерживает сертификаты, а вместо этого возвращает публичный ключ только что сгенерированной пары.
Также пользователь может сам настроить метод, с помощью которого он хочет вернуть аттестацию. Так например пользователь может вообще запретить возвращать аттестацию и клиент просто удалит её, вернув регистрационный ответ без аттестации. Об этом я расскажу позже.
6. Тест на наличие пользователя
Одно из фундаментальных требований FIDO это тест на наличие пользователя. В данном случае имеется в виду, что аутентификатор обязан удостоверится в присутствии пользователя… Это может быть сделано по-разному: простое нажатие на кнопку, отпечаток, пин-код и другое.
WebAuthn
В этой секции мы рассмотрим JS API для работы с FIDO2.
Credential Management API
WebAuthn это дополнения к Credential Management API для менеджмента учетных записей публичных ключей. CredMan API это API(неожиданно!) для менеджмента учетных данных пользователя или если выразиться проще: это API для доступа к автозаполнению в браузере.
Далее мы рассмотрим пример создания учетных данных:
navigator.credentials.store({
'type': 'password',
'id': 'alice',
'password': 'VeryRandomPassword123456'
})
А вот пример запроса учетных данных и последующего использования их для аутентификации:
navigator.credentials
.get({ 'password': true })
.then(credential => {
if (!credential) {
throw new Error('No credentials returned!')
}
let credentials = {
'username': credential.id,
'password': credential.password
}
return fetch('https://example.com/loginEndpoint', {
method: 'POST',
body: JSON.stringify(credentials),
credentials: 'include'
})
})
.then((response) => {
...
})
Джеймс Аллардайс сделал прекрасную презентацию в прошлом году по CredManAPI
pusher.com/sessions/meetup/js-monthly-london/building-a-better-login-with-the-credential-management-api
Create public-key credential
Для создания Public-Key Credential мы будем использовать navigator.credentials.create метод, передав ему CreateCredential объект типа «publicKey».
var randomChallengeBuffer = new Uint8Array(32);
window.crypto.getRandomValues(randomChallengeBuffer);
var base64id = 'MIIBkzCCATigAwIBAjCCAZMwggE4oAMCAQIwggGTMII='
var idBuffer = Uint8Array.from(window.atob(base64id), c=>c.charCodeAt(0))
var publicKey = {
challenge: randomChallengeBuffer,
rp: { name: "FIDO Example Corporation" },
user: {
id: idBuffer,
name: "alice@example.com",
displayName: "Alice von Wunderland"
},
attestation: 'direct',
pubKeyCredParams: [
{ type: 'public-key', alg: -7 }, // ES256
{ type: 'public-key', alg: -257 } // RS256
]
}
// Note: The following call will cause the authenticator to display UI.
navigator.credentials.create({ publicKey })
.then((newCredentialInfo) => {
console.log('SUCCESS', newCredentialInfo)
})
.catch((error) => {
console.log('FAIL', error)
})
Думаю, код говорит сам за себя, но отмечу при этом несколько моментов:
— challenge и user.id должны быть буферами
— pubKeyCredParams — это список алгоритмов, которые поддерживает сервер. В данный момент сертифицированные сервера FIDO2 обязаны поддерживать: RSA-PSS 2048 с SHA256/384/512, RSA-PKCS1_3 с SHA256/384/512/1, EC с SHA256/384/512, а также кривые secp256/384/521p1(NIST) и secp256k1, и EdDSA ED25519.
— attestation — это собственно вид аттестации, возвращаемой клиентом. Есть три возможные значения: none, direct, indirect. Direct это, собственно, классическая аттестация. None это полное отсутствие аттестации, при котором клиент просто удалит всю аттестационную секцию и заменит AAGUID в ответе на 0x00000000000000000000000000000000. Indirect это аттестация через privacy-ca. По-умолчанию attestation установлена на none. То есть если вы хотите аттестацию, то надо это чётко указать в параметрах. При этом необходимо учитывать, что пользователь все равно может вам отказать в аттестации и вернуть 'none' если он того захочет.
Вот пример пример того как пользователь может контролировать аттестацию в Firefox Nightly
В ответ вы получите аттестационный объект:
Здесь вы можете видеть:
— id/rawId — это идентификатор пары ключей на устройстве или credId. id это base64url закодированная версия буфера rawId.
— response.clientDataJSON — это буфер CollectedDataJSON, JSON объекта содержащего сессионную информацию и сам вызов. Пример декодированного clientDataJSON:
{
"challenge": "1KnytoY-it44IiEMx0lK5GBlBvAJeVULPSCw5E-5qpA",
"origin": "http://localhost:3000",
"tokenBinding": {
"status": "not-supported"
},
"type": "webauthn.create"
}
— attestationObject — это CBOR объект, содержащий аттестацию, информацию об аутентификаторе, флаги, счётчик и публичный ключ.
— authData — это сырой буфер, содержащий хеш источника или rpIdHash, флаги, счетчик, идентификатор пары ключей, блок с аттестационной информацией и информацию от расширений.
— fmt — это формат аттестации. В данный момент WebAuthn поддерживает «packed», «fido-u2f», «android», «tpm» и «safety-net» аттестации.
— attStmt — это собственно информация по аттестации. Подпись, сертификаты и так далее.
Для верификации подписи мы высчитываем хеш clientDataJSON и получаем clientDataHash. Затем мы объединяем authData и clientDataHash и получаем signatureBase. И в конце мы подтверждаем подпись с помощью attStmt.sig, сертификата или публичного ключа пользователя и signatureBase.
Get assertion
Для того чтобы получить аутентификационую подпись мы будем использовать navigator.credentials.create метод, передав ему объект типа «publicKey».
var randomChallengeBuffer = new Uint8Array(32);
window.crypto.getRandomValues(randomChallengeBuffer);
var idBuffer = encoder.encode("mFuXJYt-0qYZDUBFyN_SW_Cach6U56mrnHA_ZuxtlOnjHLhjfWjYVftbxr4WMmxp1-MG3nRRNQoI7WvvAM0pmw")
var options = {
challenge: randomChallengeBuffer,
allowCredentials: [{ type: "public-key", id: idBuffer }]
}
navigator.credentials.get({ "publicKey": options })
.then((assertion) => {
console.log('SUCCESS', assertion)
})
.catch((error) => {
console.log('FAIL', error)
})
allowCredentials — это список разрешенных учетных записей, которые идентифицируются идентификатором пары ключей на устройстве (credId). Для двухфакторной аутентификации вы всегда обязаны передавать allowCredentials c credId в запросе. Если во время создания учетной записи мы установили флаг authenticatorSelection.requireResidentialKey, то в дальнейшем обязаны не добавлять поле allowCredentials.
В ответ получаем вот такой объект:
Как вы видите, структура очень похожа, но есть несколько различий:
— clientDataJSON.type теперь типа «webauthn.get»
{
"challenge": "-0NPkC-1zxpcGanUJMbKFdd7Ze0kRphWFy1_Sgc4FpI",
"origin": "http://localhost:3000",
"tokenBinding": {
"status": "not-supported"
},
"type": "webauthn.get"
}
— attestationObject отсутствует
— authenticatorData это authData, но теперь без authenticatorAttestation секции
— signature это подпись
— userHandle — это идентификатор пользователя, который вы передали во время регистрации в поле user.id
Вычисление подписи работает так же, как и при создании учетной записи.
UPD: Демо webauthn.org (Нужен U2F токен)
На этом я закончу первую часть из цикла статей. В следующей части мы разберем протокол общения клиента и аутентификатора CTAP2(Client-to-Authenticator 2).
Большая благодарность Павлу Замятину за редактуру и орфографию.
Комментарии (198)
vanburg
04.06.2018 03:30Давно пора, ждем реализацию в бравзях
herrjemand Автор
04.06.2018 03:37Chrome и Firefox уже. Edge пока что только в Insiders Build *)
shifttstas
04.06.2018 09:22В конце страницы ожидал ссылку на демку, не приложите?, хотелось бы в Safari проверить
shifttstas
04.06.2018 09:24Собственно сам нашел: webauthn.org таблица с поддержкой браузеров developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API#Browser_compatibility
dkukushkin
04.06.2018 06:11А как это можно попробовать с точки зрения простого пользователя? Могли бы описать по шагам, на какой сайт зайти, что ввести и пр.
sheknitrtch
04.06.2018 10:41Если Я всё правильно понял, то регистрация и вход на сайт происходят следующим образом:
- Открываете сайт;
- Придумываете имя или вводите email;
- Наживаете кнопку «Зарегистрироваться»;
- Браузер просить подключить FIDO2 токен;
- Вставляете специальный USB токен и нажимаете кнопку на нём;
- Ждёте пока сайт закончит регистрацию;
- return true;
- Открываете сайт;
- Вводите имя или email;
- Нажимаете кнопку «Войти»;
- Браузер просить подключить FIDO2 токен;
- Вставляете USB токен, с которым вы регистрировались на сайте, и нажимаете кнопку на нём;
- Ждёте пока сайт закончит регистрацию;
- return true;
USB токен хранит закрытые ключи и использует их для наложения ЭЦП. приватные ключи не покидают это устройство. Если кто-то взломает сайт, то получит только открытые ключи. При каждой регистрации устройство генерирует новый закрытый ключ.Sklott
04.06.2018 10:45+2Теперь мы теряем USB токен и… мы теряем доступ ко всем сайтам. Замечательно же!
bromium
04.06.2018 10:53Забавно еще и то, что как правило, для совершения операций с токеном требуется… пароль. Который альянс с пафосом публично «убил» (правда, пока только в заголовке поста).
Впрочем, ниже я уже написал, для чего все затеяно.herrjemand Автор
04.06.2018 10:56Хочу заметить что мы не убили пароли как средство верификации. Только как средство аутентификации. То есть между сервером и аутентфикатором FIDO2, а пароль или короткий пин можно прекрасно использовать для верификации на устройстве
bromium
04.06.2018 11:03Только в заголовке к статье вы об этом стыдливо умолчали. А вообще, игра слов. Ввод пароля к токену (который вы обозвали аутентификатором) это аутентификация юзера перед токеном. Хоть как обзовите (верификация, проверка итп). Далее — а как защищается ввод пароля? Поставил тот же килоггер или usb-сниффер. и вот удаленно, пока рассуждаю теоретически, получаешь доступ к данным юзера, который думает, что он защищен, ведь он не дурак, он вместо паролей теперь… аутентификатор юзает
sheknitrtch
04.06.2018 11:07Наверное herrjemand имел в виду пароль, который вводится не на компьютере, а на токене:
Как вы сюда установите кейлогер? ))herrjemand Автор
04.06.2018 11:15У меня также есть токены со считывателем отпечатков:
Также если аутентификатором выступает смартфон, то там можно и пин, и отпечаток, и решение теоремы пифагора
bromium
04.06.2018 11:16Во-первых, автор утверждает, что в качестве аутентификатора может быть мобильное устройство. Во-вторых, я подобными штуками пользуюсь. А также читал статьи, где разбирали безопасность от одного производителя и как легко взломали пароль. В-третьих, кардеры знают множество способов узнать вводимы на пинпаде пин, здесь тема похожая. В четвертых, что вы к словам придираетесь, я привел лишь возможный способ, про юсб сниффинг вы промолчали почему-то
Преимущество пароля в том, что его можно хранить в голове и нигде не размещать и не записывать, и в любое время им можно воспользоваться, без всяких аппаратных штук. Ну а их недостатки мы все знаемsheknitrtch
04.06.2018 11:23А что даст юсб сниффинг? Вы можете перехватить сообщение от браузера к токену или ЭЦП от токена к браузеру. Но это не даёт никакой информации о приватных ключах, хранящихся на устройстве.
bromium
04.06.2018 11:33Я не хочу углубляться в способы взлома, не занимаюсь этим. Но злоумышленнику и не нужны сами приватные ключи, если есть доступ к токену: сформировал поддельный запрос, отправил на токен, подписал.
Возможно, fido2 от этого как раз и защищаетsheknitrtch
04.06.2018 11:35+1Насколько Я знаю, стандарт FIDO подразумевает «Тест на наличие пользователя» (см. статью). То есть пользователь должен совершить какое-то физическое действие с токеном, чтобы инициировать ответ от устройства: нажать кнопку, ввести PIN, отсканировать палец.
Alexeyslav
04.06.2018 11:46+1А смысл пароля без токена? Атакующий не сможет использовать пароль от токена без самого токена. Это очень сильно сокращает область проведения атаки.
herrjemand Автор
04.06.2018 11:48Пароль может быть либо использован если аутентификатор использован в режиме второго-фактора, либо чтобы разблокировать сам аутентификатор
juray
04.06.2018 12:19А что такое «верификация»? Чем отличается от «аутентификации»?
Почему-то во всяких учебниках и статьях в цепочке «идентификация — аутентификация — авторизация» нет никакой «верификации».
Я так понял, вы просто переносите точку ввода пароля «внутрь туннеля», тем самым повышая защищенность процесса. Но это все равно остается аутентификацией.
Полный отказ от пароля — это убирание одного фактора аутентификации, фактора знания. В этом плане действительно, заголовок у вас получился «жёлтый», то есть искажающий факты, описанные в статье.herrjemand Автор
04.06.2018 12:52Верификация и есть идентификация. *)
juray
04.06.2018 13:14Вы такими своими высказываниями с неправильным применением терминологии теряете доверие читателей к вашим компетенциям в сфере ИБ.
Идентификация — это предъявление системе идентификатора, сопоставленного с субъектом (например — логина), без проверки правомерности предъявления идентификатора субъектом.
Сами идентификаторы чаще всего — открытая информация, по крайней мере для участников системы.
пароли как средство верификации
Пароль — средство аутентификации, то есть проверки правомерности владения субъекта идентификатором (фактор знания уникального секрета).
Токен — тоже средство аутентификации (по фактору владения уникальным объектом).
Верификация — это существенно более общий термин, «перепроверка иным, независимым методом», она может применяться и при идентификации и при аутентификации.
Hardcoin
04.06.2018 13:15Разве? Это абсолютно точно не синонимы. Да и не используются пароли для идентификации. Для аутентификации используются.
juray
04.06.2018 14:04Кстати, я вот задумался, а как рассматривать изначальное применение паролей и «токенов» (всякие там перстни) в древние времена, когда «логины» не назывались. Точнее, что удостоверяло знание пароля (или обладание каким-то предметом) в современных понятиях ИБ?
Аутентификацию без идентификации я что-то не могу себе представить. Вот авторизацию — вполне. «Всё что сделал податель сего...» или «знаешь пароль — имеешь право прохода».VolCh
05.06.2018 05:51Это именно секретные токены, свидетельствующие, что хозяин системы произвел идентификацию и аутентификацию и отнёс к одной из групп пользователей.
juray
05.06.2018 12:21О, точно. Идентификация и аутентификация при регистрации.
VolCh
05.06.2018 12:25Ну и отозвать токен могут и надо будет новый получать (если не страшно :) ). Военные пароли собственно тухнут по расписанию штатно, а идентификация и аутентификация часто биометрическая — командир своих солдат в лицо знает :)
juray
04.06.2018 14:49В общем, про «желтизну» я извиняюсь, был неправ.
Я осознал, что описанный вами механизм действительно ликвидирует необходимость в куче паролей для разных сервисов, заменяя этот фактор на аналогичный, но в более защищенной точке (пароль на токене), или на другой (биометрия), также оставляя возможность для пользователя упростить процедуру до одного фактора владения, если его это устраивает.
AlexPancho
04.06.2018 13:01идентификация = аутентификация. Убеждаемся, что вы — это вы. Пример — сотрудник полиции смотрит на фото в вашем паспорте и на вас, спашивает фамилию и год рождения.
авторизация — (от «авторити» — власть) — наличие прав на совершение действия. Т.е.наличие паспотрта не означает, что у вас есть водительские права (дают право вождения) или допуск работ выше 1000 В (дается электрикам после трех лет стажа)juray
04.06.2018 13:20Не равно.
См. мой коммент
Идентификация — это просто «как вас называть», без проверки. Идентификаторы вообще могут присваиваться директивными способами: «по порядку номеров — рассчитайсь!»
VolCh
05.06.2018 05:53Идентификация — спрашивает фамилию, аутентификация — сравнивает фотографию. Сравнение с записанной фамилией в паспорте — поиск записи в базе.
AlexPancho
04.06.2018 13:05верификация — очень в общем проверка подлинности. Паспотрт \ права могут быть настоящими, но не вашими. Потому, правильнее разбивать на аутентификацию\идетнтиикацию и авторизацию
herrjemand Автор
04.06.2018 10:54Вы теряете ключи от дома, и теперь вы не можете зайти в дом. Решение: держать второй ключ в сейфе, жене, бабушке *)
bromium
04.06.2018 11:07После потери ключей, как правило, замки потом меняют. А в случае потери аутентификатора как быть?
herrjemand Автор
04.06.2018 11:14Иметь второй, иметь методы восстановления. Сейчас кстати вышел delegated-recovery протокол, с помощью которого вы можете восстанавливать доступ к своим аккаунтам через третьи сервисы: https://www.facebook.com/notes/protect-the-graph/improving-account-security-with-delegated-recovery/1833022090271267/
Если тема будет интересна я с радостью напишу статью *)
VolCh
04.06.2018 11:25Вот как раз вопрос восстановления доступа к аккаунтам в случае утраты возможности пользоваться текущими будет, по-моему, основным среди конкурирующих способов. Притом, на мой взгляд, победит тот, который предложит гибкие механизмы, типа для доступа к простому форуму по email или sms восстановить вполне нормально, а вот для банка или портала типа «госуслуги» лишь личный визит с паспортом.
Sklott
04.06.2018 11:35+2Ага, замечательный способ. Только чтобы воспользоваться этим механизмом, вам надо зайти на тот-же Facebook (как пример), ключи от которого… сюрприз! на потерянном токене…
У меня уже случилась похожая заморочка, только с e-mail-ом. Пропал доступ к e-mail-у, к которому привязан facebook, к которому привязано n-дцать других сайтов. И я вам скажу, это жопа пострашней атомной войны… Теперь я думаю, что сочетание login/password, без привязки ко всяким e-mail-ам/facebook-ам, это все-же гораздо надежней. Даже при возможности «угона» аккаунтов. Пусть у меня пропадет один аккаунт, зато останутся все остальные.herrjemand Автор
04.06.2018 11:41У Facebook есть список доверенных друзей которые могут вам восстановить доступ https://www.facebook.com/help/204495386254288
Alexeyslav
04.06.2018 11:51А если я никому не доверяю?
herrjemand Автор
04.06.2018 11:56Каждый сайт имеет свои подходы к восстановлению. Кто-то OTP. Кто-то Delegated-recovery. Пока-что нету универсального решения этой проблемы, так что держите бекап аутентификатор в сейфе *)
Eldhenn
04.06.2018 11:12+1Нет, мы теряем уникальный ключ от всех персональных мест присутствия. И мы не можем попасть домой, на работу, на дачу, в дом родителей, в транспорт, в магазин и т.д.
sheknitrtch
04.06.2018 10:55Если потерялась бумажка с паролем от WiFi — придётся менять роутер ))
Проблемы сохранности USB токена — это другой вопрос (надеюсь будет возможность создания резервной копии). Главное, что FIDO2 позволяет не боятся за сохранность паролей на стороне сервера. И Twitter/GitHub не будут присылать тебе письмо с просьбой сменить пароль из-за того, что программисты по ошибке записывают все пароли в лог.bromium
04.06.2018 11:09Не понял только, чем это отличается от входа по токену с эп. На сайт госуслуги давно так захожу. Фидо альянс изобрел очередной велосипед? Что-то имя фидо несчастливое какое-то. Вроде штука интересная, но не живучая
herrjemand Автор
04.06.2018 11:18Рутокен поддерживается всеми браузерами без драйверов и имеет защиту от фишинга?
bromium
04.06.2018 11:25При установке плагина — поддерживается. Что логично. Насчет защиты от фишинга -спросите рутокен, пусть они расскажут
sheknitrtch
04.06.2018 11:20Я не знаю подробностей работы токенов для сайта госуслуг, но фишка FIDO — универсальность. Стандарт FIDO2 поддерживают (или планируют поддерживать) современные браузеры и мобильные ОС, с помощью одного и того токена можно авторизоваться и в Банке, и в Windows домене, и на телефоне (токены работают по NFC).
bromium
04.06.2018 11:23Теоретически да, можно. Если его поддержат банки, ос итп. Но я вот сомневаюсь, что сайты госуслуг будут его поддерживать. В силу специфики и требований использовать гост
herrjemand Автор
04.06.2018 11:27+1Протоколы FIDO используют 750 миллионов пользователей, большая часть которых это пользователи банковских клиентов.
bromium
04.06.2018 11:34Вы говорите про fido2? И как же они пользуются, если по вашим слова в статье браузеры только начали поддерживать этот протокол? Или они устанавливают плагины?
herrjemand Автор
04.06.2018 11:44У FIDO есть три протокола: U2F, UAF и FIDO2. U2F это чисто второй фактор. UAF это целый фреймворк для аутентификации, с разными алгоритмами, с криптографическим подтверждением транзакции и всеми плюшками. UAF сейчас используют более 700млн человек во всевозможных решениях, включая банковские приложения.
Так что у FIDO есть рынок
dkukushkin
04.06.2018 10:52А какой сайт открыть можно уже сейчас и где взять этот USB токен? Сколько он стоит? Что делать на телефоне мобильном? Что делать если потерял?
sheknitrtch
04.06.2018 10:59Ищите, например, в Amazon: www.amazon.com/s/?field-keywords=fido2
Самый известный производитель токенов — компания Yubikey.dkukushkin
04.06.2018 11:09Там физическая кнопка? Раньше у Microsoft была технология беспарольной аутентификации Windows CardSpace — она чем то хуже?
herrjemand Автор
04.06.2018 11:22WebAuthn совместим с U2F так что https://www.amazon.com/Feitian-ePass-NFC-FIDO-Security/dp/B01M1R5LRD либо Yubikey https://www.yubico.com/ вот тут списочек: https://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=u2f
Так же если у вас макбук https://github.com/mplatt/virtual-u2f
sheknitrtch
04.06.2018 11:33+1Так же если у вас макбук github.com/mplatt/virtual-u2f
Вот бы такой эмулятор под Windows :)
Я понимаю, что это понижает безопасность (физическое устройство сложнее взломать), но всё таки надуюсь, что виртуальные токены кто-нибудь реализует.herrjemand Автор
04.06.2018 11:46Я хотел написать один, но писать драйвера эмулятора HID под Windows это 9 кругов ада *(
ValdikSS
04.06.2018 21:08Давно думаю сделать U2F с использованием чипа TPM, который есть во многих ноутбуках, но пока руки не дошли. Это, однако, не так безопасно, как отдельное устройство, т.к. в TPM нет возможности физического подтверждения операции.
herrjemand Автор
04.06.2018 21:10Microsoft как раз работает над этим https://blogs.windows.com/business/2018/04/17/windows-hello-fido2-security-keys/
ValdikSS
04.06.2018 21:18+1Microsoft делает совсем другое — внедряет поддержку физических ключей FIDO2 в инфраструктуру Microsoft. Я же хочу сделать эмулятор физического ключа, который хранил бы все секретные данные в чипе Trusted Platform Module на этом же компьютере (хочу сделать реализацию U2F на TPM).
TPM уже есть во многих ноутбуках, вы уже за него заплатили. Он может делать все те же операции, что и внешний ключ FIDO2, поэтому такой проект, по моему мнению, разумен и востребован.herrjemand Автор
04.06.2018 21:29Тогда для теста на наличие пользователя можно использовать TCG PPI https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/e9d37053-fdbb-4674-8fa5-84b5bc40908a
ValdikSS
04.06.2018 21:43Это не о том, в TPM Physical Presence работает только до загрузки ОС, в настройках UEFI, например. Сделано для того, чтобы из ОС нельзя было очистить данные внутри TPM.
Busla
04.06.2018 19:00В России по-моему проще Джакарту купить, чем Yubikey: www.aladdin-rd.ru/catalog/jacarta-u2f
wolfus
04.06.2018 22:13Не покупайте это никогда. Говорю вам, как внедренец ЕГАИС. Лучше Рутокен.
bromium
04.06.2018 23:27Хорошо бы аргументировать
wolfus
05.06.2018 13:48Навскидку из гугла: olegon.ru/showthread.php?t=27405
У нас из 55 джакарт заблокировалось 55- 100%. Да у всей страны, погуглите.
Просто выкинули в мусор.
Busla
04.06.2018 23:43у Рутокена есть U2F?
Ну и я бы сказал ГОСТовская криптография — слишком специфичная ниша, чтобы опыт работы с ней экстраполировать на все варианты использования. Для внутренних нужд используем JaCarta на Windows и Linux — проблем не было. Рутокен с ГОСТ настраивали клиентам тоже на обеих платформах.
herrjemand Автор
04.06.2018 10:53+1FIDO аутентификатор это не только токен. Им может быть как и физическое устройство в виде токена, так и мобильный телефон.
VolCh
04.06.2018 11:05Расширение для браузера с облачным хранилищем может быть? Или просто отдельный сайт, с которого ключ можно скопипастить?
herrjemand Автор
04.06.2018 19:04Или просто отдельный сайт, с которого ключ можно скопипастить?
Для каждой регистрации генерируется уникальная пара ключей, как вы себе представляете это процесс? В добавок вы будете доверять незнакомому сайту со своим вторым фактором?
Расширение для браузера с облачным хранилищем может быть?
Я видел идею сделать что-то похожее на основе OSX keyChain.
VolCh
05.06.2018 05:58Грубо: вхожу под своей учёткой на этот сайт, вбиваю адрес целевого сайта, он или ключи генерирует, если не найдено, либо даёт уже имеющиеся. По сути key-value хранилище, где ключ — адрес целевого сайта, а значение — пара ключей.
AlexPancho
04.06.2018 09:02Чем вам SRT6 не угодил? Велосипед уже придуман!
sheknitrtch
04.06.2018 10:26Пытался нагуглить, что такое «SRT6». Узнал, что это модель крайслера, фонарик, оружие в игре Battletech. Но так и не нашёл описания метода аутентификации.
Главное достоиство описанного в статье FIDO2 — это поддержка браузерами. Уже сейчас разработчики сайтов могут использовать новые API как одну из опций аутентификации.
site6893
04.06.2018 10:50и что єто такое SRT6? кроме всякой фигни связанной с автомобилями?
Видимо что-то оооочень засекюреное раз даже гугл ничего связанного с ІТ или безопасностью по єтой фразе не выдает )))
herrjemand Автор
04.06.2018 10:51+1Вы наверное имеете ввиду SRP6 https://habr.com/post/121021/
SRP6 и FIDO2 похожи тем что они вызов-ответ протоколы и тем что они генерируют регистрационно зависимые пары ключей. На этом схожесть заканчивается.
FIDO2 также генерирует ключи случайно а не на основе пароля, имеет механизмы защиты от фишинга, поддерживается всеми браузерами, и делегирован аутентификаторам что позитивно сказывается на безопасности.
AlexPancho
04.06.2018 11:06SRP6 тоже присутвует ненулевое разглашение, а поддержка браузерами — ну так ее запилить надо. Хотя я, например, вхожу на сайт с SRP в своем браузере, но, при помощи ява-скриптов. Ну а если все переместить на уровень браузера- будет еще веселей и надежней.
плюсы очевидны -независимость от биометрики.
А еще он разрабатывается в Сенфорде с 1998 г., т.е. все критические моменты там пофикшены: srp.stanford.edu/doc.htmlherrjemand Автор
04.06.2018 11:25+1FIDO2 независим от биометрики. Биометрика это одна из опций верификации а не требование
Goron_Dekar
04.06.2018 10:17А как этим пользоваться на сайтах, где не хочешь оставлять ПД (а таких больше всего)
Чаще всего сайты делятся на 2 группы: в первых ты уже авторизован, а во вторых ты не хочешь быть аутинтифицирован. Это не значит, что ты хочешь быть анонимен, но это значит, что лично тебе нет никакой выгоды от того, что сайт может тебя идентифицировать.
И вот у любого человека должна возникать лёгкая параноя от того, что очередной магазин или сайт для скачивания выкройки будет использовать тот же механизм авторизации, что и банк или личная почта.herrjemand Автор
04.06.2018 10:41+1Аутентификатор генерирует уникальную пару-ключей для каждой регистрации, что сохраняет анонимномть. Почитайте секцию 4. Приватность
VBKesha
04.06.2018 10:36+2И вот мы ушли от страшно неудобных паролей. И получили аутентификатор круто!
Что могло случится с паролем, его могли забыть и украсть(пофиг как).
Что мы получили теперь, во первых в отличии от пароля аутентификатор как я понял железный, а значить стоит денег.
Дальше так как он железный его можно потерять(ну либо украсть и зная логин получить доступ ко всем сайтам жертвы), пароли на сайтах можно менять восстанавливать итд, что делать с токеном как его восстанавливать?
Токен можно забыть, сутра забыл дома и до свиданья почта так?
Токен это железо, у меня например сейчас на столе лежит 3 дохлые влешки, токен ведь также может сдохнуть.
ИМХО недостатков больше чем достоинств.herrjemand Автор
04.06.2018 10:40Аутентификатором может выступать и мобильный телефон
dkukushkin
04.06.2018 11:10Как мне попробовать вашу систему с моб. телефоном? Что нужно сделать по шагам?
juray
04.06.2018 12:40+1Ну, чтобы украсть одновременно и токен (физически) и пароль (программно) у одной и той же жертвы, атака должна быть целевой — то есть более затратной. И она существенно менее вероятна, чем по отдельности перехват пароля или кража токена.
Возможность самому потерять доступ — это обратная сторона практически любой защиты, со степенью защиты от чужого доступа зависимость прямая. Пароль тоже можно забыть.
А процедура восстановления в любом случае должна предусматривать какой-то резервный способ аутентификации, не связанный с основным — чтобы исключить или хотя бы значительно снизить вероятность одновременной утери.
Весь вопрос в балансе — что важнее, лёгкий и непрерывный доступ или защита. Точнее, правильнее будет проанализировать, последствия чего будут хуже — временной потери доступа или утечки. И тут стоит заметить, что утечка пароля сама по себе может вызвать прерывание доступа (злоумышленник меняет пароль и привет).
В разных случаях, конечно, баланс получается разный.VBKesha
04.06.2018 12:58Ну, чтобы украсть одновременно и токен (физически) и пароль (программно) у одной и той же жертвы
Так мы же хороним пароли? Ну судя по заголовку, или хороним но глубоко не закапываем.
Пароль тоже можно забыть.
Как пароль восстанавливать обычно понятно, как восстанавливать токен?
А процедура восстановления в любом случае должна предусматривать какой-то резервный способ аутентификации, не связанный с основным — чтобы исключить или хотя бы значительно снизить вероятность одновременной утери.
По паролю что ли?
что утечка пароля сама по себе может вызвать прерывание доступа (злоумышленник меняет пароль и привет).
И пока не одного ответа как восстановить токен?
PS. Я в общем то не против токенов и прочего, но когда при помощи них начинают хоронить пароли выглядит не очень.juray
04.06.2018 13:33Как уже неоднократно заметили в комментах, хоронятся пароли только в заголовке.
Простая замена пароля токеном — это замена одного фактора аутентификации на другой, при этом она остается однофакторной, а утечка одного фактора имеет достаточно значимую вероятность.
И пока не одного ответа как восстановить токен?
Пока что не описана и процедура начальной инициализации токена.
juray
04.06.2018 15:19Как пароль восстанавливать обычно понятно
Я так понимаю, имеется в виду, что обычно пароль восстанавливается по почте или через привязанный телефон. Правильнее обобщить «резервный канал связи». В случае токена тоже можно предусмотреть резервные каналы. Если уж сайт предоставляет API для токенов, в этом API можно предусмотреть и такие возможности.
И пока не одного ответа как восстановить токен?
А как восстанавливают базу парольного менеджера, если диск накрылся до нечитаемости?
Обычно для этого служат бэкапы.
Без бэкапа ситуация утери кучи паролей сразу — это вообще то еще развлечение, востанавливать пароли по одному.
Конечно, в случае компрометации базы паролей в любом случае придётся их все поменять. В случае токена — зайдя с помощью резервного, а уж сама процедура может быть выполнена автоматически. Заодно можно и отвязать утерянный токен (отозвать ключи). Тут, конечно, возникает угроза, что злоумышленник может так же заблокировать резервный токен, если основной и резервный симметричны (взаимозаменяемы). Остаётся надеяться только на временной лаг у злоумышленника — но при наличии средства аутентификации на самом токене он может быть достаточно большим.
А если несимметричны, и резервный токен имеет приоритет, то он становится таким же резервным каналом, как почта для пароля. И его требуется защищать сильнее, чем основной. Как собственно, и пароль к почте в привычном нам случае сброса пароля.
jrthwk
04.06.2018 16:51… а еще отдельной тема для возможных проблем — это то как этот токен будет работать в разных системах, с разным железом, с разным софтом. То что это типа usb не должно внушать ложных надежд на тему совместимости — её реально не будет. Ну а отдельной темой для проклятий будет работа с этим токеном на мобилах, особенно одной известной фирмы, любящей разъемы не как у всех…
herrjemand Автор
04.06.2018 17:06FIDO2 поддерживает USB, NFC и BLE. USB работает через USB HID, протокол который используют ваши мышки и клавиатуры, так что да наши устройства работают с любой операционной системой
bromium
04.06.2018 10:47Давайте называть вещи своими именами: цель альянса — это продвижение на рынок устройств-аутентификаторов, в которых реализован описываемый протокол. Достаточно посмотреть, кто в него входит — производители микроконтроллеров. Сейчас это вошло в моду: придумывать новые открытые стандарты, протоколы, ведь это вроде как здорово и хорошо, и под это дело толкать на рынок новые девайсы, или микроконтроллеры в составе других девайсов. Вот такая бизнес-модель под вывеской безопасности и открытости
herrjemand Автор
04.06.2018 11:37Аутентификатором может выступать как и токен так и мобильный телефон. Может мы
и рептилоиды, но мы точно не продвигаем рынок железных аутентификаторов. Я вам больше скажу: FIDO2 вредит рынку железных аутентификаторов, так как дает возможность использовать мобильные решение в отличие от U2F.Sklott
04.06.2018 11:55+1Честно говоря сильно смущает необходимость именно отдельного физического устройства. От большинства проблем можно было-бы защитится сделав работу с паролями только внутри браузера.
Т.е. что-то типа такого, навскидку:
1) От сервера приходит chalenge request
2) Браузер на основе введенного пароля и challenge считает некий хэш и отправляет серверу
Тут остаются только два пути утечки: кейлоггер и вирус встраивающийся непосредственно в браузер.
От первого можно защититься с помощью on-screen клавиатуры, от второго и так защита можно сказать есть. Если не поможет, то и FIDO не особо поможет, т.к. мы уже встроились в цепочку клиент/сервер…
Frankenstine
05.06.2018 15:49Честно говоря сильно смущает необходимость именно отдельного физического устройства…
Тут остаются только два пути утечки: кейлоггер и вирус встраивающийся непосредственно в браузер
Дык в том-то и фича, что отдельное физическое устройство решает обе эти (и некоторые другие) проблемы: сервер и физический токен обмениваются сообщениями, подписываемыми приватными ключами, которые не передаются ни в одну из сторон. Ни кейлоггер, ни троян никак не смогут их перехватить, потому что они не покидают физического устройства, на котором применяются.
Уязвимость может быть только тогда, когда вы инициируете работу (регистрируетесь) на уже скомпрометированной системе.Sklott
06.06.2018 08:53Да вот мне пофиг на кейлоггер и троян. Потому как вероятность перехвата ими именно паролей от сайтов (если не говорим про банкинг и т.п.) стремится к 0. В отличие от остальных векторов атаки. К тому-же, если вы параноик, решение для кейлоггера есть.
При всем при этом мне абсолютно не улыбается использовать физическое устройство для доступа везде! (Я пользовался как-то уже довольно давно RSA Token-ом для доступа к рабочему VPN, мне не понравилось). А именно к такому, отсутствию выбора, индустрия нас и толкает…
vassabi
04.06.2018 11:46-1вам больше нравятся проприетарные закрытые протоколы?
herrjemand Автор
04.06.2018 11:48+1Все наши стандарты открытые:
https://fidoalliance.org/specs/ https://w3c.github.io/webauthn/vassabi
04.06.2018 15:50ваши — да, я про обвинителя с его «Вот такая бизнес-модель под вывеской безопасности и открытости»
Desavian
04.06.2018 12:02Ну и ладно, если это действительно приведет к усилению безопасности обычного пользователя, почему бы и нет? Только вот большая часть поленится брать железку и поставит утилиту на мобилку… а это сразу нивелирует всю защищенность. Это все равно что ставить клиент-банк на мобильный телефон, на который приходят смски от двухфакторной авторизации…
herrjemand Автор
04.06.2018 12:13Нет. У Андроида на пример есть безопасное хранилище ключей которое в новых телефонах еще и физически защищено, так что безопасность ключей там на высоте. Также там есть нативный WebAuthn API. Так что безопасность использования FIDO2 на мобильных телефонах будет высокой
Desavian
04.06.2018 17:00Я не говорю про софт, логично что уровень защиты на нем будет не хуже стационарных машин.
Просто мобильные телефоны слишком часто теряют, чтобы держать на них критичные хранилища паролей/аутентификационных данных, а я в статье не увидел ничего про возможность клонирования аутентификатора, чтобы один можно было иметь на мобилке и второй резервный в сейфе.herrjemand Автор
04.06.2018 17:07Самое лучшее комбо это: Мобильный + железный аутентификатор в сейфе. Ничего не надо клонировать, просто регистрируете оба на сайте. Если один теряется, берете другой.
slavius
04.06.2018 12:16Меня гугл не пустил в акк с правильным(!) паролем на телефоне из приватной вкладки — запросил подтверждение на телефон. Это такая hardware привязка аккаунтов к номерам? А если ему не понравится новый хранитель отпечатков?
JC_IIB
04.06.2018 13:19Меня гугл не пустил в акк с правильным(!) паролем на телефоне из приватной вкладки — запросил подтверждение на телефон
У меня не привязаны телефоны к гуглоаккаунтам. Периодически при логине в почту мне показывают окно, где требуют добавить номер «в целях безопасности». Обойти это можно простым обновлением страницы :)
Frankenstine
05.06.2018 15:56Приватная вкладка это как новое устройство — невозможно идентифицировать пользователя. Поэтому ввод правильного пароля в приватной вкладке почти (айпи может совпадать с айпи валидной сессии) не отличается от ввода украденного пароля на устройстве злоумышленника. Именно поэтому гугл относится к таким логинам подозрительно и просит дополнительной валидации, если есть такая возможность (к аккаунту привязан верифицированный телефон).
А если ему не понравится новый хранитель отпечатков?
Гугл не человек, чтобы нравиться или нет, так же как «хранитель отпечатков» :) Если он не узнаёт «хранитель отпечатков», он попросит вас подтвердить, что ему можно доверять. Каким-нибудь доступным способом.
DanielStrolz
04.06.2018 13:43Купил U2F-девайс с full basic attestation (общие ключи и сертификат на партию устройств), при этом устройство не сертифицировано/аттестовано в FIDO. Но это не помешало мне воспользоваться устройством для входа в gmail и dropbox.
Получается, аттестация для простого пользователя не нужна?
И вопрос, herrjemand, требования к прохождению сертификации в webauthn для серверов и аутентификаторов когда должны появиться?herrjemand Автор
04.06.2018 13:48Да, для большинства случаев аттестация не нужна. Это механизм который полезен только серверам у которых реальные требования к типу устройств.
Сертификация сейчас в разработке, мы за последних этапах. Здесь можно запросить доступ к инструментам: https://fidoalliance.org/test-tool-access-request/
DanielStrolz
04.06.2018 18:18Спасибо за ответы.
И еще вопрос, в CTAP2 упоминается ECDH для защиты канала между клиентом и аутентификатором. В webauthn я не нашел этого. Вы не в курсе, это сделано сознательно для упрощения реализации пусть и в ущерб _предполагаемой_ безопасности?herrjemand Автор
04.06.2018 18:41ECDH используется только в клиентском пине для генерации сессионного ключа шифрования пин-кода. Я расскажу ближе об этом в следующей статье *)
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#authenticatorClientPIN
Nirvano
04.06.2018 16:52Было бы здорово придумать не железное решение, а алгоритмическое. Например, если задача стоит не отправлять пароли, то можно на основе пароля генерировать приватный и публичный ключ. А далее уже по этой схеме.
herrjemand Автор
04.06.2018 17:08Протокол открытый. Аутентификатор может быть программным. Пример для U2F https://github.com/github/SoftU2F
thauquoo
Какой-то оверинжиниринг.
Для пользователя «пароль» — это универсальное средство аутентификации, которое не завязано ни на сторонние сервисы, ни на технологии, ни на биометрию. И в клиент-серверных приложениях давно есть возможность не передавать пароль в открытом виде.
vanburg
Похоже вы невнимательно читали раздел про 6 потенциальных дырок при использовании пароля
vanburg
четыре, сорян, засыпаю уже :)
Sklott
Разнообразные физические «заменители паролей» существуют уже очень давно, точно не скажу, но наверняка более 10-ка лет. До сих пор почему-то они пароли не изжили. И тут вдруг приходит «новый стандарт» который конечно же изживет… Конечно, верим…
Он их конечно может изжить если производители браузеров будут тупо давить на всех как сейчас с HTTPS. Но подругому врядли…
AlexPancho
HTTPS — это реальный шаг вперед к безопасности.
А вся биометрика -это реальный шаг назад, сколько бы ее не улутшали. Потому что отпечаток пальца не поменяешь за несколько секунд, у тебя не может быть более 20 отпечатков а паролей- сколько угодно и т.д. и т.п
Sklott
Насчет биометрии согласен, но тут недостаток не только в биометрии как таковой, но еще и в необходимости некоего железа, которое должно эту биометрию как-то снимать. А если надо снимать биометрию на разных устройствах (разных производителей), то где вообще гарантия что все будет одинаково. А если такая гарантия откуда-то вдруг появится, то где гарантия что у «китайского» производителя Х не будет дырки, через которую твоя биометрия «уплывает»…
По HTTPS: я не спорю, что HTTPS — это хорошо там где он нужен. Но зачем HTTPS на сайтах, где защита не нужна в принципе?
Примеры:
— новостной сайт
— библиотека
— простой форум
и т.д. и т.п.
Но нас при этом подпихивают внедрять HTTPS ну просто везде…
При этом ладно бы у HTTPS vs. HTTP не было недостатков, так ведь они есть!
ЗЫ: Вообще этот тут оффтоп, так что предлагаю тему не развивать, просто накипело…
VolCh
Чтобы исключить с одной стороны, подмену контента, например провайдером. Ту же рекламу чтобы не вставлял. Или фейковые новости не публикоал. С другой, не передавать открытым текстом пользовательские данные (логин пароль на форуме, например).
sena
Для того чтобы исключить подмену не нужно шифровать содержание, достаточно его подписывать.
sumanai
Проще зашифровать, чем разбираться, где приватные данные, требующие шифрования, а где публичные, которым достаточно подписи.
sena
Проще не значит лучше. Шифрование делает невозможным работу кэширующих прокси, например.
juray
А https и шифрует и подписывает одновременно.
Реализовать отдельные протоколы, то есть http(какаятобуква) — а как быть если требуется и то и другое? В итоге иметь вместо одного три протокола для двух опций? Проще запихать обе в один и не париться.
herrjemand Автор
HTTPS нужет везде, потому что он гарантирует что вы именно читаете тот новостной сайт а не малварь с соседнего столика
Bal
Он гарантирует только то, что ты о такой подмене узнаешь. У меня на сайте народ с этим уже сталкивается. Вмешательство по пути происходит, а сделать с ним ничего ты не можешь — политика провайдера, например, а поменять его нельзя :)
Alexeyslav
Отпечаток пальца это не пароль. Это способ удостоверится что паролем распоряжается именно владелец. Невозможность сменить отпечаток в этом случае идёт в плюс.
AlexPancho
как подделать отпечаток пальца
253 000 страниц с результатами в открытом доступе.
Alexeyslav
И везде нужен физический доступ к оригинальному отпечатку. Будь-то стакан с бара или любой другой предмет, которого касался пользователь. Это уже сильно усложняет атаку.
sumanai
Или видео с этим человеком.
juray
habr.com/post/356608 — «Отпечатки пальцев человека можно «снять» с цифровой фотографии»
habr.com/post/356612 — «Специалисту удалось получить отпечаток пальца министра обороны Германии по фотографии»
Не говоря уж о том, что можно получить доступ к базе отпечатков:
habr.com/company/pt/blog/267931
Alexeyslav
Это всё хорошо, но в конце статьи имеется интересный вывод: «Пока что технология мало применима в реальности».
juray
Но принципиальная возможность есть.
И с ростом разрешения публичных снимков применимость тоже будет расти.
herrjemand Автор
Все эти виды атаки все равно будут направленные что делает их достаточно дорогими для массовых атак какие мы видим сегодня
juray
Согласен.
Frankenstine
Если отпечатки пальцев в БД будут такими же частыми явлениями, как хэши паролей — их станут так же часто и похищать, ведь защищённость БД с паролями и БД с отпечатками равнозначна. Однако слив пароля к одному сервису это просто беда (если вы человек разумный и не используете один пароль к множеству сервисов), но слив всего одного вашего отпечатка пальца — уже беда-беда…
herrjemand Автор
Отпечатки только хранятся в безопасном хранилище на устройстве и никогда его не покидают. Опять же никто вас не заставляет ими пользоваться, это просто одна из опций.
Frankenstine
Это если речь о сабже, то есть об использовании отпечатка на физическом устройстве для верификации пользователя локально. Но в данном отдельном треде разговор ушёл в сторону использования отпечатка для аутентификации непосредственно на удалённом ресурсе, т.е. когда вы его используете непосредственно, а не для авторизации на промежуточном устройстве. Ну или мне так показалось :)
herrjemand Автор
Да но чтобы сейчас взломать кого-то, достаточно просто перебрать пароли. Чтобы скопировать отпечаток надо лично вас найти сначала. Это все-таки тяжелее для Васи-Пупкина лететь к вам лично чем просто удаленно взламывать
sumanai
Если это было так просто, всех бы уже взломали.
herrjemand Автор
Всех уже и взламывают https://haveibeenpwned.com/
sumanai
Понятно, я везде исключение. Сижу на XP кстати.
Frankenstine
Малварь на лету подменила страницу ответа, чтобы вы оставались в неведении :))
sumanai
Пойду проверю с андроида версии 4.1 )
juray
Такие сервисы, вообще-то сами по себе вызывают приступ паранойи — а не отдаю ли я свой мейл в спамерскую базу?
Ладно хоть, этот довольно известный.
herrjemand Автор
Ну я именно заметил HIBP только потому что он известный и проверенный. Пользуйтесь проверенными сервисами *)
Wesha
Скажите, пожалуйста, с какого дерева Вы рухнули? Не надо искать Вас — достаточно найти любую поверхность, до которой Вы дотронулись. Навскидку — поручень в метро; стакан, который Вы оставили на столе в столовой. Далее в дело вступает скотч.
herrjemand Автор
Во первых будьте любезны не хамить. Никто ни откуда не "рухнул".
Во вторых тот факт что вы ищете отпечаток конкретного человека в местах которых он бывал и есть факт целенаправленности атаки. Мы все можем согласится что поиск отпечатка определенного человека в определенных местах гораздо более трудозатратный процесс чем подбор пароля или фишинг атака.
VolCh
А внедрение в сканеры отпечатков пальцев закладок, которые все «сырые» данные будут слать на сервер злоумышленников?
Alexeyslav
Такие сканеры довольно быстро спалятся. Почему-то банкоматовские клавиатуры ввода пин-кодов не сливают ваш пин-код в сеть. Или сливают?
EviGL
Сливают, скиммерами. Потом карточку блокируют и перевыпускают с другим пин-кодом. Прощайтесь с пальцем :)
Понятно, что набрать базу человек — палец, дороже чем обычные базы человек — пароль.
Но ценность такой базы потенциально намного больше: пароли поменяют, а пальцы останутся навсегда.
VolCh
А отпечатки уже сольются. Что будете делать со своими слитыми отпечтакими, если вообще допустить, что можете с ними (слитыми) что-то делать.
herrjemand Автор
Все сертифицированные продукты FIDO обязаны следовать нашим требованиям защиты информации и приватности которые включают строгий запрет на передачу биометрической информации за предел биометрического сканера. Все компании которые у нас сертифицируются подают документацию по своим биометрическим сканерам и должны пройти дополнительно биометрическую сертификацию.
sumanai
Не весь мир сертифицируется в FIDO, а обычному пользователю вообще невдомёк, что это такое и с чем его едят.
Alexeyslav
поручень в метро затирается очень быстро — прямо следующим за вами пассажиром, со стаканом в столовой примерно та же беда — вам надо буквально подбираться к жертве. А для этого нужно найти…
Hardcoin
Но разве это способ удостовериться? Вот отпечаток снимает железо. Если оно, банально, отправит куда-то снятый отпечаток, то потом кто угодно может им воспользоваться. Где же тут способ удостовериться?
Самая проблема, что поменять не выйдет. Как пользоваться-то потом аккаунтами?
Alexeyslav
Насколько я знаю, всё эти сканеры отпечатков никогда не отдают сырые данные наружу, только хеш отпечатка пальца и не более. Поэтому даже если система будет скомпрометирована, ваш отпечаток никуда не уйдёт.
herrjemand Автор
Даже не хеш а случайны идентификатор.
vm03
https://m.habr.com/post/357708/
"отпечатки приходят просто картинкой и обрабатываются в юзерспейсе"
herrjemand Автор
Есть разные типы считывателей отпечатков. Внешние USB обычно используются именно для сбора отпечатков различными организациями, для централизованного менеджмента. Производителям мобильных телефонов это не нужно. Им нужно только локально верифицировать.
В добавок производители не смогли бы тогда пройти FIPS и PCI/DSS сертификации, что негативно бы повлияло на их эксплуатацию на различных рынках
Hardcoin
Никогда? Даже если в сканере дыра или "окошко" для отладки, которое забыли закрыть?
Вот железо безопасное да. Никогда такого не было, что б через пять лет находили ошибку. Сарказм, если что.
juray
По-хорошему, и хеш отпечатка не должен никуда уходить, а использоваться как секретный ключ.
Danik-ik
Не верьте в незыблемость биометрии. Любая биометрическая информация может измениться по причинам, не связанным с потребностями в аутентификации. У меня набор отпечатков изменился, к примеру — подарил палец онкологам. Другой руку в пилу засунет, третий в морду получит… Риск потерять важный доступ на фоне внезапной (или даже не очень внезапной) трагедии — неотъемлемая фича биометрической аутентификации.
Danik-ik
Хотя есть и "плюс". Если тебя будут пытать молотком по пальцам, ты можешь смеяться и кричать "Но пасаран!"
Alexey2005
Вы наверное удивитесь, но пользователям по большому счёту не нужна безопасность. Им нужно удобство. Это программисты трясутся над безопасностью.
На любом крупном форуме примерно такие отзывы от пользователей и лежат, т.к. HTTPS создаёт кучу точек отказа, и — вот засада! — охрененно глючит на XP. Что-то там у неё за проблемы с поддержкой сертификатов. И на Android 4.2 почему-то глючит, тоже видать где-то что-то там устарело.У среднего юзера на компе может быть полным-полно адвари, и знаете что он ответит, если обратить на этот факт его внимание? «Да пусть хоть миллиард вирусов, лишь бы работать не сильно мешали». А когда спросишь, почему антивирус выключен — «а на кой он нужен, когда от него комп тормозит сильнее, чем от вирусов, да ещё и ни одного кряка не запустишь, он их трёт прямо в момент загрузки».
Так вот, на случай, если вы не знали, что юзеры думают о вашем HTTPS, то думают они примерно так (копипаста с первого попавшегося ресурса):
Поэтому на HTTPS народ загоняют силой, и в основном те, кто на этом зарабатывает.
Пользователю же от этого одни проблемы, и никаких преимуществ.
А в Firefox, видимо для большей любви пользователей к https, оно сейчас выглядит примерно так:
Вот интересно, те, кто такое сотворил — они вообще вменяемые?
juray
sumanai
Не только, ещё SHA2 не поддерживается. Впрочем, FF это исправляет, в нём всё прекрасно работает.
juray
Ну у FF свое собственное хранилище, он не использует системное. Вот прекратят выпускать esr для XP — и всё.
Так и это тоже из-за отсутствия обновлений, только уже не хранилища, а библиотек самой ОС.
sumanai
Можно в общем-то руками.
FF с этим прекрасно справляется.
juray
Что руками?
Добавлять сертификаты в хранилище? Согласен, можно — только нужен другой комп, чтобы достоверно скачать сертификат.
Или собрать FF из исходников? Это как-то не очень тривиально для пользователей Win. Ну и если сами исходники будут заточены под системные вызовы х64, то вообще ой. Хотя не должны, учитывая кроссплатформенность FF.
sumanai
Зачем? Не смотрел, как они там хранятся, но всегда можно поднять например виртуалку и выцарапать из нового.
У меня как раз 64 бита.
juray
Виртуальный или железный — все равно другой.
С новой системой, да.
Но чем выцарапывать из хранилища, наверно проще в этой новой системе открыть хранилище, сделать экспорт, перенести файлы на старую систему и импортировать в системное хранилище.
Собственно, на данный момент для этого даже новая система не понадобится, пока FF на XP работает, можно в нём сертификаты корневых центров экспортировать.
XP 64?
sumanai
Да, этот редкий зверь, самая лучшая ОС, выпущенная МС, по моему мнению.
juray
В том и дело, что редкий.
Но вполне вариант, да.
AlexPancho
Мне кажется это типичная ошибочность рассуждений, вызванная эффектом подтверждения. И еще те, кого всё устраивает, не пишут на форумах и вы не учли их мнение.
Что до Файрфокса — тут, безусловно ЮИ прокол, но причем тут HTTPS?
Ну и пострадавшие на ХП будут страдать всё больше — система давно никем не поддерживается. Почти нет новых браузеров, много утаревших дыр… Скайп вот-вот отвалится… Молимся на РеактОС, потому как моя ноут и теща не признают ничего кроме ХП
sumanai
Знаете? Они никому не нужны, эти дыры. Уже сколько лет сижу на ней, FF разве что перестал обновляться, и я вздохнул с облегчением: больше ничего не сломают.
juray
Если вы постоянно ездите на красный свет, потому что быстрее, или перебегаете дорогу в неположенном месте, потому что короче — аргумент «со мной до сих пор ничего не случилось» не дает вам основания распространять свой опыт на других, какова бы ни была длительность вашего успеха.
Это «ошибка выжившего».
sumanai
Конечно. И я выживший, и моя мама выжившая. Везёт мне наверное.
juray
Именно. Везёт.
Два человека — тоже не может считаться достаточной выборкой для обобщения.
А вот одной моей знакомой не повезло — схватила таки трояна.
sumanai
Она схватила именно трояна, работающего в XP и не работающего в более новых версиях?
juray
Ну, на самом деле — хрен его знает, в чем он работает а чем нет. Твёрдо утверждать не берусь. Тогда не до того было, чтобы таким вопросом задаваться.
Но в любом случае это иллюстрирует, что в софте таки есть дыры и малварь через эти дыры пролезает (на тему «юзер сам что-то запустил» знакомой можно доверять, у нее в этом плане паранойя просто зашкаливает).
А если софт старый, с закончившейся поддержкой — значит, дыры, имеющиеся в последней версии не закрываются не то что оперативно — они не закроются никогда.
Alexeyslav
Это мнение у них будет до первого крупного фишинга в котором они невольно поучаствуют и лишаться своих денег/наработок.
Даже если это сайт с анекдотиками, высока вероятность того что в кафешке на общедоступном WiFi вам подсунут трояна, потом лишитесь паролей и доступа к многим аккаунтам не защищённым двухфакторной авторизацией.
shifttstas
А что плохого? все заменители пароля по факту парольные менеджеры, которые сами за пользователя вводят пароль, менеджер же аутентифицирует пользователя по биометрии (у apple так например).
И все равно, каждый год появляются утечки паролей с сайтов, местами не хэшированные.
Почему бы не убрать промежуточный шаг в виде паролей?
herrjemand Автор
FIDO2 можно использовать полностью без паролей. Выше демка того как это выглядит
juray
Действительно, парольные менеджеры, выполняющие «ввод пароля за пользователя» имеют слабую точку — раз их вывод взаимозаменяем с пользовательским набором с клавиатуры — значит, в этой точке «подмены ввода пользователя» пароль появляется в открытом виде и может быть перехвачен. И если этот участок закрыть, упаковать в шифрованный туннель от менеджера до точки контроля доступа, то смысл в человекозапоминаемых паролях пропадает, лучше сразу использовать ключи-хеши-запросы-ответы — в общем весь арсенал криптографии.
Что, собственно, и отражает заголовок статьи, — это я только что осознал, так то должен взять свои слова про желтизну обратно.
Но это требует переработки самой инфраструктуры, наличия API. Пока есть сайты, принимающие исключительно пароль — эту дырку не закрыть, как ни наворачивай хранилище паролей.
Хранение же сайтами паролей в открытом виде — тема отдельная.
herrjemand Автор
Ни один из существующих методов не решает проблему фишинга. И опать же, как я и говорил, аутентфикатором может быть и мобильное устройство. Не обязательно токен.
bromium
Избитая картинка, но все же у меня такая ассоциация:
Wesha
del