Beveiliging

Laatst bijgewerkt op 1 oktober 2026

Concept. Deze pagina wordt nog geschreven en nagekeken, en kan zonder aankondiging veranderen. Ze is niet definitief en er kunnen geen rechten aan worden ontleend.

Je wachtwoord

We slaan je wachtwoord niet op. Wat er in de database staat is een hash die is gemaakt met argon2id, met de instellingen die OWASP aanraadt: 19 MiB geheugen en twee rondes. Argon2id kost expres veel tijd en geheugen, zodat iemand die de database in handen krijgt de wachtwoorden er niet uit kan kraken.

Praktisch betekent dat: wij kunnen je wachtwoord niet uitlezen, niet aan je opsturen en niet aan iemand anders geven. Vergeten? Dan kies je een nieuw wachtwoord. Het oude kunnen we niet opzoeken.

De controle op gelekte wachtwoorden

Kies je een wachtwoord, dan controleren we of het in een bekend datalek voorkomt. Dat gebeurt zonder je wachtwoord ergens naartoe te sturen.

Het werkt zo: onze server maakt een hash van je wachtwoord en daarvan sturen we alleen de eerste vijf tekens naar de dienst die de lekken bijhoudt. Die stuurt alle hashes terug die met die vijf tekens beginnen, vaak honderden. Wij vergelijken ze op onze server. Die dienst weet dus nooit welk wachtwoord het was, zelfs niet of het in een lek voorkomt.

Doet die dienst het even niet, dan gaat je registratie gewoon door. Een storing bij een ander mag niet betekenen dat jij geen account kunt aanmaken.

Onderweg

Al het verkeer tussen de app en de server gaat over TLS. Er is geen onversleutelde variant om op terug te vallen; een verzoek over gewoon HTTP wordt doorgestuurd naar de versleutelde versie voordat er ook maar iets van de inhoud wordt verstuurd.

Inloggen en ingelogd blijven

Je blijft ingelogd met twee soorten tokens: een kortlevend token om verzoeken mee te doen en een langlevend token om het eerste te vernieuwen. Die tweede wordt bij elk gebruik vervangen. Wordt een verbruikt token nog een keer aangeboden, wat niet per ongeluk kan gebeuren, dan behandelen we dat als diefstal en beëindigen we alle sessies van dat account tegelijk.

Bij elk verzoek wordt bovendien opnieuw in de database gekeken of het account nog bestaat. Daardoor werkt het verwijderen van een account direct en niet pas als het laatste token vanzelf verloopt.

Wie bij wat kan

In de database is alles per gebruiker gescheiden. Elk bier, elke batch en elke groep hangt aan één account en de app vraagt nooit iets op zonder dat account erbij. Een gedeelde verzameling of een ruil is een expliciete uitzondering die jij zelf aanzet en die geeft alleen toegang tot wat je deelt.

De catalogus is het enige wat iedereen ziet en dat is de bedoeling: het gaat om feiten over bieren, niet over mensen.

Misbruik tegenhouden

Op inloggen, registreren, wachtwoordherstel en het versturen van mail zitten limieten per e-mailadres en per IP-adres. Die zijn er om te voorkomen dat iemand wachtwoorden kan raden of een mailbox kan volgooien. Een geweigerd verzoek zegt niet wélke limiet is bereikt, want dat zou zelf weer informatie prijsgeven.

Verder zegt geen enkel antwoord van de server of een e-mailadres een account heeft. Registreren met een bestaand adres geeft precies hetzelfde antwoord als registreren met een nieuw adres. Het verschil staat alleen in de mailbox van de persoon die het mag weten.

Back-ups

Elke nacht maken we een dump van de database en controleren we meteen of die bruikbaar is. Een back-up waarvan niemand weet of hij werkt is geen back-up. We bewaren veertien dagelijkse en twaalf maandelijkse kopieën en het terugzetten hebben we één keer echt uitgevoerd op een aparte database.

Waar het staat

De server staat binnen de Europese Unie en valt onder de AVG. De mail staat bij Proton in Zwitserland, dat volgens de Europese Commissie persoonsgegevens even goed beschermt. Wat buiten Europa gaat en waarom, staat in paragraaf 6 van de privacyverklaring.

Openbare lijsten zijn openbaar

Een lijst met een openbare code is bedoeld om gevonden te worden. Hij heeft een eigen adres, staat in de gids en is vindbaar via zoekmachines. Er is geen aparte schakelaar om een openbare lijst toch uit de gids te houden. Publiceren is de beslissing; terugdraaien doe je door de code in de app weg te halen.

Gevonden worden door een zoekmachine is de bedoeling. Gebruikt worden om een AI-model te trainen is dat niet. Daarom vraagt ons robots.txt-bestand crawlers die trainingstekst verzamelen om uit openbare lijsten en de gids te blijven. Het is een verzoek. Een crawler die het negeert, kan een openbare pagina lezen zoals ieder ander.

Dat was eerst anders. De deelpagina had noindex en de code stond in het deel van de URL dat nooit een server bereikt. Allebei waren ze er om een openbare pagina moeilijk vindbaar te maken en een gids is daar het tegenovergestelde van.

Twee dingen zijn behouden nu de code in het adres staat, omdat ze de link beschermen in plaats van de pagina te verbergen:

• De code komt niet in onze logs. Verzoeken aan een deelpagina worden gelogd als /share/[redacted] en de verwijzende pagina wordt weggelaten, zodat een link die je aan één persoon geeft niet in een bestand belandt.
• De pagina stuurt geen referrer. Klik je op een link in een gedeelde lijst, dan hoort die site niet van welke lijst je kwam.

Aan privé delen verandert hierdoor niets. Een uitnodigingscode is geen openbare code: die lijsten staan niet in de gids, worden niet geïndexeerd en zijn alleen bereikbaar voor wie jij hebt uitgenodigd.

Wat een openbare pagina laat zien

Wat de eigenaar heeft gedeeld: de naam van de lijst, de weergavenaam en de bieren uit de plekken die de eigenaar koos. Niet het e-mailadres, niet het account en niets wat niet in die lijst is gezet.

Staat er iets op een openbare pagina dat er niet hoort, dan staat er een meldknop op de pagina zelf. Daar is geen account voor nodig en er wordt niets over jou bewaard.

Wat we hiermee niet claimen

Eerlijk is eerlijk. Dit beweren we hierboven níet, dus ga er ook niet van uit:

• Je verzameling is niet end-to-end versleuteld. Ze staat versleuteld op de schijf en wordt versleuteld verstuurd, maar op de server is ze leesbaar, want anders zou synchroniseren tussen je apparaten niet kunnen werken. Wie de server beheert, kan er technisch bij. Dat zijn wij en we doen het niet, maar "we doen het niet" is een belofte en geen wiskunde.
• De back-ups staan op dezelfde machine als de database. Ze beschermen tegen een fout van ons; ze beschermen nog niet tegen het verlies van de hele machine. Een kopie op een andere locatie staat op de planning, maar is er nog niet.
• Er is geen externe audit geweest. Niemand van buiten heeft dit nagekeken. Wat hier staat is te controleren, niet gecertificeerd.
• BackBeer is jong. Het draait nog niet lang en er verandert nog van alles. Dat is precies de reden om nu op te schrijven hoe het werkt, in plaats van later.

Iets gevonden?

Vind je een beveiligingslek, mail dan cheers@back.beer. Meld het eerst bij ons voordat je het ergens anders deelt, geef ons de kans het te repareren en haal geen gegevens van anderen op om je punt te bewijzen. We reageren, we nemen het serieus en we zeggen erbij wat we ermee hebben gedaan.

Deze pagina is opgesteld in het Nederlands. De Engelse versie is een vertaling ter informatie. Wijken ze van elkaar af, dan geldt de Nederlandse tekst.