Which Authentication Method Fits the Risk?

There is no perfect authentication method.

A fingerprint can be convenient but difficult to replace if biometric data is compromised. A hardware security key can be strong but easy to lose. A long passphrase can be memorable but still vulnerable to phishing. SMS codes add another step but depend on a phone number and mobile network.

Security design is not about picking the method with the most impressive label.

It is about matching the authentication method to the risk, user, device, environment, and recovery plan.

Compare the major options

Password or passphrase

Strengths

• inexpensive
• widely supported
• easy to deploy

Weaknesses

• can be reused
• can be guessed
• can be phished
• can be forgotten

App-based one-time code

Strengths

• adds a second factor
• does not depend on remembering another secret

Weaknesses

• still vulnerable to some phishing workflows
• depends on access to the authenticator device
• recovery must be planned

Hardware security key

Strengths

• can provide strong possession-based authentication
• useful for high-value accounts

Weaknesses

• costs money
• can be lost or damaged
• backup access has to be designed

Biometrics

Strengths

• fast and convenient
• tied to a physical characteristic

Weaknesses

• false accepts and false rejects can occur
• biometric traits are difficult to replace
• privacy and storage choices matter

SMS code

Strengths

• familiar to many users
• works without a dedicated authenticator app

Weaknesses

• depends on the phone number and cellular account
• can be affected by number-transfer or interception risks
• may be unavailable without service

The point is not to memorize a ranking. The point is to compare trade-offs.

Authentication has to survive failure

A system is not finished when the happy-path login works.

Ask what happens when:

• the phone is lost
• the security key is damaged
• the user forgets the password
• the biometric sensor fails
• the account is locked
• the recovery email is also compromised
• the user changes phone numbers

Recovery is part of authentication security.

If the recovery process is weaker than the normal login process, an attacker may target recovery instead.

Worked design case

A school robotics team needs access to a repository containing competition code.

The team has:

• 12 student contributors
• 2 adult mentors
• 3 students who need permission to merge changes
• Chromebooks and personal phones
• no need for one shared account

A reasonable design might use:

• individual accounts for every person
• unique passphrases
• MFA for all accounts
• elevated permissions only for people who need them
• backup recovery codes stored through an approved team process
• immediate removal of access when a member leaves the team

Why not one shared account?

Because shared credentials destroy accountability and make access removal harder.

Why not give everyone administrator rights?

Because authentication answers who you are. Authorization still determines what you are allowed to do after login.

Authentication versus authorization

These terms are easy to mix up.

Authentication: Who are you?

Authorization: What are you allowed to do?

A student can successfully authenticate to a school account and still be unauthorized to change administrative settings.

A security system needs both.

The Garden State Cyber design challenge

You are going to complete a Which Authentication? project.

Choose one of these fictional systems:

• school learning portal
• robotics code repository
• student Chromebook sign-in
• teacher gradebook
• school visitor-management system
• club equipment checkout system

Design an authentication plan.

Your plan must include:

1. The users

Who needs access?

Do different users need different privileges?

2. The assets

What could be exposed, altered, or made unavailable if authentication fails?

Connect this back to the CIA Triad.

3. The first factor

Choose a password/passphrase or another primary mechanism.

Explain why.

4. The second factor

Decide whether MFA is required.

If yes, choose the second factor and explain the trade-off.

If no, defend that decision.

5. The recovery process

What happens if the user loses access to the factor?

Do not make recovery weaker than the login you designed.

6. Logging and alerts

What authentication events should be recorded?

Examples:

• repeated failed attempts
• successful recovery
• new device login
• MFA reset

7. Account lifecycle

How is access created, changed, and removed?

A secure account that never gets disabled after a user leaves is still a security problem.

Threat-test your own design

Test your system against these scenarios:

Scenario A

The password is exposed in a phishing message.

What stops or limits account takeover?

Scenario B

The user's phone is lost.

How does the legitimate user recover without giving an attacker an easy bypass?

Scenario C

A former team member still knows an old password.

What prevents continued access?

Scenario D

A student signs in successfully but tries to change a setting they should not control.

Which part of the system should stop them?

Score the trade-offs

Rate your proposed design from 1 to 5 on:

• security
• usability
• recovery
• cost
• privacy
• accessibility

A design with six perfect scores is probably not being evaluated critically enough.

Choose the weakest score and explain what you would do if you had more resources.

Evidence for Lesson 3

Submit a one-page Authentication Architecture containing:

• system and users
• authentication factors
• authorization roles
• recovery path
• logging plan
• account lifecycle
• threat-test results
• trade-off scores

Finish with this statement:

The strongest authentication method is not automatically the best design because...

That is the real lesson. Security architecture is choosing controls that fit the system instead of collecting controls because they sound advanced.