Authentication & Authorization

Wallet-Based Authentication

// Authentication flow
1. Server generates challenge: "Sign this message: [nonce]"
2. User signs with Solana wallet
3. Server verifies signature against public key
4. Session token issued (JWT)

Access Control Model

interface AccessGrant {
  fileHash: string;
  owner: PublicKey;
  recipient: PublicKey;
  createdAt: number;
  expiresAt: number;
  maxAccess: number;
  accessCount: number;
  revoked: boolean;
  signature: string; // Owner's signature
}

Verification:

function verifyAccessGrant(grant: AccessGrant): boolean {
  // 1. Check expiration
  if (Date.now() > grant.expiresAt) return false;
  
  // 2. Check access limit
  if (grant.accessCount >= grant.maxAccess) return false;
  
  // 3. Check revocation
  if (grant.revoked) return false;
  
  // 4. Verify owner's signature
  const message = `grant:${grant.fileHash}:to:${grant.recipient}`;
  return verifySignature(message, grant.signature, grant.owner);
}

Security Model

Threat Model

Assumptions

  1. User's device is secure (not compromised by malware)

  2. User protects their private keys (wallet seed phrase)

  3. Cryptographic primitives are sound (AES-256, SHA-256, Ed25519)

  4. Browser environment is trusted (HTTPS, no MITM)

Threats Addressed

✅ Server Compromise

  • Server never sees plaintext data or keys

  • Encrypted files are useless without user's key

  • Metadata exposure is minimal (file size, timestamps)

✅ Network Eavesdropping

  • All communication over HTTPS

  • Encrypted data in transit

  • No sensitive data in URLs or headers

✅ Unauthorized Access

  • Cryptographic access control (not database ACLs)

  • Time-locked and usage-limited grants

  • Revocable permissions

✅ Data Loss

  • Redundant storage (IPFS + S3)

  • Content-addressed (no accidental overwrites)

  • User can backup keys independently

Threats NOT Addressed

❌ Client-Side Malware

  • If user's device is compromised, attacker can steal keys

  • Mitigation: Hardware wallet support, multi-factor auth

❌ Weak Passwords

  • If user chooses weak password, key can be brute-forced

  • Mitigation: Password strength requirements, wallet-based keys

❌ Social Engineering

  • User can be tricked into sharing keys or signing malicious messages

  • Mitigation: User education, clear warnings in UI

Cryptographic Specifications

Encryption

  • Algorithm: AES-256-GCM

  • Key Size: 256 bits

  • IV Size: 96 bits (12 bytes)

  • Tag Size: 128 bits (16 bytes)

Key Derivation

  • Algorithm: PBKDF2-HMAC-SHA256

  • Iterations: 100,000

  • Salt Size: 128 bits (16 bytes)

  • Output: 256 bits (32 bytes)

Digital Signatures

  • Algorithm: Ed25519 (Solana native)

  • Key Size: 256 bits

  • Signature Size: 512 bits (64 bytes)

Hashing

  • Algorithm: SHA-256

  • Output: 256 bits (32 bytes)

  • Use Cases: File integrity, commitments, IPFS CIDs

Security Best Practices

For Users

  1. Use strong passwords (12+ characters, mixed case, numbers, symbols)

  2. Enable hardware wallet for maximum security

  3. Backup your keys in multiple secure locations

  4. Verify URLs before entering sensitive information

  5. Keep software updated (browser, wallet extensions)

For Developers

  1. Never log sensitive data (keys, passwords, plaintext)

  2. Use constant-time comparisons for cryptographic operations

  3. Validate all inputs (file size, metadata, signatures)

  4. Implement rate limiting (prevent brute-force attacks)

  5. Regular security audits (code review, penetration testing)

PreviousStorage LayerNextUse Cases

Last updated