sleep is for the weak

GMOT-tijd is off by 1:40 minuten

Is er nog genoten van het weer gisteren?

GMOT Zoom-meet met vooraf bepaalde gespreksstof-agenda when?

woooooo

ik WOON in utrecht zelfs :0

Ik denk dat ik nog wat context mis om het merendeel van je antwoord te snappen, maar ik lees het straks nog een keer door.
Wat betreft de afbeelding op GitHub, ik zie dat die van https://www.stamhoofd.be/images/logo.svg moet komen en dat dat naar /404 redirect, welke weer naar /404 redirect, die weer naar /404 redirect, enz. tot Firefox het opgeeft en een infinite redirect error geeft. GitHub probeert het te proxyen maar geeft dan "error fetching resource" met status 404. Just to be sure, ik bedoel deze readme: https://github.com/stamhoofd/stamhoofd/blob/development/README.md

Bedankt!


Je hebt het al aardig onderzocht, tof Leuk al die vragen, meestal beseffen mensen niet echt wat die end-to-end encryptie inhoudt en denkt men dat dat hetzelfde is als versleuteling.

Er zijn inderdaad enkele afwegingen die je hier en daar moet maken. Ik was van plan om daar nog enkele uitgebreidere teksten over te schrijven.

• Als iedereen zijn wachtwoord vergeet (van een vereniging) dan is die vereniging alle data eigenlijk kwijt. Dat is helaas al gebeurd omdat er maar één beheerder was, we raden elke vereniging daarom ook aan om zeker twee beheerders aan te maken. Om dit minder ernstig te maken slaan we de voornaam en e-mailadres niet end-to-end encrypted op, zo kunnen ze tenminste nog een e-mail sturen met de vraag om terug in te schrijven of gegevens aan te vullen (die leden zelf moeten dan trouwens niet meer alles opnieuw ingeven). We gaan later nog een app lanceren, dus in dat geval kunnen we de sleutel nog on-device backuppen (wel nog steeds met toegangscontrole door server). Er komt later misschien ook nog een backup op papier (via een QR-code die je kan afdrukken en die bv. de geëncrypteerde sleutel bevat, en de sleutel voor die sleutel op de server staat als extra veiligheid en toegangscontrole).
• Als een ouder of een lid zijn wachtwoord vergeet, dan kan die nog 'wachtwoord vergeten' doen, maar dan moet hij/zij ook terug alle gegevens invullen (enkel als ze iets willen wijzigen). Dat is een aanvaardbaar nadeel in mijn ogen (ze moeten hun wachtwoord maar onthouden als ze niet alles opnieuw willen ingeven). Daarom ook dat we voornaam bv. nog moeten hebben. Dan weet de ouder nog wie welk lid was als ze de gegevens aanvullen, en kan je nog zaken communiceren als 'Simon' is al ingeschreven bij 'leeftijdsgroep x', wijzig zijn gegevens hier. Voor leden van politieke partijen of andere gevoelige verenigingen, is het wel nog niet ideaal dat we die emailadressen en voornamen publiek hebben staan. Eventueel maken we daar een toggle voor, maar dan moeten we dit probleem op een andere manier oplossen (suggesties welkom).
• Er is momenteel niet echt een trust store of iets wat vertrouwen in een public key ergens opslaat. Elke gebruiker heeft wel een eigen encrypted en authenticated keychain op de server, maar dat is enkel voor private keys. De enige public key die een gebruiker eigenlijk moet vertrouwen is die van de vereniging zelf. En het is in een browser niet echt mogelijk om die persistent op te slaan. Ik speelde al met het idee om die eventueel in een TXT-record van de DNS van de vereniging op te slaan als optionele beveiligingslaag. Maar dan moet die DNS al extern zijn, en moeten ze al genoeg technische kennis hebben om die snel te kunnen wijzigen. Dusja, dat veroorzaakt miscshien te veel andere problemen. Bij sommige verenigingen is die sleutel al moeten wijzigen, dusja, in dat geval had de trust al een probleem veroorzaakt.
• Nog een probleem - wat we nu hebben en moeten oplossen - is voor het importeren van leden uit een bestaande ledenlijst. Daar is het moeilijk om de sleutel bij de leden/ouders te krijgen, omdat ze nog geen wachtwoord of account hebben. Voor beheerders gebruiken we al een key share systeem dat niet via de server verloopt (via link die je stuurt via bv. WhatsApp), maar dat is bij leden/ouders niet echt mogelijk.

De reden dat er nog een aparte encryptedPrivateKey op de server staat is omdat authEncryptionKey gerelateerd is aan het wachtwoord. Als ik daarvoor een public key voor zou moeten opslaan, dan wil ik geen enkel verband tussen die public key en het wachtwoord van die gebruiker (ookal is dat nagenoeg random). De privateKey (uit encryptedPrivateKey ) en publicKey van de user zijn nu wel 100% random. Ik wou geen publiek verband tussen het wachtwoord tentoon stellen, aangezien dat overen zou komen met een offline brute force mechanisme om het wachtwoord te kunnen achterhalen (niet helemaal omdat de authEncryptionKeyConstants niet publiek zijn, maar die staan wel leesbaar op de server, en je weet maar nooit bij een software bug of fout, of een hack). Nu heb je dat verband wel voor de publicAuthSignKey, maar die public key is niet publiek (wel de authSignKeyConstants), en dat is dan ook maar één plaats om in de gaten te houden.

Daarnaast is er nog de mogelijkheid om andere login methodes toe te laten naast wachtwoord based, en dan is het ook nuttig dat er geen verband is met het wachtwoord (dat je misschien niet hebt).

Ik vind de wachtwoord login methode eigenlijk niet echt ideaal, maar het is een afweging die ik heb moeten maken omdat ik nu eenmaal met browsers te maken heb. Je kan daar allereerst geen permanente storage garanderen + mensen switchen regelmatig van browser en device. x aantal bytes per website voor key storage + onmogelijkheid om die te verwijderen zonder dat per website manueel te doen en daar duidelijk een bericht van te krijgen (je verliest mogelijk toegang tot je account voor altijd) zou een oplossing zijn. Er is nu een browser extensie om keys en dergelijke on device op te slaan: https://webauthn.io, maar die ondersteunt nog geen encryptie (enkel signatures) en heeft nog als nadeel dat er geen mechanisme is om keys te sharen tussen computer en smartphone + helemaal geen recovery heeft wanneer je je device kwijt bent (logisch uiteraard). Externe YubiKey zijn een oplossing, maar die zijn helemaal niet ingeburgerd.

Ik had ook echt graag login methode van Apple en Google toegevoegd, vooral omdat ik niet echt wil dat ouders een wachtwoord moeten onthouden voor elke vereniging waar ze inschrijven. Maar end-to-end encryptie maakt dat knap lastig. En je kan ook niet echt iemand verplichten om een app te installeren om te kunnen inschrijven bij een vereniging. Dat laatste is vooral een probleem van branding omdat je niet voor elke vereniging een app kan lanceren. En een vereniging aan hun leden laten vragen om in te schrijven via een app die Stamhoofd heet, is misschien niet ideaal. Hoewel ik dit eventueel wel kan overwegen als een alternatief op wachtwoorden. Zo kunnen ouders kiezen. Maar ik vrees dat als de keuze wordt aangeboden tussen een app installeren of een wachtwoord kiezen, veel mensen wel voor het wachtwoord zullen kiezen. Enja, wat als ze de app verwijderen... Veel problemen hehe.

Edit:
De GitHub header image werkt hier wel hoor? Staat zelf op GitHub gehost zie ik

End to end encryption? Vet! De landing page ziet er ook awesome uit En eventual open source vind ik ook hip.

Hoe werkt de encryptie precies? Ik zie op de site of GitHub niet direct info.

Je github readme header image geeft wel een error bij het laden: https://snipboard.io/CzQAB8.jpg

Edit: ik ben zover dat het libsodium gebruikt aan de client side en een key pair genereert op basis van een geKDF'd wachtwoord en dat upload naar de server en vervolgens mee inlogt.

Open vraag is met name hoe een andere gebruiker die data kan ontsleutelen zonder daarbij de server te moeten vertrouwen. Sla je in localStorage op welke keys er allemaal geverifiëerd zijn door de gebruiker? Kun je elkaars QR-codes scannen? Krijgt de server een versleutelde kopie zodat een nieuwe client die verificatie ook weer heeft? Wat als iedereen tegelijkertijd zijn/haar wachtwoord vergeet, is het dan game over en moet je opnieuw starten als je geen backups hebt? Is eigenlijk alles wel naar iedereen versleuteld, of zijn er dingen die enkel bepaalde gebruikers kunnen ontsleutelen?

Een andere vraag is nog waarom je encryptedPrivateKey op de server hebt als de privkey al vanaf een seed gegenereerd wordt. De gebruiker kan 'm toch opnieuw genereren vanaf dezelfde wachtwoord-gebaseerde seed, de server heeft die toch helemaal niet nodig?

Sorry voor alle vragen, ik vind het vernieuwend en cool maar ben benieuwd naar hoe je verschillende problemen hebt aangepakt

We kunnen ook een legale meeting doen via mibo