Juice Shop t6login (Login Morty) Challenge: Step-by-Step Solution

The t6login challenge — formally titled “Login Morty” in the OWASP Juice Shop scoreboard — is one of the most-searched Juice Shop challenges. It sits at three-star difficulty (⭐⭐⭐) and teaches credential discovery through source code review: finding a hardcoded password embedded in the application’s JavaScript bundle.

This guide walks through exactly how to complete the t6login / Login Morty challenge, what the t6_L33t_sPa4n credential is and where it comes from, and what this challenge teaches about real-world hardcoded credentials vulnerabilities.

---

What Is the t6login Challenge?

In Juice Shop’s scoreboard, this challenge appears as:

“Login with Morty’s user credentials without applying SQL Injection or any other bypass.”

The challenge requires you to log in as Morty — a regular (non-admin) Juice Shop user — by finding and using the actual password. SQL injection is explicitly prohibited, so this is a credential discovery exercise, not an authentication bypass.

The password is t6_L33t_sPa4n. Finding it is the challenge.

---

Why Is This Challenge Called “t6login”?

Juice Shop challenge solutions spread across the internet often refer to this challenge as “t6login” because the login URL pattern in Juice Shop’s Angular frontend includes challenge-specific routing parameters, and community writeups frequently reference the numeric challenge identifier t6 when describing the Login Morty challenge.

The t6 prefix corresponds to how Juice Shop challenge IDs are structured internally in some versions. You may see it referenced in CTF writeups as:

• t6login
• juice shop t6 challenge
• juice shop login morty
• juice shop morty password

All of these refer to the same challenge: log in as Morty with real credentials — no SQL injection.

---

Step-by-Step Solution: Login Morty (t6login)

Step 1: Start Juice Shop

If you haven’t already started Juice Shop, run it with Docker:

docker run --rm -p 3000:3000 bkimminich/juice-shop

Open http://localhost:3000/ and navigate to the scoreboard at http://localhost:3000/#/score-board.

Step 2: Find Morty’s Email Address

Before you can log in as Morty, you need his email address. There are two approaches:

Approach A: Via the Admin User List (requires admin access first)

If you have already completed the Login Admin challenge (SQL injection bypass), navigate to:

http://localhost:3000/#/administration

The administration panel lists all registered users with their email addresses. Morty’s email is: morty@juice-sh.op

Approach B: Via Product Reviews

Morty has left product reviews visible on the shop. Browse product pages and look for reviews signed with “Morty” — his full email (morty@juice-sh.op) may appear, or you can confirm the username matches.

Approach C: Via the Users API

With admin credentials (from the Login Admin challenge), you can query the Users API:

curl http://localhost:3000/api/Users \
  -H "Authorization: Bearer YOUR_ADMIN_JWT_TOKEN"

The response lists all users including morty@juice-sh.op.

Step 3: Find the Password in the JavaScript Source

Morty’s password (t6_L33t_sPa4n) is hardcoded into Juice Shop’s JavaScript bundle — an intentional vulnerability teaching the dangers of hardcoded credentials in source code.

Finding it via browser DevTools:

1. Open http://localhost:3000/ in Chrome or Firefox
2. Open DevTools (F12) → Sources tab
3. Navigate to the main.js file (the bundled Angular application)
4. Use Search (Ctrl+F or Cmd+F within the Sources panel) and search for: t6_L33t_sPa4n
5. You’ll find the password hardcoded in the application source

Finding it via direct bundle search:

# Download the main bundle and search for Morty's credentials
curl -s http://localhost:3000/main.js | grep -o "t6_L33t_sPa4n"

Alternative: Search for Morty’s email in the bundle:

curl -s http://localhost:3000/main.js | grep -o "morty@juice-sh.op"

In the surrounding code context, you’ll find the hardcoded password alongside the email address.

Step 4: Log In as Morty

Navigate to http://localhost:3000/#/login and log in with:

• Email: morty@juice-sh.op
• Password: t6_L33t_sPa4n

Do not use any SQL injection in the email or password fields — the challenge requires actual credential use. Juice Shop will detect if you bypass authentication rather than using the real credentials.

Upon successful login, the challenge notification popup appears and the scoreboard marks “Login Morty” as solved.

---

What This Challenge Teaches: Hardcoded Credentials (CWE-798)

The t6login / Login Morty challenge is a hands-on demonstration of CWE-798: Use of Hard-Coded Credentials — one of the most consistently critical vulnerability classes in real-world application security.

Why Hardcoded Credentials Are Dangerous

When credentials are embedded in source code or compiled application bundles:

1. Source code is often widely distributed — npm packages, open-source repositories, Docker images, and version control history all become attack vectors
2. Compiled bundles are readable — JavaScript bundles (like Juice Shop’s Angular app), .NET assemblies, and Java JARs can all be decompiled or searched as text
3. Credentials cannot be rotated without redeployment — if a hardcoded password is compromised, changing it requires a full build and deployment cycle
4. Version control history preserves them forever — even after removal, credentials added to a git repository remain discoverable in the commit history

In Juice Shop, the t6_L33t_sPa4n password is embedded in the compiled JavaScript bundle served to every user who loads the application — anyone who opens DevTools can find it in seconds.

Real-World Hardcoded Credential Incidents

Hardcoded credentials are among the most commonly reported vulnerabilities in production applications:

• Credentials hardcoded in JavaScript bundles are discoverable by any user with DevTools access
• API keys embedded in mobile app binaries are extractable with basic reverse engineering tools
• Hardcoded database credentials in server-side configuration files exposed in public repositories have led to mass data breaches
• Docker images published to Docker Hub have repeatedly been found to contain hardcoded AWS access keys, database passwords, and API tokens

The OWASP Top 10 maps this to A07:2021 — Identification and Authentication Failures, and it appears on the CWE Top 25 Most Dangerous Software Weaknesses at CWE-798.

How SAST Detects Hardcoded Credentials

Static Application Security Testing (SAST) tools detect hardcoded credentials by:

1. Pattern matching — detecting strings matching common credential formats (passwords, API keys, connection strings) in source files
2. Entropy analysis — identifying high-entropy strings that are statistically likely to be secrets rather than ordinary application strings
3. Context analysis — recognizing credential-adjacent patterns (password = "...", api_key = "...", Authorization: Bearer <string>)

The fix is straightforward: credentials should never appear in source code. Use environment variables, secrets management systems (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), or runtime configuration injection instead.

---

Other Juice Shop Login Challenges

The t6login challenge is one of several authentication-related challenges in Juice Shop. Here’s how the login challenges compare:

Challenge	Stars	Technique	Credential
Login Admin	⭐⭐	SQL injection bypass	No real password needed
Login Jim	⭐⭐	SQL injection (targeted)	No real password needed
Login Morty (t6login)	⭐⭐⭐	Credential discovery in source	morty@juice-sh.op / t6_L33t_sPa4n
Login Bender	⭐⭐⭐	SQL injection (specific pattern)	No real password needed
Login Amy	⭐⭐⭐	Security question answer	Guessable from profile data
Login Bjoern (OAuth)	⭐⭐⭐⭐	OAuth login flow abuse	OAuth-based

The Login Morty challenge is specifically designed to teach the difference between authentication bypass (SQL injection) and credential discovery — finding real credentials that were carelessly embedded in application code.

---

Finding t6_L33t_sPa4n Without Hints

If you’re attempting this challenge without solution guides, the methodical approach is:

1. Explore the JavaScript bundle — Juice Shop’s Angular frontend is a single compiled main.js file. Searching this file for email addresses, passwords, and user references is a standard reconnaissance technique in web app penetration testing.

2. Look for test/demo credentials — Applications often ship with test accounts and hardcoded demo credentials. Searching source bundles for password, pass, secret, key, and common username formats is a standard SAST and manual code review technique.

3. Check configuration endpoints — Some Juice Shop challenges expose configuration or API endpoints that return internal data. Exploring http://localhost:3000/api/ without authentication reveals what the application exposes publicly.

4. Read community walkthroughs — The companion book Pwning OWASP Juice Shop (free at pwning.owasp-juice.shop) contains hints and solutions for every challenge, including Login Morty.

---

Preventing Hardcoded Credentials in Your Applications

If the t6login challenge has illustrated the risk, here’s how to eliminate hardcoded credentials from your own codebase:

Use Environment Variables

// VULNERABLE — hardcoded credential in source
const dbPassword = "t6_L33t_sPa4n";

// SECURE — read from environment at runtime
const dbPassword = process.env.DB_PASSWORD;
if (!dbPassword) throw new Error("DB_PASSWORD environment variable is required");

Use a Secrets Manager

# Python — AWS Secrets Manager
import boto3
import json

def get_secret(secret_name):
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response['SecretString'])

# At runtime — secret never in source code
creds = get_secret("prod/db/credentials")
db_password = creds["password"]

Scan Your Repository for Secrets

# Use trufflehog to scan git history for secrets
trufflehog git file://. --only-verified

# Or gitleaks
gitleaks detect --source . -v

Add Pre-Commit Hooks

Add secret scanning to your CI/CD pipeline to prevent credentials from ever being committed:

# GitHub Actions — scan for secrets on every PR
- name: Scan for secrets
  uses: trufflesecurity/trufflehog@main
  with:
    path: ./
    base: ${{ github.event.repository.default_branch }}
    head: HEAD

---

SAST Detection of Hardcoded Credentials

Offensive360 SAST detects CWE-798 hardcoded credentials through:

• Pattern matching on credential-adjacent variable assignments (password, secret, key, token, api_key)
• High-entropy string detection for API keys, tokens, and random-looking secrets
• Connection string analysis identifying embedded database passwords
• Configuration file scanning for secrets in YAML, JSON, .env, and properties files

Hardcoded credential findings appear as Critical severity in the SAST report, with the exact file, line number, and the matched credential pattern highlighted.

---

Summary

The t6login (Login Morty) challenge in OWASP Juice Shop:

• Objective: Log in as morty@juice-sh.op without SQL injection
• Password: t6_L33t_sPa4n (found in the JavaScript bundle)
• Technique: Source code / bundle reconnaissance — reading the compiled Angular app to find hardcoded credentials
• What it teaches: CWE-798 Hardcoded Credentials — one of the most critical and commonly exploited vulnerability classes in real applications
• Real-world analog: API keys in JavaScript bundles, database passwords in git history, hardcoded credentials in mobile app binaries

Field	Value
Challenge name	Login Morty
Challenge ID	t6 (community designation)
Difficulty	⭐⭐⭐ (3 stars)
Email	morty@juice-sh.op
Password	t6_L33t_sPa4n
Where to find it	Juice Shop’s compiled main.js bundle
CWE	CWE-798 — Use of Hard-Coded Credentials
OWASP Top 10	A07:2021 — Identification and Authentication Failures

---

For more Juice Shop challenge solutions across all difficulty levels, see our complete OWASP Juice Shop walkthrough. For source-code detection of hardcoded credentials and 100+ other vulnerability classes, see Offensive360 SAST.