login

Description

Solution

1. Step 1Read the page source
   View the page source or open the Network tab and find index.js. All authentication logic is written in client-side JavaScript -- there is no server-side validation.
   Learn more

   Everything a web browser renders is sent to the client -- HTML, CSS, and JavaScript are all downloadable and readable. When authentication logic is implemented entirely in client-side JavaScript (as opposed to a server-side check), the credentials and validation rules are necessarily included in that code. An attacker simply reads the script to understand exactly what the application checks.

   Browser developer tools (F12) are the primary instrument for client-side web analysis. The Sources tab shows all loaded JavaScript files, the Network tab shows every HTTP request and response, and the Console lets you run arbitrary JavaScript in the page's context. Pressing Ctrl+U shows the raw HTML source including inline scripts.

   Real applications should always perform authentication on the server, where the code is not exposed to users. Client-side checks are appropriate only for UI feedback (like disabling a submit button before all fields are filled) -- they must never be the only gate protecting sensitive resources.

2. Step 2Decode the username
   The script compares btoa(username) === 'YWRtaW4=' -- decode this base64 string to get the required username.
   python3 -c "import base64; print(base64.b64decode('YWRtaW4=').decode())"Copied!
   Learn more

   Base64 is an encoding scheme that converts binary data (or arbitrary text) to a string using only 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). It is used for data transmission contexts that require text-safe encoding, such as HTTP Basic Auth headers, data URIs, and email attachments. Critically, it is not encryption -- it is trivially reversible by anyone, as this step demonstrates.

   btoa() is a browser JavaScript function (Base64 encode) and atob() is its inverse (Base64 decode). The names derive from the historical Unix programs btoa (binary to ASCII) and atob (ASCII to binary). Encoding a password or username in base64 and comparing it provides zero security -- it is security theater that only stops someone who has never heard of base64.

   The = or == at the end of a base64 string is padding: base64 encodes 3 bytes into 4 characters, so strings whose length is not a multiple of 3 are padded to reach the next boundary. Recognizing this padding is one of the simplest ways to identify base64-encoded data in the wild.

3. Step 3Decode the password / flag
   The password is compared against a base64 string. Decoding it in the browser console reveals the flag directly -- the password itself is the flag.
   # In browser console: atob('cGljb0NURns1M3J2M3JfNTNydjNyXzUzcnYzcl81M3J2M3JfNTNydjNyfQ==')Copied!
   Learn more

   The browser console is itself a full JavaScript REPL (Read-Eval-Print Loop) running in the page's security context. Calling atob() there is equivalent to calling it in the application code -- you get the same decoded string the application would compare against. This makes the console the fastest way to evaluate JavaScript expressions you find in the page source without writing a separate script.

   The password being the flag itself is a common CTF shortcut that avoids the need to log in at all -- once you decode the password, you have the flag regardless of whether the login form actually works. In real-world penetration testing, hardcoded credentials found in client-side JavaScript are a critical finding even when they are obfuscated beyond simple base64, because automated tools and reverse engineering can always extract them.

   This pattern -- client-side-only authentication with hardcoded or client-visible credentials -- falls under CWE-798 (Use of Hard-coded Credentials) and CWE-602 (Client-Side Enforcement of Server-Side Security). Both appear regularly in real-world web application security assessments, particularly in older or hobby-built sites.

Flag

picoCTF{...}

Client-side authentication is trivially bypassable -- all validation logic and credentials are sent to the user's browser and can be read directly from the JavaScript source.