Ravindra BagaleCourses & study guides मराठी Track your progress

22. Password Attacks

22.6 Defending Against Password Attacks

By Last updated:

Quick answer: the short, self-contained version of this lesson is the guide How to Enable MFA on Google, Microsoft and AWS.

Attack samajla ki defence sopa hoto. He sagle tumhi tumchya reels app aani servers var lavu shakta:

Defence What it stops How (from earlier chapters)
Slow, salted hashing (bcrypt/Argon2) Offline cracking password_hash() in PHP; never md5/sha1
Strong password policy Weak, guessable passwords Length over complexity; check against leaked lists
Account lockout / rate limiting Online guessing (Hydra) Lock after N failures; fail2ban for SSH
Multi-factor authentication (MFA) Stolen or cracked passwords OTP/app on logins; AWS MFA (Chapter 25)
Key-only SSH SSH password attacks Disable PasswordAuthentication (Chapter 4, hardening in 28)
No password reuse + a manager One leak breaking many accounts User awareness

fail2ban watches log files and bans an IP after too many failed logins:

sudo yum install epel-release -y && sudo yum install fail2ban -y   # Amazon Linux
sudo service fail2ban start
sudo fail2ban-client status sshd     # see banned IPs

Why this matters for security

Most real breaches do not use a clever exploit – they use a weak, reused or leaked password. Strong hashing, MFA and lockouts stop the large majority of attacks in this chapter at almost no cost.

Ravindra Bagale's Tip

"A password must have a capital, a number and a symbol" is old advice – people end up creating guessable passwords like Pass@123. Today's good advice: a long passphrase + MFA. GhodaChaChahaPeto2024 is much safer than P@ss1. Make sure to tell students this.

Lab

Install fail2ban on your lab server, run Hydra against its SSH from Kali, and confirm your Kali IP gets banned (sudo fail2ban-client status sshd). Then enable MFA on your AWS account and describe how it would stop a cracked console password.

Real incident: DTU (Technical University of Denmark) – stolen logins used to download IAM data (Oct 2026)

1. What happened On Friday 2 October 2026, the Technical University of Denmark (DTU) disclosed a serious personal-data breach in DTUBasen, its identity and access management (IAM) system. DTU said unauthorised people compromised DTU user profiles (stolen logins) and used them to get into DTUBasen, then downloaded a large amount of data going back to 2003. DTU said it cannot yet determine exactly what was downloaded or how many people are affected; DTUBasen holds data on about 40,000 active and 160,000 former users, so up to 200,000 people may be affected. For current users the data can include Danish civil registration (CPR) numbers, full names, home addresses, profile pictures, work email, job titles, office locations, and next-of-kin names and phone numbers. DTU reported the case to the Danish Data Protection Agency (Datatilsynet), handed it to the authorities, and is investigating with outside specialists. DTU has not said publicly how the profiles were compromised. Educational framing only.

2. How the hack happened (public reporting only – high-level)

  1. Attackers got hold of working DTU account logins (DTU has not said how – phishing, reused passwords, or something else is not confirmed).
  2. They logged in as real users, so to the system it looked like normal sign-ins, not a break-in.
  3. Those accounts could reach DTUBasen, the system that stores user records for staff, students, guests and partners since 2003.
  4. They downloaded a large amount of data from it before the activity was found.
  5. DTU warned that the stolen CPR numbers and personal details can be used for identity fraud and for more convincing phishing emails, SMS and phone calls.

3. How to stop it / defend (this chapter: password attacks)

  • MFA on every login to admin and IAM systems, ideally phishing-resistant (security key / passkey) — a stolen password alone should not be enough.
  • No password reuse: check passwords against leaked-password lists and push users to a password manager (a leak on another site should not open DTU-style accounts).
  • Rate limiting and lockout on login pages to slow password guessing and credential stuffing (same idea as fail2ban above).
  • Least privilege: a normal student or staff account should not be able to pull bulk records out of the identity system.
  • Alert on unusual activity: a new location or device, logins at odd hours, or one account downloading far more data than usual.

4. How to take care so it won't happen again (checklist)

  • [ ] MFA turned on for 100% of accounts that can reach identity or HR data; no "MFA later" exceptions.
  • [ ] Reset passwords and sign-in sessions for every account involved; tell users to change any other service where they reused the same password.
  • [ ] Review who can read or export from the IAM system; remove access that is not needed.
  • [ ] Data minimisation: delete old records you no longer need (DTU already deletes some former-user details after six months — apply the same habit to everything).
  • [ ] Warn users: be careful with unexpected emails, SMS and calls that "know" about you; never share passwords; never approve a login request you did not start.
  • [ ] India students: the same lesson applies to college and company portals that store Aadhaar or PAN details — report incidents to CERT-In within the required time (see Ch.34).

Source: DTU official notice "Hackerangreb mod DTU: Underretning om brud på persondatasikkerheden", 2 October 2026 (also published by DKCERT, 2 October 2026); BleepingComputer, Ionut Ilascu, "Danish university DTU breach exposes data of up to 200,000 people", 3 October 2026.

Check if you're safe: Password Strength Checker

Real incident: mSecure – an encrypted password vault database was stolen from mSecure Cloud (Nov 2026)

1. What happened

In this lesson you learnt how to defend against password attacks: use a long unique master password, turn on MFA where you can, and rotate after a leak. This real case is a password manager itself. Encryption protects the vault, but a stolen encrypted copy can still be attacked offline if the master password is weak.

  • mSecure is a password manager made by mSeven Software. People store passwords, passkeys, and other secrets in encrypted vaults that can sync across devices.
  • Around 3 November 2026, mSeven emailed current and former customers about suspicious activity linked to the mSecure app. It asked them to protect stored secrets: change passwords, reset or re-enrol two-factor (2FA), and remove existing passkeys.
  • On 4 November 2026, BleepingComputer (Lawrence Abrams) reported the notice and follow-up replies that customers shared from mSeven support.
  • Those follow-ups say an unauthorized actor acquired an encrypted copy of a database of current and former users. The company says the issue only affects people who were syncing with mSecure Cloud.
  • mSeven says it has no evidence the attacker accessed the confidential contents inside the encrypted database, and that it has no evidence the app is currently unsafe to use. It says it added extra security measures.
  • mSeven's docs claim AES-256 encryption and a zero-knowledge design (data encrypted on the device before it goes to the cloud). The company has been sparse on how the breach happened.
  • BleepingComputer notes the parallel with the 2022 LastPass breach: stolen encrypted vaults can still be cracked offline later if the master password is weak.

2. How the hack happened (public reporting only – high-level)

  1. Someone got unauthorized access that let them take a copy of a cloud-side database used for mSecure Cloud sync.
  2. That copy was still encrypted. The company says it has no evidence the attacker opened the vault plaintext.
  3. Even so, an offline attacker can try to guess weak master passwords against the stolen encrypted file, without touching mSecure's live servers again.
  4. mSeven warned current and former users, especially those who synced to the cloud, to change the master password and rotate important stored secrets, 2FA, and passkeys.

3. How to stop it / defend (this lesson: defending against password attacks)

Why: cloud sync is convenient, but a stolen encrypted vault turns into an offline guessing race. A long random master password and unique stored passwords keep you safe even if a copy leaks.

What you can do:

  1. Change your mSecure master password now if you use (or used) mSecure Cloud sync. Make it long and random, not a short word (Example 1 and 2).
  2. Rotate vital stored passwords (email, bank, work, crypto, social). Assume a weak master could be guessed offline later.
  3. Reset or re-enrol 2FA for accounts that used authenticator codes or recovery from the vault, and replace passkeys that were stored there if the vendor asked you to.
  4. Never reuse the master password on any website. The master unlocks everything.
  5. Prefer a password manager that supports a strong, unique master + MFA, and keep the app updated.
  6. Watch for fake "reset your vault" phishing. Go to the official site or app yourself; do not trust surprise email links.

Example 1: make a long random master-password candidate on your own computer.

  1. Open a terminal on a machine you trust.
  2. Run python3 -c "import secrets; print(secrets.token_urlsafe(24))"
  3. Output: one long random string, like xK9mR2... (about 32 random characters)
  4. What it means: save that string only as your new master password inside the password manager after you change it. Do not paste it into chat or email.

Example 2: change the master password in the app, then re-sync.

  1. Open mSecure (or your password manager) on a trusted device.
  2. Follow the in-app path: # In your password manager: Settings → Security → Change master password
  3. Output: a success message like Master password updated. Re-sync devices. Old vault copies cannot use the new master.
  4. What it means: devices must sync again with the new master. Old stolen copies should not unlock with the new master.

Example 3: rotate the most important stored logins first.

  1. List email, bank, work SSO, cloud admin, and crypto exchange logins stored in the vault.
  2. Change each one on the real website (type the URL yourself), then update the vault entry.
  3. Output: each site shows "password updated" and a fresh vault entry.
  4. What it means: even if an old vault copy is cracked later, those high-value passwords are already dead.

4. How to take care so it won't happen again (checklist)

  • [ ] My password-manager master password is long, random, and unique.
  • [ ] I changed the master password after this mSecure Cloud notice (if I sync or synced to the cloud).
  • [ ] I rotated email, bank, work, and other vital passwords stored in the vault.
  • [ ] I reset 2FA / passkeys where the vendor asked, and I turned MFA on for important sites.
  • [ ] I do not reuse the master password anywhere else.
  • [ ] I ignore surprise "reset your vault" emails and open the official app myself.
  • [ ] I keep the password-manager app updated.

Source: BleepingComputer, "mSecure password manager hack prompts password reset warnings" (Lawrence Abrams), 4 November 2026; mSeven Software customer security notice (~3 November 2026); mSeven support follow-up text shared by customers on support.msecure.com (discussion topic about the cloud database).

Ravindra Bagale's Tip

If your password manager says the cloud copy was stolen, do not wait. Change the master password to a long random one, then rotate email and bank passwords stored inside. Encryption is good, but a weak master password can still be guessed offline, just like after the 2022 LastPass vault theft.

Check if you're safe: Password Strength Checker