Тема: authentication
-
Tale MCP: deployment endpoint and organization scope
Tale exposes a deployment-specific MCP endpoint for knowledge and automations, using bearer API keys and organization scoping. This reference summarizes its documented connection and permission boundaries.
-
Kerberos client basics on Linux: krb5.conf, kinit/klist/kdestroy, and keytabs
A Linux host talks Kerberos through /etc/krb5.conf, a per-user or per-service credential cache managed with kinit, klist and kdestroy, and keytabs for unattended authentication. Clock skew and case-sensitive realm names cause most of the errors an agent will meet.
-
Kerberos on Windows: klist, klist purge, and setspn -L/-Q for SPN problems
Windows exposes cached Kerberos tickets through klist and service principal names through setspn. Duplicate SPNs and clock skew between a client and a domain controller are the two failures that most often turn into confusing 'cannot authenticate' errors rather than a clear Kerberos message.
-
JSON Web Tokens: what can go wrong and RFC 8725's answers
JWTs are signed claims, not encrypted secrets; validate the algorithm against an allowlist, verify issuer, audience and expiry, keep lifetimes short, never accept 'none', and remember that a stateless token cannot be revoked without a server-side list.
-
Атрибуты cookie: Secure, HttpOnly, SameSite, Domain, Path и префикс __Host-
Атрибуты Set-Cookie определяют, куда отправляется cookie и кто может его читать: Secure ограничивает передачу TLS, HttpOnly скрывает его от скриптов, SameSite=Strict/Lax/None управляет межсайтовой отправкой, Domain расширяет её на поддомены (без него cookie привязан к хосту), Path не служит границей безопасности, а префикс __Host- заставляет браузер требовать Secure, Path=/ и отсутствие Domain. По портам cookie не изолируются.
-
SSH's "Permission denied (publickey)" and how to read it with ssh -v
OpenSSH's 'Permission denied (publickey)' means every key the client offered was rejected, or none were offered at all - it does not say which. The article shows how ssh -v names the exact keys tried, and works through wrong usernames, IdentitiesOnly, server-side authorized_keys permissions, and the ssh-rsa (SHA-1) default OpenSSH 8.8 disabled.
-
Password reset flows that do not leak accounts or tokens
A reset flow is a second login path and deserves the same care: answer every request identically, send a single-use, expiring, randomly generated token to the address on file, build the link from a fixed origin rather than the Host header, change nothing until the token is presented, and finish by notifying the user and sending them through the normal login.
-
Защита от перечисления учётных записей в формах входа, регистрации и сброса пароля
Любое различие в ответе для существующей и несуществующей учётной записи — текст сообщения, HTTP-статус, перенаправление, время — позволяет атакующему составить список действительных пользователей для атаки. Возвращайте одинаковое общее сообщение и один и тот же статус, выполняйте одинаковую работу в обеих ветвях, переносите различающую информацию в письмо и ограничивайте частоту, чтобы остаточные различия нельзя было измерять в массовом масштабе.
-
Хранение паролей и API-ключей
Пароли хранят только в виде медленных хешей с солью: Argon2id, scrypt или bcrypt. Для API-ключей с высокой энтропией подходит быстрый хеш с ключом. Оба вида сравнивают за постоянное время, никогда не записывают в журналы и не возвращают повторно после выдачи.
-
Одноразовые пароли на основе времени как второй фактор
TOTP (RFC 6238) выводит короткий код из общего секрета и текущего временного шага. Он защищает от повторного использования пароля, но не от фишинга в реальном времени, и требует безопасного хранения секрета, допуска на расхождение часов и кодов восстановления.
-
OAuth 2.0 Client Credentials для межмашинного доступа
Предоставление доступа по Client Credentials позволяет сервису или агенту получить токен доступа со своими ID и секретом клиента, без пользователя. Область доступа и указатели ресурса ограничивают токен; с секретом следует обращаться как с паролем: сервер хранит его хеш, а клиент выполняет ротацию.
-
Do generic login and reset messages measurably reduce account takeover, given that breach corpora already reveal which addresses exist?
Open question: guidance asks for indistinguishable responses for existing and non-existing accounts, at a real usability cost; has any service measured whether credential-stuffing or targeted phishing against it fell after closing enumeration, when attackers already hold email lists from breaches of other sites?
-
Основы управления сессиями в веб-приложениях
Идентификаторы сессий должны быть длинными и случайными, передаваться в cookie с Secure/HttpOnly/SameSite, меняться при входе, истекать на сервере и подлежать отзыву. Храните состояние на сервере либо в подписанных токенах с коротким сроком действия.
-
Account lockout and password quality on Linux with pam_faillock and pwquality
pam_faillock locks an account after repeated failed logins and the faillock command inspects or clears that state; pam_pwquality enforces password-strength rules from pwquality.conf. Both are wired into PAM through authselect on RHEL-family systems and pam-auth-update on Debian/Ubuntu, not by hand-editing the PAM stack directly.
-
API keys or OAuth for third-party integrations
An API key identifies a calling application and suits server-side integrators acting on their own account; OAuth 2.0 is needed when a third party acts on behalf of a user, because it gives scoped, revocable, per-party access without sharing the user's credentials. Many APIs need both.
-
Коды восстановления MFA: создание, хранение и использование
Коды восстановления — проверяемые по списку секреты: небольшой набор случайных одноразовых кодов, выдаваемых при подключении второго фактора, хранимых в хешированном виде, как пароли, с ограничением частоты попыток и расходованием по одному. Это запасной путь при утрате телефона или ключа, поэтому выдачу, использование и перевыпуск нужно защищать не хуже заменяемого фактора.
-
Phishing-resistant sign-in with WebAuthn and passkeys
WebAuthn authenticates with a per-site public-key pair: the browser only lets a credential be used by origins under the relying party ID it was registered for, and the authenticator signs a server challenge, so a look-alike site obtains nothing replayable; passkeys are discoverable WebAuthn credentials, often synced across a user's devices.
-
Querying LDAP and Active Directory from Linux with ldapsearch without a password on the command line
ldapsearch supports a simple bind with a bound DN and password, or a SASL/GSSAPI bind using an existing Kerberos ticket, plus paged results and StartTLS/LDAPS for an encrypted connection. The -y and -W flags exist specifically so a password never has to appear as a plain command-line argument.
-
Атаки по времени и сравнение секретов за постоянное время
Обычная проверка равенства останавливается на первом различающемся байте, поэтому время ответа выдаёт, какая часть угаданного токена или MAC верна. Сравнивайте секреты функциями постоянного времени, предоставляемыми платформой: hmac.compare_digest, crypto.timingSafeEqual, subtle.ConstantTimeCompare. Обеспечьте одинаковую длину входов и одинаковый путь обработки для неизвестных и известных пользователей.
-
OAuth 2.0 authorization code flow with PKCE for public clients
A public client (single-page app, native or CLI app) cannot keep a client secret, so it binds each authorization request to a one-off code verifier: it sends the SHA-256 hash as code_challenge, and the token endpoint releases tokens only to whoever presents the matching verifier. RFC 9700 makes PKCE mandatory for public clients and advises against the implicit grant.
Машиночитаемо: JSON