Bewijs uit jouw test:
Inloggen zonder wachtwoord: actief — je ontvangt en gebruikt een persoonlijke e-maillink.
Inloglink 15 minuten geldig: actief — dit wordt door Code.gs afgedwongen.
Dagelijkse PIN: actief — PIN_VERIFY staat in de activiteitenlog.
Vertrouwd apparaat: actief — je werd automatisch opnieuw ingelogd zonder nieuwe e-maillink.
Voor een nette beveiligingsopzet kunnen we hiervan echte instellingen maken:
Dit apparaat 30 dagen vertrouwen — gebruiker kiest dit tijdens het inloggen.
Dagelijkse PIN actief — automatisch afgevinkt na succesvolle verificatie.
E-maillink gecontroleerd — automatisch afgevinkt na MAGIC_CONSUME.
Vertrouwd tot — echte einddatum van het vertrouwde token.
. De databasebasis voor de PIN is nu correct geïnstalleerd. De volgende bouwstap is de gebruikersinterface en de beveiligde koppeling.
We hebben uiteindelijk zes volledige bestanden nodig:
PinView.html — PIN instellen en dagelijks invoeren.
PinStyles.html — vormgeving van het PIN-scherm.
PinScripts.html — PIN instellen, controleren en wijzigen.
Nieuwe volledige Index.html — bevat de extra PIN-weergave.
Nieuwe volledige Scripts.html — controleert na de e-maillogin eerst de PIN.
Nieuwe volledige PortalApi.gs — voorkomt dat iemand de PIN via een directe serveraanroep omzeilt.
Die laatste aanpassing is noodzakelijk. Alleen het PIN-scherm in de browser tonen is niet voldoende beveiliging. Ook alle serverfuncties voor klanten, berichten, offertes en andere gegevens moeten controleren of de dagelijkse PIN geldig is.
De nieuwe volgorde wordt:
E-maillink
↓
Geldige toegangssessie
↓
getPinStatus()
↓
Nog geen PIN → PIN instellen
↓
PIN nog niet dagelijks gecontroleerd → PIN invoeren
↓
PIN geldig
↓
Portal.html laden
↓
Iedere CRUD-aanroep controleert opnieuw sessie + PIN
Bouwvolgorde:
Eerst de drie nieuwe PIN-HTML-bestanden volledig toevoegen.
Daarna de volledige nieuwe Index.html.
Daarna de volledige nieuwe Scripts.html.
Daarna de volledige beveiligde PortalApi.gs.
Vervolgens één nieuwe aparte v2-testdeployment maken.
Laat je huidige werkende deployment ondertussen actief. Maak nog geen nieuwe deployment met alleen PinApi.gs, want de bestaande login blijft voorlopig nog zonder PIN doorwerken.
De eerstvolgende concrete stap is nu de volledige PinView.html.
De nieuwe Portal.html verbetert dit zonder de beveiligingswerking te veranderen:
Uitloggen blijft linksonder beschikbaar.
Er komt een zichtbare uitlogknop rechtsboven.
Op mobiel staat uitloggen in de mobiele bovenbalk.
Het mobiele menu blijft via ☰ bereikbaar.
Dezelfde logoutUser()-functie trekt zowel de sessie als het vertrouwde apparaat in.
Daarna kan direct een tweede gebruiker worden getest.
Na plaatsing en een nieuwe deployment kun je verder testen in deze volgorde:
Log in als ADMIN.
Controleer dashboard en navigatie.
Klik rechtsboven op Uitloggen.
Controleer dat het loginformulier verschijnt.
Log in als gebruiker 2.
Controleer e-mailadres en rol.
Controleer dat beheermodules voor een KLANT verborgen zijn.
Controleer dat de klant alleen records met de gekoppelde Klant_ID ziet.
Daarna is de logische vervolgstap het testen van de eerste echte CRUD-module: Klanten toevoegen, bekijken, bewerken en archiveren.
vandaag 13:56
inloggen lukt nu, ook uitloggen, nu de volgende stap van het proces? Beveiliging van KlantKompas
1 E-maillink en beveiligde sessiesIn deze versie actief > laten we gaan werken aan de >
2 Dagelijkse KlantKompas-PIN Toe te voegen in de volgende bouwfase
en 3 Passkeys Vingerafdruk, gezichtsherkenning of de toestel-PIN
Ja. De volgende stap wordt fase 2: een dagelijkse 6-cijferige KlantKompas-PIN. Daarna bouwen we fase 3 met passkeys.
De PIN wordt niet iedere keer gevraagd, maar maximaal eenmaal per dag per actieve sessie/apparaat.
De gewenste werking:
Gebruiker logt in via de e-maillink.
Nieuwe gebruiker stelt een 6-cijferige PIN in.
De PIN wordt nooit leesbaar in de Sheet opgeslagen.
Bij een vertrouwde login vraagt KlantKompas dagelijks de PIN.
Na een correcte PIN wordt het portaal geopend.
Na vijf verkeerde pogingen wordt de PIN tijdelijk geblokkeerd.
Een vergeten PIN kan alleen via een nieuwe beveiligde e-maillink worden hersteld.
Uitloggen trekt sessie en vertrouwd apparaat in.
De toegangsstatus wordt dan:
E-maillink geldig
+ actieve sessie
+ dagelijkse PIN gecontroleerd
= toegang tot Portal.html
PIN_Auth:
Kolom
Functie
Pin_ID
Uniek record
User_ID
Gekoppelde gebruiker
Pin_Hash
Beveiligde hash
Salt
Uniek willekeurig salt
Aangemaakt
Insteldatum
Gewijzigd
Laatste wijziging
Actief
JA/NEE
Mislukte_Pogingen
Teller
Geblokkeerd_Tot
Tijdelijke blokkering
PIN_Verifications:
Kolom
Functie
Verification_ID
Unieke controle
User_ID
Gebruiker
Session_ID
Actieve sessie
Device_ID
Vertrouwd apparaat
Geverifieerd_Op
Controlemoment
Geldig_Tot
Einde dagelijkse toegang
Resultaat
SUCCES/GEWEIGERD
Een PIN heeft maar een beperkt aantal combinaties. Daarom gebruiken we:
Zes cijfers in plaats van vier
Uniek salt per gebruiker
Server-side geheime pepper
Alleen een hash in de Sheet
Maximaal vijf pogingen
Tijdelijke blokkering
Logging in Security_Log
Geen informatie over de juiste PIN in de browser
Geen toegang tot Portal.html voordat de PIN-controle geldig is
De PIN is een extra beveiligingslaag, maar geen vervanging voor een echte passkey.
Voor fase 2 maken we:
PinApi.gs — instellen, controleren, blokkeren en herstellen
PinView.html — PIN instellen en dagelijks invoeren
PinStyles.html — vormgeving
PinScripts.html — browserinteractie
Volledige nieuwe Index.html
Volledige nieuwe Scripts.html
Code.gs, PortalApi.gs, Portal.html, PortalScripts.html en PortalStyles.html