Løbende kontrol med om kodeord findes i lækkede kodeordslister

Description

Ønske fra Vallensbæk

Løbende kontrol med om brugernes kodeord er indeholdt i lister med lækkede kodeord.

Løsningsforslag

Kodeordene i OS2faktor gemmes som saltede hash-værdier, så de gemte oplysninger kan ikke anvendes til løbende kontrol. I stedet kan der laves kontrol når brugeren logger ind, da brugeren her indtaster sit kodeord i forbindelse med login’et.

For ikke at sænke loginhastigheden unødiget, foreslås det at løsningen modelleres på følgende måde

  • Der sættes et timestamp på brugerens konto for hvornår der sidst er foraget “læk-kontrol”

  • Hvis der under login er et timestamp som er ældre end én månede, så foretages “læk-kontrol” under dette login

  • Hvis kontrollen resulterer i at kodeordet er indholdet i en liste af lækkede kodeord, informeres om dette (*)

OBS! Logins er alle kodeordvalideringer - dvs også logins foretaget via WCP’en på windows maskinen.

(*) det skal afklares hvordan vi helst vil informere om dette. Da mange brugere alene laver login på windows, og aldrig kommer forbi IdP’en, vil vi formodentligt ikke kunne informere brugeren direkte på skærmen på en god og effektiv måde. En løsning kunne være at sende en email til brugeren, eller evt sende en email til en systempostkasse i kommunen, og så lade kommunen vurdere hvad der skal gøres her.

Vi kan også vælge at sætte et “skal skifte kodeord ved næste login” på brugerens konto - rent teknisk kunne vi sætte flagget både i OS2faktor og i AD’et (via kodeords-agenten), så brugeren får skiftet kodeord automatisk ved næste login. Det er dog vigtigt I så fald at informere brugeren om at dette er gjort, så de ikke undrer sig unødigt over at de pludselig skal skifte kodeord (igen - windows login kan ikke rigtigt sige noget til brugeren om hvorfor de pludselig skal skifte kodeord).

OBS!

Lav mailskabelon til denne hændelse

Pris

8.000 DKK

Acceptance criteria

None

How to test

None

Activity

Show:
Fixed

Details

Assignee

Reporter

Priority

Created 1 August 2024 at 07:27
Updated 11 December 2024 at 12:44
Resolved 11 November 2024 at 08:21