Blue Lodge Credential Briefing

For non-technical stakeholders

Members do not create their own accounts. Grand Lodge issues usernames and passwords centrally. Local lodges import a hashed credential CSV, and only approved members can enter.

• Less confusion: one authority, one list.
• Better control: rapid disable/rotation.
• No plaintext password storage in app data.

For masters, secretaries, trustees

This shifts access from local passphrases to identity-based credentials. If a member transfers, is suspended, or is reinstated, central credential records can be re-issued and re-imported the same day.

• Defines who can access by name, not shared phrase.
• Supports audit posture and incident response.
• Creates a clean path for quarterly credential hygiene.

For Grand Lodge decision makers

Policy recommendation: credentials are issued by Grand Lodge only, distributed through approved channels, and delivered to lodges as hashed CSV with mandatory rotation schedule.

• Standard columns: username, password_hash.
• Hash algorithm baseline: SHA-256 (hex string).
• Operational controls: issue, revoke, rotate, verify.

For IT and implementation teams

Client hashes entered password and compares to imported hash locally. Plaintext is not persisted. Session state can be scoped to browser session only for tighter control.

• Input password -> SHA-256 via Web Crypto.
• Compare with imported hash registry entry.
• Grant session; deny on mismatch.

Who does what

• Grand Lodge: issue registry and cadence.
• Local lodge: import updated hashed CSV.
• Secretary: confirm active roster mapping.
• IT: run periodic control verification.

Common questions

• Why not one shared passphrase? Shared phrases leak and are hard to retire safely.
• What if a member forgets credentials? Reissue from Grand Lodge authority.
• Can this expand later? Yes, to role-based access and centralized identity provider.