Identity and Data Security for Web Development

1. Assume Data Will Be Stolen and Use Proper Encryption

No matter how big you are, you should always assume that the possibility exists that your database security will be breached, and data stolen.

Worst-case scenario. The core principle of data security is to plan for the worst. Always assume that your database will be breached and sensitive data stolen. This mindset dictates the need for robust encryption practices. Encryption isn't just about preventing theft; it's about buying time and making data unusable if stolen.

Encryption is essential. All sensitive information, including passwords, credit card data, and personal details, should be properly encrypted. This includes data at rest (stored on servers) and data in motion (transmitted between systems). Strong encryption algorithms like SHA-256, AES, and RSA should be used.

Minimize data storage. Only store the minimum amount of sensitive user data required to run your application. Avoid the temptation to collect and store excessive information "just in case." The less data you store, the less risk to your users in the event of a breach. Data federation, maintaining distinct database systems in different regions, can also limit the impact of breaches.

2. Balance Security with Usability

Favor security too much over the experience and you’ll make the website a pain to use.

Usability vs. security. Striking the right balance between security and usability is crucial. Overly complex sign-in forms, multi-screen checkout processes, and constant identity verification can alienate users. Security measures should be implemented in a way that minimizes disruption to the user experience.

User-centric approach. Consider the user's perspective when implementing security measures. Ask questions like:

• Can I obtain identity information without imposing additional security checks?
• Can I build a more usable experience for users I have high confidence in?
• What content requires user identification, and when should I impose additional security?

Behind-the-scenes security. Implement as much security as possible behind the scenes, so users aren't forced to continually verify themselves. This might involve using browser fingerprinting, location-based tracking, or device fingerprinting to establish trust zones.

3. Understand and Mitigate Password Attack Vectors

With regular cryptographic hash functions, an attacker can guess billions of passwords per second.

Password vulnerabilities. Attackers employ various methods to gain access to user accounts, including phishing, social engineering, brute-force attacks, dictionary attacks, rainbow tables, malware, and offline cracking. Understanding these attack vectors is essential for building effective defenses.

Brute-force prevention. Implement CAPTCHAs after failed login attempts to increase login complexity and prevent automated attacks. Adding two-factor authentication (2FA) can also significantly reduce the risk of brute-force attacks.

Dictionary attack defense. Use salting to protect against dictionary attacks. Salting involves adding a random, unique string to each password before hashing, making it much harder for attackers to use precomputed tables of common passwords. Key stretching, which involves repeatedly applying a hashing function, also makes brute-force attacks more time-consuming.

4. Salting Passwords Prevents Dictionary and Rainbow Table Attacks

In simple terms, a salt of sufficient length and randomness provides a massive boost in security toward certain attack vectors, with just that simple, unique addition.

Salting defined. A salt is random data used in conjunction with a user's password when hashing. It protects against dictionary attacks and rainbow tables by ensuring that even if multiple users have the same password, the resulting hashes will be unique.

Salt generation and storage. Generate a random salt for each password using a cryptographically secure random number generator. The salt should be of sufficient length (at least 16 bytes) and stored alongside the hashed password in the database.

Salt reuse and length. Never reuse salts. Each user account should have a unique salt. The salt should be the same size as the output of the hash function used. A short salt can be cracked with lookup tables.

5. Trust Zones Enhance Security Based on User Behavior and Environment

Trust zones allow us to scale our security based on users’ behavior, environment, and our ability to determine whether they are who they say they are.

Contextual security. Trust zones allow you to adjust security measures based on a user's behavior, environment, and your confidence in their identity. This approach balances security with usability by reducing friction for trusted users.

Digital fingerprinting. Create a digital fingerprint for each user by collecting data about their browser configuration, hardware, devices, and location. This information can be used to identify users and assess their level of trust.

Data points for trust zones:

• Browser fingerprinting (user agent, plugins, fonts, etc.)
• Location-based tracking (GPS, IP address)
• Device fingerprinting (OS version, device model, Bluetooth paired devices)

6. OAuth 2.0 and OpenID Connect Secure Logins and Data Sharing

OpenID Connect enables handling a user’s login or determining whether a user is logged in already.

Authentication vs. authorization. Authentication verifies a user's identity, while authorization grants access to specific resources. OAuth 2.0 is primarily an authorization framework, while OpenID Connect builds on top of OAuth 2.0 to provide authentication capabilities.

OAuth 2.0 grant types:

• Authorization Code: For apps running on a web server
• Implicit: For browser-based or mobile apps
• Resource Owner Password Credentials: For logging in with a username and password
• Client Credentials: For application access

OpenID Connect's ID Token. OpenID Connect uses an ID Token, a security token containing authentication information, signed using JSON Web Signatures (JWS). It also uses a UserInfo endpoint to provide claims (profile information) about the authenticated user.

7. Two-Factor Authentication (2FA) Adds a Layer of Security

The most important element in this chain, the human being, is often taken out of the equation.

Beyond passwords. Two-factor authentication (2FA) requires users to provide two independent factors to verify their identity, such as something they know (password) and something they have (one-time password sent to their phone). This significantly reduces the risk of unauthorized access.

One-time passwords (OTPs). OTPs are short-lived, unique passwords that can be generated by authentication apps (e.g., Google Authenticator, Authy) or sent via SMS or email. They prevent replay attacks and other common security exploits.

Implementing 2FA with Authy:

• Register users with Authy, storing the Authy user ID in your database.
• Send SMS verification codes to users during login.
• Verify the verification codes entered by users to confirm their identity.

8. Biometrics Offer Identity Verification, Not Just Security

When using fingerprints, we run into a whole new dimension of issues: human beings have a maximum of ten fingers, and it is highly desirable that those fingerprints are not invalidated by being exposed to the public.

Biometrics for identity. Biometrics, such as fingerprint scanners and facial recognition, can be used to verify a user's identity, but they should not be relied upon as the sole security mechanism. Biometric data can be compromised or spoofed.

False-positive rates. When using biometrics, it's crucial to consider the false-positive rate (false-acceptance rate) of the technology. Google requires Android fingerprint scanners to have a false-positive rate of no higher than 0.002%.

Combining factors. Biometrics are best used in conjunction with other authentication factors, such as passwords or OTPs, to provide a layered security approach.

9. SSL/TLS Encryption Protects Data in Transit

One of the most important investments that you can make in a system, company, or application is in your security and identity infrastructures.

Secure communication. Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are cryptographic protocols that provide secure communication over a network. They encrypt data transmitted between a client and a server, protecting it from eavesdropping and tampering.

SSL certificates. To use SSL/TLS, you need to obtain an SSL certificate from a certificate authority (CA). The certificate verifies the identity of your website and enables secure connections. Different validation types (Domain Validation, Organization Validation, Extended Validation) offer varying levels of assurance.

Self-signed certificates for testing. For testing purposes, you can create your own self-signed certificates. However, these certificates should never be used in production, as they are not trusted by browsers and will display security warnings to users.

10. Asymmetric Cryptography Secures Communication Over Insecure Channels

As we explore each chapter and concept, you’ll learn how to plug holes in existing systems, protect against viable attack vectors, and work in environments that are sometimes naturally insecure.

Public/private key pairs. Asymmetric cryptography uses pairs of public and private keys. The sender encrypts data with the recipient's public key, and the recipient decrypts it with their private key. This ensures that only the intended recipient can read the message.

Signing for verification. The sender also signs the message with their private key. The recipient can then verify the signature using the sender's public key, ensuring that the message is authentic and hasn't been tampered with.

Use case: insecure devices. Asymmetric cryptography is useful in scenarios where communication channels are potentially insecure, such as when using Bluetooth Low Energy (BLE) beacons for in-aisle purchasing.

11. Symmetric Cryptography Provides Fast Encryption in Trusted Environments

With that said, there are certain standard mechanisms that we use for account security, and others that we should avoid.

Shared secret. Symmetric cryptography uses a single, shared secret key to encrypt and decrypt data. This method is faster than asymmetric cryptography but requires a secure way to exchange the shared secret.

Trusted environments. Symmetric cryptography is well-suited for trusted environments where the communication channel is secure, such as when transmitting data between two servers owned by the same organization.

AES block ciphering. AES (Advanced Encryption Standard) is a popular symmetric encryption algorithm. It can be used with different modes of operation, such as Cipher Block Chaining (CBC), to provide additional security. Initialization vectors and padding are often used with block ciphers to ensure data integrity and prevent attacks.

Last updated: March 17, 2025