Authentication, Access Control, and WDAC

1. User Authentication: Passwords

HTWG has ca. 5,000 user accounts that are protected by passwords chosen by users. Each password needs to be at least 14 characters long. Assuming that users prefer simple passwords that are exactly 14 characters long, how many different passwords are possible when users only use lower case characters a…z for their passwords?

  • Number of characters: 26 (lowercase a-z)
  • Password length: 14
  • Total number of passwords = 26

1.1. An attacker might perform an online attack on the passwords of HTWG’s users. Assume that the probability of all passwords is equal. Assume further that the attacker can try 30,000 different passwords per second. How many days in total does the attacker have to guess passwords until the attacker guesses the correct password for a specific account?

Best case scenario the attacker can guess the password instantly, however, because it is unlikely for the attacker to guess the password instantly, I will calculate the average case scenario. Assuming it takes the attacker half the numbers of guesses to guess the password:

Or assuming it takes all possible tries to guess the password (worst case scenario):

For 5000 users, if 90% of them (4500) choose their passwords from a set of 1000 popular passwords and the attacker can try 10,000 different passwords per second, we can calculate the average time by taking half of the number of popular passwords:

Then we can calculate attempts needed to guess the password for 90 accounts:

So the time needed to guess the password for 90 accounts is:

if 90% of users use the top 1000 most popular passwords then we need to check only for them because we assume the worst case scenario, that the attacker will try all 1000 passwords.
So let

and also

so for the attacker to be unsuccessful with a probability of 95%, we calculate the probability of success of 5%:

and rounding down gives us:


2. Access Control

Restricting access by people/accounts/programs (“subjects”) to resources (“objects”) is a method to preserve confidentiality, integrity, and availability of objects. There are different approaches how you can define who can perform which actions on what.

2.1. Pick three apps on your smartphone. What is the purpose of each app and what permissions are associated with these apps? Is the association of permissions with apps an access control list or a capability list? Why?

App NamePurposePermissionsACL or CLWhy?
WhatsAppMessagingCamera, Microphone, Contacts, StorageCLOS gives permissions to the app directly
TiktokSocial MediaCamera, Microphone, Location, ContactsCLApp proves its permissions at runtime
InstagramSocial MediaCamera, Microphone, Storage, ContactsCLApp presents its access rights, not managed per device
Access Control List vs Capability List:
  • An Access Control List typically assigns permissions to specific objects (like files, folders, or resources) and determines who or what can access those objects. It defines what users or apps can do with those objects
  • A Capability List, on the other hand, assigns permissions to the subject, specifying what actions or resources the app is capable of interacting with (e.g., camera, location, contacts)

2.2. Explain how role-based access control works. Use Moodle as an example for an application that uses role-based access control.

Role-based access control means that users don’t get permissions directly, but instead they are assigned roles and each role has a set of permissions.
This makes it easier to manage many users, because you just change the role once instead of adjusting every user manually.
In Moodle, for example, there are different roles like student, teacher, and admin. Each role has different permissions, like students can only view course materials while teachers can create and edit course content.
When a user is assigned a role, they automatically inherit the permissions associated with that role.

Reason 1: Reducing risk if something goes wrong
If I’m logged in with an admin account all the time, every program I run also has admin rights.
So if malware or a bad website manages to attack my system, it automatically gets full control.
But if I’m using a normal account, even if something bad happens, it’s much harder for the attacker to do real damage (like installing ransomware or deleting important system files).

Reason 2: Avoiding mistakes
As a normal user, I simply don’t have permission to accidentally change important system settings or delete critical files.
When I really need admin rights, I can log in separately and be more careful because I know I’m doing something sensitive.


3. Application Whitelisting

3.1. Explain how application whitelisting works with WDAC (Windows Defender Application Control)?

Policies are created that define trusted apps.
The policy can say: only apps signed by a trusted certificate, or only apps from specific paths, or only specific files are allowed.
When a user or even malware tries to run a program WDAC checks the policy. If the app is not on the allowed list, Windows blocks it before it can even start.
The checks happen very early when the program loads before it runs any code.

WDAC works by using things like:

  • File hashes (specific fingerprints of allowed files),
  • Code signing certificates (apps must be signed by trusted developers)
  • Specific file paths or folder rules.

The goal is to prevent unknown or untrusted software from ever running, even if a user downloads something by accident.

3.2. Does WDAC restrict users/processes with respect to executing code? How?

Yes it restricts users and processes by checking if the code they want to run is on the whitelist. If it’s not, Windows blocks it. This means that even if a user tries to run a program that’s not allowed or if malware tries to execute code it wont be able to run because it doesn’t meet the whitelist criteria.

3.3. Does WDAC restrict users/processes with respect to reading and writing files? How?

It doesn’t stop users or programs from accessing files. Instead, it just controls which apps can be executed. So even if someone can read or write files, they can’t run any software that isn’t trusted. The operating system takes care of file access permissions separately and that’s not included in its policy.

3.4. What are the different file rules hat you can use with WDAC?

Type of ruleWhat it does
Publisher ruleAllows all files that are signed by a trusted publisher (e.g., Microsoft, Adobe) very flexible if you trust the company
File path ruleAllows files from specific folders or locations (e.g., only allow programs from C:\Program Files), easy to set up but risky if the folder can be modified by users
File hash ruleAllows only files that exactly match a certain cryptographic fingerprint (hash). Super strict even small file changes break the match
Package rules (for MSIX packages)Allows modern Windows apps (UWP apps) based on their package identity. Useful for Store apps or enterprise-deployed apps

3.5. What is the purpose of the audit mode in WDAC?

Audit mode lets you check WDAC policies without stopping any apps. It records what would have been blocked if the rules were active. This way, you can see which apps might be impacted and adjust the policy before fully enforcing it. It’s like a practice run to ensure everything goes smoothly without any interruptions.

3.6. How do you debug WDAC policies, i.e., how do you find out that they are effective and where are WDAC events logged?

You need to check the event logs in Windows. Whenever WDAC permits or denies an application (or would deny it in audit mode) it logs an entry in the Windows Event Viewer.
When you access this log you’ll see information about what occurred, like whether an app was allowed or denied, which rule caused the decision and the reasoning behind it. If something crucial gets blocked or if unexpected applications attempt to run you can catch it here.
If you’re testing a policy in audit mode this is also where you can see which applications would have been blocked allowing you to tweak the WDAC policy before putting it into effect.