Source code, documentation and tests are available on GitHub.
01 / CONTEXT
Project context
Passwords alone are vulnerable to credential reuse and compromise. The capstone explored how a second authentication step can strengthen login security while creating its own operational and threat-model limitations.
02 / EXECUTION
What I did
Designed local account registration with bcrypt password hashing and TOTP enrollment.
Implemented the password-verification and one-time-code flow with failed-login lockout and event logging.
Evaluated expected behavior using eight controlled manual functional and security checks.
Documented threats and limitations including TOTP phishing relay, replay handling, secret storage, CSRF and deployment hardening needs.
SYSTEM FLOW
Local authentication prototype flow
01Login requestAccount identifier and password supplied locally
Selected source-backed examples from the linked repositories. Images are published from already-sanitized source files; report excerpts remain explicitly labelled.
REPOSITORY REPORT EXCERPT
Original capstone evaluation
8/8 reported local manual checks
Source evaluation distinguishes the historical report's controlled tests from later portfolio regression tests; no current production assurance is implied.
The architecture document distinguishes a pending second factor from an authenticated session and records known phishing, replay and deployment limitations.
What a TOTP second factor adds—and what it does not
Does a password plus one-time code make a login phishing-resistant?
Method
The local Flask prototype separates password verification and TOTP verification, hashes passwords with bcrypt and records authentication outcomes.
Observed / documented
Controlled tests documented rejection of invalid codes and prevention of password-only authenticated access.
Limits of the evidence
The prototype does not establish resistance to real-time phishing relay or every replay and lockout abuse scenario; stored TOTP secrets remain sensitive.