Sécurité

1. Architecture de chiffrement

1.1 Chiffrement côté client (Zero-Knowledge)

Lorsque vous activez votre code de sécurité à 6 chiffres, ARGO active un système de chiffrement Zero-Knowledge. Cela signifie que vos données financières (revenus, patrimoine, dettes, objectifs) sont chiffrées directement dans votre navigateur, avant toute transmission vers nos serveurs.

Le processus technique est le suivant :

• Algorithme : AES-256-GCM (Advanced Encryption Standard, 256 bits, Galois/Counter Mode)
• Dérivation de clé : votre code à 6 chiffres est transformé en clé cryptographique via PBKDF2 avec 100 000 itérations et un salt unique par utilisateur
• Vecteur d'initialisation (IV) : un IV aléatoire de 12 octets est généré pour chaque opération de chiffrement
• Stockage du code : votre code de sécurité n'est jamais stocké, ni en clair, ni sous forme hashée, nulle part — ni sur nos serveurs, ni dans votre navigateur

En pratique, cela signifie que même si notre base de données était intégralement compromise, vos données financières resteraient illisibles sans votre code de sécurité. ARGO Labs, nos administrateurs, nos prestataires, et toute personne tierce ne peuvent physiquement pas déchiffrer vos données.

1.2 Chiffrement en transit

Toutes les communications entre votre navigateur et nos serveurs sont chiffrées via TLS 1.3, le protocole de chiffrement le plus récent et le plus sûr. Cela inclut les requêtes vers notre base de données Supabase et les requêtes vers Stripe pour le paiement.

1.3 Chiffrement au repos

Les données stockées dans notre base de données Supabase sont chiffrées au repos via AES-256 au niveau du disque (chiffrement transparent géré par l'infrastructure AWS sous-jacente). Cette couche s'ajoute au chiffrement côté client pour les utilisateurs ayant activé leur code de sécurité.

2. Isolation des données

2.1 Row Level Security (RLS)

Notre base de données utilise les politiques Row Level Security (RLS) de PostgreSQL, activées sur chaque table contenant des données utilisateur. Ces politiques garantissent qu'un utilisateur authentifié ne peut accéder qu'à ses propres lignes de données, quelles que soient les requêtes effectuées.

Concrètement, même si une vulnérabilité applicative permettait d'injecter une requête SQL modifiée, les politiques RLS agissent comme une couche de protection au niveau du moteur de base de données lui-même, empêchant tout accès non autorisé.

2.2 Authentification

L'authentification des utilisateurs est gérée par Supabase Auth, qui implémente les standards suivants :

• Hashage des mots de passe : bcrypt avec un coût adaptif (minimum 10 rounds)
• Tokens JWT : sessions gérées par des JSON Web Tokens signés, avec expiration automatique
• Protection brute-force : limitation du nombre de tentatives de connexion par IP et par compte
• Emails de confirmation : vérification de l'adresse email à l'inscription

3. Paiements sécurisés

Les paiements sont intégralement traités par Stripe, leader mondial du traitement de paiements en ligne. ARGO Labs n'a à aucun moment accès aux données de carte bancaire de l'Utilisateur.

4. Infrastructure & hébergement

4.1 Base de données

• Prestataire : Supabase (PostgreSQL managé)
• Région : Europe — Francfort, Allemagne (eu-central-1)
• Certifications : SOC 2 Type II
• Sauvegardes : sauvegardes quotidiennes automatiques avec rétention de 7 jours, Point-in-Time Recovery disponible
• Réseau : base de données accessible uniquement via le réseau interne Supabase, non exposée sur l'internet public

4.2 Hébergement front-end

• Prestataire : Netlify (CDN global)
• Protection DDoS : incluse nativement dans l'infrastructure Netlify
• HTTPS : certificats SSL/TLS automatiques et renouvelés automatiquement (Let's Encrypt)
• Headers de sécurité : Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options configurés

4.3 Email

• Prestataire : OVH (serveur SMTP)
• Localisation : France
• Protocole : SMTP sur TLS (port 587), chiffrement en transit garanti
• Enregistrements DNS : SPF, DKIM et DMARC configurés pour prévenir le spoofing

5. Ce que nous ne faisons pas

La confiance se construit aussi sur ce que nous choisissons de ne pas faire. Voici nos engagements :

6. Modèle de menaces & limites

Par souci de transparence, voici les scénarios contre lesquels notre architecture vous protège, et ceux qui dépassent notre périmètre :

6.1 Protections actives

• Compromission de la base de données : les données chiffrées côté client restent illisibles sans le code de sécurité
• Interception réseau (man-in-the-middle) : TLS 1.3 empêche toute interception en transit
• Accès non autorisé entre utilisateurs : les politiques RLS empêchent tout accès croisé
• Fuite de données de paiement : aucune donnée bancaire ne transite par nos serveurs
• Brute-force sur les comptes : limitation des tentatives de connexion

6.2 Limites de notre périmètre

• Compromission de votre appareil : si votre ordinateur ou téléphone est infecté par un malware, vos données pourraient être interceptées avant le chiffrement. Nous recommandons de maintenir vos appareils à jour et d'utiliser un antivirus.
• Code de sécurité faible : un code à 6 chiffres offre 1 000 000 de combinaisons possibles. Bien que la dérivation PBKDF2 rende le brute-force extrêmement coûteux, nous recommandons de ne pas utiliser de codes triviaux (000000, 123456, date de naissance).
• Perte du code de sécurité : par conception, nous ne pouvons pas récupérer vos données si vous perdez votre code. C'est le prix de la confidentialité totale.

7. Signaler une vulnérabilité

Si vous découvrez une vulnérabilité de sécurité dans le Service, nous vous encourageons à nous la signaler de manière responsable. Nous nous engageons à :

• Accuser réception de votre signalement sous 48 heures
• Traiter la vulnérabilité avec la priorité la plus élevée
• Vous tenir informé de l'avancée de la correction
• Ne jamais engager de poursuites contre les chercheurs de bonne foi

Contact sécurité : security@argolabs.fr

Nous demandons aux chercheurs de ne pas divulguer publiquement la vulnérabilité avant que nous ayons eu l'opportunité de la corriger (disclosure responsable, délai maximum de 90 jours).

8. Certifications de nos prestataires

9. Mises à jour de cette page

Cette page est mise à jour lorsque notre architecture de sécurité évolue. Nous nous engageons à communiquer de manière transparente sur tout changement significatif de nos pratiques de sécurité.

Pour toute question relative à la sécurité : security@argolabs.fr