Problem med svenska tecken

2020-10-23: Det finns f.n. problem med å, ä och ö på stora delar av Sunets wiki. Felsökning pågår...

SWAMID template Password Policy


Purpose and Scope

This wiki page is SWAMIDs?template?Password Policy including password complexity and password guessing rate limiting. In this page there is an example in Swedish with an additional translation to English how to create an environment that establish a resonable security level to fulfil both SWAMID Identity Assurance Level 1 Profile and SWAMID Identity Assurance Level 2 Profile.

Determining password strength

There are two factors to consider in determining password strength:

  1. the average number of guesses the attacker must test to find the correct password and
  2. the ease and speed of which an attacker can check the validity of each guessed password.

The first factor is determined by how long the password is, how large set of characters or symbols that be used in the password, if a combination of both lower, upper and non alphabetic characters is used and whether the password is created randomly or created by the user himself. There is a trade of regarding demanding a high complexity and the users ability to remember the password.

The second factor is the rate at which an attacker can submit passwords guesses to the system. If some kind of rate limiting and maximum password age is used the need for password complexity is greatly redused in online scenarios. However the identity management system must store information about the user passwords in some form and if that information is stolen, say by breaching system security, the less complex passwords can be at greater risk.

Swedish template Password Policy

SWAMID template password policy is written in Swedish due to that the implementing organisation are Swedish legal entities.

Some reading help:

  • The policy is made for a decentralised IT-organisation but is easily adapted to a centralised organization.
  • All text within [] should be changed to local information.

1 Inledning

Detta dokument anger [ORGANISATION] policy f?r kvalitet p? samt hantering av l?senord i enlighet med identitetsfederationen SWAMIDs policy.

2 Ansvar

2.1 Efterlevnad

Som anv?ndare av [ORGANISATION] informationssystem ansvarar du sj?lv f?r

  • att dina l?senord uppfyller den kvalitet och hantering som anges i denna policy.
  • att du h?ller dina l?senord hemliga.
  • att, som en del av ovanst?ende punkt, aldrig uppge dina l?senord till n?gon som efterfr?gar dem via e-post, i telefon eller p? annat s?tt.

F?r system som ?r kopplade till [ORGANISATION] gemensamma inloggnings- och autentiseringsrutiner (Webbinloggning, LDAP och Active Directory) finns systemst?d f?r efterlevnad av policyn.

F?r system med egen l?senordshantering ?r det system?gare som ansvarar f?r efterlevnad av denna policy.

3 Definitioner

L?senordskvalitet. God l?senordskvalitet inneb?r att ett l?senord ?r tillr?ckligt l?ngt och komplext sammansatt f?r att reducera risken f?r att en inkr?ktare kan gissa sig till r?tt l?senord. Tv? saker avg?r sv?righeten i att gissa ett l?senord: l?ngden och komplexiteten p? l?senordet. Med hj?lp av dessa kan man r?kna ut l?senordets entropi . Ju h?gre entropi ett l?senord har desto sv?rare ?r det att gissa det. Se pkt. 6.1 och bilaga 1 f?r vidare information.

L?senordsskydd. S?ker l?senordshantering inneb?r, f?rutom att varje anv?ndare ansvarar f?r att h?lla sina l?senord hemliga, att inloggningstj?nsten skyddar l?senord fr?n otillb?rlig ?tkomst och anv?ndning. Se pkt. 6.2 f?r vidare instruktioner.

Tv?faktorautentisering. Inloggning (autentisering) med tv? skilda faktorer; ?n?got man vet? (t.ex. ett l?senord) och ?n?got man har? (t.ex. ett kort).

4 Syfte

Det ?vergripande syftet med denna policy ?r att s? l?ngt det ?r m?jligt skydda [ORGANISATION] l?senordsskyddade informationssystem fr?n obeh?riga anv?ndare.

5. Strategier

Alla informationssystem (applikationer) ska vara kopplade till [ORGANISATION] gemensamma inloggningstj?nst om inte s?rskilda sk?l f?religger.

[ORGANISATION] gemensamma inloggningstj?nst inneh?ller teknikst?d f?r god l?senordskvalitet och s?ker l?senordshantering, se pkt. 6.1 och 6.2.

Varje anv?ndare har ett?l?senord f?r inloggning till [ORGANISATION] IT-tj?nster. F?r inloggning till vissa [ORGANISATIONSGEMENSAMMA] IT-tj?nster som t.ex. det tr?dl?sa n?tverket har varje anv?ndare dessutom ytterligare ett l?senord. D?rut?ver kan verksamhets- och/eller systemspecifika l?senord finnas.

Tv?faktorautentisering ska anv?ndas f?r ?tkomst till IT-tj?nster eller system (applikationer) som enligt [ORGANISATION] policy f?r informationsklassificering inneh?ller konfidentiell information med H?GA eller S?RSKILDA KRAV p? att skydda informationen fr?n obeh?riga anv?ndare.

6 Omfattning

Policyn f?r l?senordshantering g?ller f?r alla IT-tj?nster och system (applikationer) vid [ORGANISATION].

Policyn omfattar tv? omr?den, l?senordskvalitet och l?senordsskydd.

6.1 L?senordskvalitet

6.1.1 L?senordssammans?ttning

Ett l?senord ska vara sammansatt p? f?ljande s?tt:

  • Best? av minst 8 tecken.
  • Vara sammansatt av f?ljande tecken:
    • A ? Z
    • a ? z
    • 0 ? 9
    • mellanslag
    • f?ljande specialtecken: ~,!, @, #, $, %, ^, &, (, ), _, +, -, *, /, =, {, }, [, ], |, \, :, ;, ? (enkelt citationstecken), ? (dubbelt citationstecken), <, >, , (kommatecken), . (punkt), och ?.
  • Inneh?lla minst en versal, minst en gemen och antingen minst ett specialtecken eller en siffra.

6.1.2 L?senordss?kerhet

Alla anv?ndare avr?ds aktivt fr?n att dela med sig av sina l?senord med andra anv?ndare, b?de interna och externa, antingen genom att anv?nda tekniska kontroller eller genom att kr?va att anv?ndare bekr?ftar anv?ndarregler som f?rbjuder delning av l?senord eller agerar p? ett s?tt som g?r det enkelt att stj?la l?senordet.

Alla anv?ndare ?r uttryckligen avr?dda fr?n att anv?nda sina l?senord i andra interna och externa system.

6.1.3 L?senordskontroll

I [ORGANISATION] gemensamma inloggningstj?nst finns teknikst?d f?r att s?kerst?lla god l?senordskvalitet. Vid l?senordsbyte kontrolleras att dessa l?senord med avseende p? att de

  • ?r sammansatta enligt pkt. 6.1.1 ovan,
  • inte ?terfinns i en katalog med l?senord av d?lig kvalitet (123456, egennamn, ?rstider, bilm?rken etc.)1,
  • inte ?r detsamma som det n?rmast f?reg?ende och
  • inte ?r?samma som?anv?ndarens ?vriga l?senord i den gemensamma inloggningstj?nsten, t.ex. l?senordet f?r inloggning i tr?dl?sa n?t1.

L?senordet g?r inte att spara f?rr?n det uppfyller minimikraven.

1I Active Directory och andra nyckelf?rdiga system ?r det inte alltid m?jligt att genomf?ra kontroller enligt punkt?tv? och fyra. Om detta g?ller er ?r det rekommenderat att kravet p? minsta l?senordsl?ngd ?kas med?tv? tecken till?tio tecken.

6.1.4 Undantag

Om det i enskilda system som inte ?r kopplade till den gemensamma inloggningstj?nsten f?religger s?rskilda tekniska sk?l f?r att inte f?lja ovanst?ende policy f?r god l?senordskvalitet ska undantag godk?nnas av system?gare och dokumenteras i systemets f?rvaltningsspecifikation eller motsvarande dokument. Vidare m?ste s?rskild h?nsyn tas vid ?tkomst av data h?mtade fr?n andra system.

6.2 L?senordsskydd

6.2.1 Datalagring och transport av l?senord

F?r att reducera risken f?r obeh?rig ?tkomst till l?senord g?ller f?ljande policy f?r lagring och transport av l?senord:

  • L?senord ska alltid lagras och transporteras i krypterad form. Detta g?ller ?ven backupmedia.
  • L?senord ska aldrig presenteras i l?sbar form.
  • L?senord ska aldrig kommuniceras via epost, telefon eller motsv.
  • IT-personal med teknisk ?tkomst till de datorer och datamedia d?r l?senord lagras ska underteckna s?rskilda ansvarsf?rbindelser. En uppdaterad lista ?ver medarbetare med dessa priviligierade beh?righeter ska finnas vid den organisation som sk?ter driften av systemet, t.ex. [IT-ORGANISATION].

6.2.2 Skydd mot n?tbaserade gissningsattacker (Rate limiting)

F?r att reducera risken f?r automatiserade gissningsattacker mot l?senord ska inloggningen vara skyddad genom s.k. rate limiting som f?rhindrar en inkr?ktare att g?ra m?nga upprepade l?senordsgissningar p? kort tid.

I?[ORGANISATION] gemensamma inloggningstj?nst ?r detta utformat enligt f?ljande:

  • 10 felaktiga gissningar innan automatisk kontol?sning.
  • 5 minuters automatisk kontol?sning efter maximalt antal felaktiga gissningar.
  • R?knaren ?ver antalet felaktiga gissningar nollst?lls efter korrekt inloggning eller efter 60 minuter efter senaste felaktiga inloggningsf?rs?k.

6.2.3 Undantag

Om det i enskilda system f?religger s?rskilda tekniska sk?l f?r att inte f?lja ovanst?ende policy f?r l?senordsskydd ska undantag godk?nnas av system?gare och dokumenteras i systemets f?rvaltningsspecifikation eller motsvarande dokument. Vidare m?ste s?rskild h?nsyn tas vid ?tkomst av data h?mtade fr?n andra system.

Bilaga 1: Ber?kning av l?senordsentropi

L?senordsentropi l?senord r?knas i bitar och enligt f?ljande formel fr?n NIST SP 800-63-2 bil. A.

Entropi f?r av anv?ndaren sj?lv satt l?senord ber?knas enligt formeln:

  • F?rsta tecknet ger fyra bitar.
  • Tecken 2 till 8 ger 2 bitar.
  • Tecken 9 till 20 ger 1,5 bitar.
  • Tecken 21 och upp?t ger 1 bit.
  • Ett till?gg om 6 bitar f?s om l?senorden ?r komplexa, dvs. l?senordet inneh?ller minst en versal, minst en gemen och antingen minst en siffra och ett specialtecken.
  • Ett till?gg om 6 bitar f?s om omfattande ordlistekontroll sker s? l?nge l?senordet inte ?verstiger 20 tecken.

Sammans?ttning av l?senord enligt avsnitt 6.1.1 i medf?r en l?senordsentropi p? 24 bitar vilket ?r minimikravet p? god l?senordskvalitet f?r [ORGANISATION].

English?template Password Policy

SWAMID template password policy is written in Swedish due to that the implementing organisation are Swedish legal entities. The English template is a translation from Swedish.

Some reading help:

  • The policy is made for a decentralised IT-organisation but is easily adapted to a centralised organisation.
  • All text within [] should be changed to local information.

1. Introduction

This document describes [ORGANISATION] policy for the quality and usage of password in accordance with SWAMID's policy.

2. Responsibilities

2.1 Compliance

As a user of the computer systems at [ORGANISATION], you are yourself responsible for the following:

  • that your passwords fulfil the quality and usage described in this policy
  • that you keep your passwords secret
  • that, in accordance with the point above, you never divulge your passwords to anyone who asks for them via email, telephone or in any other way.

For systems that are connected to [ORGANISATION] centralised login and authentication (web login, LDAP, Active Directory) there is inbuilt support for compliance with this policy.

For systems with own, inbuilt password handling it is the responsibility of the system owner to ensure compliance with this policy.

3. Definitions

Password Quality. Good password quality means that a password is both sufficiently long and complicated such that the risk that an attacker can guess the password is minimised. Two variables determine the difficulty when guessing a password - length and complexity. These can be used to calculate the passwords entropy. The higher the entropy, the harder it is to guess. Password entropy is calculated in bits according to the following formula from NIST SP 800-63-2 in Appendix A. See point 6.1 for more information.

Password protection. Secure password usage means, apart from the fact that every user is responsible for keeping his/her passwords secret, that the login service protects passwords from unauthorised access and use. See point 6.2 for further instructions.

Two-factor authentication. Login (authentication) with two distinct steps ; "something you know" (e.g. a password) and "something you have" (e.g. a smartcard).

4. Purpose

The overall purpose of this policy is, as much as possible, to protect [ORGANISATION]'s password protected information systems from unauthorised users.

5. Strategies

All information systems (applications) must be connected to [ORGANISATION]'s central login service unless specific reasons apply.

[ORGANISATION]'s central login service supports strong passwords and secure password management, see points 6.1 and 6.2.

Every user has a?password for login to [ORGANISATION]'s IT services. Login to certain [ORGANISATION CENTRALISED] IT services, for example Wireless network, user have additionally another password. Furthermore, additional system or business-specific passwords can exist.

Two-factor authentication must be used for access to IT services or systems (applications) that according to [ORGANISATION]'s policy for information classification contain confidential information with HIGH or SPECIFIC REQUIREMENTS to protect the information from unauthorised users.

6. Scope

The policy for password usage applies to all IT services and systems (applications) at [ORGANISATION].

The scope of the policy covers two areas, password quality and safeguarding of passwords.

6.1 Password quality

6.1.1 Password composition

A password must be comprised as follows:

  • Contains at least 8 characters.
  • Be comprised with the following characters:
    • A-Z
    • a-z
    • 0-9
    • space
    • following special characters ~,!, @, #, $, %, ^, &, (, ), _, +, -, *, /, =, {, }, [, ], |, \, :, ;, ' (single quote), " (double quote), ,(comma), .(full stop) and ?.
  • contain at least one upper case, at least one lower case and either at least one special character or a number.

6.1.2 Password security

All users are actively discouraged from sharing credentials with other users, both internal and external, either by using technical controls or by requiring users to confirm policy forbidding sharing of credentials or acting in a way that makes stealing credentials easy.

All users? are explicitly?discouraged to reuse their passwords in other internal and external systems.

6.1.3 Password control

In [ORGANISATION] central login service there is technical support that maintains good password quality. During a password change, the password is validated such that:

  • it is comprised according to point 6.1.1 above
  • it does not exist in a word list comprising of bad passwords (12345, own name, seasons, car makes etc.)1
  • it is not the same as the previous password
  • it is not similar to the user's other passwords in the central login service.1

The password must not be saved until it fulfils these base requirements.

1In Active Directory or other?commercial systems is it not possible?to adhere to?item?two or four. If that's true it's recommended that the least acceptable is password length is extended two characters to?ten characters.

6.1.4 Exceptions

If there exist specific systems, not connected to the central login service, where there are exceptional technical reasons for not complying with the above policy, such exceptions must be approved by the system owner and documented in the system's management plan or similar document. Furthermore, special consideration must be taken when accessing the data retrieved from other systems.

6.2 Safeguarding of passwords

6.2.1 Data storage and transport of passwords

To reduce the risk of authorised access to passwords the following policy applies to the storage and transport of passwords:

  • Passwords must always be stored and transported in encrypted form. This applies also to backup media.
  • Passwords must never be visible in a readable format.
  • Passwords must never be divulged over email, telephone or any other communicable manner.
  • IT staff with technical access to those computer systems or media where passwords are stored must sign special responsibility agreements. An updated with over employees with such privileges must exist within the organisation that manages the systems, e.g. [IT-ORGANISATION].

6.2.2 Protection against network-based brute force attacks (Rate limiting)

To reduce the risk of brute force attacks against passwords, logins must be protected via so-called rate limiting that prevents an attacker from making repeated password guesses during a short time frame.

In [ORGANISATION] central login service this should be designed as follows:

  • Maximum of 10 wrong guesses during a time frame of 60 minutes.
  • Thereafter automatic disabling of account for 5 minutes

6.2.3 Exceptions

If there exist systems with specific technical reasons for not following the above policy, they must be approved by the system owner and documented in the system's management plan or similar document. Furthermore, special consideration must be taken when accessing the data retrieved from other systems.

Complex passwords in Active Directory

If you in Active Directory?enable complexity requirements policy for passwords,?define a minimum password length, define rate limiting and define a maximum password age?you can fulfil the proposed password policy.

Enabling the password complexity requirement?policy setting requires new passwords to meet the following requirements:

  1. Passwords may not contain the user's samAccountName (Account Name) value.
    • The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
    • The check is not case sensitive.
  2. Passwords may not contain the user's?entire displayName (Full Name value).
    • The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed to not be included in the password. Tokens that are less than three characters are ignored, and substrings of the tokens are not checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password.
    • The check is not case sensitive.
  3. The password contains characters from three of the following categories:
    • Uppercase letters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters).
    • Lowercase letters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters).
    • Base 10 digits (0 through 9).
    • Non-alphanumeric characters (special characters) (for example, !, $, #, %).
    • Any Unicode character that is categorised as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.