テーマ： 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 はサブドメインへ送信範囲を広げ、省略するとホスト限定になります。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 のクライアントクレデンシャルによるマシン間アクセス
クライアントクレデンシャルグラントでは、サービスやエージェントが利用者を介さず、自身のクライアント 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?
-
Web アプリケーションのセッション管理の基礎
セッション識別子は十分に長い乱数とし、Secure/HttpOnly/SameSite を付けた cookie で範囲を制限する。ログイン時に再生成し、サーバー側で期限を切り、失効できるようにする。状態はサーバー側、または短寿命の署名付きトークンに保存する。
-
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回復コード：生成、保存、使用済み化
回復コードはルックアップシークレットです。第2要素の登録時に発行する少数のランダムな使い捨てコードを、パスワードのようにハッシュ化して保存し、試行を制限し、1つずつ使用済みにします。電話やキーを失った場合の代替手段なので、発行、利用、再発行は、置き換える要素と同程度に厳重に守る必要があります。
-
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