Beveiliging

Beveiliging

Versleuteling van de seeds, scheiding per team, rollen, toegangslogboek, accountbeveiliging en hosting: wat Share Auth doet, en wat het niet doet.

Share Auth bewaart geheimen die toegang geven tot accounts. Deze pagina beschrijft hoe ze bij elke stap worden beschermd, en waar de garanties van de tool ophouden.

De seeds blijven versleuteld

Een TOTP-seed wordt met AES-256 versleuteld voordat hij wordt opgeslagen, met een sleutel die eigen is aan de applicatie en niet in de database staat. Hij wordt pas ontsleuteld op het moment dat er een code wordt berekend, in het geheugen, en wordt nooit teruggegeven door de API, de browserextensie of de MCP-connector: die krijgen alleen de actuele code.

Elk team staat op zichzelf

Een geheim hoort bij één team. Elk verzoek controleert of het bij het actieve team van de persoon hoort, en daarna of zijn rol de gevraagde actie toestaat:

  • lezer: codes bekijken en kopiëren, zonder de seed te zien;
  • bewerker: geheimen toevoegen en wijzigen, en hun seed zien;
  • beheerder: dat alles, plus verwijderen en de facturatie;
  • eigenaar: alle rechten, waaronder de leden, de facturatie en het toegangslogboek.

De limieten van je abonnement gelden daarbovenop, zonder ooit iets te verwijderen.

Elke verstrekte code wordt vastgelegd

Het toegangslogboek legt vast wie welke code heeft opgehaald, wanneer en via welk kanaal: site, API, Slack, Discord of Microsoft Teams, met het IP-adres voor de site en de API. Alleen de eigenaar kan het inzien. Herhaalde raadplegingen van hetzelfde geheim door dezelfde persoon worden per vijf minuten samengevoegd, zodat een pagina die openstaat de geschiedenis niet overspoelt.

De chatbots

Elke aanroep van een bot wordt geauthenticeerd met de handtekening van het platform (Slack, Discord of Microsoft Teams), en het aantal opdrachten per persoon is beperkt. Alleen de eigenaar kan een integratie aanmaken, en hij kan haar op elk moment uitschakelen.

Een integratie geeft de hele gekoppelde werkruimte toegang: het platform bewijst waar de opdracht vandaan komt, niet welk Share Auth-account haar geeft, dus de rollen van het team gelden er niet. De beperkingen per kanaal begrenzen de geheimen die elk kanaal kan opvragen. Elke code die een bot verstrekt, staat in het logboek, met de naam die het platform opgeeft.

De accounts zijn beveiligd

  • Tweefactorauthenticatie van je Share Auth-account met een TOTP-app, met herstelcodes.
  • Zonder authenticatie-app moet elke nieuwe browser per e-mail worden bevestigd, via een link of een code. Een bevestigde browser wordt 30 dagen herkend.
  • Je wachtwoord wordt opnieuw gevraagd voordat je een nieuw apparaat koppelt, zoals de browserextensie.

API-tokens zijn begrensd

Een token heeft de rechten die bij het aanmaken zijn gekozen, en niet meer: een token dat codes opvraagt en leest, kan niets wijzigen. De looptijd is 1, 7, 30 of 90 dagen, je trekt het in vanuit je profiel, en de API beperkt elke gebruiker tot 60 verzoeken per minuut.

Hosting en transport

De gegevens worden in Frankrijk gehost. Alles verloopt via HTTPS, met HSTS, en de pagina’s van de applicatie die geheimen tonen, worden nooit in de cache gezet. De details over de dienstverleners staan in het privacybeleid.

Wat Share Auth niet doet

Share Auth deelt 2FA-codes. Het vervangt geen wachtwoordbeheerder en geen strategie voor identiteitsbeheer, en het beschermt geen account waarvan het wachtwoord al rondgaat. Houd de lijst met bewerkers kort: zij zijn degenen die de seeds kunnen zien.

Veelgestelde vragen

Bewerkers, beheerders en eigenaars, op de bewerkpagina van een geheim, zodat ze het ergens anders naartoe kunnen verhuizen. Een lezer ziet alleen de actuele code. De API, de extensie en de MCP-connector geven de seed nooit terug, welke rol je ook hebt.