Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Ethical hacking · Question Set
Passwords & Auth Attacks interview questions for placements and exams.
Questions
15
Included in this set
Subject
Ethical hacking
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for Ethical hacking.
Credential stuffing is about replaying real pairs from past leaks. Brute force is about trying many guesses that the victim never used elsewhere. Defenses differ. For stuffing, use breach checks, rate limits, and multi factor. For brute force, use password policies and throttling.
Defend: MFA + rate limit + breached-password check
For complete preparation, combine this set with full subject-wise practice for Ethical hacking. You can also explore other subjects and sets from the links below.
Argon two i d is designed to be slow and memory hard. That means attacks on GPUs and ASICs are more expensive. Bcrypt and scrypt are also strong. MD five, SHA one, and NT L M are fast and weak for password storage.
Argon2id params: memory=64–256 MB; iterations=2–4; parallelism>=1
A per user salt makes identical passwords hash to different values. That kills precomputed tables and cross user comparisons. It does not replace a slow hash. You still need bcrypt, scrypt, or Argon two i d.
store: user, salt, argon2id_hash(salt + password)
A pepper is a server side secret. Even if the database is dumped, the attacker cannot verify guesses without the pepper. Keep the pepper in a key manager, not next to the hashes.
hash = argon2id(salt || password || PEPPER_SECRET)
F I D O two uses origin bound cryptography. The key checks the real site and signs a challenge. Proxy pages cannot replay it easily. T O T P and SMS can be fooled by real time phishing.
Policy: prefer platform authenticator or roaming key; fall back to TOTP only if needed
Hard lockouts create easy denial of service. Progressive delays, captchas after risk checks, and alerts make attacks slower while keeping real users able to sign in.
Backoff: 1s, 2s, 4s…; captcha after risk score; notify user on spikes
First, verify scope, storage rules, and the allowed time budget. Identify the hash type. Then start with a strong wordlist and a few proven rules. Move to masks for company patterns, like season plus year. Keep logs of every attempt. Stop when you reach the agreed limit. Report cracked samples with redaction and immediately rotate or reset them with the owner. The goal is to measure risk, not to collect secrets.
hashcat -m 1000 hashes.txt rockyou.txt -r rules/best64.rule hashcat -m 3200 hashes.txt ?l?l?l?l?l?d?d
Prefer length over weird complexity. Allow passphrases. Block known breached passwords with a deny list. Require unique passwords per system. Encourage a password manager. Pair with strong multi factor. Remove forced frequent resets; do resets only after risk events. Give clear feedback at signup and show the user if the choice is in a breach corpus.
Rules: min 12 chars; no frequent expiry; breach check; allow spaces; manager recommended; MFA required
Look for many usernames failing once or twice from the same source or network. Look for a single username failing many times from many sources. Track user agent reuse. Watch for spikes in failures around shift changes or campaigns. Correlate with registration and password reset flows. Add a simple rule that flags the same password guess across many accounts.
Detect: group by src_ip, username, hour; alert on wide but shallow failure pattern
Revoke all old sessions and tokens. Rotate refresh tokens. Invalidate magic links. Ask the user to sign in again on all devices. Notify the user by email or push so they can spot abuse. Log the event with a trace id so support can help quickly.
onPasswordChange: revokeAllSessions(userId); rotateTokens(userId); sendSecurityNotice(userId)
If the client trusts any token that decodes, an attacker can use a token from a different app or a different identity provider. Always check issuer, audience, expiration, and the nonce for implicit and hybrid flows.
verify(id_token, { issuer, audience, nonce, exp })The idea is simple. Ask for a ticket for a service principal name. You get a blob that is crackable offline. If the service account has a weak password, the hash falls. Defend with strong, random service account passwords and managed service accounts.
Ethical test: request TGS for SPN; crack offline with limited, approved rules
Spraying spreads attempts over many accounts. This dodges lockouts and alert thresholds. Good defenses are multi factor, unique password rules, alerts on many distinct users failing once, and smart lockout with delay.
Detect: many users fail once with the same user agent or source
In relay, the attacker sits in the middle and forwards the handshake to a target. In pass the hash, the attacker uses the NT L M hash as if it were the password. SMB signing, LDAP signing, and Kerberos only help reduce both risks.
Mitigate: enforce SMB signing; restrict delegation; use Kerberos where possible
Start by enforcing multi factor everywhere. Add number matching or device binding to cut push fatigue. Next, introduce WebAuthn for admins and high risk roles. Roll out platform authenticators on managed devices. Finally, default everyone to FIDO keys with passkeys as a friendly option. Keep backup codes safe and train users on lost device recovery. Measure success by drop in successful phishing and by user satisfaction.
Phase 1: MFA everywhere Phase 2: push number matching Phase 3: WebAuthn for admins Phase 4: org wide passkeys