Skip to main content

Overview

DVWA comes with five pre-configured user accounts in the database. These accounts are created during the database setup process and are used for various security exercises, particularly brute force attacks, SQL injection, and access control testing.

Default User Accounts

The following accounts are automatically created when you run the database setup:
User IDUsernamePasswordFirst NameLast NameRole
1adminpasswordadminadminadmin
2gordonbabc123GordonBrownuser
31337charleyHackMeuser
4pabloletmeinPabloPicassouser
5smithypasswordBobSmithuser
These credentials are intentionally weak and publicly documented. They’re designed to be discovered and exploited as part of the learning process.

Administrator Account

Username: admin
Password: password
Role: admin

Characteristics

  • Primary login account for accessing DVWA
  • Full administrative privileges
  • Used to configure security levels and system settings
  • Target for privilege escalation exercises
  • Can be reset at any time via database setup

Usage

  • Initial login to DVWA
  • Database setup and configuration
  • Security level management
  • Administrative tasks
  • Testing authorization bypass vulnerabilities

Standard User Accounts

The four non-admin accounts serve different purposes in security exercises:

gordonb (Gordon Brown)

Password: abc123
  • Common, simple password
  • Good target for dictionary attacks
  • Demonstrates weak password choices

1337 (Hack Me)

Password: charley
  • Username suggests a hacker persona
  • Password is a common name
  • Tests username enumeration

pablo (Pablo Picasso)

Password: letmein
  • Classic weak password example
  • One of the most common passwords
  • Perfect for demonstrating password cracking

smithy (Bob Smith)

Password: password
  • Same password as admin (intentional)
  • Tests password reuse scenarios
  • Useful for access control exercises

User Roles and Permissions

DVWA implements a basic role-based access control system:

Admin Role

  • Access to all functionality
  • Can view security logs and access logs
  • Can perform administrative actions
  • Required for system configuration

User Role (Default)

  • Standard access to vulnerability modules
  • Limited access to certain features
  • Cannot access administrative functions
  • Used in Broken Access Control (BAC) exercises
The role column was added to support the Broken Access Control vulnerability module, where users attempt to access resources they shouldn’t have permission to view.

Password Storage

Passwords in DVWA are stored using MD5 hashing:
INSERT INTO users VALUES (
  '1', 'admin', 'admin', 'admin', MD5('password'), ...
);
```sql

<Warning>
  MD5 is cryptographically broken and should never be used in production. DVWA uses it intentionally to demonstrate insecure password storage and to make password cracking exercises feasible.
</Warning>

### Security Implications by Level

**Low Level:**
- Passwords transmitted in plain text
- No password strength requirements
- Unlimited login attempts

**Medium Level:**
- Still using MD5
- Minimal rate limiting
- Weak protection against brute force

**High Level:**
- MD5 with additional controls
- Anti-CSRF tokens
- Random delays

**Impossible Level:**
- Still uses MD5 (database limitation)
- Account lockout protection
- Failed login tracking

## Account Usage in Exercises

### Brute Force Module
Goal: Discover user passwords through automated guessing

- Start with username enumeration
- Use wordlists to crack passwords
- Progress through security levels
- Learn about account lockouts at Impossible level

**Objective:** "Get the administrator's password by brute forcing. Bonus points for getting the other four user passwords!"

### SQL Injection Module
Goal: Extract user data from the database

- Dump the users table
- Retrieve password hashes
- Extract usernames and other details
- Understand data exposure risks

**Sample Exploitation:**
```sql
' UNION SELECT user, password FROM users-- -

Broken Access Control (BAC)

Goal: Access resources belonging to other users
  • View files/data of other users
  • Bypass role-based restrictions
  • Understand horizontal privilege escalation
  • Test vertical privilege escalation (user to admin)

Authorization Bypass

Goal: Bypass authentication mechanisms
  • Manipulate user data
  • Access functionality without proper authentication
  • Change other users’ information
  • Understand authentication vs. authorization
DVWA creates several tables related to user management:

users Table

Main user account storage:
CREATE TABLE users (
  user_id int(6) PRIMARY KEY,
  first_name varchar(15),
  last_name varchar(15),
  user varchar(15),
  password varchar(32),
  avatar varchar(70),
  last_login TIMESTAMP,
  failed_login INT(3),
  role VARCHAR(20) DEFAULT 'user',
  account_enabled TINYINT(1) DEFAULT 1
);
```sql

### access_log Table
Tracks user access to resources:
```sql
CREATE TABLE access_log (
  id INT AUTO_INCREMENT PRIMARY KEY,
  user_id INT NOT NULL,
  target_id INT NOT NULL,
  action VARCHAR(50) NOT NULL,
  timestamp DATETIME NOT NULL,
  FOREIGN KEY (user_id) REFERENCES users(user_id),
  FOREIGN KEY (target_id) REFERENCES users(user_id)
);

security_log Table

Tracks security events:
CREATE TABLE security_log (
  id INT AUTO_INCREMENT PRIMARY KEY,
  user_id INT NOT NULL,
  target_id INT NOT NULL,
  action VARCHAR(50) NOT NULL,
  timestamp DATETIME NOT NULL,
  ip_address VARCHAR(45) NOT NULL,
  FOREIGN KEY (user_id) REFERENCES users(user_id),
  FOREIGN KEY (target_id) REFERENCES users(user_id)
);
```bash

## Account Management

### Resetting Accounts
To restore all accounts to default:

1. Navigate to **Setup DVWA**
2. Click **Create / Reset Database**
3. All accounts return to original passwords
4. All logs are cleared
5. Failed login counters reset to 0

### Account Lockout (Impossible Level)

At the Impossible security level, the brute force module implements account lockout:

- 5 failed login attempts within 15 minutes triggers lockout
- Locked accounts cannot log in (even with correct password)
- Prevents user enumeration
- Can cause denial of service
- Demonstrates realistic security controls

**Lockout Behavior:**
Username or password incorrect. (Same message for locked accounts and invalid credentials)

## Using Accounts in Testing

### Password Cracking Practice

1. Extract password hashes via SQL injection
2. Use tools like John the Ripper or Hashcat
3. Compare cracking times for different passwords
4. Learn about rainbow tables and dictionary attacks

**Example hash extraction:**
```sql
SELECT user, password FROM users;

Session Hijacking

  • Log in as different users
  • Examine session cookies
  • Test session fixation
  • Understand session management flaws

Privilege Escalation

  • Log in as regular user
  • Attempt to access admin functionality
  • Modify role via SQL injection
  • Test horizontal and vertical escalation

User Avatars

Each user has an associated avatar image:
/hackable/users/admin.jpg
/hackable/users/gordonb.jpg
/hackable/users/1337.jpg
/hackable/users/pablo.jpg
/hackable/users/smithy.jpg
These are used in:
  • File inclusion exercises
  • Path traversal testing
  • Understanding file upload contexts

Security Lessons

Weak Passwords

All five accounts demonstrate common password mistakes:
  • Using “password” (admin, smithy)
  • Simple sequences (abc123)
  • Common words (charley, letmein)
  • No complexity requirements

Password Reuse

  • admin and smithy share the same password
  • Demonstrates risks of password reuse
  • Shows importance of unique passwords per account

Predictable Usernames

  • Simple names (admin, pablo, smithy)
  • Numeric usernames (1337)
  • Easy to enumerate
  • Common in real-world systems

Insufficient Protection

  • No multi-factor authentication
  • Weak hashing (MD5)
  • No password complexity requirements
  • No password expiration
When practicing with these accounts, try creating your own wordlists based on the user information. This simulates targeted attacks where attackers research their targets.

Next Steps

  • Learn about Security Levels to understand how account protection varies
  • Try the Brute Force module to practice password attacks
  • Use SQL Injection to extract account data
  • Test the Broken Access Control module to understand authorization
  • Review Getting Started for navigation tips
These weak credentials are for educational purposes only. Never use simple passwords, MD5 hashing, or weak authentication in production systems.

Build docs developers (and LLMs) love