Un servicio de tareas cron que hace solicitudes HTTP en nombre de los usuarios es, por definicion, un servicio que maneja credenciales. Tus tareas llaman APIs que requieren autenticacion. Esas claves API, tokens bearer y secretos de webhook necesitan vivir en algun lugar -- y ese lugar mejor que este encriptado, con acceso controlado y auditable.
0cron tiene cuatro capas de seguridad distintas: almacenamiento encriptado de secretos para credenciales de usuario, autenticacion basada en JWT para sesiones del dashboard, autenticacion con clave API para acceso programatico, y verificacion externa para Google Sign-In y webhooks de Stripe.
Capa 1: Secretos encriptados (AES-256-GCM)
Cuando un usuario almacena una clave API en 0cron, ese valor se encripta antes de tocar la base de datos. Usamos AES-256-GCM, el estandar de oro para encriptacion autenticada.
rustpub fn encrypt_secret(plaintext: &str, key: &[u8]) -> AppResult<Vec<u8>> {
let key = aes_gcm::Key::<Aes256Gcm>::from_slice(key);
let cipher = Aes256Gcm::new(key);
let nonce = Aes256Gcm::generate_nonce(&mut OsRng);
let ciphertext = cipher.encrypt(&nonce, plaintext.as_bytes())
.map_err(|e| AppError::Encryption(format!("Encryption failed: {e}")))?;
let mut result = nonce.to_vec();
result.extend_from_slice(&ciphertext);
Ok(result)
}Nonces aleatorios de OsRng. Cada operacion de encriptacion genera un nonce fresco de 12 bytes.
Texto cifrado prefijado con nonce. El formato de almacenamiento es nonce || ciphertext -- los primeros 12 bytes son el nonce, y todo despues es los datos encriptados mas la etiqueta de autenticacion GCM.
La clave de encriptacion es un secreto del lado del servidor. Si la base de datos se compromete, el atacante obtiene blobs encriptados que son inutiles sin la clave.
Interpolacion de secretos en configuraciones de tareas
rustpub async fn interpolate_secrets(text: &str, team_id: Uuid, db: &PgPool, key: &[u8]) -> AppResult<String> {
let re = Regex::new(r"\$\{secrets\.([A-Za-z0-9_]+)\}").unwrap();
let mut result = text.to_string();
for (full_match, key_name) in re.captures_iter(text)... {
// Lookup, decrypt, substitute
}
Ok(result)
}Los usuarios referencian secretos usando sintaxis ${secrets.API_KEY}. La interpolacion ocurre en tiempo de ejecucion, no en tiempo de creacion de tarea. Los secretos nunca se almacenan en texto plano en las configuraciones de tareas.
Capa 2: Autenticacion JWT
Usuarios del dashboard se autentican via JSON Web Tokens con HS256, con un secreto del lado del servidor.
Capa 3: Autenticacion con clave API
Las claves API se hashean con Argon2 antes de almacenarse. Solo el prefijo (primeros 8 caracteres) se almacena en texto plano para busqueda. Argon2 es deliberadamente lento por diseno -- resiste ataques de fuerza bruta basados en GPU.
Capa 4: Verificacion externa
Google Sign-In: Decodificar encabezado JWT, obtener claves publicas de Google, verificar firma RS256, validar claims (aud, iss, email_verified).
Webhooks de Stripe: Verificacion de firma HMAC-SHA256 con tolerancia de marca de tiempo de 5 minutos y comparacion de tiempo constante.
El modulo de secretos de 93 lineas
Todo el modulo de secretos -- encriptacion, desencriptacion e interpolacion -- son 93 lineas de Rust. El middleware de auth son 86 lineas. El codigo total relacionado con seguridad es menos de 400 lineas. Usamos bibliotecas criptograficas bien auditadas (aes-gcm, jsonwebtoken, argon2, hmac) y escribimos las 93 lineas de pegamento que las conectan a nuestro modelo de dominio.
La seguridad no es una funcionalidad que se anade al final. Es una propiedad de la arquitectura. En 0cron, los secretos fueron encriptados desde el dia uno, la autenticacion fue requerida desde el primer endpoint, y las integraciones externas fueron verificadas desde el primer webhook.
Este es el articulo 9 de 10 en la serie "Como construimos 0cron".