Security Best Practices
Recommendations for keeping your Hygate workspace secure.
Overview
Hygate handles sensitive operations: access to physical spaces, payment processing, and team management. This guide covers security best practices across authentication, integrations, data protection, and operational procedures.
Authentication and Access Control
Passwords
| Recommendation | Why |
|---|
| Minimum 16 characters | Makes brute force attacks impractical |
| Mix of upper/lower case, numbers, symbols | Increases the search space |
| Use a password manager | Enables unique, strong passwords for every account |
| Never reuse passwords | Compromised passwords are a common attack vector |
| Change passwords every 90 days | Limits the impact of undiscovered leaks |
Two-Factor Authentication (2FA)
| Recommendation | Why |
|---|
| Enable 2FA for all admin accounts | Protects against credential theft |
| Use Authenticator App over Email OTP | Authenticator apps are phishing-resistant |
| Store backup codes securely | Required for account recovery if 2FA device is lost |
| Don't use SMS-based 2FA | Hygate doesn't support SMS, which is correct — SMS 2FA is vulnerable to SIM swapping |
Login Flow with 2FA
[1] LOGIN ATTEMPT
User enters email + password on login page
│
▼
[2] CREDENTIAL VALIDATION
System validates email/password combination
│
▼
[3] 2FA REQUIRED
If credentials valid → system generates 6-digit code
│
▼
[4] EMAIL DISPATCH
Hygate → Resend API: send email
Email contains: 6-digit code, expiry time (5 minutes)
│
▼
[5] USER RECEIVES EMAIL
User receives email with 2FA code
│
▼
[6] CODE ENTRY
User enters code on 2FA screen
│
▼
[7] CODE VALIDATION
System validates entered code
│
▼
[8] SUCCESS PATH
Valid code: session created, redirected to dashboard
│
▼
[9] FAILURE PATH
Invalid code: error shown
Code expires after 3 attempts or 5 minutes
Session Management
| Recommendation | Why |
|---|
| Set reasonable session timeouts | Reduces the window of opportunity after leaving a session open |
| Enable trust period (30 days) | Balances security with convenience for trusted devices |
| Log out of shared devices | Prevents session hijacking on public computers |
| Monitor audit logs for suspicious logins | Catch unauthorized access early |
Integration Credentials
API Key Management
| Integration | Rotation Frequency | Storage |
|---|
| Stripe | Every 90 days | Encrypted in database |
| TTLock | Every 90 days | Encrypted in database |
| Shelly | Every 90 days | Encrypted in database |
| Resend | Every 180 days | Encrypted in database |
Credential Rotation Procedure
- Generate new keys in the provider's dashboard
- Enter new keys in Hygate Settings
- Test the integration connection
- Verify the old key no longer works
- Revoke the old key in the provider's dashboard
- Document the rotation in audit logs
Credential Storage
- All integration credentials are encrypted at rest in the Hygate database using AES-256
- Credentials are decrypted only at the point of use
- Never store credentials in:
- Version control (
.env, settings.json)
- Plain text files
- Slack, email, or messaging apps
- Shared spreadsheets
TTLock Security
| Risk | Mitigation |
|---|
| Unauthorized lock control | TTLock credentials are encrypted; only admins can configure |
| Credential theft | Rotate credentials every 90 days |
| Guest impersonation | QR access codes are single-use and time-limited |
| Passage mode misuse | Passage mode is logged in audit logs |
| Lock hacking | TTLock uses standard encryption; keep lock firmware updated |
Hardening TTLock
- Use a dedicated TTLock account for the integration
- Enable lock notifications in the TTLock app
- Monitor audit logs for unexpected lock state changes
- Regularly check battery levels in the TTLock app
Shelly Security
| Risk | Mitigation |
|---|
| Unauthorized relay control | Shelly auth keys are encrypted; only admins can configure |
| Relay hijacking | Shelly Cloud API requires authentication for all commands |
| Physical device access | Shelly devices should be installed in tamper-resistant enclosures |
| Network exposure | Shelly devices should be on a separate VLAN if possible |
Hardening Shelly
- Use strong WiFi passwords for Shelly devices
- Enable SSL/TLS for Shelly Cloud communication (enabled by default)
- Place devices in locked enclosures
- Monitor relay state changes in audit logs
Stripe Security
| Risk | Mitigation |
|---|
| Payment fraud | Use Stripe Radar (fraud detection) |
| Webhook spoofing | Hygate verifies Stripe's signature on every webhook |
| Key exposure | Secret keys are encrypted; never share them |
| Refund abuse | Refunds require Stripe Dashboard access; log all refund events |
Stripe Best Practices
- Enable Stripe Radar for automatic fraud detection
- Set up Stripe Alerts for unusual activity
- Monitor the Stripe Dashboard for suspicious transactions
- Enable 3D Secure support — Hygate handles this automatically
- Keep your Stripe account secure with 2FA and strong passwords
Webhook Security
| Protection | Implementation |
|---|
| Signature verification | Hygate verifies Stripe's HMAC-SHA256 signature on every webhook |
| Replay prevention | Webhook timestamps are validated to prevent old webhook replays |
| Secret storage | Webhook secrets are encrypted in the database |
| HTTPS only | Hygate must be served over HTTPS for webhooks to work |
Data Protection
Encryption
| Data | At Rest | In Transit |
|---|
| Integration credentials | AES-256 encrypted | TLS 1.3 |
| User passwords | bcrypt hashed | TLS 1.3 |
| Payment data | Not stored (delegated to Stripe) | TLS 1.3 |
| Audit logs | Encrypted | TLS 1.3 |
| Session tokens | JWT with signature verification | TLS 1.3 |
| Guest emails | Stored as plain text | TLS 1.3 |
What Hygate Does NOT Store
- Credit card numbers (handled entirely by Stripe)
- TTLock account passwords (only MD5-hashed before OAuth)
- Shelly device passwords (if any)
Operational Security
Access Control Principles
| Principle | Description |
|---|
| Least privilege | Assign the Operator role by default; only admins get Administrator |
| Need to know | Operators only see what they need for operations |
| Separation of duties | No single person should control both integration settings and audit logs |
| Regular review | Quarterly review of team access and role assignments |
Audit Log Monitoring
Review your audit logs regularly for:
| Pattern | What It May Indicate |
|---|
| Multiple failed logins | Brute force attack |
| Login from unusual location | Account compromise |
| 2FA method changed | Account takeover attempt |
| Integration credentials updated | Credential rotation or unauthorized change |
| Session force-ended | Equipment issue or unusual activity |
| Bulk deletions | Insider threat or accidental action |
Incident Response
| Incident | Response |
|---|
| Suspected account compromise | 1. Deactivate the account immediately 2. Reset all passwords 3. Review audit logs 4. Rotate all integration credentials |
| Suspected payment fraud | 1. Review Stripe Radar flags 2. Contact Stripe support 3. Review the payment record in Hygate |
| Unauthorized lock activation | 1. Check TTLock app for lock history 2. Review Hygate audit logs 3. Check for suspicious QR code placements |
| Data breach suspected | 1. Contact your hosting provider immediately 2. Preserve all logs 3. Assess scope 4. Notify affected parties |
Infrastructure Security
Server Requirements
| Requirement | Recommendation |
|---|
| HTTPS | Mandatory — enables webhook verification |
| TLS version | TLS 1.3 minimum |
| Firewall | Block all ports except 80, 443, and SSH |
| SSH access | Key-based authentication only, no password SSH |
| Updates | Apply security patches within 7 days of release |
Environment Variables
Never hardcode secrets in your application. Use environment variables:
# Required
DATABASE_URL=
ENCRYPTION_KEY= # 32-byte key for encrypting credentials
STRIPE_SECRET_KEY= # Use Stripe env var directly
# Optional overrides
TTLOCK_CLIENT_ID=
TTLOCK_CLIENT_SECRET=
SHELLY_AUTH_KEY=
RESEND_API_KEY=
Database Security
| Practice | Recommendation |
|---|
| Access control | Use database roles with minimum necessary permissions |
| Encryption | Enable encryption at rest (provided by most cloud providers) |
| Backups | Enable automated backups with encryption |
| Connection pooling | Use connection pooling to limit connections |
| SSL | Require SSL for all database connections |
Compliance
GDPR Considerations (EU)
| Consideration | Recommendation |
|---|
| Guest emails | Only collect if necessary; don't use for marketing |
| Right to erasure | Guest data is pseudonymized in Hygate; Stripe data is managed through Stripe |
| Data retention | Retain payment records as required by financial regulations |
| Audit logs | Keep audit logs for at least 2 years |
| Encryption | Hygate encrypts all sensitive data at rest and in transit |
PCI DSS (Payment Card Industry)
Hygate is not PCI DSS scope because:
- Hygate never stores, processes, or transmits card numbers
- Stripe handles all card data on their PCI-compliant infrastructure
- Hygate only stores Stripe Payment Intent IDs
You remain responsible for:
- Securing your Stripe account with strong credentials and 2FA
- Monitoring for fraudulent transactions
- Maintaining compliance with local payment regulations
Security Checklist
Initial Setup
Integrations
Team
Monitoring
Maintenance