Использвание PAM в веб-интерфейсе

TLS/SSL?

А чего ты можешь ещё передать? Каждый из отдельных методов аутентификации PAM'овских в конечном итоге всё равно получает на вход парольную фразу, введённую пользователем. Тебе так или иначе её придётся передавать, так что TLS.

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

Да, это есть, но все равно хотелось чего-то более безопасного. Спасибо!

А чего ты можешь ещё передать?

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

Каждый из отдельных методов аутентификации PAM'овских в конечном итоге всё равно получает на вход парольную фразу, введённую пользователем.

Не додумался до этого, спасибо!

Ну или напиши свой pam_unix.so

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

Я бы зашёл с другого конца и сделал кастомный passwd/usermod, чтобы при установке пароля у тебя он сохранялся ещё в отдельной базе для веб-приложения. И там иметь какую-то прогрессивную схему, например, SCRAM-SHA-1-PLUS https://prosody.im/doc/plain_or_hashed

отдавать твоей вебморде описание метода хэширования, ты будешь выполнять его на клиенте и отдавать хэш обратно своему кастомному pam_unix.so

Только в этом случае парольной фразой будет является не пароль, а hash(пароль), который хранится в открытом виде в /etc/shadow. Это плохо, очень плохо, ибо вся суть теневой аутентификации исчезает.

в открытом виде в /etc/shadow

Почему в открытом?

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

хэши с /etc/shadow солятся «статической» солью вроде как, что понижает криптостойкость

варианты:

- шифрование на клиенте в общем случае способно решить большинство проблем (есть годные реализации на js или написать addon для лисы): это по-сути криптоконтейнер. Либо ssl (персональный)

- hmac (sha-2, sha-256) + динамическая соль

Kerberos + GSSAPI

Почему в открытом?

Потому что в открытом. Если противник скопирует /etc/shadow, то по факту произойдет в этом случае тоже самое, что и в случае, если бы пароли хранились в открытом виде. А все потому, что в этом случае парольной фразой является не пароль, а hash(пароль).

Я бы зашёл с другого конца и сделал кастомный passwd/usermod, чтобы при установке пароля у тебя он сохранялся ещё в отдельной базе для веб-приложения. И там иметь какую-то прогрессивную схему, например, SCRAM-SHA-1-PLUS https://prosody.im/doc/plain_or_hashed

Я бы немедленно удалил свой аккаунт на любом сервисе, который использует подобную схему. Потому, что он, очевидно, спроектирован некомпетентными идиотами, считающими, что хранить пароли в открытом виде — нормально.

Так можно же не пароль хранить а хэши всякие. Поменял пароль в ОС - в БД отправился новый хэш.

То есть хранить 2 разных хэша пароля, хэшировать на клиенте, хэшировать то, что пришло с клиента для сверки с хэшем в БД, используя малопроверенные алгоритмы, и всё это — лишь ради того, чтобы не пользовать SSL?

считающими, что хранить пароли в открытом виде — нормально

Где в предложенной схеме пароли хранятся в открытом виде?

не пользовать SSL

Где в предложенной схеме отказ от TLS?

Если есть TLS, то эта схема не нужна.

Да, в принципе, не обязательна. Но почему-то даже при наличии TLS гонять пароль открытым текстом для аутентификации - моветон. Ну и кто тут некомпетентный идиот?

С чего бы моветон?

Где в предложенной схеме пароли хранятся в открытом виде?

установке пароля у тебя он сохранялся ещё в отдельной базе для веб-приложения

Яснее мысли свои надо излагать. Про характеристику индивидуума предлагающего такую штуку совершенно согласен с предыдущим оратором. Впрочем многие протоколы аутентификации подразумевают хранение секрета (PSK).

По теме - самый простой вариант это GSSAPI / Kerberos, либо не парься - Let's Encrypt вполне юзабелен.

Да у в целом меня нет необходимости в простой аутентификации пользователей или какой-то защите соединения. Мне главное привязать учетки в вебморде к системным, но хотелось сделать это чуть безопаснее средствами PAM, не прикручивая ничего дополнительно. С GSSAPI / Kerberos пока не разбирался, но обязательно займусь

И там иметь какую-то прогрессивную схему, например, SCRAM-SHA-1-PLUS https://prosody.im/doc/plain_or_hashed

Ясно, что вы не в курсе, что это такое. Вот не разжуёшь термин, так мимокрокодилы сразу заклеймят некомпетентным идиотом.

Смысла париться с Kerberos особо нет. Общепринятое решение - POST запрос с login / password через https.