LINUX.ORG.RU

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

 ,


0

2

Привет!

Есть небольшая вебморда на python, к которой нужно прикрутить возможность авторизации по системным учеткам (того хоста, на котором этот сервер запущен). Через python-pam я могу передать PAM логин+пароль и проверить корректность этой связки, но гонять пароль plaintext'ом мне совсем не хочется. Нет ли каких-то общепринятых решений на этот счет?

А, да, сравнивать хэши с /etc/shadow не получится как минимум потому что прав на доступ к нему нет.

Заранее спасибо!

★★★★★

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

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

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

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

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

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

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

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

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

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

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

alozovskoy ★★★★★
() автор топика

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

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

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

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

Deleted
()
Ответ на: комментарий от Andrey_Utkin

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

alozovskoy ★★★★★
() автор топика

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

варианты:

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ei-grad ★★★★★
()

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

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

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

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от ei-grad

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

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

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

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

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