/
BIN - Inloggen en wachtwoorden

BIN - Inloggen en wachtwoorden

 

Inleiding

Dit document beschrijft het inloggen en de specificatie voor wachtwoorden. Aan het inloggen zijn vooraf aan het ontwikkeltraject geen andere eisen gesteld, dan dat two-factor-authenticatie (2FA) vereist was. Gedurende het ontwikkelen heeft het inloggen vorm gekregen. Enkele wensen die daaruit zijn ontstaan, zijn nog niet ingevuld of is verbetering wenselijk.

Beschrijving

Zie voor een beschrijving van de gebruikers document ‘BRL - Beheerdersrollen’.

BIN - Eisen (en aanbevelingen) inloggen

Eisen (en aanbevelingen) inloggen:

#

Eis

#

Eis

001

Gebruikersnaam is minimaal 6 karakters en alfanumeriek, zonder spaties en tekens.

002

Gebruikersnaam mag na aanmaken niet gewijzigd worden.

003

Toegang met Two-Factor Authenticatie (2FA) voor beheerders is vereist en mag niet uitgeschakeld kunnen worden.

004

Wachtwoord moet voldoen aan de eisen van security. Zie specificaties hieronder.

005

Het moet mogelijk zijn om testusers aan te maken.

006

Ingevoerde nieuwe wachtwoord moet herhaald worden voor verificatie.

007

Bij eerste keer aanloggen of op verzoek gebruiker wordt een QR code getoond, die ingescand kan worden in een authenticator app, zodat het account gekoppeld kan worden aan de app.

008

Er zijn geen restricties m.b.t. welke authenticator app gebruikt mag worden.

009

Indien een verkeerd wachtwoord of een verkeerde 2FA code wordt ingevoerd verschijnt de melding: 'Het aanmelden is mislukt. Dit kan komen doordat uw gegevens onjuist zijn en/of uw account geblokkeerd is.' (Er kan geen onderscheid gemaakt worden tussen een ongeldige gebruikersnaam/wachtwoord/code en een account dat geblokkeerd is.)

010

Wordt voor de 5e keer fout ingelogd dan verschijnt '503 service unavailable' pagina. (Dit is standaard IRIS gedrag.) (In de tst omgeving is dat een '403 Forbidden' pagina.)

011

De ingelogde user is zichtbaar op het scherm, en heeft de mogelijkheid om uit te loggen uit de beheerapplicatie.

012

Een mislukte aanlog poging moet zichtbaar worden in de application log. In dit geval moet een log regel gemaakt worden met “Foutieve inlogpoging“, datum/tijd, eventuele gebruiker.
In de details van de log regel moet de afzender staan (indien beschikbaar).

013

Voor een gebruiker die niet actief is en/of waarvoor de einddatum geldigheid is verstreken mogen geen notificatiemails worden uitgestuurd

014

Een beheeraccount heeft een maximale geldigheid van 90 dagen. Veel beveiligingsstandaarden en regelgeving, zoals ISO 27001 en NIST, bevelen een wachtwoordverlooptermijn van 90 dagen aan. Door een wachtwoordverlooptermijn van 90 dagen in te stellen, vinden we een goede balans tussen het beschermen van gevoelige gegevens en het behouden van een werkbare en
gebruiksvriendelijke omgeving voor de beheerders binnen de koppeltaalvoorziening.

015

Wanneer een wachtwoord verloopt stuurt het systeem een mail, conform genoemde template, naar de gebruiker met de waarschuwing dat het wachtwoord verloopt.

016

Bij het verlopen van het wachtwoord moet de gebruiker verplicht worden tijdens het login proces zijn wachtwoord te wijzigen.

017

De laatste 10 wachtwoorden mogen niet opnieuw gebruikt worden. Er verschijnt dan de melding: "Dit wachtwoord is eerder gebruikt; dat is niet toegestaan."

018

Scherm om wachtwoord te wijzigen: Indien 'nieuw wachtwoord' en 'herhaal nieuw wachtwoord' niet overeenkomen, dan verschijnt de melding: "De wachtwoorden komen niet overeen".

019

Scherm om wachtwoord te wijzigen: Indien oud wachtwoord niet correct is, verschijnt de melding: "Wachtwoord kon niet gewijzigd worden (oude wachtwoord is niet juist)".

020

Zolang de gebruiker geen actie onderneemt omdat het wachtwoord is verlopen, wordt elke 7 dagen en 2 dagen voor einde termijn, een herinneringsmail verstuurd naar de gebruiker.

021

Na het verlopen van zijn/haar wachtwoord heeft de gebruiker een periode van 30 dagen de
mogelijkheid om alsnog zijn wachtwoord bij inloggen te wijzigen. Daarna wordt account inactief gezet.

022

Bij het activeren van bestaande gebruikers, wordt de einddatum automatisch op 31-12-2099 gezet. (Veld kan niet leeg gelaten worden in IRIS). (Zie ook BRL - eis 012)

N.B. Het is niet mogelijk om met 2 verschillende user binnen dezelfde browser aan te loggen. Dit heeft met de cookies in de browser te maken.

 

Er staan nog verschillende verbeterpunten open die nog gespecificeerd moeten worden, o.a. 018:

  • Toevoegen functie als 'Wachtwoord vergeten?'

Hiervoor kan contact met KT Support opgenomen moet worden.

Van Security zijn de volgende algemene specificaties voor wachtwoorden ontvangen:

#

Eis

#

Eis

001

Voor gewone gebruikers: Een sterk wachtwoord is een wachtwoord bestaande uit minimaal 12 karakters, bestaande uit letters, minimaal 1 hoofdletter, 1 cijfer en 1 leesteken. Het is niet toegestaan om herhaalde of opeenvolgende tekens (bijvoorbeeld 'aaaaaa', '1234abcd') te gebruiken. Deze instellingen moeten worden afgedwongen. --> N.B. Deze eis is in overleg, n.a.v. ondervonden problemen, voor Koppeltaal aangepast: Het is mogelijk om 2 zelfde of opeenvolgende tekens te gebruiken.

002

Voor het wijzigen van wachtwoorden wordt de periode afgestemd op het risicoprofiel. Best practices bij NIST geven nu zelfs grote termijn aan (2 jaar). Bij het wijzigen moeten afgedwongen worden dat niet hetzelfde wachtwoord gebruikt kan worden (wachtwoord historie van 10 vorige wachtwoorden).

003

Wachtwoorden worden in beveiligde vorm (onleesbaar/gehashed en gesalt) opgeslagen in systemen.

004

Standaard wachtwoorden en accounts moeten direct worden gewijzigd.

005

Gebruikers worden geïnstrueerd wachtwoorden geheim te houden, niet hetzelfde wachtwoord op meerdere plekken te gebruiken, niet te delen met anderen en niet te gebruiken bij zelf gemaakte inlogprocessen via b.v. scripts of macro’s.

006

Wachtwoorden voor accounts met admin (root) rechten worden bij voorkeur éénmalig uitgegeven met een vooraf gedefinieerde expiratie tijd (one time password en Account Checkout).

007

Wachtwoorden voor service accounts en local admin accounts zijn door één beheerder aangemaakt, minimaal 20 karakters lang en worden bewaard in een password manager.

008

Voor functionele accounts, zoals een service-/local admin accounts, dient een natuurlijk persoon aangewezen te worden die er voor verantwoordelijk is.

009

Na 10 foutieve inlogpogingen wordt de account gelock. --> N.B. Deze eis is anders geïmplementeerd in Koppeltaal: Het account wordt uitgeschakeld na 5 keer invoeren fout wachtwoord en/of 5 keer invoeren van een foute 2FA code.

Verlopen wachtwoord


Het wachtwoord van een gebruiker verloopt na 90 dagen. De gebruiker dient het wachtwoord dan te
wijzigen, en ontvangt hiervoor een emailnotificatie.


Het verwerkingsproces draait 's nachts en zoek gebruikers waarvan de PasswordChangeDateTime langer dan
het ingestelde aantal dagen (90) geleden is. Deze gebruikers ontvangen een email met het onderstaande
template. De "expirydate" is de termijn "LoginDateTime" (90 dagen) + termijn "InactiveLimit" (30 dagen).
Bij het versturen van een notificatie, wordt de datum en tijd opgeslagen in property
LastPasswordExpiredEmail.


Onderwerp: Wachtwoord verlopen voor <username> in omgeving <omgevingnaam>


<p>Beste {{fullname}},</p>
<p><br/></p>"
<p>Het wachtwoord voor gebruiker {{username}} is verlopen. Log voor {{expirydate}} in op het
Koppeltaal Beheerportaal om dit te wijzigen.</p>

<p><br/></p>

<p>Met vriendelijk groet,</p>

<p>Het Itzos Koppeltaal beheerteam</p>

Het verwerkingsproces bevat een vertragingsmechanisme "DaysBetweenEmails", die op 7 dagen gezet is. Dit
betekent dat er wekelijks een emailnotificatie wordt aangemaakt, zolang het wachtwoord niet gewijzigd is, en
zolang de user actief staat. De laatste email wordt 2 dagen voor de 120 dagen grens gestuurd.


Totaal kunnen er dus 5 emails aangemaakt worden, nl. op dag 90, 97, 104, 111 en 118.

Alle gebruikers die gevonden worden met de volgende query en die geen email hebben gehad in de laatste 7
dagen, ontvangen een email:

 

SELECT ID, EmailAddress, LoginDateTime, DATEDIFF(D, PasswordChangedDateTime,
CURRENT_TIMESTAMP) as PasswordAgeInDays
FROM Security.Users
WHERE FOR SOME %ELEMENT(Roles) (%VALUE IN
('Systeembeheerder','Domeinbeheerder','Applicatiebeheerder'))
AND DATEDIFF(D, PasswordChangedDateTime, CURRENT_TIMESTAMP) >=
{PasswordExpirationDays}
AND LoginDateTime > 0
AND Enabled = 1
And PasswordNeverExpires = 0
ORDER BY PasswordAgeIndays DESC

 

Alle emailnotificaties worden gelogd in de Servicelog Koppeltaal (tabel kt2_mgmt_log.ServerEvents). Zie
BEB - Beheren van entiteiten en bevoegdheden

Inactief zetten gebruiker


Dit proces zit volledig in het intersystems platform. Het is niet helder hoe het werkt of wanneer het
geactiveerd wordt. Optimaal zou zijn als dit bij de nachtverwerking zou plaatsvinden, maar dat lijkt nu niet
zo te zijn. (De vraag is uitgezet bij Intersystems.)


Na 120 dagen, "LoginDateTime" (90 dagen) + termijn "InactiveLimit" (30 dagen), wordt een gebruiker
uitgeschakeld.


N.B. gebruikers kunnen alleen uitgeschakeld worden, als ze een keer hebben ingelogd. Nooit ingelogde
gebruikers worden in dit proces niet herkend

Related content

BEB - Beheren van entiteiten en bevoegdheden
BEB - Beheren van entiteiten en bevoegdheden
Read with this
(MedMij Afsprakenstelsel 2.2.5B) Authenticeren
(MedMij Afsprakenstelsel 2.2.5B) Authenticeren
More like this
BRL - Beheerdersrollen
BRL - Beheerdersrollen
Read with this
(MedMij Afsprakenstelsel 2.2.0) Authenticeren
(MedMij Afsprakenstelsel 2.2.0) Authenticeren
More like this
TOP-KT-019 - Beheer
Read with this
(MedMij Afsprakenstelsel 2.1.0B) Authenticeren
(MedMij Afsprakenstelsel 2.1.0B) Authenticeren
More like this