Cybersave your pc

Maintenance and bugs

Password policy


This policy deals with issues regarding the use of passwords as part of the authentication of users of ICT facilities and operational information.

The legislation and umbrella security policy of Delft University of Technology (DUT) serves as frame of reference in this context.

The policy is in line with other policies and Regulations at institutional level, such as the Code of Conduct, the formal Regulations on use of computer and network facilities by staff and visitors of Delft University of Technology, the Regulations on use of buildings, precincts and facilities by students and visitors of Delft University of Technology, and the sections regarding the use of ICT in the Student Statute.

Passwords are an important aspect of information security; they form part of the access codes. An easily guessable access procedure is a threat not only to the integrity and confidentiality of stored information, but also to the image of DUT, the continuity of the ICT facilities and ultimately to the operational processes. Thus all users of these facilities are held responsible for the choice of good personal passwords, and for keeping these secret.

Text in italics refers to other sections or to related documents, irrespective of their status (published or still under development).


The password policy has three related goals:

• to set the rules to which passwords must conform,

• to protect these passwords, and

• to define the criteria for changing passwords.


The policy is applicable to all employees, visitors and students of DUT who have an account (or another form of access requiring a password) on one or more of the networks, systems or facilities provided by the institution.

The policy focuses on the use of passwords, and is without prejudice to the application of harder means of authentication for access to sensitive or critical systems and to confidential or secret information.

Writing down passwords involves risks, and forgetting a password leads to time being wasted. Various methods for designing good, memorable passwords have been published. This policy does not deal with this subject.

Information related to this policy can be found in the policy document 

Technical Infrastructure,

in several other policies, namely

Confidentiality of Information,

Encryption and Authentication,

Clear Desk,

and in the

Administrative regulations per facility,

Access regulations per facility.

General Procedures

Publication and documentation

The password policy can, like other related documents, be consulted on the DUT security website, security.tudelft.nl, where necessary accompanied by explanatory notes.

DUT ensures that all Procedures which are applied to enforce the policy, as well as possibilities for appealing against measures resulting from the policy, can be consulted by the public.

The policy comes into force from the moment of announcement through the regular media for publication of security measures within DUT.

Enforcement and sanctions

The access security and accompanying measures are subject to regular security checks, to be carried out on the authority of the Security Manager.

The security organisation may without prior announcement carry out audits of the quality of passwords (for instance by means of official hacking attempts or by trying out easily guessable combinations of characters), and of compliance with password-related sections of the clear desk policy.

The general Code of Conduct (CoCon) of DUT remains fully applicable to all ICT facilities, as does the code of conduct for administrators.

Breach of the rules of conduct may lead to disciplinary measures (for this see the Regulations at institution level).

The Security Manager maintains a list at institution level of situations and applications whereby the policy may be deviated from temporarily or permanently, and to what extent this may be done.

Incident reporting

The contact point for reporting malfunctions, faults and deficiencies in log-in procedures is a help desk or call centre, defined as such in the SLA between the client administration unit or department and the provider of the ICT facility in question.

The contact point for reporting breaches of the password policy and accompanying Guidelines is Abuse@remove-this.TUDelft.NL .

Possibilities for appeal

Comments on or objections to the content or import of the policy may be submitted to the contact point ToBe@remove-this.TUDelft.NL .

The following paths are available for submitting and handling complaints regarding the content and the enforcement of the policy.

• With regard to the text and the formal interpretation of the policy:

the contact point ToBe@TUDelft.NL.

• With regard to the application of related Procedures and Guidelines by security functionaries or administrators of ICT facilities:

the contact point SST@TUDelft.NL.

• With regard to the handling of complaints via the aforementioned contact points:

the Security Manager.

• With regard to official interventions:

the Security Board of DUT.

• With regard to verdicts/statements of the Security Board:

government bodies in the field of private or labour law.


• the level of authentication is determined, per facility, on the basis of risk analyses;

• the baseline level for authentication within the institution is the utilisation of accounts;

• only registered users have access to shielded functionality or information, by means of an account assigned to them;

• an account, consisting of the combination of account name and password, is strictly personal;

• accounts are granted only the rights matching the authorised role assigned to the account;

• a distinction is drawn between system accounts, administrator accounts and user accounts;

• a system account facilitates communication between facilities, for instance from a transaction system to the enterprise directory;

• system passwords which form part of the factory defaults in systems or applications are changed before acceptance: they may not be the same as an administrator or user password;

• an administrator account is used only by a functionary in his role as administrator;

• in order to ensure the administrator function in the event of emergencies, the data from administrator accounts are stored in a physically secured room;

• an administrator/user who holds accounts with various levels of rights may not have the same password for the various accounts;

• the regulations stated below for the frequency of change for passwords may be deviated from if good arguments can be cited for this, to be judged by the Security Manager;

• all administrator passwords (for accounts with more than the usual user rights, such as root, administrator etc.) must be changed at least once every 90 days;

• all passwords for system and user accounts must be changed at least once every 180 days;

• compliance with the frequency of change will where possible be compelled by technical means;

• urgent reasons for an earlier change of rights or passwords are

- termination or change of employee function,

- (suspicion of) compromise due to malware or cracking,

- (suspected) breaches of information security policy;

• when irreversible loss of operational information may occur as a consequence of a password being forgotten, then an emergency solution must kept in reserve, such as a note at a physically secure location;

• passwords for user accounts at facilities are stored in encrypted form in the enterprise directory, the base authentication system of the institution;

• passwords may not be cited in non-secure e-mail messages or other forms of non-secure communication;

• all passwords must comply with the guidelines stated below.

Guidelines for acceptable use

a. characteristics of acceptable passwords

• a password contains at least eight characters, and

• it contains at least one upper case letter, and

• it contains at least one lower case letter, and

• it contains at least one digit or another character such as!@#$%^&(){}[]<>... , and

• it is not a term in a familiar language or jargon, and

• it is not identical to or derived from the accompanying account name, from personal characteristics or from information from one’s family/social circle, and

• it is easy to remember, for instance by means of a key sentence, and

• it can be typed in fluently.

b. best practices for protecting passwords

• avoid the use of the same password for work and private life;

• regard all passwords as sensitive information, and do not share them with the accounts of colleagues, family members or other acquaintances;

• do not reveal passwords to colleagues, one’s boss or other acquaintances, neither in normal circumstances nor in the event of leave or sickness;

• do not mention any password in public, by telephone or in unencrypted communication;

• never note down a password in a freely accessible location;

• do not give any hints about the mnemonic used to remember your password;

• never provide information about a password in questionnaires or security forms;

• if misuse is suspected, then report this to the security organisation and immediately change all involved passwords;

• if someone wants to know a password, then refer him to this policy.

c. supporting rules

• strong passwords can only be supported with a strong encryption method;

• insufficient support of powerful passwords within a facility must lead to replacement of the security level in the facility;

• the institution ensure means of safe transport of account/password information through the networks;

• the institution ensures means of compelling the proper frequency of change for passwords; in this respect it is being considered whether it is necessary to prevent a double change (reverting to the old password within a certain period);

• passwords may not be stored in a file in unencrypted form;

• it must not be possible to derive the password from passwords stored in encrypted form;

• passwords may not be ‘remembered’ electronically for automatic application after logging out of a system or an application;

• when creating new accounts, and when a user has lost the password, then a one-time key with limited validity is generated for one-time use; the aim here is that once the user has received this he can set up a new personal password as quickly as possible.

d: acceptance rules for new applications

• applications aim their procedures for user authentication at persons, not at groups;

• user sessions of an application must be reducible to one person;

• no user passwords are stored within applications;

• right are assigned to accounts on the basis of well-defined roles, so that temporary use of someone else’s account/password can be avoided;

• when conducting base authentication, applications make use of a secure link to the enterprise directory.

e: rules for system accounts

• system accounts should be used exclusively for formally defined information exchange;

• the rights linked to system accounts suffice precisely for the intended exchange, and for no more than this.

Appendix: pass phrases

Pass phrases form a separate category of passwords. They are mainly used for authentication with the help of a combination of a public and a private key. A system that facilitates the application of this method defines a mathematical relationship between a user’s public key (which is made known to relations or even published) and a private key which is known only to the user himself. Without a pass phrase for decrypting the private key the user is unable to access information rendered secure in this way.

The security of this form of communication depends chiefly on the quality of the pass phrase used.

Pass phrases are for example applied for encrypting and decrypting electronic messages, such as e-mail messages and client/server communication.

Other applications can be found in wireless networks and in software for encrypting the content of a storage medium.

Good pass phrases are stronger than the baseline passwords. In principle they contain the same mix of characters, but they are much longer.

The rules for passwords are also applicable to pass phrases.




Naam auteur: Webbeheer SSC ICT
© 2014 TU Delft