Password-reset and verification emails sent unencrypted in production

Nobody has started this yet — be first.

Business impact

Every password-reset token and email-verification token this service issues is single-use but still a live credential for up to 24 hours or 30 minutes. Sending them over an unencrypted SMTP connection means anyone positioned on the network path between this app and the mail server can read them in plaintext and take over the account before the legitimate user even opens their inbox. This is also the kind of finding that fails a SOC 2 / PCI audit outright and can block enterprise deals.

Problem

SMTPEmailSender.send() has an inverted TLS condition: if not self.use_tls: smtp.starttls() attempts STARTTLS only when TLS was explicitly turned off, and skips it whenever TLS is on -- the exact opposite of every deployment's intent, including the documented default of SMTP_USE_TLS=true.

Current behavior

Constructing SMTPEmailSender(..., use_tls=True) and calling .send() never calls smtp.starttls(), so the email goes out over an unencrypted connection.

Expected behavior

SMTPEmailSender.send() calls smtp.starttls() when use_tls=True, and does not call it when use_tls=False.

Steps to reproduce

Construct SMTPEmailSender(host, port, user, pass, from_addr, use_tls=True).
Call sender.send(to, subject, body) with smtplib.SMTP mocked.
Observe: instance.starttls.called is False -- should be True.

Why this matters

An inverted boolean condition is one of the easiest single-token mistakes to introduce and one of the easiest to miss in review, because both branches of the if are individually reasonable-looking code -- the bug is only visible when you check the condition against the variable's name and documented meaning, not just its syntax.

Suggested approach

Read the condition against what use_tls is supposed to mean (its name is not "skip_tls"), and check it against MailerExtension.init_app()'s comment about the documented SMTP_USE_TLS default.

Acceptance criteria

use_tls=True results in smtp.starttls() being called
use_tls=False results in smtp.starttls() NOT being called

Verification

pytest practice_tickets/tests/test_ticket_06.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/smtp-tls-inverted

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/smtp-tls-inverted

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Production-Style Flask Auth Service

A from-scratch Flask authentication service: JWT access + refresh tokens with rotation and reuse detection, real session/device revocation, password reset, email verification, and TOTP 2FA with backup codes.

Fork on GitHub

Download

Setup

Production-Style Flask Auth Service

git clone <your-fork>
cd FlaskDevTraining/flask_auth_service
cp .env.example .env
make docker-up   # docker compose up --build: Postgres + Redis + Flask dev server

Migrations run automatically on container start. The app is reachable at . Seed two demo users (one plain, one with 2FA already enabled) with -- it prints the 2FA user's TOTP secret, provisioning URI, and a one-liner to compute a current code with , so the 2FA flow is fully testable without an authenticator app. A production-style path with gunicorn (no dev server, no bind mount) is available via .