နားလည်ထားရမယ့် အချက်
Cybersecurity Basics က primary login (strong password, 2FA, password manager) ကို ဆွေးနွေးထားပါတယ်။ ဒါပေမယ့် နက်နက်နဲနဲ့ မဆွေးနွေးခဲ့တဲ့ path တစ်ခုရှိပါတယ် - account recovery ပါ, အားလုံးကို ကျော်ဖြတ်လို့ရနိုင်ပါတယ်။
- Recovery codes - offline note ဒါမှမဟုတ် password manager မှာသိမ်း, public note/screenshot ဘယ်တော့မှ မဖြစ်ရ
- Recovery email/phone - main account နဲ့ တန်းတူ level ကာကွယ်ဖို့ လို
- Trusted devices - ပုံမှန် ပြန်စစ်ဆေးဖို့ လို
အားနည်းဆုံး Link က ဆုံးဖြတ်တယ်
Account ရဲ့ အမှန်တကယ် လုံခြုံရေးအဆင့်ကို သတ်မှတ်ပေးတာက အားနည်းဆုံး recovery path ဖြစ်ပြီး, ခိုင်မာဆုံး login method မဟုတ်ပါဘူး။
Recovery ကို လုံခြုံအောင် ထားတာက ရွေးချယ်စရာ extra credit မဟုတ်ဘဲ account ရဲ့ attack surface ကိုယ်တိုင်ရဲ့ တစ်စိတ်တစ်ပိုင်းပါ။
FRONT DOOR vs BACK DOOR
-----------------------
FRONT DOOR vs BACK DOOR
------------------------
FRONT DOOR BACK DOOR
(primary login) (account recovery)
----------------- -----------------
password / passkey recovery codes
2FA recovery email
recovery phone
trusted devices
| |
| |
v v
must be secured must ALSO be secured
----------------- -----------------
both lead to the SAME account
an attacker only needs ONE open doorလက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
အောက်က code က account တစ်ခုရဲ့ recovery setup description ကို ယူပြီး အားနည်းဆုံး link ကို flag လုပ်ပေးပါတယ်, ကိုယ့် account audit ပုံစံအတိုင်းပါ။
- Well-secured example - all three check pass, weak link ဘာမှ မထွက်
- Poorly-secured example - recovery codes နဲ့ recovery email 2FA weak link နှစ်ခု တိတိကျကျ ဖော်ပြ
ဒါကို ကိုယ့်ဟာကိုယ် quick self-audit template တစ်ခုအဖြစ် သုံးကြည့်ပါ။ Question သုံးခုကို ပြန်ဖြေပြီး "မဟုတ်ဘူး" ဆိုရင် task တစ်ခုအဖြစ် ကိုင်တွယ်ပါ။
Account Recovery Security Checklist
အတူတူ စမ်းရေးကြည့်မယ်
function findWeakestRecoveryLink({ recoveryCodesStoredSecurely, recoveryEmailHas2FA, recoveryPhoneCurrent }) {
const checks = [
{ name: "recoveryCodes", ok: recoveryCodesStoredSecurely, risk: "Recovery codes are not stored securely -- anyone who finds them can bypass your main login entirely." },
{ name: "recoveryEmail", ok: recoveryEmailHas2FA, risk: "Recovery email lacks its own 2FA -- compromising that inbox compromises this account too." },
{ name: "recoveryPhone", ok: recoveryPhoneCurrent, risk: "Recovery phone number is outdated -- a reassigned number could let a stranger receive your recovery messages." }
];
const weakLinks = checks.filter(c => !c.ok);
return {
allRecoveryPathsSecure: weakLinks.length === 0,
weakestLinks: weakLinks.map(c => c.risk)
};
}
const wellSecured = findWeakestRecoveryLink({ recoveryCodesStoredSecurely: true, recoveryEmailHas2FA: true, recoveryPhoneCurrent: true });
const poorlySecured = findWeakestRecoveryLink({ recoveryCodesStoredSecurely: false, recoveryEmailHas2FA: false, recoveryPhoneCurrent: true });
console.log(JSON.stringify({ wellSecured, poorlySecured }, null, 2));Well-secured example ကို run ကြည့်ရင် `allRecoveryPathsSecure: true` နဲ့ weak link ဘာမှ မရှိပါဘူး။ Poorly-secured example ကတော့ `allRecoveryPathsSecure: false` နဲ့ weak link နှစ်ခုကို တိတိကျကျ ဖော်ပြပါတယ်။ Output အတိအကျမှာ:
{
"wellSecured": {
"allRecoveryPathsSecure": true,
"weakestLinks": []
},
"poorlySecured": {
"allRecoveryPathsSecure": false,
"weakestLinks": [
"Recovery codes are not stored securely -- anyone who finds them can bypass your main login entirely.",
"Recovery email lacks its own 2FA -- compromising that inbox compromises this account too."
]
}
}၅ မိနစ် စမ်းကြည့်
`findWeakestRecoveryLink` ထဲကို "trustedDevicesReviewed" ဆိုတဲ့ check အသစ်တစ်ခု ထပ်ထည့်ကြည့်ပါ, `false` ဖြစ်ရင် weak link တစ်ခုအဖြစ် report ဖြစ်အောင် ရေးကြည့်ပါ။
သတိလေးတစ်ချက်
Recovery code screenshot ကို cloud photo ထဲမှာ သိမ်းထားတာ, ဒါက public note တစ်ခုနဲ့ တူတူပါပဲ
Primary login ကို passkey/2FA နဲ့ ကောင်းကောင်း ကာကွယ်ထားပြီးရင် ပြီးပြီလို့ ထင်ပြီး recovery email/phone ကို လျစ်လျူရှုတာ
CISA — Secure Our World — Digital Privacy & Modern Security