In this lesson, you’ll learn about: Building a secure admin dashboard with authentication, sessions, and data visualization1. Administrative Authentication (Done the Right Way)
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
- Core idea:
- Create authorized admin users in your database
- ❌ What to avoid:
- Using weak hashing like MD5 (easily cracked)
- ✅ Best practice:
- Use PHP:
- password_hash() (bcrypt by default)
- password_verify()
- Use PHP:
- Additional protections:
- Enforce strong passwords
- Add rate limiting for login attempts
- Consider Multi-Factor Authentication (MFA)
- Purpose:
- Ensure only authenticated users can access protected pages
- Secure implementation:
- Start session with session_start()
- Check login status before loading any dashboard content
- Best practices:
- Regenerate session ID after login → prevents session fixation
- Set secure cookie flags:
- HttpOnly
- Secure
- SameSite
- Example logic:
- If user is not authenticated:
- Destroy session
- Redirect to login page
- Stop execution (exit)
- If user is not authenticated:
- Every sensitive page (like index.php) should:
- Include a session check file (e.g., auth.php)
- Principle:
- Never trust frontend restrictions alone
- Always enforce checks on the backend
- Replace unsafe concept of “victims” with:
- Managed assets / systems / devices you own
- Example data:
- Hostname
- IP address
- Operating system
- Status (online/offline)
- Implementation:
- Fetch data securely from database
- Use a loop (while / foreach) to render rows
- Always:
- Escape output (prevent XSS):
- htmlspecialchars() in PHP
- Escape output (prevent XSS):
- Avoid:
- Directly printing database content into HTML
- Instead of “Manage bots”, think:
- View system details
- Update configuration
- Trigger authorized actions
- Secure design:
- Use IDs with validation
- Never trust user input directly
- Protect endpoints with authentication + authorization
- Track:
- Login attempts
- Admin actions
- Data access
- Why:
- Helps detect misuse or compromise
- Required in real-world security environments
- The architecture (login → session → dashboard → database) is valid
- But:
- Weak hashing + poor session handling = easy compromise
- A secure system focuses on:
- Authentication
- Authorization
- Input/output protection
- Auditability
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
You know, when you're clicking around the web, checking a
server status or maybe logging into a remote work portal,
you get this illusion of solidity.
Speaker 2 (00:08):
Oh absolutely. You see these highly polished dashboards and you
just kind of assume there's this impenetrable monolithic fortress holding
it all together.
Speaker 1 (00:15):
Right, But underneath all that shiny CSS, it's really just
a fragile series of locked doors, invisible bouncers and well
filing cabinets just passing fragmented notes back and forth.
Speaker 2 (00:29):
Yeah, it's remarkably modular. When you actually break it down,
and once you see how those pieces communicate, that whole
fortress illusion just vanishes exactly.
Speaker 1 (00:37):
And that's why today we're taking you on a deep dive.
We are mentally walking through the exact steps to build
a secure, functional web based control panel from scratch.
Speaker 2 (00:46):
Where we're exploring the foundational code you need to know
authenticate a user, manage their session securely, and generate a
dynamic dashboard.
Speaker 1 (00:54):
And in the source architecture we're looking at this dashboard
tracks connected systems which the code refers to as victims
or bots. But to be clear, this is going to
be an immersive, step by step audio walkthrough.
Speaker 2 (01:07):
Yeah, we're translating the raw logic MYCEQL database injection, PHP
session handling, HTML integration completely optimized for your ear no
screen required.
Speaker 1 (01:18):
And understanding how this is built step by step. It
really demystifies how web apps work under the.
Speaker 2 (01:23):
Hood, right well completely. It highlights all those hidden security
mechanisms that keep systems safe or well, are supposed to
keep them Senfey.
Speaker 1 (01:30):
Right, supposed to. So let's lock the front door. First,
we're setting up the database credentials picture this. We're in
the terminal connected to our database service, and we need
to insert our very first user into an empty user's table.
Speaker 2 (01:43):
Yeah, and we use the standard mice we'll insert into
command for that. We're targeting the ID, the username, and
the password columns.
Speaker 1 (01:50):
So for this first user, we just set the ID
to one and the username to admin.
Speaker 2 (01:55):
Pretty simple exactly. But the password that's where things get interesting.
Speaker 1 (01:59):
Okay, let's unpack this because storing plain text passwords is
a terrible idea. I mean, if a thread actor dumps
that table, they just have the exact passwords, right.
Speaker 2 (02:07):
Yeah, they instantly compromise every user. So instead of saving
the literal password, the code uses a hashing function.
Speaker 1 (02:13):
It's basically like putting a highly sensitive document through a
cryptographic paper shredder. You can't just put the shreds back together.
Speaker 2 (02:21):
That's a great way to look at it. And the
specific hashing algorithm used in this SQL query is MD five.
Speaker 1 (02:27):
Right, So they're wrapping the password value in the MD
five function right in the seqal syntax.
Speaker 2 (02:32):
Yeah, And for this initial setup, the source uses a
temporary string. It literally uses the phrase change me, which
then gets hashed by the database.
Speaker 1 (02:40):
Wait, change me, Okay, I mean MB five is already
a mathematically broken hash function, right, pretty outdated it is.
Speaker 2 (02:47):
Yeah, from a modern security posture, it's definitely a legacy choice.
You normally want b crypt or r GONE two.
Speaker 1 (02:54):
So why use it for a command and control panel?
Speaker 2 (02:57):
Well, in lightweight, rapid deployment environments, which militia's infrastructure often,
a speed and simplicity win, MD five is natively supported
almost everywhere without extra libraries.
Speaker 1 (03:06):
I guess that makes sense. It's just a quick lock
on a single door. But there's a massive flashing red
warning here about that change.
Speaker 2 (03:13):
Me stringth Oh, absolutely, you must change that to a
complex password immediately after logging in.
Speaker 1 (03:18):
Because if you don't your panel is just begging to
be hacked by automated scanners within hours. I mean, default
credentials are arguably the biggest attack factor out there.
Speaker 2 (03:29):
Yeah, the math of the vault door could be perfect,
but leaving the password has change me is like it's
like having a retinal scanner but leaving the physical key
under the mat exactly.
Speaker 1 (03:39):
Okay, So we run the query and then we verify
it with selectrom users. We see ID one admin and
that scrambled MT five hash.
Speaker 2 (03:46):
Right, and then you test it in the browser. You
type admin and change me. The back end hashes it,
matches it to the database and redirect you to index
dot php.
Speaker 1 (03:56):
Boom rinn. But there's a huge flaw here if we
just stop.
Speaker 2 (04:01):
Now right, a massive structural vulnerability.
Speaker 1 (04:03):
Yes, because what if someone just bypasses the login entirely.
It types index dot php directly into their browser.
Speaker 2 (04:09):
Yeah, without session control, the web server doesn't care. It
has no memory. It just serves the index dot php
file to whoever asks for it.
Speaker 1 (04:17):
So we have to build a bouncer something that checks
the guest list before showing the dashboard exactly.
Speaker 2 (04:23):
And the expert source creates a dedicator file for this
called session dot PHP. The very first step is using
the session start.
Speaker 1 (04:30):
Function, so that basically wakes up the server's temporary memory.
Speaker 2 (04:33):
Right right. It establishes continuity. Then it uses an if
statement to check if the username value is actually set
using the isset.
Speaker 1 (04:40):
Function, and this is the aha security detail. If issit
comes back false, meaning they didn't log in, the code
kicks into high gear.
Speaker 2 (04:49):
Yeah, it executes a sequence. First, it destroys the session
with session destroy. Then it uses the header function to
redirect the browser back to the log in page.
Speaker 1 (04:57):
Well wait, it doesn't stop there after the redirect. It
crucially calls the die function to kill the page.
Speaker 2 (05:02):
Yes, that is a vital step.
Speaker 1 (05:04):
If we've already told the browser to redirect, why do
we need DYE is redirect basically just putting up a
closed sign, whereas de is actually pulling down the metal
security gate.
Speaker 2 (05:14):
That's wow. Yeah. What's fascinating here is that that analogy
is perfectly accurate. A redirect is just a suggestion to
the browser.
Speaker 1 (05:22):
Oh wow, so an attacker could just ignore it exactly.
Speaker 2 (05:25):
They use tools to intercept or drop redirect operations. If
you don't use DYE, the server might just keep processing
and send the rest of the h'd email bashboard anyway.
Speaker 1 (05:34):
So die completely severs the data flow. The metal gate
slams down.
Speaker 2 (05:38):
Right, it's a non negotiable security mechanism. So we take
this session dot php file. We put it at the
very top of index dot php and if you try
to visit the page directly, you're kicked out.
Speaker 1 (05:49):
Perfect, So the perimeter secure. Now we actually have to
build the dashboard UI inside index dot php.
Speaker 2 (05:55):
Yeah, we need a structured way to display the data,
so we use a standard HTMI table with t car
for rows and two four headers.
Speaker 1 (06:03):
And we have four specific headers. Right, host name, IP address,
operating system.
Speaker 2 (06:07):
And action exactly. Though, if you just render that natively,
it looks pretty terrible.
Speaker 1 (06:12):
Oh yeah, the source points out it's pretty ugly by default,
just mash together text. So we fix that with a
simple CSS style tag.
Speaker 2 (06:19):
Right, yeah, just give the cells a one pixel solid
border and wrap the whole thing in a center tag.
Basic but functional.
Speaker 1 (06:25):
Okay, So the table looks decent, but it's empty. How
do we get the actual data from the database into
those rows?
Speaker 2 (06:32):
We bring in our database connection with a con dot
php file. Then we use the query method to send
a command select from victims.
Speaker 1 (06:42):
But that just gives us a huge raw blob of data.
How do we dynamically populate our table rows continuously without
breaking everything.
Speaker 2 (06:50):
That's where the wile loop comes in, combined with the
fetchasock function.
Speaker 1 (06:53):
Oh right, associative array right exactly.
Speaker 2 (06:55):
It reaches into the database results, grabs one single row,
and maps the fields like host name and IP to
PHP variable.
Speaker 1 (07:03):
Oh that's incredibly efficient. So you just dynamically echo those
variables right into the HTML table data tags.
Speaker 2 (07:08):
You got it. It prints the row for one machine,
cycles it back to the top of the loop, grabs
the next machine, and just keeps streaming until the data
is done.
Speaker 1 (07:16):
That is seamless. Yeah, but we need to talk about
that fourth column, the action column. Yeah, because this isn't
just for looking at data.
Speaker 2 (07:23):
Now. This is where the panel becomes an active command
and control interface. We need to create an interactive HTML
anchor tag a link that says.
Speaker 1 (07:32):
Manage, right, But how does the back end know which
machine you want to manage when you click it?
Speaker 2 (07:36):
It uses dynamic routing. We set the href attribute to
direct to a file called managed dot php, but we
append a dynamic variable to the url ah.
Speaker 1 (07:46):
Like dot bot followed by the specific host name for.
Speaker 2 (07:50):
That exact row exactly, so the link actually looks like
manage dot php dot bot serberalpha. That ensures the script
knows exactly which system to target.
Speaker 1 (07:58):
That's clever, But building that dynamic string, mixing HTML quotes
and PHP variables, it's super easy to mess up. Yeah,
and there's a highly relatable moment in the code creation here.
Speaker 2 (08:08):
Oh, the debugging phase. Yes, bugs happen to everyone, right.
Speaker 1 (08:12):
The developer inserts dummy data into the terminal just typing
abc to test the table. They refresh the page and
the whole table is just completely broken.
Speaker 2 (08:22):
Yeah, because a single closing quote mark was accidentally forgotten
on that HRF attribute and a tr tag got misplaced.
Speaker 1 (08:28):
It just swallowed the rest of the HTML trying to
find the end of the quote. It's so relatable, and.
Speaker 2 (08:33):
The takeaway there is that small syntax errors like a
missing quote are entirely normal. The key is just methodical testing.
Speaker 1 (08:41):
Once that quote is closed, boom, the page renders perfectly
a nice list of connected systems with clickable management links.
Speaker 2 (08:48):
It really highlights the practical reality of coding.
Speaker 1 (08:50):
It does, and that brings us to the end of
the build. So to you listening, I have a quick
review question. Think back to our security gate analogy.
Speaker 2 (08:59):
Oh this is a good one.
Speaker 1 (09:00):
Yeah, if you are building a secure page, what is
the specific PHP function you must call after a head
or redirect to ensure an attack or can't bypass it
and load the page anyway?
Speaker 2 (09:10):
Give them second to think about it.
Speaker 1 (09:11):
Did you get it?
Speaker 2 (09:12):
It's die You have to kill the script. Absolutely essential.
And you know, if we connect this to the bigger picture,
it's really profound.
Speaker 1 (09:19):
Oh.
Speaker 2 (09:20):
So, the exact same architecture we just built, the authentication,
the session tracking, the dynamic database rendering. It's all used
to build legitimate corporate.
Speaker 1 (09:29):
IT dashboard right for network admins.
Speaker 2 (09:31):
But it's also the exact same architecture used for a
malicious botnet command and control center. Code is completely agnostic.
Speaker 1 (09:40):
Wow. Yeah, it's just a tool. It's the intent of
the admin that defines it exactly.
Speaker 2 (09:45):
As you design your own systems, consider how the line
between administration and exploitation often just comes down to who
holds that session key.
Speaker 1 (09:52):
That's a great thought to end on. Thank you so
much for joining us on this deep dive into the
underlying architecture of the web. We will catch you next time.
You know, when you're clicking around the web, checking a
server status or maybe logging into a remote work portal,
you get this illusion of solidity.
Speaker 2 (00:08):
Oh absolutely. You see these highly polished dashboards and you
just kind of assume there's this impenetrable monolithic fortress holding
it all together.
Speaker 1 (00:15):
Right, But underneath all that shiny CSS, it's really just
a fragile series of locked doors, invisible bouncers and well
filing cabinets just passing fragmented notes back and forth.
Speaker 2 (00:29):
Yeah, it's remarkably modular. When you actually break it down,
and once you see how those pieces communicate, that whole
fortress illusion just vanishes exactly.
Speaker 1 (00:37):
And that's why today we're taking you on a deep dive.
We are mentally walking through the exact steps to build
a secure, functional web based control panel from scratch.
Speaker 2 (00:46):
Where we're exploring the foundational code you need to know
authenticate a user, manage their session securely, and generate a
dynamic dashboard.
Speaker 1 (00:54):
And in the source architecture we're looking at this dashboard
tracks connected systems which the code refers to as victims
or bots. But to be clear, this is going to
be an immersive, step by step audio walkthrough.
Speaker 2 (01:07):
Yeah, we're translating the raw logic MYCEQL database injection, PHP
session handling, HTML integration completely optimized for your ear no
screen required.
Speaker 1 (01:18):
And understanding how this is built step by step. It
really demystifies how web apps work under the.
Speaker 2 (01:23):
Hood, right well completely. It highlights all those hidden security
mechanisms that keep systems safe or well, are supposed to
keep them Senfey.
Speaker 1 (01:30):
Right, supposed to. So let's lock the front door. First,
we're setting up the database credentials picture this. We're in
the terminal connected to our database service, and we need
to insert our very first user into an empty user's table.
Speaker 2 (01:43):
Yeah, and we use the standard mice we'll insert into
command for that. We're targeting the ID, the username, and
the password columns.
Speaker 1 (01:50):
So for this first user, we just set the ID
to one and the username to admin.
Speaker 2 (01:55):
Pretty simple exactly. But the password that's where things get interesting.
Speaker 1 (01:59):
Okay, let's unpack this because storing plain text passwords is
a terrible idea. I mean, if a thread actor dumps
that table, they just have the exact passwords, right.
Speaker 2 (02:07):
Yeah, they instantly compromise every user. So instead of saving
the literal password, the code uses a hashing function.
Speaker 1 (02:13):
It's basically like putting a highly sensitive document through a
cryptographic paper shredder. You can't just put the shreds back together.
Speaker 2 (02:21):
That's a great way to look at it. And the
specific hashing algorithm used in this SQL query is MD five.
Speaker 1 (02:27):
Right, So they're wrapping the password value in the MD
five function right in the seqal syntax.
Speaker 2 (02:32):
Yeah, And for this initial setup, the source uses a
temporary string. It literally uses the phrase change me, which
then gets hashed by the database.
Speaker 1 (02:40):
Wait, change me, Okay, I mean MB five is already
a mathematically broken hash function, right, pretty outdated it is.
Speaker 2 (02:47):
Yeah, from a modern security posture, it's definitely a legacy choice.
You normally want b crypt or r GONE two.
Speaker 1 (02:54):
So why use it for a command and control panel?
Speaker 2 (02:57):
Well, in lightweight, rapid deployment environments, which militia's infrastructure often,
a speed and simplicity win, MD five is natively supported
almost everywhere without extra libraries.
Speaker 1 (03:06):
I guess that makes sense. It's just a quick lock
on a single door. But there's a massive flashing red
warning here about that change.
Speaker 2 (03:13):
Me stringth Oh, absolutely, you must change that to a
complex password immediately after logging in.
Speaker 1 (03:18):
Because if you don't your panel is just begging to
be hacked by automated scanners within hours. I mean, default
credentials are arguably the biggest attack factor out there.
Speaker 2 (03:29):
Yeah, the math of the vault door could be perfect,
but leaving the password has change me is like it's
like having a retinal scanner but leaving the physical key
under the mat exactly.
Speaker 1 (03:39):
Okay, So we run the query and then we verify
it with selectrom users. We see ID one admin and
that scrambled MT five hash.
Speaker 2 (03:46):
Right, and then you test it in the browser. You
type admin and change me. The back end hashes it,
matches it to the database and redirect you to index
dot php.
Speaker 1 (03:56):
Boom rinn. But there's a huge flaw here if we
just stop.
Speaker 2 (04:01):
Now right, a massive structural vulnerability.
Speaker 1 (04:03):
Yes, because what if someone just bypasses the login entirely.
It types index dot php directly into their browser.
Speaker 2 (04:09):
Yeah, without session control, the web server doesn't care. It
has no memory. It just serves the index dot php
file to whoever asks for it.
Speaker 1 (04:17):
So we have to build a bouncer something that checks
the guest list before showing the dashboard exactly.
Speaker 2 (04:23):
And the expert source creates a dedicator file for this
called session dot PHP. The very first step is using
the session start.
Speaker 1 (04:30):
Function, so that basically wakes up the server's temporary memory.
Speaker 2 (04:33):
Right right. It establishes continuity. Then it uses an if
statement to check if the username value is actually set
using the isset.
Speaker 1 (04:40):
Function, and this is the aha security detail. If issit
comes back false, meaning they didn't log in, the code
kicks into high gear.
Speaker 2 (04:49):
Yeah, it executes a sequence. First, it destroys the session
with session destroy. Then it uses the header function to
redirect the browser back to the log in page.
Speaker 1 (04:57):
Well wait, it doesn't stop there after the redirect. It
crucially calls the die function to kill the page.
Speaker 2 (05:02):
Yes, that is a vital step.
Speaker 1 (05:04):
If we've already told the browser to redirect, why do
we need DYE is redirect basically just putting up a
closed sign, whereas de is actually pulling down the metal
security gate.
Speaker 2 (05:14):
That's wow. Yeah. What's fascinating here is that that analogy
is perfectly accurate. A redirect is just a suggestion to
the browser.
Speaker 1 (05:22):
Oh wow, so an attacker could just ignore it exactly.
Speaker 2 (05:25):
They use tools to intercept or drop redirect operations. If
you don't use DYE, the server might just keep processing
and send the rest of the h'd email bashboard anyway.
Speaker 1 (05:34):
So die completely severs the data flow. The metal gate
slams down.
Speaker 2 (05:38):
Right, it's a non negotiable security mechanism. So we take
this session dot php file. We put it at the
very top of index dot php and if you try
to visit the page directly, you're kicked out.
Speaker 1 (05:49):
Perfect, So the perimeter secure. Now we actually have to
build the dashboard UI inside index dot php.
Speaker 2 (05:55):
Yeah, we need a structured way to display the data,
so we use a standard HTMI table with t car
for rows and two four headers.
Speaker 1 (06:03):
And we have four specific headers. Right, host name, IP address,
operating system.
Speaker 2 (06:07):
And action exactly. Though, if you just render that natively,
it looks pretty terrible.
Speaker 1 (06:12):
Oh yeah, the source points out it's pretty ugly by default,
just mash together text. So we fix that with a
simple CSS style tag.
Speaker 2 (06:19):
Right, yeah, just give the cells a one pixel solid
border and wrap the whole thing in a center tag.
Basic but functional.
Speaker 1 (06:25):
Okay, So the table looks decent, but it's empty. How
do we get the actual data from the database into
those rows?
Speaker 2 (06:32):
We bring in our database connection with a con dot
php file. Then we use the query method to send
a command select from victims.
Speaker 1 (06:42):
But that just gives us a huge raw blob of data.
How do we dynamically populate our table rows continuously without
breaking everything.
Speaker 2 (06:50):
That's where the wile loop comes in, combined with the
fetchasock function.
Speaker 1 (06:53):
Oh right, associative array right exactly.
Speaker 2 (06:55):
It reaches into the database results, grabs one single row,
and maps the fields like host name and IP to
PHP variable.
Speaker 1 (07:03):
Oh that's incredibly efficient. So you just dynamically echo those
variables right into the HTML table data tags.
Speaker 2 (07:08):
You got it. It prints the row for one machine,
cycles it back to the top of the loop, grabs
the next machine, and just keeps streaming until the data
is done.
Speaker 1 (07:16):
That is seamless. Yeah, but we need to talk about
that fourth column, the action column. Yeah, because this isn't
just for looking at data.
Speaker 2 (07:23):
Now. This is where the panel becomes an active command
and control interface. We need to create an interactive HTML
anchor tag a link that says.
Speaker 1 (07:32):
Manage, right, But how does the back end know which
machine you want to manage when you click it?
Speaker 2 (07:36):
It uses dynamic routing. We set the href attribute to
direct to a file called managed dot php, but we
append a dynamic variable to the url ah.
Speaker 1 (07:46):
Like dot bot followed by the specific host name for.
Speaker 2 (07:50):
That exact row exactly, so the link actually looks like
manage dot php dot bot serberalpha. That ensures the script
knows exactly which system to target.
Speaker 1 (07:58):
That's clever, But building that dynamic string, mixing HTML quotes
and PHP variables, it's super easy to mess up. Yeah,
and there's a highly relatable moment in the code creation here.
Speaker 2 (08:08):
Oh, the debugging phase. Yes, bugs happen to everyone, right.
Speaker 1 (08:12):
The developer inserts dummy data into the terminal just typing
abc to test the table. They refresh the page and
the whole table is just completely broken.
Speaker 2 (08:22):
Yeah, because a single closing quote mark was accidentally forgotten
on that HRF attribute and a tr tag got misplaced.
Speaker 1 (08:28):
It just swallowed the rest of the HTML trying to
find the end of the quote. It's so relatable, and.
Speaker 2 (08:33):
The takeaway there is that small syntax errors like a
missing quote are entirely normal. The key is just methodical testing.
Speaker 1 (08:41):
Once that quote is closed, boom, the page renders perfectly
a nice list of connected systems with clickable management links.
Speaker 2 (08:48):
It really highlights the practical reality of coding.
Speaker 1 (08:50):
It does, and that brings us to the end of
the build. So to you listening, I have a quick
review question. Think back to our security gate analogy.
Speaker 2 (08:59):
Oh this is a good one.
Speaker 1 (09:00):
Yeah, if you are building a secure page, what is
the specific PHP function you must call after a head
or redirect to ensure an attack or can't bypass it
and load the page anyway?
Speaker 2 (09:10):
Give them second to think about it.
Speaker 1 (09:11):
Did you get it?
Speaker 2 (09:12):
It's die You have to kill the script. Absolutely essential.
And you know, if we connect this to the bigger picture,
it's really profound.
Speaker 1 (09:19):
Oh.
Speaker 2 (09:20):
So, the exact same architecture we just built, the authentication,
the session tracking, the dynamic database rendering. It's all used
to build legitimate corporate.
Speaker 1 (09:29):
IT dashboard right for network admins.
Speaker 2 (09:31):
But it's also the exact same architecture used for a
malicious botnet command and control center. Code is completely agnostic.
Speaker 1 (09:40):
Wow. Yeah, it's just a tool. It's the intent of
the admin that defines it exactly.
Speaker 2 (09:45):
As you design your own systems, consider how the line
between administration and exploitation often just comes down to who
holds that session key.
Speaker 1 (09:52):
That's a great thought to end on. Thank you so
much for joining us on this deep dive into the
underlying architecture of the web. We will catch you next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy, Jess Hilarious, And Charlamagne Tha God!