Dangerous Applications need to remove from your phone immediately

Cyble လို့ခေါ်တဲ့ ဆိုက်ဘာလုံခြုံရေးဆော့ဖ်ဝဲလ်ကုမ္ပဏီရဲ့ Report တခုမှာ သင့်ရဲ့  Mobile Phone ထဲမှာ တကယ့် App အစစ်တွေရဲ့ နာမည် (သို့မဟုတ်) ပုံစံတူ အတုယူထားတဲ့ App တွေ သွင်းထားတယ်ဆိုရင် ဖျက်ပစ်ဖို့ အကြံပြုထားပါတယ်။ 

ဒီအတုအယောင် Digital Wallet, Crypto Wallet App တွေဟာ ထည့်သွင်းပြီး ဖွင့်လိုက်တာနဲ့ Phishing Website (သို့မဟုတ်) In-App Browser တစ်ခုကို ဖွင့်ပေးတာကို တွေ့ရှိခဲ့ပါတယ်။

အဲဒီနောက်မှာ App တွေက သင့်ရဲ့  Digital Wallet, Crypto Wallet ကို ရှင်းထုတ်ဖို့ အသုံးပြုနိုင်တဲ့ စကားလုံးအတွဲ (mnemonic phrase) ကို တောင်းဆိုပါတယ်။ 

အဆိုပါ အတုအယောင် App တွေဟာ အသုံးပြုသူတွေကို စကားလုံးအတွဲ (mnemonic phrase) ထည့်သွင်းမိအောင် လှည့်စားဖို့အတွက် လုံခြုံမှုမရှိတဲ့ (သို့မဟုတ်) ပြန်လည်အသုံးပြုထားတဲ့ developer အကောင့်တွေကို အသုံးပြုထားပါတယ်။ 

လက်ရှိမှာတော့ Wallet အစစ်ကို တုပထားရတဲ့ Fake Wallet (၉) ခု ရှိတယ်လို့ သတိပေးထားပေမယ့် လက်ရှိတွေ့ရှိထားတဲ့ အက်ပ် ၂၀ ကျော် ရှိတာကြောင့် အဲဒီစာရင်းက တိုးလာနိုင်ပါတယ်။

ချက်ချင်းဖျက်ပစ်သင့်တဲ့ App တွေကတော့ -

Pancake Swap

Suiet Wallet

Hyperliquid

Raydium

BullX Crypto

OpenOcean Exchange

Meteora Exchange

SushiSwap

Harvest Finance Blog

တို့ပဲ ဖြစ်ပါတယ်တဲ့။

Digital Wallet, Crypto Wallet Appတွေမှာ လုံခြုံရေးစနစ် (safety net) မရှိတဲ့အတွက် ဘယ်လိုဆုံးရှုံးမှုမျိုးမဆို ပြန်လည်ရယူလို့မရပါဘူး။ ဒါကြောင့် Wallet ပိုင်ရှင်တွေက တကယ်ထုတ်ပေးတာ ဟုတ်၊ မဟုတ် သေချာပြီး တရားဝင် Website ကနေ Wallet App ကို ချိတ်ဆက်ထားတာ မဟုတ်ရင် ဘယ် App ကိုမှ Download and Install မလုပ်ဖို့ အရေးကြီးပါတယ်။ အပေါ် က App တွေထဲက တစ်ခုခု သင့် ဖုန်းထဲမှာရှိနေတယ်ဆိုရင် ချက်ချင်းဖျက်ပစ်ဖို့ အရေးကြီးပါတယ်။

Safety Net ဆိုတာကတော့ အလွယ်‌‌ပြောရရင် Protection mechanism ထည့်သွင်းတည်ဆောက်ထားတာကို ဆိုလိုတာပါ။

Apple Pay, Paypal တို့လို Digital Wallet မျိုးကျတော့ ကြားခံ Custodian လို့ ခေါ် တဲ့ Apple, Bank တွေ ရှိတဲ့ အတွက် သူတို့ရဲ့ ထိန်းချုပ်မှု တစိတ်တပိုင်း (သို့မဟုတ်) အပြည့်အဝ ရှိတဲ့ အတွက် ငွေမှားလွှဲမိတာ တို့ ၊ မိမိ မသိလိုက်ပဲ ငွေလွှဲ ထားတာတို့ ဆိုရင် ပြန်လည်ရယူနိုင်တာမျိုးပေါ့။

Crypto Wallet တွေ မှာလဲ Centralize Exchange တွေ က ထုတ်ပေးထားတာမျိုးဆိုရင် Safety Net တချို့ တလေ ပါတဲ့ အတွက် လုံခြုံမှု အတိုင်းအတာ တခုထိ ရရှိနိုင်ပေမယ့် Decentralize Crypto Wallet App မျိုးဆိုရင်တော့ mnemonic phrase အခိုးခံရတာတို့ ၊ ပျောက်သွားတာ မေ့သွားရင်တော့ အဆုံးလို့သတ်မှတ်ရမှာပါပဲ။

Report မှာ နိဂုံးချုပ်ထားတာကတော့ 'ဒီလှုပ်ရှားမှုဟာ အလျင်အမြန်တိုးပွားနေတဲ့ Digital Wallet, Crypto Wallet App အသုံးပြုသူတွေကို ပစ်မှတ်ထားပြီး စနစ်တကျစီစဉ်ထားတဲ့ phishing operation ကို မီးမောင်းထိုးပြနေပါတယ်။ 

Google Play Store ကနေ Fake Android App (၂၀) ကျော်ကို ဖြန့်ဝေခြင်းအားဖြင့် Attackerတွေဟာ PancakeSwap, SushiSwap, Raydium စတဲ့ Legit Wallet App တွေကို အတုယူပြီး အသုံးပြုသူတွေရဲ့ ဒစ်ဂျစ်တယ်ပိုင်ဆိုင်မှုတွေကို ဝင်ရောက်ဖို့အတွက် မရှိမဖြစ်လိုအပ်တဲ့ စကားလုံးအတွဲ (mnemonic phrases) တွေကို ခိုးယူနေကြပါတယ်။ 

ဒီလှုပ်ရှားမှုကို အထူးသဖြင့် အန္တရာယ်များစေတာကတော့ ယခင်က အန္တရာယ်မရှိခဲ့ဖူးတဲ့ (သို့မဟုတ်) လုံခြုံမှုမရှိတော့တဲ့ developer အကောင့်တွေအောက်မှာ ထားရှိတဲ့ Legit ဖြစ်ပုံပေါ်တယ်လို့ ထင်ရတဲ့ App တွေကို အသုံးပြုထားခြင်းအပြင်၊

Traditional Protection တွေ ရဲ့ Detection ကို ရှောင်ရှားနိုင်ဖို့ နဲ့ Attack Surface ကို ပိုကျယ်ကျယ်ပြန့်ပြန့် ရောက်စေဖို့  Webiste Domain (၅၀) ကျော်နဲ့ ချိတ်ဆက်ထားတဲ့ Phishing Infrastructure တွေပါ ပေါင်းစပ်ထားပါသေးတယ်တဲ့။

နောက်ဆုံး အနေနဲ့ Cyble က လူတွေကို စိစစ်ပြီးသား developer တွေဆီကနေပဲ App တွေကို Download and Install လုပ်ဖို့နဲ့ ဘာကိုမဆို Download and Install မလုပ်ခင် သုံးသပ်ချက်တွေကို ကြည့်ဖို့ အကြံပြုထားပါတယ်။ 

သူတို့က အသုံးပြုတွေအနေနဲ့ ကွန်ပျူတာ၊ လက်ပ်တော့ပ်နဲ့ ဖုန်းလိုမျိုး ပစ္စည်းတွေမှာ ယုံကြည်စိတ်ချရတဲ့ Antivirus, Internet Security Software တွေကို အသုံးပြုသင့်တယ်လို့လည်း အလေးအနက်ထား ပြောကြားထားပါတယ်။ 

Password တခုထက်ပို တဲ့ multi-factor authentication ကို အသုံးပြုဖို့ ကိုလဲ အကြံပြုထားပြီး လုံခြုံရေး ပိုမိုကောင်းမွန်ဖို့အတွက် တတ်နိုင်သမျှ Face, Fingerprint တို့လို biometric data တွေကို အသုံးပြုဖို့လည်း တိုက်တွန်းထားပါတယ်။

သင့်ဖုန်းရဲ့ လုံခြုံရေးအတွက် ဒီအချက်အလက်တွေက အထောက်အကူပြုမယ်လို့ မျှော်လင့်ပါတယ်။ 

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

The Security Artichoke Metaphor: Understanding Layered Defense in Cybersecurity

လက်ပတ်နာရီတို့ ၊ အိမ်က ရေခဲသေတ္တာတို့ ၊ Smart Bulb တို့၊ Smart TV/CCTV တို့က အစ အင်တာနက် က နေ လှမ်း ပြီး Control လုပ်လို့ရနေတဲ့ ဒီနေ့လို ခေတ်ကြီး မှာ ကျတော် တို့ လို Information Security Professional တွေ အတွက် အရင်က သုံးနေတဲ့ Security Onion Model ကို သုံးဖို့ သိပ်အဆင်မပြေ တော့ ပါဘူး။

အဲဒီအတွက် System/ System Group တခုချင်းစီအတွက် Security Artichoke ဆိုတဲ့ Model ကိုသုံးဖို့ လုပ်လာကြရပါတယ်။

သို့ပေမယ့် Security Artichoke Model ဟာ လုံခြုံ တယ်၊ မလုံခြုံ ဘူးဆိုတဲ့ အဖွဲ့ နှစ်ဖွဲ့ ကွဲနေပြန်ပါရော။

ကျတော် က Security Artichoke Model ဟာ မလုံခြုံ ဘူး ဆိုတဲ့ အဖွဲ့ ဖက်ကနေ ဘာလို့ မလုံခြုံ တာလဲ ဆိုတာကို နည်းနည်း ရှင်းပြချင်ပါတယ်။

Security Onion မှာဆိုရင် System အားလုံး အတွက် layered security defense လို့ ခေါ် တဲ့ တလွှာချင်းစီကို လုံခြုံ ရေး အဆင့် ခံ ထားတဲ့ အတွက် Attacker တယောက်အနေနဲ့  Core Data/System ဆီကို ရောက်ဖို့ တဆင့်ချင်းစီကို ထိုးဖောက်ရမှာဖြစ်လို့ပါပဲ။

Security Artichoke မှာကျတော့ Core Data/System ဆီကို ရောက်ဖို့ အတွက် Attacker တယောက်က  လုံခြုံ ရေး တလွှာချင်းစီကိုထိုးဖောက်ဖို့ ကြိုးစားစရာမလိုပဲ။ Core Data/System ကို ရောက်နိုင်တဲ့ လုံခြံရေး အလွှာ တခုကို ချိုးဖျက်နိုင်တာနဲ့ ရသွားနိုင်တာဖြစ်နေလို့ပါ။

ဥပမာ အနေနဲ့  Corporate Infra ကို Access လုပ်နိုင်တဲ့ BYOD တခုခုရဲ့  IoT/Bluetooth Gadgets (Wireless Earbud/Smart Tracker လိုဟာမျိုး) ကို Exploit လုပ်နိုင်ရင်ကိုပဲ အဲ့ကနေ တဆင့် Lateral Movement လုပ်သွားပြီး Core Data/System ကို ရောက်နိုင်ဖို့ လွယ်လို့ပါ။

IoT gadgets တွေဟာ ဆိုရင် minimum hardware ပေါ် မှာ သူတို့ Firmware ကို Run နိုင်အောင် လုပ်ထားရလို့ လုံခြုံ ရေး ပိုင်း နဲ့ ပတ်သတ်တာမှန်သမျှ အားလုံးနီးပါး ထည့်သွင်းထားလေ့ မရှိတဲ့ အပြင် Manufacture/Vendor တွေက လဲ Security Fix Update တွေ မထုတ်ကြတာများတဲ့ အတွက် အလွယ်တကူ ချိုးဖောက်နိုင်ကြပါတယ်။

Security Artichoke ဟာ လုံခြုံတယ်ဆိုတဲ့ အဖွဲ့က ပြောတာကတော့ ဒီလိုပါ။

အပေါ် မှာ ဥပမာပြောထားတဲ့ ပြဿနာမျိုးက Security Artichoke ရဲ့ အားနည်းချက်ကြောင့် မဟုတ်ပဲ Implementation လုပ်တဲ့သူတွေ ရဲ့ အားနည်းချက်ကြောင့် ပါတဲ့။

အဲ့လို ပြဿနာမျိုးကို မဖြစ်အောင် လုပ်ရမယ့် နည်းလမ်းတွေ အများကြီး ရှိတဲ့ အထဲက ၃ မျိုးလောက် ကျတော် ပြန်လည် ဝေမျှချင်ပါတယ်။

၁) Zero Trust

 Corporate Infra ကို ချိတ်ဆက်မဲ့  ဘယ် အလွှာကပဲ ဖြစ်ဖြစ် No Trust လုပ်ရမှာ ဖြစ်ပြီး Authentication, authorization နဲ့ accounting ကို လုပ်ကိုလုပ်ရမှာပါတဲ့။

၂) Air-Gapping

Core Data/System ရှိတဲ့ အလွှာကို Physically Isolated လုပ်ထားရမှာဖြစ်ပြီး၊ လိုအပ်လို့ Access လုပ်မယ်ဆိုရင်တောင် အဆင့်ဆင့်သော ခွင့်ပြုမိန့် တွေ ရယူဖို့ လိုတဲ့ စနစ်တခု ရှိနေရပါမယ်တဲ့။

၃) Chaos Engineering

ဒါကတော့ Secured Layer တိုင်းဟာ သူတို့ လုပ်သင့်တဲ့ အလုပ်ကို မျှော်လင့်ထားသလို တကယ်လုပ်သလားဆိုတာကို လက်တွေ့ စမ်းသပ်ကြည့်ခြင်းပါတဲ့။

ဥပမာ အနေနဲ့ ပြောရမယ်ဆိုရင် အနည်းဆုံး အပေါ် ကပြထားတဲ့ Zero Trust System တခုကို Disable လုပ်လိုက်ပြီး  Core Data/System ကို Red Team/Penetration Tester က ထိုးဖောက်နိုင်လား ဆိုတာကို စမ်းကြည့်တာမျိုးပါ။

Onion ကတော့ ကြက်သွန်နီဥ ဆိုတော့ ကြက်သွန်ဖက် အလွှာလေးတွေ ကို ပြောတာမှန်း သိသာပေမယ့် Artichoke ဆိုတာကို ကျတော်လဲ မြန်မာလို မသိလို့ မရေး ပြတော့ဘူး။ ‌

ဂေါ်ဖီ ထုပ်လိုလို၊ ငှက်ပျောဖူးလိုလို ပဲ။ ဒါနဲ့ Artichoke ဆိုတာ မျက်လုံးထဲ မြင်အောင် ပုံလေးပါ ပြထားပါတယ်။

မြန်မာနှစ်သစ်မှာ အားလုံးပဲ ဘေးဘယာဝေးကွာပြီး ကိုယ်စိတ်နှစ်လုံး ရွှင်ပြုံး ကျန်းမာကြပါစေဗျာ။

ပျှော်ရွှင်ပါစေ။

(Be knowledgeable, pass it on then)

Network Challenges and Requirements for AI Workloads for Network Engineers

 ယနေ့ ခေတ် မှာ ကျတော်တို့ တွေ သုံးနေတဲ့ Mobile Application/Web Application တွေ ဟာ Real-Time  အလုပ်လုပ်နေ တာ က အများဆုံးဖြစ်ပါတယ်။

ဥပမာ Facebook/Gmail လို App တောင် မှ Application ကို ကိုယ် ဘယ် Device ပေါ် မှာသုံးနေလဲ။ ဘယ် IP ကနေ သုံးနေလဲ။ ဘယ်အချိန်မှာ သုံးနေလဲ စတာတွေ ကို အမြဲ check and detect လုပ်နေပြီး တကယ့် Account ပိုင်ရှင် အစစ်က သုံးနေတာလား၊ တခြား တယောက်ယောက်က သုံးနေတာလားဆိုတာကို ဆုံးဖြတ်ဖို့ (Inferencing လုပ်တယ်လို့ ခေါ် ပါတယ်) နောက်ကွယ်ကနေ စောင့်ကြည့် နေတာမျိုးပေါ့။

ခုခေတ် မှာ အဲ့လိုလုပ်နေနိုင်ဖို့ အတွက် AI/ML infrastructure တွေ ကို သုံး နေ တာပါ။

ဒီလို AI/ML infrastructure တွေ အတွက် လိုအပ်တာက 

Backend မှာဆိုရင် Up-to-date dataset တွေ နဲ့ Training လုပ်ဖို့အတွက် AI/ML Server Nodes တွေ၊

 Train လို့ရလာတဲ့ Model နဲ့ Inferencing Engine တွေ Deploy လုပ်ဖို့ အတွက် Edge Device/User Device တွေပါ။

ဒါပေမယ့် Training နဲ့ Inferencing အတွက် လိုအပ်တဲ့ တကယ့် အ‌‌ရေးကြီး တာ တခုကတော့ Networking ပါပဲ။

အပေါ် က ဥပမာ ပြထား တဲ့ Real-Time Application လို မျိုး အတွက် အလုပ်လုပ်ပေး နေတဲ့ AI/ML Infrastructure တခုဟာ Training တွေ လုပ်ပေး နေတဲ့ AI Node Server တွေ အတွက် High-Bandwidth, Non-Blocking Lossless Network နဲ့ Congestion Management တွေ ဟာ မဖြစ်မနေ ကို လိုအပ်လာပါတယ်။

ဒါတင်ပဲလားဆိုတော့ Inferencing အတွက် လဲ Low Latency နဲ့ Low Jitter network connection ဟာ မဖြစ်မနေ လိုအပ်လာပါတော့တယ်။

AI/ML တွေ ဟာ GPU တွေ ပေါ် မှာ Run နေတာ ဖြစ်တဲ့ အပြင် low latency နဲ့ low jitter network connection ရအောင် လုပ်ဖို့ အတွက် CPU load ကို လျော့ ဖို့ လိုလာပါတယ်။

ဒီအခါ မှာ Remote Direct Memory Access over Converged Ethernet (RoCEv2) protocol ဆိုတာကို ကျတော် တို့ Network သမားတွေ ဟာ Quality of Service (QoS) နဲ့ တွဲသုံးရပါတော့ တယ်။

ဒါမှသာ AI/ML Infrastructure တခုရဲ့ လိုအပ်ချက်တွေ ဖြစ်တဲ့ 

High-Bandwidth

Non-blocking lossless network

congestion management

low latency

low jitter ဆိုတာတွေ ကို ရလာနိုင်မှာဖြစ်ပါတယ်။

အခုရေးပြထားတာ‌တွေ ဟာ Cisco U က နေ ပေးထားတဲ့ AI Solutions on Cisco Infrastructure Essentials | DCAIE ကို တက်ပြီး တကယ့်ကို အပေါ် ယံ လောက်သာ ရေးထားတာပါ။

 AI/ML Infrastructure တွေ အတွက် ကျတော် တို့ Network သမားတွေ တကယ်လေ့လာရမယ့် အပိုင်းတွေ အများကြီး ရှိလာပါတော့တယ်။

နောက်များ အချိန်ရလာနိုင်ရင် အသေးစိတ်ရေးနိုင်မယ်လို့ မျှော်လင့်ပါတယ်။

ကျေးဇူးတင်ပါတယ်။

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Things to note for Typosquatting Domain Attack

 ဇူလိုင်လ တုန်းက တကမ္ဘာလုံး အတိုင်းအတာနဲ့ ထိခိုက်စေခဲ့ တဲ့ CrowdStrike ရဲ့ IT Incident ကို တော်တော်များများ မှတ်မိကြမယ် ထင်ပါတယ်။

CrowdStrike ဟာ Security Agent Incident တခုကိုပဲ ရင်ဆိုင်ဖြေရှင်းခဲ့ရတာတော့ မဟုတ်ပါဘူး။

သူ့ ရဲ့ Security Agent ကြောင့် ဖြစ်တဲ့ Incident အပြင် Typosquatting Domains တွေ ကြောင့် ဖြစ်လာတဲ့ ကိစ္စ တွေ ကို ပါ လိုက်ရှင်းရတာပါ။

Typosquatting Domains ဆိုတာကတော့ ဆင်တူယိုးမှား Domain တွေ လုပ်၊ Company ရဲ့ Logo နဲ့ တခြား အချက်အလက်တွေ ကို ကူးတင်ထားပြီး User တွေ Browser website မှားရိုက်လိုက်လို့ ရောက်လာတာကနေ အကျိုးအမြတ် ရအောင် လုပ်ထားတာပါ။

Information Security သမားတွေ အတွက် ခေါင်း ခဲ စေတဲ့ ကိစ္စ တွေ ထဲမှာ ဒါလဲ ထိပ်ဆုံးကပါပါတယ်။ ဘာလို့လဲ ဆိုတော့ Company Brand Reputation ကိုပါထိခိုက် ဆုံးရှုံးမှုတွေ ရှိနိုင်လို့ပါ။

CrowdStrike က ဖြစ် သွားတဲ့ Typosquatting Domains တွေ မှာတော့ အောက်က အချက်တွေ နဲ့ User တွေ ကို ပစ်မှတ်ထားတယ်လို့ Akami က လုပ်တဲ့ စစ်တမ်းက နေ သိရပါတယ်။

- False support claims: Company က တကယ်မပေးတဲ့ Service တွေ ပေးသလိုနဲ့ Login credential တွေ ရဖို့ ကြိုးစားတာ

- Urgency tactics: System တွေ Down နေ တာကို အခွင့်ကောင်းယူပြီး အခုမှ မလုပ်ရင် မရဘူးဆိုတာမျိုး နဲ့ တခုခု (App သွင်းခိုင်းတာ၊ လင့်တွေနှိပ်ခိုင်းတာ စသည်ဖြင့်) လုပ်ခိုင်းတာ 

- Malicious ZIP files: Bug fix ပါတယ်ပြောပြီး Malware ပါတဲ့ ZIP ဖိုင်ကို Download လုပ်ပြီး ဖွင့်ခိုင်းတာ

- Phishing Email : Social media ပေါ် မှာ တက်လာတဲ့ အချက်အလက်ကို ကြည့် ပြီး Targeted Phishing Email တွေ ပို့ပြီး ဖန်တီးထားတဲ့ Fake Website တွေ ဆီရောက်အောင်လုပ်တာ။ Credentials တွေ ရယူတာမျိုးတွေ လုပ်ပါတယ်။ 

အထက်ပါ နည်းလမ်းများနဲ့  Incident တခုကို အကြောင်းပြုပြီး Panic Users များဆီက နေ System access, Credentials တွေ ရဖို့ ကြိုးစားကြပါတယ်။

ဒီတော့ အပေါ် က လို ဖြစ်ရပ်မျိုးကို ကိုယ့်ဆီမှာ လဲ ဖြစ်လာတဲ့ အခါ ဘယ်လိုဖြေရှင်းသင့်လဲ ဆိုရင် 

၁) User ကို  Email လက်ခံရာမှာ Sender နဲ့ Email content ကို အမြဲ စစ်ဆေးဖို့ Information Security Awareness သင်တန်းပေးပါ။

၂) Incident တကယ်ဖြစ် လာရင် IT Team ကို ပဲ ဆက်သွယ်ဖို့ နဲ့ တကယ့်တရားဝင် Website, Social Media Page တွေ ကို သိနေစေ ဖို့ သတိထားတတ်ဖို့ Training ပေးပါ။

၃) နောက် တခု ကတော့ Company Data တွေ သုံးပြီး တုပထားတဲ့ Typosquatting Domains တွေ ကို  Netcraft တို့ Bolster တို့လို Automatic Domain Takedown Service Tool တွေ နဲ့ အမြဲ Scanပြီး  ဖြုတ်ချနိုင်ဖို့ပါပဲ။

အားလုံးပဲ Typosquatting ကနေ ဖြစ်လာမယ့် Cyber Security Incident တွေ ကို ကျော်လွှားနိုင်ကြပါစေ။ 

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)

Some recommendation about password from NIST SP 800-63B

 Harvard က ပေးတဲ့ သင်ခန်းစာ တခုကြည့်ရင်း သင်ခန်းစာထဲက ညွှန်းတဲ့  

NIST Special Publication 800-63B ကို ဖတ်ကြည့်တော့ အဲ့ထဲက Digital Identity Guidelines: Authentication and Lifecycle Management မှာ အောက်က Recommendation နှစ်ခုပါတယ်။

Memorized secret verifiers SHALL NOT permit the subscriber to store a "hint" that is accessible to an unauthenticated claimant. 

Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., "What was the name of your first pet?") when choosing memorized secrets.

ခုလက်ရှိထိ Company တော်တော်များများ က သူတို့ရဲ့  Website, Application တွေမှာ အပေါ် က ၂ ခု ကို မလိုက်နာကြသေးဘူး။ 

Social Media, AI ခေတ်မှာ မင်း ရဲ့ ပထမဆုံး Pet က ဘာလဲ၊ မင်း ပထမဆုံး စီးခဲ့တဲ့ ကားက ဘာ မော်ဒယ်လဲ ဆိုတာတွေက  သိဖို့မှ မခက်တော့တာနော်။ 

ကိုယ်မဟုတ်တဲ့ တခြားသူက ကိုယ့်ရဲ့ Password ကို recovery ပြန် ယူဖို့ လွယ်သွားတာပေါ့။ 

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).

ခုအချိန်ထိ Corporate တွေ ရဲ့  Information Security Policy တွေ ထဲက Password Policy တွေမှာ Password ကို ရက် (၃၀)/ရက် (၄၅)/ ရက် (၉၀) တိုင်း ပြောင်းခိုင်းနေတာကြီးက အမြဲတွေ့ နေကြပါ။

Account Password တခု compromise ဖြစ် သွားတဲ့အချိန် (သို့မဟုတ်) လက်ရှိသုံးနေတဲ့ Account Password တခုခုကို Breach ဖြစ်သွားတဲ့နေရာက နေ Threat Intel က သိတဲ့အချိန်မျိုးမှ သာ Password ကို ပြောင်းခိုင်းသင့်ပါတယ်တဲ့။

နောက်ဆို Password Policy ကို Review လုပ်ပေးပါ ပြောရင် ဒါကြီး ကိုင်ပြီး ပြန်ငြင်းကပေါ့ ။ 

အဲ့ဒါကြောင့် ပြောတာ သိပ္ပံပညာရပ်က အမြဲ မမှန်ဘူး။ အရင်က တွေ့ ခဲ့တဲ့ သီအိုရီ က အခု ကျ မှားရင် မှားနေ တတ်တာမျိုးလေ။ 

သူငယ်ချင်းတို့ စာတွေ အရမ်းလုပ်မနေကြနဲ့ တော့ ...

ခုလို အဘိဓမ္မာအခါတော် နေ့ မှာ အမြဲမှန်တဲ့ အဝိဇ္ဇာ။ တဏှာ၊ နာမ် နဲ့ ရုပ်၊ သစ္စာလေးပါး တရားတွေ တာ သိအောင် အားထုတ်ကြတော့။ 😁

ပျော်ရွှင်ပါစေဗျာ။

(Be knowledgeable, pass it on then)