LSS - Lecture V - NSS and PAM.pdf

# Name Service Switch (NSS) The Name Service Switch (NSS) in Linux is a mechanism that allows administrators to configure the sources from which the system obtains various types of naming and identity information. It defines which services are consulted and in what order for name lookups [4](#page=4). ### 1.1 Configuration of NSS The primary configuration file for NSS is located at `/etc/nsswitch.conf`. This file dictates how the system resolves names for users, groups, hosts, and other network information. The `man nsswitch.conf` and `man nss` commands provide detailed information on its usage [4](#page=4). ### 1.2 Functionality of NSS NSS determines which sources are used to obtain naming service information and the order in which these services are contacted. For instance, it specifies whether user credential information should be retrieved from local files or across a network. It is crucial to note that the program or service that relies on NSS must be specifically programmed to utilize it; this is the responsibility of the program's developer [4](#page=4). ### 1.3 The `/etc/nsswitch.conf` file structure The `/etc/nsswitch.conf` file is organized into sections that define the databases to be queried and the sources to be used for each database [7](#page=7) [8](#page=8). #### 1.3.1 Databases Databases are categories of information that the system needs to look up. Common databases include: * `passwd`: User account information. * `group`: Group information. * `hosts`: Hostname-to-address mappings. * `services`: Network service names and their port numbers. * `networks`: Network names and numbers. * `protocols`: Protocol names and numbers. #### 1.3.2 Sources Sources are the actual locations or mechanisms from which the system can retrieve information for a given database. The NSS configuration specifies the order in which these sources are queried. Common sources include [8](#page=8): * `files`: Information is retrieved from local configuration files (e.g., `/etc/passwd`, `/etc/group`, `/etc/hosts`) [9](#page=9). * `dns`: Information is retrieved using the Domain Name System [10](#page=10). * `nis`: Information is retrieved from Network Information Service (formerly Yellow Pages). * `nisplus`: Information is retrieved from Network Information Service Plus. * `compat`: A compatibility mode that allows older applications to work with NSS [9](#page=9). * `local`: Similar to `files`, but often refers to system-specific local sources. #### 1.3.3 Specifying the order of sources The order in which sources are listed for a database is significant. The system queries them sequentially until the requested information is found or all configured sources have been exhausted. > **Tip:** The `compat` source can be useful for ensuring backward compatibility, but it's generally recommended to use explicit sources like `files` and `dns` for clarity and better control [9](#page=9). ### 1.4 Example: Host name lookup A typical scenario involves looking up a hostname, such as resolving `www.example.com` to its IP address. The `/etc/nsswitch.conf` file would specify the order of services to consult for host lookups [10](#page=10) [5](#page=5). For example, a configuration line might look like this: ``` hosts: files dns ``` This line indicates that when the system needs to look up a hostname: 1. It will first consult the local `files` (typically `/etc/hosts`) [10](#page=10). 2. If the hostname is not found in the local files, it will then query the `dns` [10](#page=10). > **Example:** If `/etc/hosts` contains `192.168.1.10 www.example.com`, and a lookup for `www.example.com` is performed, the system will return `192.168.1.10` directly from the files without querying DNS. If `www.example.com` is not in `/etc/hosts`, then DNS will be queried [10](#page=10). --- # Pluggable Authentication Module (PAM) Pluggable Authentication Modules (PAM) bieden een flexibel en modulair systeem voor authenticatie in Linux, waardoor systeembeheerders de manier waarop gebruikers worden geverifieerd kunnen aanpassen zonder applicaties te hoeven wijzigen [14](#page=14). ### 2.1 PAM-concept en doel PAM staat voor Pluggable Authentication Module en is ontworpen om authenticatiefuncties modulair te maken. Dit stelt systeembeheerders in staat om de authenticatieprocedure voor specifieke situaties aan te passen en zelf te kiezen hoe individuele service-aanbiedende applicaties gebruikers authenticeren. Een belangrijke eigenschap is dat het lokale authenticatiesysteem volledig kan worden geüpgraded zonder de applicaties of services zelf aan te raken. Applicaties moeten specifiek zijn geschreven en gecompileerd om PAM te gebruiken, wat betekent dat ze gelinkt moeten zijn tegen `libpam.so` of deze functionaliteit statisch hebben geïmplementeerd. PAM definieert de authenticatie voor alle services die iets met authenticatie te maken hebben, niet alleen voor de loginprocedure. Voorbeelden hiervan zijn `su`, `chsh`, `sshd`, en meer. Elk systeem waarvoor een PAM-module bestaat, kan voor authenticatie worden gebruikt, zoals smartcards, vingerafdrukken of tweefactorauthenticatie. Het gebruik van PAM kan voor specifieke services worden ingeschakeld of uitgeschakeld in het configuratiebestand van die service, bijvoorbeeld in `/etc/ssh/sshd_config` voor SSH [14](#page=14) [15](#page=15) [16](#page=16). ### 2.2 PAM-modules PAM-modules zijn dynamisch laadbare objectbestanden met de extensie `.so` (shared object). Ontwikkelaars kunnen meerdere dynamische bibliotheken in hun C-code laden. Deze modules worden opgeslagen in specifieke "library" mappen, zoals `/usr/lib64/security/` op RHEL of `/usr/lib/x86_64-linux-gnu/security/` op Debian. Elk PAM-module heeft zijn eigen man-pagina, bijvoorbeeld `man pam_unix` of `man pam_deny` [18](#page=18). #### 2.2.1 Voorbeelden van PAM-modules Er zijn diverse PAM-modules beschikbaar met verschillende functionaliteiten [19](#page=19): * `pam_unix`: Traditionele wachtwoordauthenticatie [19](#page=19). * `pam_deny`: Een module die altijd faalt [19](#page=19). * `pam_permit`: Een module die altijd slaagt [19](#page=19). * `pam_time`: Controleert toegang op basis van tijdstip van de dag [19](#page=19). * `pam_pwquality`: Handhaaft de sterkte van wachtwoorden [19](#page=19). * `pam_rootok`: Controleert of de echte gebruikers-ID nul (root) is [19](#page=19). * `pam_nologin`: Voorkomt dat niet-root gebruikers inloggen als `/etc/nologin` bestaat [19](#page=19). #### 2.2.2 Functionaliteitstypes van PAM-modules PAM-modules kunnen vier verschillende soorten functies bieden [20](#page=20): * **auth (authenticatie)**: Verifieert of de gebruiker is wie hij zegt te zijn [20](#page=20). * **account (account)**: Controleert de status van het gebruikersaccount en of de gebruiker geautoriseerd is om iets te doen [20](#page=20). * **session (sessie)**: Voert acties uit die specifiek zijn voor de huidige sessie van de gebruiker, zoals het weergeven van een bericht van de dag (`/etc/motd`) [20](#page=20). * **password (wachtwoord)**: Wijzigt het wachtwoord of andere inloggegevens van een gebruiker [20](#page=20). Een module kan meerdere functies combineren. Bijvoorbeeld, `pam_unix.so` biedt functies voor `auth`, `account`, `session` en `password`, terwijl `pam_securetty.so` alleen de `auth` functie biedt [21](#page=21). > **Tip:** Controleer de sectie "MODULE TYPES PROVIDED" in de man-pagina van een PAM-module voor een overzicht van de aangeboden functies [21](#page=21). ### 2.3 PAM-configuratiebestanden PAM-configuratiebestanden definiëren de koppeling tussen applicaties (services) en de PAM-modules die de daadwerkelijke authenticatietaken uitvoeren. Deze bestanden worden opgeslagen in de map `/etc/pam.d` of, op oudere systemen, in een enkel bestand `/etc/pam.conf`. Als `/etc/pam.d` bestaat, wordt `/etc/pam.conf` genegeerd. De naam van het configuratiebestand verwijst naar de applicatie waarvoor PAM is geconfigureerd, bijvoorbeeld `/etc/pam.d/login`, `/etc/pam.d/sshd`, etc.. Als een applicatie geen eigen bestand heeft in `/etc/pam.d`, wordt `/etc/pam.d/other` gebruikt [22](#page=22). #### 2.3.1 Gedeelde configuratie Veel services maken gebruik van gemeenschappelijke configuratie die in aparte bestanden wordt geplaatst en vervolgens door andere configuratiebestanden wordt geïncludeerd. Op RHEL is dit vaak `/etc/pam.d/system-auth`. Op Debian zijn de gemeenschappelijke configuratiebestanden `common-auth`, `common-password`, `common-session` en `common-account` [23](#page=23). #### 2.3.2 Structuur van configuratiebestanden Een configuratiebestand in `/etc/pam.d` bestaat uit meerdere regels met een vergelijkbare structuur. Deze regels specificeren de functionaliteitstypes (`auth`, `account`, `password`, `session`) en de PAM-modules die gebruikt moeten worden, samen met de bijbehorende control flags [25](#page=25). De structuur van een regel is: `moduletype control_flag module_path [module_arguments]` [28](#page=28). * `moduletype`: Geeft het type functie aan dat de module uitvoert (bv. `auth`, `account`, `password`, `session`) [25](#page=25). * `control_flag`: Bepaalt hoe het succes of falen van de module de authenticatie beïnvloedt [27](#page=27). * `module_path`: Het pad naar het PAM-modulebestand [28](#page=28). * `module_arguments`: Optionele argumenten die aan de module worden meegegeven [28](#page=28). Het configuratiebestand bepaalt dus welke PAM-functies van welke PAM-modules worden gebruikt en in welke volgorde. Hierdoor worden vier "stacks" gevormd: `auth`, `account`, `password` en `session`, die doorlopen moeten worden [26](#page=26). #### 2.3.3 Control flags Elke PAM-module in een stack retourneert `SUCCESS` of `FAILURE`. De uiteindelijke uitkomst van de stack wordt bepaald door de control flags. Er zijn vier verschillende control flags [27](#page=27) [29](#page=29): * **`required`**: Een `required` module moet slagen voor de authenticatie om te slagen. Als een `required` module faalt, zal de stack uiteindelijk falen, maar de uitvoering van de overige modules in de stack wordt voortgezet [29](#page=29) [32](#page=32). * **`requisite`**: Als een `requisite` module faalt, faalt de authenticatie onmiddellijk. De resterende modules in de stack worden niet uitgevoerd [29](#page=29) [31](#page=31). * **`sufficient`**: Als een `sufficient` module slaagt, slaagt de authenticatie onmiddellijk, mits er geen `required` modules vóór de `sufficient` module hebben gefaald. Als een `sufficient` module faalt, heeft dit geen invloed op de uitkomst; de volgende modules worden geëvalueerd [29](#page=29) [30](#page=30). * **`optional`**: Het succes of falen van een `optional` module heeft geen directe invloed op de uitkomst van de authenticatie. Het resultaat wordt meegenomen in de uiteindelijke beslissing, maar is niet doorslaggevend [29](#page=29) [33](#page=33). > **Voorbeeld:** In `/etc/pam.d/chsh` [34](#page=34): > ``` > auth sufficient pam_rootok.so > auth requisite pam_shells.so > auth sufficient pam_unix.so > auth required pam_deny.so > ``` > De `pam_rootok.so` module wordt als eerste gecontroleerd. Als deze slaagt, is de authenticatie succesvol (`sufficient`). Als `pam_shells.so` faalt, faalt de authenticatie onmiddellijk (`requisite`). Als `pam_unix.so` slaagt, is de authenticatie succesvol (`sufficient`). Ten slotte controleert `pam_deny.so` of de authenticatie moet falen (`required`). #### 2.3.4 Module-specifieke configuratiebestanden Naast de configuratiebestanden in `/etc/pam.d`, die bepalen *welke* PAM-modules te gebruiken, in welke volgorde en met welke gevolgen, zijn er ook configuratiebestanden voor de PAM-modules zelf. Deze worden meestal opgeslagen in `/etc/security` [40](#page=40). * `/etc/security/time.conf`: Configuratie voor de `pam_time.so` module om toegang op specifieke tijden van de dag te beperken [40](#page=40). * `/etc/securetty`: Kan worden aangemaakt voor de `pam_securetty.so` module om een lijst van TTY's op te geven waarvandaan root kan inloggen. Let op: dit is niet meer beschikbaar sinds Debian 11 [40](#page=40). --- # PAM configuratiebestanden en controlemechanismen PAM configuratiebestanden in `/etc/pam.d` bepalen welke PAM-modules worden gebruikt voor specifieke applicaties (services), in welke volgorde, en met welke consequenties, waarbij controlemechanismen (flags) de uitkomst van authenticatie sturen [25](#page=25) [26](#page=26). ### 3.1 Structuur van PAM configuratiebestanden PAM configuratiebestanden, doorgaans gevestigd in de `/etc/pam.d/` directory, bevatten regels die de functionaliteit van PAM voor een specifieke applicatie of service definiëren. Elke regel heeft doorgaans de volgende structuur: `moduletype control_flag module_path [module_arguments...]` [25](#page=25) [26](#page=26) [28](#page=28). * **Moduletype:** Dit geeft aan voor welk doel de module wordt gebruikt. De vier hoofdtypes zijn: * `auth`: Voor authenticatie (verifiëren van de identiteit van de gebruiker) [26](#page=26). * `account`: Voor accountbeheer (controleren of het account geldig is, niet verlopen, etc.) [26](#page=26). * `password`: Voor het beheren van wachtwoorden (wijzigen, updaten) [26](#page=26). * `session`: Voor sessiebeheer (handelingen die aan het begin en einde van een gebruikerssessie moeten worden uitgevoerd, zoals het mounten van home directories of het loggen van sessie-informatie) [26](#page=26). * **Control flag (controlemechanisme):** Dit bepaalt hoe het succes of falen van een specifieke module de algehele uitkomst van de stap in de PAM-stack beïnvloedt. Er zijn vier verschillende controlemechanismen [27](#page=27) [29](#page=29): * `required`: Een `required` module moet slagen voor de hele authenticatie-stap om te slagen. Als een `required` module faalt, faalt de gehele stack uiteindelijk, maar de uitvoering van de stack wordt voortgezet om alle modules te kunnen uitvoeren [29](#page=29) [32](#page=32). * `requisite`: Als een `requisite` module faalt, faalt de authenticatie-stap onmiddellijk. De uitvoering van de stack stopt [29](#page=29) [31](#page=31). * `sufficient`: Als een `sufficient` module succesvol is, slaagt de authenticatie-stap onmiddellijk, *tenzij* er voorgaande `required` modules zijn gefaald. Als er geen voorgaande `required` modules zijn die gefaald zijn, en de `sufficient` module slaagt, wordt de rest van de modules in de stack voor dit moduletype genegeerd [29](#page=29) [30](#page=30). * `optional`: Het succes of falen van een `optional` module heeft geen invloed op de algehele uitkomst van de authenticatie-stap. Deze modules worden vaak gebruikt voor logging of andere informele taken [29](#page=29) [33](#page=33). * **Module Path:** Het pad naar de PAM-module die moet worden geladen (bijvoorbeeld `pam_unix.so`) [28](#page=28). * **Module Arguments:** Optionele argumenten die specifieke gedragingen van de module kunnen beïnvloeden [28](#page=28). Elk van de vier moduletypes (`auth`, `account`, `password`, `session`) vormt een "stack" van modules die in de gedefinieerde volgorde moeten worden doorlopen [26](#page=26). #### 3.1.1 De rol van controlemechanismen bij het bepalen van de uitkomst De controlemechanismen zijn cruciaal voor het bepalen van het uiteindelijke resultaat van een PAM-stap. De interactie tussen deze flags en de resultaten van de individuele modules bepaalt of een gebruiker succesvol wordt geauthenticeerd, of dat de toegang wordt geweigerd [27](#page=27). > **Tip:** Het begrijpen van de interactie tussen `required` en `sufficient` flags is essentieel. Een `sufficient` module kan een succesvolle stap garanderen, tenzij een eerdere `required` module al heeft gefaald. Dit zorgt voor flexibiliteit en robuustheid in het authenticatieproces. ### 3.2 Voorbeeld: `/etc/pam.d/chsh` configuratie Een vereenvoudigd voorbeeld van een PAM-configuratiebestand, specifiek voor de `chsh` (change shell) commando, illustreert de toepassing van deze concepten [34](#page=34) [35](#page=35) [36](#page=36) [37](#page=37) [38](#page=38) [39](#page=39): ``` auth sufficient pam_rootok.so auth requisite pam_shells.so auth sufficient pam_unix.so auth required pam_deny.so ``` Laten we dit voorbeeld analyseren: 1. `auth sufficient pam_rootok.so`: Als `pam_rootok.so` succesvol is (wat betekent dat de gebruiker root is), dan slaagt de `auth`-stap onmiddellijk [35](#page=35) [36](#page=36). 2. `auth requisite pam_shells.so`: Als de gebruiker geen root is, wordt deze regel geëvalueerd. `pam_shells.so` controleert of de gewenste shell van de gebruiker in de lijst van toegestane shells staat. Als deze module faalt (de shell is niet toegestaan), faalt de authenticatie onmiddellijk [37](#page=37). 3. `auth sufficient pam_unix.so`: Als de `pam_shells.so` module succesvol was (en de gebruiker dus root is óf de shell toegestaan is), dan controleert `pam_unix.so` de gebruikersnaam en het wachtwoord tegen de `/etc/shadow` database. Als dit succesvol is, slaagt de `auth`-stap onmiddellijk (omdat het een `sufficient` module is en de vorige `required` modules (of in dit geval `requisite`) succesvol waren) [38](#page=38). 4. `auth required pam_deny.so`: Deze regel wordt alleen bereikt als de voorgaande `sufficient` modules niet tot een onmiddellijk succes hebben geleid. `pam_deny.so` faalt altijd, wat impliceert dat als de vorige stappen het niet al tot succes hebben gebracht, deze regel de authenticatie definitief zal laten falen [39](#page=39). > **Voorbeeld:** Stel, een gebruiker probeert `chsh` te gebruiken. > * Als de gebruiker `root` is: `pam_rootok.so` slaagt (sufficient), dus de `auth`-stap is succesvol [35](#page=35). > * Als de gebruiker geen `root` is maar de gewenste shell is toegestaan: `pam_rootok.so` faalt (en wordt genegeerd omdat het `sufficient` is). `pam_shells.so` slaagt (requisite). Vervolgens slaagt `pam_unix.so` (sufficient) na correcte wachtwoordinvoer, dus de `auth`-stap is succesvol [37](#page=37) [38](#page=38). > * Als de gebruiker geen `root` is en de gewenste shell NIET is toegestaan: `pam_rootok.so` faalt. `pam_shells.so` faalt (requisite), dus de `auth`-stap faalt onmiddellijk [37](#page=37). > * Als om een andere reden de eerdere modules falen, maar de stappen nog niet definitief zijn afgesloten, zal `pam_deny.so` (required) de `auth`-stap laten falen [39](#page=39). ### 3.3 Module-specifieke configuratiebestanden Naast de algemene PAM-configuratiebestanden in `/etc/pam.d`, kunnen individuele PAM-modules hun eigen configuratiebestanden hebben om specifieke instellingen te beheren. Deze bestanden bevinden zich vaak in de `/etc/security/` directory [40](#page=40). * **Voorbeeld:** `/etc/security/time.conf` wordt gebruikt door de `pam_time.so` module om toegang te beperken tot specifieke tijden van de dag [40](#page=40). * **Voorbeeld:** `/etc/securetty` kan worden aangemaakt voor de `pam_securetty.so` module om een lijst van TTY's te specificeren van waaruit `root` mag inloggen (hoewel dit mechanisme sinds Debian 11 niet meer beschikbaar is) [40](#page=40). --- # Praktische toepassing en bronnen Deze sectie behandelt de praktische implementatie van tweefactorauthenticatie (2FA) met Time-based One-Time Passwords (TOTP) en biedt een lijst met nuttige bronnen voor verdere studie. ### 4.1 Implementatie van tweefactorauthenticatie (2FA) met TOTP De implementatie van tweefactorauthenticatie (2FA) maakt gebruik van Time-based One-Time Passwords (TOTP). Dit kan worden gerealiseerd door het gebruik van applicaties op mobiele telefoons, zoals de Google Authenticator app. Daarnaast is de integratie met Pluggable Authentication Modules (PAM) een gebruikelijke methode binnen Linux-omgevingen [41](#page=41). > **Tip:** TOTP-mechanismen genereren codes die slechts een beperkte tijd geldig zijn, wat de veiligheid aanzienlijk verhoogt door het risico op hergebruik van credentials te verminderen. ### 4.2 Bronnen voor verdere studie Voor diepgaandere kennis over Linux en gerelateerde onderwerpen, waaronder PAM, zijn de volgende bronnen aanbevolen: * **Boeken:** * "How Linux works 3rd edition" [42](#page=42). * "Practical Linux Topics" [42](#page=42). * "Beginning the Linux Command Line" [42](#page=42). * **Online documentatie (Linux-PAM):** * De officiële Linux-PAM website biedt uitgebreide documentatie, waaronder: * System Administrator Guide (SAG): http://www.linux-pam.org/Linux-PAM-html//Linux-PAM_SAG.html [42](#page=42). * Application Developer Guide (ADG): http://www.linux-pam.org/Linux-PAM-html//Linux-PAM_ADG.html [42](#page=42). * Module Writer's Guide (MWG): http://www.linux-pam.org/Linux-PAM-html//Linux-PAM_MWG.html [42](#page=42). > **Tip:** De documentatie van Linux-PAM is essentieel voor systeembeheerders en ontwikkelaars die de authenticatiemechanismen van hun systemen willen begrijpen en configureren. --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Name Service Switch (NSS) | Een mechanisme in Linux dat definieert waar en in welke volgorde naamgevingsinformatie, zoals gebruikersgegevens en hostnamen, wordt opgehaald. Het wordt geconfigureerd in het bestand `/etc/nsswitch.conf`. | | Pluggable Authentication Module (PAM) | Een flexibel framework in Linux dat het mogelijk maakt om authenticatiemechanismen modulair te beheren. Het scheidt de authenticatielogica van de applicaties zelf, waardoor systeembeheerders authenticatiemethoden kunnen aanpassen zonder applicaties te hoeven wijzigen. | | `/etc/nsswitch.conf` | Het configuratiebestand dat de Name Service Switch (NSS) beheert. Het specificeert de bronnen (zoals lokale bestanden, DNS, LDAP) die gebruikt moeten worden voor het opzoeken van diverse soorten informatie en de volgorde waarin deze bronnen worden geraadpleegd. | | `libpam.so` | Een gedeelde bibliotheek (shared object) die de functionaliteit van Pluggable Authentication Modules (PAM) bevat. Applicaties die PAM ondersteunen, worden hiertegen gelinkt om de PAM-authenticatie te kunnen gebruiken. | | Authenticatie | Het proces waarbij de identiteit van een gebruiker of entiteit wordt geverifieerd, meestal door middel van een wachtwoord, biometrische gegevens of een ander bewijs van identiteit. | | Account | Verwijst naar de status en rechten van een gebruiker in een systeem, inclusief zaken als vervaldatum, toegestane inlogtijden en toegangsrechten. | | Sessie | De context waarin een gebruiker interactie heeft met het systeem nadat authenticatie is geslaagd. Dit kan bijvoorbeeld het uitvoeren van opdrachten of het weergeven van berichten omvatten. | | Wachtwoord | Een geheime reeks tekens die wordt gebruikt om de identiteit van een gebruiker te verifiëren tijdens het authenticatieproces. PAM kan regels afdwingen voor wachtwoordsterkte en -wijzigingen. | | Dynamisch laadbare objectbestanden | Bestanden die tijdens de uitvoering van een programma in het geheugen kunnen worden geladen. PAM-modules zijn vaak van dit type, wat zorgt voor flexibiliteit en efficiëntie. | | Gedeelde objecten (`.so` bestanden) | Bestanden die code en gegevens bevatten die door meerdere programma"s tegelijk kunnen worden gebruikt. PAM-modules zijn typisch gedeelde objecten die specifieke authenticatietaken uitvoeren. | | Control flags | Parameters in PAM configuratiebestanden die bepalen hoe de uitkomst (succes of falen) van een specifieke PAM-module de algehele authenticatie voor de betreffende taak (auth, account, session, password) beïnvloedt. | | `required` (control flag) | Een controlemechanisme in PAM. Als een `required` module faalt, zal de hele authenticatiestack uiteindelijk falen, maar de uitvoering van de resterende modules in de stack wordt voortgezet. | | `requisite` (control flag) | Een controlemechanisme in PAM. Als een `requisite` module faalt, faalt de hele authenticatiestack onmiddellijk. De uitvoering van verdere modules wordt gestopt. | | `sufficient` (control flag) | Een controlemechanisme in PAM. Als een `sufficient` module slaagt, wordt de authenticatiestack als succesvol beschouwd, zelfs als andere modules falen. De uitvoering van verdere modules wordt gestopt. | | `optional` (control flag) | Een controlemechanisme in PAM. Het succes of falen van een `optional` module heeft geen directe invloed op de algehele uitkomst van de authenticatiestack. | | Tweefactorauthenticatie (2FA) | Een beveiligingsmethode die vereist dat een gebruiker twee verschillende vormen van identificatie levert om toegang te krijgen, wat de beveiliging aanzienlijk verhoogt vergeleken met een enkele authenticatiefactor. | | TOTP (Time-based One-Time Password) | Een algoritme dat een eenmalig wachtwoord genereert dat geldig is voor een beperkte tijd, gebaseerd op een gedeeld geheim en de huidige tijd. Dit is een veelgebruikte methode voor tweefactorauthenticatie. |