How to Use This Site
There are two ways in, depending on how much time you have.
If you want the fastest meaningful improvement, start with multi-factor authentication and passkeys and put a passkey on your primary email today. That single change defeats the two attacks that empty accounts at scale: password reuse and real-time phishing. It takes about fifteen minutes.
If you want to understand what is happening and why the usual advice fails, read the four guides in order. Each one stands alone, but they build on each other, and together they cover the whole of a realistic account takeover.

Two support pages sit alongside the guides: the FAQ, which answers the questions readers send most often in a few sentences each, and support and corrections, which explains how to report a factual error and, just as importantly, what we cannot do for you.
If your login has already been taken over, skip to account recovery and work the steps in order. Speed and sequence matter more than understanding the theory at that point.
One thing worth doing in the next five minutes. Open your primary email account's security settings and look for the list of ways to sign in. If everything on it is a password, an SMS code or a security question, you have found the highest-value fix available to you. Add a passkey, then a second one on another device, then print the recovery codes.
What Account Takeover Looks Like From the Inside
Account takeover means somebody else can act as you inside a service: read your mail, reset passwords elsewhere, move money, message your contacts as you. It does not require them to know your password at the moment of the attack, and it rarely announces itself with a lock-out.
A careful attacker avoids anything that would alert you. Rather than changing your password, they add a recovery address or phone number of their own, register their own authenticator or passkey, create an app-specific password that survives a reset, and add a mail rule that deletes security notifications. So the audit that matters is not the password screen. It is the lists:
- Sign-in methods and registered authenticators.
- Recovery email address and recovery phone number.
- Active sessions and signed-in devices.
- Connected third-party apps and their permissions.
- App-specific passwords.
- Mail filters, forwarding rules and delegated access.
Do not count on being told. A session resumed from a stolen cookie frequently triggers no alert at all, because from the service's point of view the login was legitimate - it was, it was just not yours. The password screen is the one place you will look; the lists are the place that matters.
Why a strong password alone does not protect you
A long, complex password defeats exactly one attack: guessing or cracking. A twenty-character password that you reuse is stuffed as easily as a short one. Typed into a proxy page, it is captured in full. Sitting in your browser's password store, it is read by infostealer malware in milliseconds. Uniqueness and storage matter at least as much as strength, which is why the second guide on this site is about managers rather than about character counts.
The Five Routes That Cause Most Takeovers
Nearly every account takeover traces back to one of five mechanisms. They are worth knowing separately, because each one defeats a different defence - which is the entire argument for defence in depth.
1. Credential stuffing
Username and password pairs leaked from one breach are replayed automatically against many other services. The attacker is not targeting you; they are testing a list. It works for one reason only: reuse. Check your address at Have I Been Pwned to see whether you appear in known datasets.
2. Phishing and adversary-in-the-middle pages
Classic phishing captures what you type. Adversary-in-the-middle goes further: the page is a proxy, passing your input to the real site and relaying its responses back, so the flow you see is the genuine one. The attacker takes the password, relays your one-time code inside its validity window, and keeps the session cookie. Codes by SMS or from an authenticator app do not stop this. Passkeys and hardware security keys do, because the credential is bound to the real domain and will not produce anything for a lookalike. This is covered in detail in the phishing guide.
3. SIM swap and port-out fraud
The target here is your phone account rather than your online accounts. Carrier staff are tricked or bribed into moving your number to a SIM the attacker controls, or a port-out request is filed with another carrier. Every service that resets by SMS then works for them. Ask your carrier for a port-freeze or an account PIN, and move your important accounts off SMS. The honest limit: some banks still offer no alternative, so there the carrier lock is your only lever.
4. Information-stealing malware
Infostealers exist to harvest credentials. They arrive as cracked software, a fake browser update, a trojanised installer from a paid search result, or an attachment in a plausible work message. Then they read your browser's saved passwords, cookies and autofill data and upload the lot. Changing one password afterwards achieves very little, because everything saved in that browser has already gone.
5. Session token theft
A session token - usually a cookie - is what keeps you logged in after you authenticate. Stolen by a proxy page or an infostealer, it lets an attacker resume your session with no password and no second factor at all. This is why "change your password" is incomplete advice after a compromise, and why revoking active sessions is a separate step.
Defence in Depth, in Practical Terms
Defence in depth means arranging controls so that the failure of any one of them is survivable. Not stacking measures that all cover the same failure, but covering different failure modes - because each route above defeats a different control.
- Unique credentials remove credential stuffing outright. A leak at one service stops being usable anywhere else. See passwords and password managers.
- A phishing-resistant sign-in - a passkey or hardware key - removes the attack that unique passwords cannot touch. See MFA and passkeys.
- Device integrity protects secrets at rest: a vault that locks itself, prompt updates, and no software from search advertisements, download aggregators or piracy sites.
- A hardened recovery path closes the back door. Recovery email, recovery phone number and security questions are all authentication - usually its weakest copy, and the one nobody reviews.
- Detection and response is the layer people skip: sign-in alerts switched on, and recovery codes you can reach once access is gone.
Name what does not help, too. Ninety-day password changes do not. Security questions are not security, because the answers are often public; store random answers in your manager instead. SMS beats nothing but loses to both SIM swap and proxy phishing. Antivirus does not undo a cookie theft that already happened. And nothing you do protects data that the service itself leaks.
Protect the Accounts That Unlock the Others
You will not harden sixty accounts; nobody does. The gain from modest effort comes from noticing that accounts are not independent - a handful of them can reset the rest. Those get your best controls. Everything else gets a unique password and whatever second factor is convenient.
Four accounts usually form that tier:
- Your primary email. It is the master key to anything offering a reset by email, so it is first in line for a passkey.
- Your password manager. It holds the plaintext of everything else.
- Your mobile phone account. It controls the number used for codes and resets, so a carrier PIN belongs here.
- Your financial logins. These are where losses are immediate and sometimes irreversible.
Add cloud storage if it holds scans of identity documents - that is the raw material for impersonating you elsewhere. The UK NCSC's top tips for staying secure online is a short checklist worth running against this tier.
One ordering note, because it causes real lock-outs: test a new sign-in method before you remove the old one, and save the recovery codes first.
What to Do in the Next Hour
- Install a password manager, give it a long passphrase used nowhere else, and store its printed recovery kit away from your desk.
- Change your primary email password to a long generated one, then add a passkey. On a Google Account this is
Security > How you sign in to Google; on an Apple Account,Sign-In and Security; on a Microsoft account,Security > Advanced security options. - In those same screens, open active sessions and devices, sign out of anything unfamiliar, and delete recovery numbers or addresses that are no longer yours.
- Run your manager's reuse and breach report - in Chrome,
Settings > Autofill and passwords > Google Password Manager > Checkup; on Apple devices,Settings > Passwords > Security Recommendations. Fix the top-tier accounts first. - Ask your mobile carrier for a port-freeze or account PIN on the line that receives your codes.
- Revoke connected third-party apps on your email and social accounts that you do not actively use.
That is most of the benefit available in one sitting. The rest needs judgement rather than a settings change, which is what the four guides are for.
The short version
- Accounts are lost to reuse and phishing, not to clever guessing. Fix those two first.
- Uniqueness beats length, but a manager gives you both at no cost.
- Only passkeys and security keys survive a proxy login page. SMS and app codes do not.
- The recovery paths - recovery email, phone, security questions - are authentication too, and usually the weakest.
- After a compromise, revoking sessions matters as much as changing the password.
- Protect the four accounts that can reset all the others, and let the rest be merely good enough.
DEWA89: quick answers
What is DEWA89?
DEWA89 is a free, independent educational resource about account security and phishing awareness, published at dewa89official.site. It explains how online accounts are taken over and what an ordinary person can do about it. It sells nothing, carries no advertising, and asks readers for no personal information.
Where should I start if I only have fifteen minutes?
Put a passkey, or a hardware security key, on your primary email account. That single change defeats password reuse and real-time phishing, which are the two mechanisms behind most account takeovers. After that, add a backup factor on a second device and print the recovery codes.
Is DEWA89 the official brand website?
This site is the educational site, published on GitHub Pages. The official DEWA89 website is dewa89official.site, and every button on this site that points there opens it in a new tab. The two are related but separate: this one teaches, that one is the brand's own site.
Sources checked for this page
About DEWA89
DEWA89 is an independent educational project written by one person. It is not a company, an agency or a managed editorial team, and it does not pretend to be one. Rehan Aldiansyah writes these pages, checks them against the primary sources cited on each one, and answers corrections sent to the address on the support page.
DEWA89 is the name the site publishes under; the name above is the person accountable for what it says. Nothing here is generated and published unread: a claim either traces to a source you can open yourself, or it is marked as the author's own judgement.
How this site is funded
It is not. There is no advertising, no sponsorship, no affiliate link, no paid placement and no product for sale anywhere on this site. No company pays to be mentioned, and no page carries a commission-bearing link. Hosting is paid for out of the author's own pocket, which is the whole of the commercial relationship. If that ever changes, the change will be disclosed on this page before it appears anywhere else.
How to read this site
- Primary sources only. Where a claim can be checked, it links to the standards body, regulator or vendor documentation that supports it — not to another summary of it.
- Limits are stated. Where a control fails, or a setting only partly helps, the page says so in the same breath as the advice.
- Country-specific answers are labelled. Reporting routes, consumer protections and privacy law differ by country, so a passage that applies in only one is marked as such.
- No fear as a sales tool. Scaring a reader into a purchase is the behaviour this site exists to argue against.
Editorial standards we hold ourselves to
- We do not quote a statistic without naming the report and its year.
- We do not name a step-by-step settings path unless the vendor's own documentation still shows it.
- We do not present a product as the answer. Where a category of tool helps, we describe the category and what to look for in it.
- We do not write in the voice of expertise we do not have. When a question needs a lawyer, a doctor or a regulator, the page says so and stops.
- We do not silently rewrite a substantive claim. Material corrections are recorded with a dated note on the page, as described on the support page.
Dates, and what they mean
The date below is the last time these pages were re-checked against the sources they cite. It is a record of what happened, not a schedule: no page here states a calendar interval for review, because a static site cannot enforce one. Pages are re-checked when something they describe actually changes — a vendor renames a setting, a standard is revised, a regulation is amended, a link breaks — and at least once a year regardless, so that nothing is left unexamined through neglect.
The date moves only when a person has re-opened the cited sources and confirmed the text still matches them. It is not the date a file was last saved. Where a passage has been left standing but is no longer certain, it is marked as uncertain rather than quietly carried forward.
If the date below looks old, that is information, not a fault. It means the pages are due for their next pass. Everything on them links its primary source precisely so you can check the current position yourself rather than relying on our copy of it.
Who is accountable for this page
| Published by | DEWA89, an independent educational project written and paid for by Rehan Aldiansyah |
|---|---|
| Written by | Rehan Aldiansyah — an independent writer, publishing under the DEWA89 name. No employer, qualification or years of experience is claimed here, because this site asserts only what can be checked. |
| Reviewed by | Rehan Aldiansyah. This site has no separate reviewer, and we do not name one to look better. Every page is self-reviewed against the sources it cites, and that is exactly what the review record below means. |
| Corrections | Send a correction — specific reports are checked against a primary source and fixed or answered |
| First published | 2026-10-08 |
| Last reviewed | 2026-10-08 — every page on this site carries the same review date, and each one links the sources it was checked against |
Contact
Corrections, factual disputes, reports of a link that now leads somewhere harmful, and notices that a described setting has moved are all welcome at the address below. Rehan Aldiansyah reads them.
We will never ask you for a password, a one-time code, a recovery code or remote access to your device, and we will never ask you to confirm account details by replying to a message. Any message claiming to come from this site and asking for any of that is not from us.
Scope and limitations
Read this before acting on anything here.
- This is general education, not advice for your situation. It explains how account takeover and phishing generally work and what a reader can do about them. It is not legal advice, it creates no advisory relationship, and it should not be quoted in a dispute, a claim or a police report. If an account, your money or your identity is already affected, the people who can act are the provider's own recovery process, your bank, and the police or reporting body where you live.
- We cannot see your accounts or your devices. We cannot tell you whether a particular message you received is genuine, whether an account has been compromised, or what an organisation holds about you.
- We cannot act on your behalf. We cannot contact a platform, bank, regulator or data protection authority for you, and we cannot investigate anyone. Requests like that have to go to the provider directly.
- Menus move. Settings are renamed, moved and reset by updates. A click path that was accurate on the review date may look different in your version. Treat every step here as a description of what to look for rather than a guarantee of what you will see.
- We can be wrong. Errors get through. If you find one, the support page explains what happens next.

