PKCE (pronounced "pixy")

RFC 7636: Proof Key for Code Exchange

www.rfc-editor.org/rfc/rfc7636

PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF (cross-site request forgery) and authorization code injection attacks.

PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use client authentication.

source: https://oauth.net/2/pkce/

AI Overview

How It Works

PKCE replaces the need for a client secret with a cryptographic proof process:

1. Create the Verifier: The client app generates a cryptographically random, high-entropy string called the Code Verifier.
2. Create the Challenge: The app hashes this string (typically using SHA-256) to create the Code Challenge.
3. Send the Challenge: The app sends the Code Challenge to the authorization server alongside the initial login request.
4. Exchange and Verify: When the authorization server returns the authorization code, the app sends the code plus the original unhashed Code Verifier back to the server. The server hashes the provided verifier and confirms it matches the original challenge before issuing an access token.

LDAP (Lightweight Directory Access Protocol)

LDAP, the Lightweight Directory Access Protocol, is a mechanism for interacting with directory servers. It’s often used for authentication and storing information about users, groups, and applications.

source: https://ldap.com/

The Lightweight Directory Access Protocol (LDAP) is a directory service protocol that runs on a layer above the TCP/IP stack. It provides a mechanism used to connect to, search, and modify Internet directories. The LDAP directory service is based on a client-server model. The function of LDAP is to enable access to an existing directory.

source: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api

PBKDF (Password Based Key Derivation Function)

PBKDF2, defined in RFC 2898, is a specific Key Derivation Function (KDF). A KDF is simply any mechanism for taking a password (something a user remembers or stores in a password manager) and turning it into a symmetric key suitable for cryptographic operations (i.e., AES).

PBKDF2 takes as input a password, a salt (see TWOTW Salt and Pepper), an integer defining how many “iterations” of the hash function to undergo, and an integer describing the desired key length for the output.

source: https://www.ssltrust.com/blog/pbkdf2-password-key-derivation

PBKDF2 applies a pseudorandom function, such as hash-based message authentication code (HMAC), to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching (see TWOTW Key Stretching).

In 2023, OWASP recommended to use 600,000 iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512.

Algorithmic representation of the iterative process of PBKDF2.

Having a salt added to the password reduces the ability to use precomputed hashes (rainbow tables) (see TWOTW Rainbow Tables) for attacks, and means that multiple passwords have to be tested individually, not all at once. The public key cryptography standard recommends a salt length of at least 64 bits. The US National Institute of Standards and Technology recommends a salt length of at least 128 bits.

source: https://en.wikipedia.org/wiki/PBKDF2

Further reading: Password Storage Cheat Sheet

Key Stretching (cryptography)

Key stretching techniques are used to make a possibly weak key, typically a password or passphrase, more secure against a brute-force attack by increasing the resources (time and possibly space) it takes to test each possible key. Passwords or passphrases created by humans are often short or predictable enough to allow password cracking, and key stretching is intended to make such attacks more difficult by complicating a basic step of trying a single password candidate. 

There are several ways to perform key stretching. One way is to apply a cryptographic hash function or a block cipher repeatedly in a loop. For example, in applications where the key is used for a cipher, the key schedule in the cipher may be modified so that it takes a specific length of time to perform. Another way is to use cryptographic hash functions that have large memory requirements.

Modern password-based key derivation functions, such as PBKDF2 (see TWOTW PBKDF), use a cryptographic hash, such as SHA-2, a longer salt (e.g. 64 bits) and a high iteration count. The U.S. National Institute of Standards and Technology (NIST) recommends a minimum iteration count of 10,000.

In 2013, a Password Hashing Competition was held to select an improved key stretching standard that would resist attacks from graphics processors and special purpose hardware. The winner, Argon2, was selected on July 1, 2015.

source: https://en.wikipedia.org/wiki/Key_stretching

Further reading: Password Storage Cheat Sheet

Salt and Pepper (password cryptography)

Salt

A “salt” is a random string that is added to a password before it undergoes the hashing process. The primary purpose of salting is to add uniqueness to each hashed password, even when two users have identical passwords.

Pepper

Pepper is a secret value added to the password before encryption. But pepper is not stored with user records. Instead, the pepper is a fixed value (or a set of values) used across the system. Pepper is kept private and away from the user/password records. Pepper is often hard-coded into the application or stored in a secure configuration file.

source: https://little-fire.com/salt-and-pepper-in-password-cryptography/

Combining the password with the pepper value means that even if the attacker has the hash and the salt, they still won’t have enough information to be able to easily get the original password back out. 

It’s impossible to change a pepper value without forcing every user to reset their password.

source: https://www.baeldung.com/cs/password-salt-pepper

Further reading: Password Storage Cheat Sheet

Rainbow Table

Rainbow Tables are commonly confused with another, simpler technique that leverages a compute time-storage tradeoff in password recover: hash tables.

Hash tables are constructed by hashing each word in a password dictionary. The password-hash pairs are stored in a table, sorted by hash value. To use a hash table, simple take the hash and perform a binary search in the table to find the original password, if it's present.

Rainbow Tables are more complex. Constructing a rainbow table requires two things: a hashing function and a reduction function. The hashing function for a given set of Rainbow Tables must match the hashed password you want to recover. The reduction function must transform a hash into something usable as a password. A simple reduction function is to Base64 encode the hash, then truncate it to a certain number of characters.

Rainbow tables are constructed of "chains" of a certain length: 100,000 for example. To construct the chain, pick a random seed value. Then apply the hashing and reduction functions to this seed, and its output, and continue iterating 100,000 times. Only the seed and final value are stored. Repeat this process to create as many chains as desired.

To recover a password using Rainbow Tables, the password hash undergoes the above process for the same length: in this case 100,000 but each link in the chain is retained. Each link in the chain is compared with the final value of each chain. If there is a match, the chain can be reconstructed, keeping both the output of each hashing function and the output of each reduction function. That reconstructed chain will contain the hash of the password in question as well as the password that produced it.

source: Answer by Crunge on security.stackexchange.com

See also: How Rainbow Tables work 

See also: https://en.wikipedia.org/wiki/Rainbow_table

Further reading: Password Storage Cheat Sheet

JWT (pronounced jot) JSON Web Token

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header
• Payload
• Signature

Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema.

Validation and Verification

Validate a JWT to make sure the token makes sense, adheres to the expected standards, contains the right data.

Verify a JWT to make sure the token hasn't been altered maliciously and comes from a trusted source.

JWT validation generally refers to checking the structure, format, and content of the JWT:

• Structure: Ensuring the token has the standard three parts (header, payload, signature) separated by dots.
• Format: Verifying that each part is correctly encoded (Base64URL) and that the payload contains expected claims.
• Content: Checking if the claims within the payload are correct, such as expiration time (exp), issued at (iat), not before (nbf), among others, to ensure the token isn't expired, isn't used before its time, etc.

JWT verification involves confirming the authenticity and integrity of the token:

• Signature Verification: This is the primary aspect of verification where the signature part of the JWT is checked against the header and payload. This is done using the algorithm specified in the header (like HMAC, RSA, or ECDSA) with a secret key or public key. If the signature doesn't match what's expected, the token might have been tampered with or is not from a trusted source.
• Issuer Verification: Checking if the iss claim matches an expected issuer.
• Audience Check: Ensuring the aud claim matches the expected audience.

source: https://www.jwt.io/introduction#when-to-use-json-web-tokens

Public and Private Keys with JWTs

With JWT, the possession and the use of the key materials are exactly the same as in any other contexts where cipher operations occur.

Signing

• The private key is owned by the issuer and is used to compute the signature.
• The public key can be shared with all parties that need to verify the signature.

Encryption

• The private key is owned by the recipient and is used to decrypt the data.
• The public key can be shared with any party that wants to send sensitive data to the recipient.

Encryption is rarely used with JWT. Most of the time the HTTPS layer is sufficient and the token itself only contains a information that is not sensitive.

The issuer of the token (the authentication server) has a private key to generate signed tokens (JWS). These tokens are sent to the clients (an API server, a web/native application). 

The clients can verify the token with the public key. The key is usually fetched using a public URI.

If you have sensitive data that shall not be disclosed to a third party (phone numbers, personal address), then the encrypted tokens (JWE) are highly recommended. In this case, each client (i.e. recipient of a token) shall have a private key and the issuer of the token must encrypt the token using the public key of each recipient. This means that the issuer of the token can select the appropriate key for a given client.

source: https://stackoverflow.com/a/60540274/113701

PKI (Public Key Infrastructure)

Public key infrastructure (PKI) refers to tools used to create and manage public keys for encryption, which is a common method of securing data transfers on the internet. PKI is built into all web browsers used today, and it helps secure public internet traffic. Organizations can use it to secure the communications they send back and forth internally and also to make sure connected devices can connect securely.

The most important concept associated with PKI is the cryptographic keys that are part of the encryption process and serve to authenticate different people or devices attempting to communicate with the network.

source: https://www.fortinet.com/resources/cyberglossary/public-key-infrastructure

The components of public key infrastructure include:

• PKI keys: A key pair used for encryption. This protects data by making it unreadable to anyone except the intended recipient. In cryptography, each public key is paired with a private key. The public key is distributed freely and openly, while the private key is secret to the owner.
• Digital certificates: Electronic credentials that link the certificate holder’s identity to a key pair that can be used to encrypt and sign information.
• Certificate authority (CA): An entity that verifies identities and issues digital certificates.
• Registration authority (RA): Responsible for accepting certificate requests and authenticating the individual or organization behind them.
• Certificate repositories: Secure storage systems that hold digital certificates for lookup and validation.
• Centralized management software: Software that lets organizations manage keys and digital certificates from one place.
• Hardware security module (HSM): Physical devices that perform cryptographic operations and store private keys securely.

A digital certificate, sometimes called a “public key certificate,” is an electronic document used to identify the owner of a public key. This allows the recipient to confirm the key came from a legitimate source, mitigating the risk of an MITM (man in the middle) attack. 

PKI certificates typically include:

• Identifiable information, such as the certificate holder’s name, the certificate’s serial number, and its expiration date
• A copy of the public key, which others can use to encrypt data and verify digital signatures, supporting both confidentiality and authentication
• The digital signature of the issuing CA to confirm authenticity

A certificate authority (CA) is a trusted third-party organization that creates and issues digital certificates. They validate identities and help establish trust chains for secure digital communications.

All CAs maintain certificate revocation lists (CRLs), which document certificates revoked before their scheduled expiration date. This helps organizations identify certificates that are no longer valid or secure.

source: https://www.entrust.com/resources/learn/what-is-pki

Passwordless Authentication

Passwordless Authentication is an authentication method that allows a user to gain access to an application or IT system without entering a password or answering security questions. Instead, the user provides some other form of evidence such as a fingerprint, proximity badge, or hardware token code. Passwordless Authentication is often used in conjunction with Multi-Factor Authentication (MFA) and Single Sign-On solutions to improve the user experience, strengthen security, and reduce IT operations expense and complexity.

source: https://www.cyberark.com/what-is/passwordless-authentication/

Trusted Source

What are Trusted sources?

Trusted Sources in Cybersecurity and Antivirus

In the context of cybersecurity and antivirus operations, the authenticity and integrity of such sources are vitally essential. In its simplest context, a trusted source can be a website that is widely recognized to have secured and encrypted measures for meeting data transfers and transactions. It is crucial to understand that no source can be considered wholly exempt from risk. Cyber-criminals often aim to pretend to be reputable entities. Unwary victims, assuming they are dealing with one of their trusted sources, might inadvertently download malware or reveal sensitive personal information.

In antivirus operations, a trusted source is a program, application, or website that the antivirus software treats as safe. That means the antivirus will not block or hinder any activities from sources it trusts. Hence, choosing a trusted source in antivirus software should be done carefully as it poses a potential vulnerability point if the trusted source is compromised.

Trusted sources should not be presumed as always safe. Trusted sources can become compromised, resulting in them being used as vehicles for delivering viruses. The concept of trusted sources is central to the fabric of cybersecurity and antivirus regimes, although intrinsically it may also be a conduit for cyber threats.

How do I identify a trusted source in cybersecurity and antivirus software?

Look for vendors with a proven track record of providing quality products and services. Also, do research on the vendor's reputation in the cybersecurity community and read reviews from other users. Additionally, ensure that the vendor is transparent about their security measures and regularly updates their software to stay ahead of emerging threats.

source: https://cyberpedia.reasonlabs.com/EN/trusted%20sources.html

The Trust Equation: Trustworthiness

Credibility

has to do with the words we speak. In a sentence we might say, “I can trust what she says about intellectual property; she’s very credible on the subject.”

Reliability

has to do with actions. We might say, “If he says he’ll deliver the product tomorrow, I trust him, because he’s dependable.”

Intimacy

refers to the safety or security that we feel when entrusting someone with something. We might say, “I can trust her with that information; she’s never violated my confidentiality before, and she would never embarrass me.”

Self-orientation

refers to the person’s focus. In particular, whether the person’s focus is primarily on him or herself, or on the other person. We might say, “I can’t trust him on this deal — I don’t think he cares enough about me, he’s focused on what he gets out of it.” Or more commonly, “I don’t trust him — I think he’s too concerned about how he’s appearing, so he’s not really paying attention.”

source: Understanding The Trust Equation by Trusted Advisor

Trust and trustworthiness are different. Trust is directed toward another person, object or organization. If that object is trustworthy, such as a sturdy chair, then that trust is well-placed. Trust also takes time. In the equation, reliability requires time to determine. Trust is also directed and limited. Trust is in some specific area, for example, trusting your doctor for medical advice is reasonable, given their credibility, but trusting them for financial advice is likely unwarranted. 

Trust, in my opinion, is based on prejudicial bias (e.g., alignment of world view), past experience, trust in third-party recommendations, personal interaction, a sense of closeness or sharing things in common, and physical proximity. One group of people may hold a person or organization as a "trusted source" while another group of people distrust that same source. And some people are more trusting and others lean toward being skeptical. Trust is given in degrees. It increases or decreases through experience.