LINUX.ORG.RU

В OpenSSH добавлена двухфакторная аутентификация

 


6

3

Новая возможность пока имеет статус «экспериментальная». Она позволяет использовать для аутентификации очень дешевые аппаратные ключи, подключаемые через USB, Bluetooth и NFC. Например YubiKey Security Key или Thetis FIDO U2F Security Key with Bluetooth стоят около 100 евро.

Руководство по включению данной аутентификации по ссылке.

>>> Подробности



Проверено: a1batross ()
Последнее исправление: cetjs2 (всего исправлений: 5)

Ответ на: комментарий от AVL2

ты слишком узко воспринимаешь слово канал.

позицию я твою, конечно, понял, может ты и прав, а может и нет — но в любом случае, спор об определениях (что считать фактором, что считать каналом), а не о технической сути

Все же, положа руку на сердце, не скажу что ты меня убедил. На мой взгляд, в приведенной мной статье написано не совсем то, о чем ты говоришь. Там в качестве ПРИМЕРА двухфакторной авторизации приведен случай с логином-паролем + СМС, но то что этот пример описывает двухфакторную не означает что другие примеры не описывают, например с файлом-ключом + паролем.

pihter ★★★★★
()
Ответ на: комментарий от A-234

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

ncrmnt ★★★★★
()
Ответ на: комментарий от pihter

Ну там в качестве ПРИМЕРА не поленились перечислить ВСЕ варианты одноразовых паролей. Включая даже карту предварительно сгенереных паролей, которую я уже в жизни несколько лет как не видел, это же еще эпоха телефонной авторизации платежей.

А простой вариант ключ и (логин)пароль почему то не указали. Или пинкод и банковская карточка или (ру)токен и его пинкод. Потому что есть точка, в которой оба фактора объединяются в один чуть более сложный.

например с файлом-ключом + паролем.

Потому что не тут двух факторов. ;) И в случае с карточкой + пинкод в банкомате тоже нет. И в случае с карточкой и дополнительным cvv кодом тоже нет. Это все дополнительная защита одного фактора.

В этом смысле будем откровенны, двухфакторная авторизация с телефона по смске, которая приходит на этот же телефон, это уже вырожденный случай, потому что появляется точка, в которой доступен перехват сразу двух факторов. В нормальной двухфакторной системе такой точки быть не должно.

AVL2 ★★★★★
()
Ответ на: комментарий от pihter

это была копия. её засунули в банкомат где-то в Германии и сняли деньги со счёта. таких случаев навалом.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Смысл аппаратных ключей в том что без физического доступа к ключу нет шансов на его копирование.

Кроме того в нормальном ключе хардварном ключе не просто сохраняется криптографический ключ, но и соответствующие ему криптографические алгоритмы.

Тоесть без физического доступа к ключу злоумышленник не только не получит доступа к криптографическим ключам, но и не будет иметь понятия о используемых в системе криптографических алгоритмах.

cvv ★★★★★
()
Ответ на: комментарий от AVL2

появляется точка, в которой доступен перехват сразу двух факторов. В нормальной двухфакторной системе такой точки быть не должно

ну вот эта мысль, которую ты отстаиваешь. На мой взгляд (сразу предупреждаю, я не сведущ в вопросе, так что на мой взгляд из деревни), ты это сам выдумал. В статье было написано «N способов аутентификации» то-есть N способов доказать что ты действительно тот, за кого себя выдаешь. Про то, что такие способы обязательно не должны сводиться к общему базису там нет.

Ну там в качестве ПРИМЕРА не поленились перечислить ВСЕ варианты одноразовых паролей ... А простой вариант ключ и (логин)пароль почему то не указали

это все равно ничего не доказывает, только косвенно намекает )

pihter ★★★★★
()
Ответ на: комментарий от Iron_Bug

это была копия. её засунули в банкомат где-то в Германии и сняли деньги со счёта

ну это с твоих слов, а тебе рассказали

таких случаев навалом.

не слышал ни одного. пруфов тоже не увидел. рабочего способа снять копию с карты без инсайдерской информации банка тоже не увидел. не уверую пока персты не вложу

pihter ★★★★★
()
Ответ на: комментарий от ncrmnt

Термин «нормальный» применительно к микроконтроллерам мне не знаком. Но вы явно не в курсе того о чем рассуждать пытаетесь. Вам не только нужно иметь память которая не считывается извне, вам нужно уметь отключать загрузку контроллера с внешней шины, запрещать jtag и т.п. Вы хоть один контроллер толком изучали?

A-234 ★★★★★
()
Ответ на: комментарий от A-234

Термин «нормальный» применительно к микроконтроллерам мне не знаком.

Тот, который выпущен партией больше 500 штук на MPW и продается.

Защита прошивки от копирования для мк сейчас это базовый функционал, который есть везде: avr, msp430, stm32, 8051 (stc, at89, nuvoton). Это из того, что ковырял. При этом у STC вообще возможности ридбэка не заложено принципиально. Загрузку с внешней шины памяти практически никто не делает, только мамонты в LON-устройствах для автоматизации (Только там видел, больше нигде). ESP8266 разве что одно время грузился с внешней SPI, но теперь есть вариант с SPI в одном корпусе с ESP8266. Но там не критично, ибо все конечные устройства привязаны по серийнику к облаку. Можно копировать прошивку сколько угодно, без облака оно бесполезно. Во всех остальных случаях, если нет защиты от ридбэка китайский клон появится не через 3-4 месяца после запуска устройства, а через неделю.

Вам не только нужно иметь память которая не считывается извне, вам нужно уметь отключать загрузку контроллера с внешней шины, запрещать jtag и т.п

Разупорись, как правило это делается либо одним фьюз битом, для удобства, либо несколькими. И включенный JTAG не гарантирует возможности чтения прошивки. См. nrf51822

Вы хоть один контроллер толком изучали?

Нет, это по ходу Вы, батенька вообще от индустрии далеко живете.

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 2)
Ответ на: комментарий от pihter

В статье было написано «N способов аутентификации» то-есть N способов доказать что ты действительно тот, за кого себя выдаешь.

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

AVL2 ★★★★★
()
Ответ на: комментарий от Iron_Bug

Когда тебе надо тысячу и раздать работникам - проще заплатить чем пилить самому.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от AVL2

Там Ki был короткий и без проверок на подбор. Пофикшено лет десять назад.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от ncrmnt

Плохой перевод. Не шифрует и не AES и не номер сессии.

Генерирует на основе закрытого ключа для эллиптической кривой, идентификатора Relying Party (сервера на который идентифицируешься, для браузера - fqdn), подписывает челлендж от сервера для аутентификации.

zink ★★
()
Ответ на: комментарий от pihter

как извечь ключ из банковской карты

Зачем ломиться в запертую дверь, если окно открыто?

DonkeyHot ★★★★★
()
Ответ на: комментарий от zink

Это что-то новое. Последняя реализация, которую я имплементил выглядела как-то так:

#include <arch/antares.h>
#include <avr/eeprom.h>
#include <string.h>
#include <util/crc16.h>
#include <skeleton.h>
#include "aes.h"


/* 8hz timer is recommended */
uint16_t g_timestamp_low;
uint8_t g_timestamp_high;

static uint8_t otps_generated;

#define YUBIKEY_MODHEX_MAP "cbdefghijklnrtuv"
const char trans[] = YUBIKEY_MODHEX_MAP;

void yubikey_modhex_encode (char *dst, const char *src, size_t srcSize)
{
  while (srcSize--)
    {
      *dst++ = trans[(*src >> 4) & 0xf];
      *dst++ = trans[*src++ & 0xf];
    }

  *dst = '\0';
}


inline uint16_t yubi_crc16_update(uint16_t crc, uint8_t a)
{
    int i;

    crc ^= a;
    for (i = 0; i < 8; ++i)
    {
        if (crc & 1)
            crc = (crc >> 1) ^ 0x8408;
        else
            crc = (crc >> 1);
    }

    return crc;
}


void skeleton_send_yubi_token(struct key_yubikey *conf)
{
	int len, i;
	char buf[64];
	struct yubikey_secret_token tok;
	char *ptr;
	uint16_t crc = 0x5af0;
	aes128_ctx_t ctx;


	len = min_t(int, 2 * YUBIKEY_ID_LEN, strlen(conf->pub_string));
	memcpy(buf, conf->pub_string, len);
	memcpy(tok.secret, conf->secret, YUBIKEY_ID_LEN);

	cli();
	tok.timestamp_high = g_timestamp_high;
	tok.timestamp_low  = g_timestamp_low;
	sei();

	tok.insert_count = g_eeprom_conf.insertcount;
	tok.otps = otps_generated++;

	tok.random = rand(); //Fair dice roll

	ptr = (char *) &tok;
	for (i=0; i < sizeof(struct yubikey_secret_token) - sizeof(uint16_t); i++) {
		crc = yubi_crc16_update(crc, ptr[i]);
	}

	tok.crc = crc;

	aes128_init(conf->aes_key, &ctx);
	aes128_enc(&tok, &ctx);

	yubikey_modhex_encode(&buf[len], &tok, sizeof(tok));
	skeleton_type_message(buf);
}

void update_rgb();
ISR(TIMER1_OVF_vect)
{
	if (++g_timestamp_low == 0) {
		g_timestamp_high++;
	}
	//update_rgb();

}

ANTARES_INIT_LOW(timer_init)
{
	TCCR1A = 0;
	TCCR1B = 0;
	ICR1 = 1470; /* ~8Hz at 12Mhz clock */
	TCCR1A = (1<<WGM11);
	TCCR1B = (1 << WGM13) | (1<<WGM12) | 0x5; // /1024
#ifdef TIMSK
	TIMSK = 1<<TOIE1;
#else
	TIMSK1 = 1<<TOIE1;
#endif

}

По сути берем секретную строку, количество втыканий, значение таймера, шифруем AES одним блоком, потом транслируем в modhex и печатаем имитируя клавиатуру.

Кому надо, вот моя старая реализация этих токенов: https://git.ncrmnt.org/firmwares/SkeletonKey/

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 2)
Ответ на: комментарий от ncrmnt

Ну и я сомневаюсь, что кто-то в здравом уме и трезвой памяти будет реверсить скомунизженный токен.

Это смотря что на нем висит. А если кошелек с битками на миллиард?

AVL2 ★★★★★
()
Ответ на: комментарий от ncrmnt

Охрана может помешать. А так ключик на пять минут тиснул и вернул.

AVL2 ★★★★★
()
Ответ на: комментарий от ncrmnt

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

A-234 ★★★★★
()
Ответ на: комментарий от ncrmnt

Ты об этом?

Мой клон YubiKey с блэкджеком: SkeletonKey-R1

Как только отлажу фирмварю - выложу все в опенсорс и сделаю детальное описание.

Получил ли проект развитие? Мне было бы интересно поковыряться.

aquadon ★★★★★
()
Ответ на: комментарий от aquadon

Он самый. Просто запилил себе несколько токенов, и пользуюсь для своих нужд. В массы выводить не думаю. Ну, еще корпус на 3д-принтере распечатал под него. Если обитаешь в мск, могу отсыпать тебе токен в обмен за годный кофеин и патчи ;)

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 2)
Ответ на: комментарий от ncrmnt

Не, я от Москвы далеко обитаю. Давай лучше обещанное

выложу все в опенсорс и сделаю детальное описание

пользуюсь для своих нужд

Причем желательно с описанием сценариев использования :)

aquadon ★★★★★
()
Ответ на: комментарий от aquadon

Собственно, сырцы валяются выше по ссылке: https://git.ncrmnt.org/firmwares/SkeletonKey

Шьется в любую авр с v-usb. На кнопки можно повесить на выбор: yubikey token, реплей длинного пароля, генератор прикольных хостнеймов по тупому алгоритму.

ncrmnt ★★★★★
()
Ответ на: комментарий от ncrmnt

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

yubikey token

Меня больше интересует именно это, т.к. его, вроде, можно с Linux PAM интегрировать.

aquadon ★★★★★
()

Например YubiKey Security Key или Thetis FIDO U2F Security Key with Bluetooth стоят около 100 евро.

Thetis FIDO U2F Security Key $19.99

Thetis BLE U2F Security Key $29.99

aquadon ★★★★★
()
Ответ на: комментарий от aquadon

Вот с этим большая проблема была, от чего я и не допилил до логического завершения тот проект, а так и оставил в минимальном виде.

  1. В том виде, в котором я тогда ковырял, надо было поднимать сервер авторизации с пыхпыхом. Сейчас, как я понимаю, тоже. Если у тебя официальный ключ, то, как я понимаю, ты можешь использовать облако yubi. Причем то, как опенсурс тулы были написаны уверенности не вселяли совершенно, и несколько раз отваливались на моем тестовом сетапе.

  2. Вытекает из пункта 1. Где держать сервера авторизации? Малейший отвал интернета или сети, и мы уже не сможем залогиниться в PAM. А это неприятно даже на моем минимальном сетами (дача и дом с бриджем по впн)

  3. Интеграция с LDAP. Вот это ад и израиль. Я больше занимался любовью с LDAP’ом, чем разводил плату, паял и прогал мк. Уже не помню деталей, но для того, чтобы она взлетела надо было на тот момент либо очень здорово уродовать схему, от чего iRedMail’у плохело, либо патчить OpenLDAP. Я хотел, добавив yubi в LDAP сразу фактически сделать авторизацию через OTP для всех приложений, работающих с LDAP. Не выгорело. Один из примеров - почтовый сервер и nextcloud/rainloop. nextcloud реюзает введенный пароль для логина уже по IMAP, но если пароль протухает при его использовании. В итоге у каждого приложения были свои загоны. Ну и плюс постоянные отвали этой системы-ниппель при обновлении.

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

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 2)
Ответ на: комментарий от ncrmnt

надо было поднимать сервер авторизации

Погоди, так ключ не автономный значит?

Может тогда лучше посмотреть в сторону чего-то другого, что можеть работать с PAM без проблем?

aquadon ★★★★★
()
Ответ на: комментарий от aquadon

В этом то и прикол. приложение, получающее одноразовый пароль должно отправить на сервер авторизации запрос по REST, там в mysql хранятся таймстемпы протухших ключей и инфа для расшифровки. Фактически эти два костыля надо разворачивать.

https://github.com/Yubico/yubikey-val

https://github.com/Yubico/yubikey-ksm

Может тогда лучше посмотреть в сторону чего-то другого, что можеть работать с PAM без проблем?

PAM для меня было некритично, хотелось добавить двухфакторку к веб-сервисам типа nextcloud, gitlab и прочим. Но по ходу везде нужна поддержка OTP самим приложением. Печаль, в общем.

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 3)
Ответ на: комментарий от aquadon

У меня валялось пара рутокенов старых, вроде поддерживаются через opensc, но определяется через opensc только один, и 3/4 команд не работают. Периодически когда обновляю систему тыкаю, не заработали ли, но пока ощущение, что с opensc все печально.

Отдельная проблема это дрова. Плюс йубика - если надо залогиниться в вебморду с потенциально протрояненного компа чужого, и не спалить пароль. А с opensc надо накатывать дрова для pkcs11, а в Винде это вообще пляски с бубном в виде криптопро.

В общем, все печально.

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 1)
Ответ на: комментарий от ivlad

Тогда что-то не сходится. Возможно U2F и OTP добавили сильно позже, уже после того, как я их ковырял. Для OTP надо точно переделывать схематику, т.к. нужна батарейка и RTC.

ncrmnt ★★★★★
()
Ответ на: комментарий от ivlad

напишешь реализацию FIDO2 CTAP в 8 килобайтах?

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

pihter ★★★★★
()
Ответ на: комментарий от pihter

Особые извращенцы могут конечно в усб стик и Линукс зашифрованный и с секурьбутом запихнуть, хехе. Было бы желание.

ncrmnt ★★★★★
()
Ответ на: комментарий от ncrmnt

Все что вы тут перечислили может быть прочитано. Я не просто так про смарт карты написал. Ваш ширпотреб прочтут и ключи сольют. А совсем без защиты есть например миландр, с фьюзами у них контроллеров пока не видел. Да и китайчатина без защиты попадается. То что вы считаете защитой основано на вашей вере в точность спецификаций.

A-234 ★★★★★
()
Ответ на: комментарий от A-234

Давай я возьму с полки ближайшую самую голимую китайщину, например nuvoton 8051, зашью туда /dev/urandom с защитой от ридбэка и предложу тебе считать. Например, можем такой спор провести на хорошие кофейные зерна. Результаты реверса в опенсорс.

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 2)
Ответ на: комментарий от ncrmnt

Особые извращенцы могут конечно в усб стик и Линукс зашифрованный и с секурьбутом запихнуть, хехе. Было бы желание.

почему сразу извращенцы? мож люди так развлекаются? у нас ведь как: если твое хобби — марки или монеты собирать — нормально, если в филармонию ходить скрипку слушать — вообще замечательно, а если человек по горам лазает или там перса качает — ну дурак дураком же...

я к чему — многие находят удовольствие в том, чтоб запихнуть самописного супермарио в 8кб атмеги, на мой взгляд — хобби не хуже других

pihter ★★★★★
()
Ответ на: комментарий от pihter

Ну, вот это всё уже есть в юбике за какие-то небольшие деньги.

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

Потому что тогда можно мысленно разделить ключ на десять частей и получить 10 факторов не вставая с места.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Так иногда и делают на практике - см Shamir Secret Sharing. И это валидно, если части ключа разданы разным людям.

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

двухфакторная авторизация в современном контексте вообще не предполагает второго человека

Аутентификация. То, что ты путаешь два эти понятия говорит о том, что ты вообще в теме не разбираешься.

В случае юбика (и любой другой смарткарты в любом форм факторе) есть два фактора аутентификации - фактор владения (без юбика нельзя залогиниться, ключ считается неизвлекаемым) и фактор знания - пароль от юбика, чтобы он начал работать.

В Шамире ни один из людей не получает собственную аутентификацию. Он вообще не получает никакой аутентификации, часть ключа сама по себе бесполезна, она не позволяет доказать, кто её владелец.

С приватными ключами в файлах ситуация принципиально такая же, как и с юбиком - ни ключ, ни файл сами по себе не обеспечивают аутентификацию. Только их совокупность обеспечивает. То, что зашифрованный файл можно скопировать, принципиально не влияет на схему. Это создаёт другие угрозы, но число факторов не уменьшает.

ivlad ★★★★★
()
Последнее исправление: ivlad (всего исправлений: 1)
Ответ на: комментарий от ivlad

ну стало быть делим в своем воображении файл побайтово и получаем 2048-4096 факторов.

То, что все эти тысячи однобайтовых ключей можно скопировать, принципиально не влияет на схему. Это создаёт другие угрозы, но число факторов не уменьшает.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

ну стало быть делим в своем воображении файл побайтово и получаем 2048-4096 факторов.

дурачок, не знаешь, чем бит от байта отличается?

разница между юбиком и твоим графоманством в том, что в юбике ключ делят не в воображении.

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

Насколько я понимаю, юбикей в том числе реализует OTP, так что и спорить не о чем, это второй фактор. А ключ он, наоборот, не делит и вообще не трогает.

AVL2 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.