Vaultwarden محفوظ ہے؟ Hardening کے اہم اقدامات

کیا Vaultwarden محفوظ ہے؟ مختصر جواب

Vaultwarden اس اہم ترین مقام پر محفوظ ہے، کیونکہ ہر vault item سرور تک پہنچنے سے پہلے آپ کے device پر encrypt ہو جاتا ہے۔ سرور ایسے blobs محفوظ کرتا ہے جنہیں وہ پڑھ نہیں سکتا۔ جو شخص پوری database کی copy حاصل کر لے، اسے بھی اس سے مفید معلومات حاصل کرنے کے لیے master password درکار ہوگا۔

یہ جواب بہت سی باتوں پر منحصر ہے، اور جو حصے ناکام ہوتے ہیں وہ وہی ہیں جنہیں آپ configure کرتے ہیں۔ ایسا admin panel جس کے پیچھے آسانی سے guess کیا جا سکنے والا token ہو۔ ایسا container port جو پورے internet پر publish ہو۔ ایک plaintext config.json۔ اسی box کی home directory میں پڑی ہوئی backup tarball۔ ان میں سے کوئی بھی cryptography کا مسئلہ نہیں ہے۔ یہی سب وہ وجوہات ہیں جن کی وجہ سے self-hosted vaults خالی ہو جاتے ہیں۔

ذیل کی تمام ہدایات ایک فعال install فرض کرتی ہیں۔ اگر آپ کے پاس ابھی install موجود نہیں ہے تو پہلے VPS کے لیے Vaultwarden install guide کے ذریعے اسے setup کریں، پھر واپس آ کر اس فہرست پر اسی ترتیب سے عمل کریں۔

سرور در حقیقت کیا محفوظ رکھتا ہے

Vaultwarden، Bitwarden کا data model نافذ کرتا ہے۔ vault item کا نام، username، password، notes اور URIs، کسی بھی request کے بھیجے جانے سے پہلے client میں آپ کے master password سے اخذ کردہ key کے ذریعے encrypt ہو جاتے ہیں۔ Attachment فائلوں کا content بھی اسی طرح encrypt ہوتا ہے۔ سرور کو UUID (universally unique identifier) کے ساتھ منسلک opaque data موصول ہوتا ہے۔

کچھ چیزیں ciphertext نہیں ہوتیں۔ آپ کو معلوم ہونا چاہیے کہ وہ کون سی ہیں:

• آپ کا account email address، plaintext میں۔
• آپ کی KDF (key derivation function) settings اور salt، کیونکہ اگلی login پر key دوبارہ بنانے کے لیے client کو ان کی ضرورت ہوتی ہے۔
• master password hash کا server-side hash جو client بھیجتا ہے، اور login کی authentication کے لیے استعمال ہوتا ہے۔
• Metadata: organisation membership، device names، last login times۔
• اس two-factor method کا secret جو Vaultwarden login کی حفاظت کرتا ہے۔ یہ twofactor table میں unencrypted رہتا ہے، کیونکہ server کو متوقع code calculate کر کے آپ کے code سے اس کا موازنہ کرنا ہوتا ہے۔ یہ اس TOTP (time-based one-time password) secret سے مختلف ہے جسے آپ vault item کے اندر محفوظ کرتے ہیں۔ وہ دوسرے fields کی طرح encrypted ہوتا ہے۔

data folder چھوٹا ہوتا ہے۔ Docker install میں یہ وہی directory ہوتی ہے جسے آپ نے /data پر mount کیا ہو۔

sudo ls -l /vw-data/

db.sqlite3 میں تقریباً تمام state محفوظ ہوتی ہے۔ attachments/ میں uploaded files، ہر UUID کے لیے ایک file، محفوظ ہوتی ہیں، اور یہ data کی واحد اہم قسم ہے جو database tables میں موجود نہیں ہوتی۔ sends/ میں Send attachments محفوظ ہوتے ہیں اور اسے عارضی استعمال کے لیے رکھا گیا ہے۔ icon_cache/ غیر ضروری data ہے جسے دوبارہ بنایا جا سکتا ہے۔ rsa_key.pem اور اس کی متعلقہ files logged-in users کے JWTs (JSON web tokens) پر دستخط کرتی ہیں، اس لیے اس private key کی copy استعمال کر کے جعلی vault login session بنایا جا سکتا ہے۔ config.json صرف admin page enable کرنے کے بعد موجود ہوتا ہے، اور project documentation اس بارے میں واضح ہے: اس میں admin token اور آپ کی SMTP credentials plaintext میں محفوظ ہوتی ہیں۔

اس لیے عملی threat model network cryptography نہیں بلکہ filesystem access ہے۔ اس ایک directory تک read access ہر user کا email address، ان کے login 2FA secrets، sessions forge کرنے والی key، اور ہر vault کی offline copy فراہم کر دیتا ہے، جس پر آرام سے حملہ کیا جا سکتا ہے۔ ذیل کا ہر قدم لوگوں کو اس directory سے دور رکھنے کے لیے ہے۔

پہلے admin token درست کریں

/admin ایک مکمل control panel ہے: صارفین کی فہرست، invitations، deletion اور ہر runtime setting۔ یہ صرف ایک مشترک secret سے محفوظ ہے۔ اس کے علاوہ کچھ نہیں۔ کوئی username نہیں۔ ہر صارف کے لیے الگ two-factor بھی نہیں۔

پرانے guides میں openssl rand -base64 48 کے ذریعے ADMIN_TOKEN generate کرنے کو کہا جاتا ہے۔ یہ طریقہ کام کرتا ہے، لیکن secret کو plaintext کی صورت میں config.json اور آپ کی compose file میں لکھ دیتا ہے۔ Vaultwarden ایک Argon2 PHC (password hashing competition) string بھی قبول کرتا ہے، اس لیے stored value کے بجائے hash محفوظ ہوتا ہے۔ چلتے ہوئے container کے خلاف ایک generate کریں:

docker exec -it vaultwarden /vaultwarden hash

یا چلتے ہوئے container کو بالکل استعمال کیے بغیر:

docker run --rm -it vaultwarden/server /vaultwarden hash

یہ password دو مرتبہ طلب کرتا ہے، پھر $argon2id$ سے شروع ہونے والی ایک line دکھاتا ہے۔ bare-metal install پر ./vaultwarden hash چلائیں۔ اگر آپ براہِ راست argon2 CLI استعمال کرنا چاہتے ہیں تو project میں OWASP کے minimum parameters درج ہیں:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

اب وہ مسئلہ جس پر لوگوں کا ایک گھنٹہ ضائع ہو جاتا ہے۔ PHC string میں $ characters بہت زیادہ ہوتے ہیں، اور Docker Compose $ کو variable interpolation سمجھتا ہے۔ اسے environment: block میں بغیر escape کیے paste کرنے سے container تک پہنچنے والی value خراب ہو جاتی ہے، اس لیے /admin ایسا token reject کرتا ہے جس کے درست ہونے کا آپ کو یقین ہوتا ہے۔ دو محفوظ طریقے ہیں۔ docker-compose.yml میں ہر $ کو دوگنا کریں:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

.env file میں escaping کی ضرورت نہیں، لیکن single quotes استعمال کریں:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

پھر panel پر rate limit لگائیں اور اس کا session مختصر کریں:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

پانچ منٹ کے اندر تین ناکام کوششوں کے بعد panel اس client کی درخواستوں کا جواب دینا بند کر دیتا ہے۔ 20 منٹ تک کوئی سرگرمی نہ ہونے کے بعد admin session ختم ہو جاتا ہے۔

ان سب سے بہتر طریقہ یہ ہے کہ page کو بند کر دیں۔ زیادہ تر instances میں اسے SMTP configure کرنے اور پہلے users کو invite کرنے کے لیے صرف ایک بار درکار ہوتا ہے، اس کے بعد کبھی نہیں۔ اسے disable کرنے کے لیے نہ ADMIN_TOKEN set کریں نہ DISABLE_ADMIN_TOKEN، config.json سے کوئی بھی "admin_token" key ہٹا دیں، پھر container دوبارہ create کریں۔ File سے key حذف کرنا اہم ہے، کیونکہ admin page settings وہیں لکھتا ہے، اور config.json میں موجود value environment پر فوقیت رکھتی ہے۔ صرف variable ہٹانے سے page کھلا رہتا ہے۔

کسی کے domain تک پہنچنے سے پہلے registration بند کریں

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED کی default قدر true ہے۔ اسے اسی طرح رہنے دینے پر جو بھی آپ کے domain تک پہنچے گا، وہ account بنا سکے گا، اور اس کا data اسی db.sqlite3 میں محفوظ ہوگا جس میں آپ کا data ہے۔ اسے false پر set کریں اور admin page سے invitations کے ذریعے لوگوں کو شامل کریں؛ اس کے لیے working SMTP درکار ہے۔ INVITATIONS_ALLOWED بھی default طور پر true ہے اور organisation owners کو دوسروں کو invite کرنے کی اجازت دیتا ہے۔ اگر آپ اپنے users پر اعتماد کرتے ہیں تو یہ مناسب ہے، اور single-user instance پر اسے false ہونا چاہیے۔ اگر صرف مخصوص domains سے registration کی اجازت ہونی چاہیے تو SIGNUPS_DOMAINS_WHITELIST=example.com، open signup کے مقابلے میں زیادہ محدود ہے، لیکن invitations کے مقابلے میں بہت کم محفوظ ہے۔

SHOW_PASSWORD_HINT default طور پر false ہے اور اسے اسی طرح رہنا چاہیے۔ یہ فعال ہونے پر login form میں valid email address درج کرنے سے اس account کا master password hint واپس آ جاتا ہے۔ اس سے hint افشا ہوتا ہے اور یہ بھی تصدیق ہو جاتی ہے کہ یہ address موجود ہے۔

اگر آپ کی instance کسی بھی مدت تک open signups کے ساتھ چلتی رہی ہے تو یہ فرض کرنے سے پہلے کہ اس پر صرف آپ کا account ہے، admin page کھولیں اور user list دیکھیں۔

وہ port جسے آپ publish نہیں کرنا چاہتے تھے

Docker image container کے اندر port 80 پر listening کرتی ہے۔ Bare-metal installation میں default طور پر ROCKET_PORT=8000 استعمال ہوتا ہے۔ Documentation میں دیا گیا run command اسے اس طرح publish کرتا ہے:

--publish 127.0.0.1:8000:80

127.0.0.1: prefix ہی اصل مقصد ہے۔ اس کے بجائے -p 8000:80 لکھنے سے Docker 0.0.0.0 bind کر دیتا ہے، اور یہ کام nat table میں DNAT (destination network address translation) rules لکھ کر ہوتا ہے۔ ان rules کا evaluation ufw کے زیر انتظام filter chains سے پہلے ہوتا ہے۔ اس لیے ufw status port کو denied بتاتا ہے، جبکہ port internet سے درخواستیں قبول کرتا رہتا ہے۔ اس پورے mechanism کی تفصیل Docker ports کے ufw کو bypass کرنے کی guide میں پڑھیں۔

دیکھیں کہ حقیقت میں کون سا port listening کر رہا ہے:

sudo ss -tlnp | grep 8000

درست نتیجے میں صرف ایک line ہونی چاہیے جو 127.0.0.1:8000 پر bound ہو۔ 0.0.0.0:8000 پر bound line کا مطلب ہے کہ vault براہ راست exposed ہے۔ Mapping درست کریں، پھر container دوبارہ create کریں، کیونکہ port binding container create ہوتے وقت مقرر ہوتی ہے اور docker compose restart اسے تبدیل نہیں کرے گا:

docker compose up -d --force-recreate

ایک اور port پرانی guides میں اب بھی نظر آتا ہے: 3012، جو الگ WebSocket port تھا۔ Vaultwarden 1.31.0 میں اس کی support ختم کر دی گئی، کیونکہ notification traffic اب main HTTP port پر منتقل ہو گیا ہے۔ WEBSOCKET_ENABLED اور WEBSOCKET_PORT کو 1.29.0 سے نظرانداز کیا جا رہا ہے۔ موجودہ switch ENABLE_WEBSOCKET ہے، جس کی default value true ہے۔ اگر آپ کا firewall یا compose file اب بھی 3012 کھولتا ہے تو اسے بند کر دیں۔

ریورس پراکسی پر TLS ختم کریں، Rocket میں نہیں

Vaultwarden خود Rocket، یعنی اپنے web framework، کے ذریعے TLS (transport layer security) فراہم کر سکتا ہے، لیکن project production میں ایسا نہ کرنے کی ہدایت دیتا ہے۔ Rocket کی built-in TLS میں strict SNI (server name indication) support موجود نہیں ہے۔ اسی وجہ سے hardening کی ہدایت یہ بھی ہے کہ اپنی instance تک hostname کے ذریعے رسائی حاصل کریں اور کبھی bare IP address استعمال نہ کریں۔ Public IP ranges کو مسلسل scan کیا جاتا ہے۔ جو vault IP address پر جواب دیتا ہے، وہ تلاش کر لیا جاتا ہے۔

nginx server block کے اہم حصے یہ ہیں:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

nginx میں client_max_body_size کی default value 1 MB ہے۔ اس لیے اس line کے بغیر attachment upload ناکام ہو جاتا ہے۔ nginx error log میں 413 Request Entity Too Large ظاہر ہوتا ہے، جبکہ Vaultwarden کوئی log بھی نہیں لکھتا۔ Upgrade اور Connection headers WebSocket handshake کو /notifications/hub تک پہنچاتے ہیں۔ اگر یہ headers نہ ہوں تو vault پھر بھی کام کرتا رہتا ہے، لیکن دوسرے devices پر تبدیلیاں اس وقت تک ظاہر نہیں ہوتیں جب تک page کو دستی طور پر reload نہ کریں۔

Caddy کی configuration مختصر ہے اور یہ خود certificate حاصل کر لیتا ہے:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

اس کے بعد Vaultwarden کو اس کے بارے میں بتائیں:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER کی default value پہلے ہی X-Real-IP ہے۔ اس لیے ضروری ہے کہ proxy واقعی یہ header set کرے۔ اگر ایسا نہ ہو تو ہر log line اور ہر login rate limit میں 127.0.0.1، یعنی خود proxy، نظر آئے گا۔ اس کا مطلب ہے کہ ایک attacker کی ناکام کوششیں instance کے ہر user کے خلاف شمار ہوں گی۔ DOMAIN کو اصل https URL پر بھی set کریں، کیونکہ Vaultwarden invitation اور password reset links اسی سے بناتا ہے، اور WebAuthn security keys اسی origin کے ساتھ bind ہوتی ہیں۔

ایک تفصیل اکثر نظرانداز ہو جاتی ہے: WebSocket connection session token کو query string میں /notifications/hub?access_token=[JWT] کے طور پر بھیجتا ہے۔ یہ token آپ کے proxy access log میں واضح حالت میں درج ہو جاتا ہے۔ log format میں access_token parameter کو redact کریں، یا یقینی بنائیں کہ یہ logs ایسی جگہ نہ بھیجے جائیں جس پر آپ کا کنٹرول نہیں ہے۔

لاگ اِن endpoint پر brute force حملے روکیں

Rate limits پہلے سے فعال ہوتے ہیں (LOGIN_RATELIMIT_SECONDS=60، LOGIN_RATELIMIT_MAX_BURST=10)۔ یہ حملہ آور کی رفتار کم کرتے ہیں۔ لیکن ایک حملہ آور کو مکمل طور پر نہیں روکتے۔ یہ کام fail2ban کرتا ہے، مگر پہلے Vaultwarden کو log file میں اندراج کرنا ہوگا، اور یہ کام وہ default طور پر نہیں کرتا:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

ناکام لاگ اِن کے بعد بالکل ایک لائن درج ہوتی ہے، اور آپ کے filter کو اسی string سے match کرنا ہوگا:

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

filter کو /etc/fail2ban/filter.d/vaultwarden.local میں لکھیں:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

اور jail کو /etc/fail2ban/jail.d/vaultwarden.local میں لکھیں:

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

اگر آپ نے admin page برقرار رکھا ہے تو ایک دوسری jail شامل کریں، جس کا failregex، ^.*Invalid admin token\. IP: <ADDR>.*$ ہو، کیونکہ admin کی ناکام کوششیں مختلف message کے ساتھ log ہوتی ہیں اور login filter انہیں کبھی نہیں دیکھے گا۔ پھر اپنی configuration کی جانچ کریں:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

فعال jail اپنی log file کو File list کے تحت دکھاتی ہے اور Currently failed: 0 رپورٹ کرتی ہے۔ مختلف network سے غلط password تین بار درج کریں۔ یہ counter بڑھ جائے گا، پھر address Banned IP list کے تحت ظاہر ہوگا۔ اگر counter کبھی نہ بڑھے تو عام وجہ logpath ہوتی ہے۔ اس میں host پر موجود file کا path ہونا چاہیے، container کے اندر موجود /data/... path نہیں۔ دوسری عام وجہ X-Real-IP کا نہ ہونا ہے، جس کی وجہ سے ہر ban آپ کے اپنے proxy کو target کرتا ہے۔ باقی setup، جس میں SSH jail بھی شامل ہے جو اس وقت تک چل رہی ہونی چاہیے، Ubuntu 24.04 کے لیے fail2ban guide میں موجود ہے۔

ماسٹر پاس ورڈ اب بھی پورے نظام کی بنیاد ہے

Client-side encryption میں ماسٹر پاس ورڈ ہی key ہوتا ہے۔ اگر کسی instance کا database attacker نے copy کر لیا ہو تو مختصر ماسٹر پاس ورڈ کو اس تحریر میں دی گئی کوئی بھی چیز محفوظ نہیں کرتی، کیونکہ attacker اس copy پر offline attack اپنی hardware کی اجازت والی رفتار سے کر سکتا ہے۔ کوئی بھی server setting attacker کی اپنی machine تک نہیں پہنچتی۔

PASSWORD_ITERATIONS=600000 وہ KDF iteration count ہے جو نئے account بنانے کے وقت clients کو دیا جاتا ہے۔ موجودہ accounts وہی value رکھتے ہیں جس کے ساتھ انہیں بنایا گیا تھا، اس لیے اسے بڑھانے سے ان users کے لیے کچھ تبدیل نہیں ہوتا جنہوں نے گزشتہ سال sign up کیا تھا۔ انہیں web vault کی security settings میں خود یہ value تبدیل کرنی ہوگی، جس سے ان کی key دوبارہ encrypt ہو جاتی ہے۔ انہیں اس بارے میں بتائیں، کیونکہ interface میں اس کا کوئی اشارہ نہیں ملے گا۔

اس کے بعد ہر account کے لیے two-factor authentication فعال کریں۔ یہ ciphertext کو محفوظ نہیں کرتا، کیونکہ vault key صرف ماسٹر پاس ورڈ سے حاصل ہوتی ہے۔ تاہم، چوری شدہ پاس ورڈ سے login کرنا اور copy sync کرنا اکیلے ممکن نہیں رہتا۔ REQUIRE_DEVICE_EMAIL=true پہلی مرتبہ کسی غیر معروف device سے account میں login کرنے پر email confirmation کا مرحلہ شامل کرتا ہے۔

بیک اپ وہ جگہ ہے جہاں self-hosted vaults میں خرابیاں پیدا ہوتی ہیں

اسی VPS کی home directory میں رکھی گئی data folder کی ایک tar czf اوپر کیے گئے تمام اقدامات کو بے اثر کر دیتی ہے۔ اس archive میں ہر صارف کا ciphertext رکھنے والی db.sqlite3، login sessions forge کرنے والی rsa_key.pem، اور admin token اور SMTP password کو plaintext میں رکھنے والی config.json شامل ہوتی ہے۔ اس ایک file تک read access کا مطلب vault تک read access ہے۔

اس کے لیے دو اصول کافی ہیں۔ Archive کو اس box سے باہر منتقل کریں۔ اسے باہر بھیجنے سے پہلے encrypt کریں۔

درستگی کا بھی ایک مسئلہ ہے۔ سروس چلتے وقت cp کے ذریعے db.sqlite3 copy کرنے سے ایسی file بن سکتی ہے جس میں write کا عمل جاری ہو۔ یہ file open نہیں ہوگی، اور آپ کو اس کا علم restore کے وقت ہوگا۔ اس کے بجائے SQLite کا اپنا snapshot استعمال کریں:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

Restore والا مرحلہ، جسے عموماً کوئی test نہیں کرتا، Vaultwarden backup اور restore guide میں بیان کیا گیا ہے۔

میزبان شدہ Bitwarden کے مقابلے میں آپ کو کن چیزوں سے دست بردار ہونا پڑتا ہے

دیانت دارانہ جائزہ۔ Bitwarden کی میزبان شدہ سروس ایسے افراد چلاتے ہیں جن کا کل وقتی کام ہی اسے چلانا ہے۔ اس کے تیسرے فریق کے شائع شدہ آڈٹ ہوتے ہیں، اور کوئی نہ کوئی شخص رات 3 بجے بھی ہنگامی ذمہ داری پر موجود ہوتا ہے۔ Self-hosting کے بعد یہ ذمہ داری آپ کے اپنے patch schedule پر منتقل ہو جاتی ہے۔

Vaultwarden سکیورٹی fixes عام releases کے طور پر جاری کرتا ہے۔ 24 July 2026 کو جاری ہونے والا Version 1.37.0، August 2026 تک موجودہ version ہے، اور اس کے notes صارفین سے جلد از جلد update کرنے کو کہتے ہیں۔ جو instance آپ نے ایک سال پہلے setup کیا تھا اور پھر بھلا دیا، وہ ایک سال پرانا code چلا رہا ہے۔ latest tag اکیلا کافی نہیں: running container اسی image کو استعمال کرتا رہتا ہے جس کے ساتھ وہ شروع ہوا تھا، جب تک آپ docker compose pull نہ چلائیں اور اسے دوبارہ create نہ کریں۔ Host packages کے لیے Ubuntu پر unattended upgrades فعال کریں، اور container update کے لیے ایسا calendar reminder مقرر کریں جسے آپ واقعی پڑھیں گے۔

ایک دیانت دار قاری کو یہ نتیجہ اخذ کرنا چاہیے: یہاں cryptography Bitwarden کے design پر مبنی ہے اور یہ مضبوط ہے، جبکہ operational risk مکمل طور پر آپ کی ذمہ داری بن جاتا ہے۔ اگر آپ اسے patch کرتے ہیں اور کسی دوسری جگہ backup رکھتے ہیں، تو آپ کے زیرِ انتظام VPS پر Vaultwarden instance اپنے passwords رکھنے کے لیے ایک معقول جگہ ہے۔ اگر یہ دونوں عادات اپنانا ممکن نہیں، تو hosted service کی ادائیگی کریں اور اپنی توجہ کسی اور کام پر صرف کریں۔ ہر feature کا تقابلی جائزہ Vaultwarden کا self-hosted Bitwarden سے موازنہ میں موجود ہے۔

کنٹینر کے نیچے موجود میزبان کو محفوظ بنائیں

Vaultwarden ایک Linux box پر چلنے والا ایک process ہے، اور اس box پر موجود root، application کی configuration کچھ بھی ہو، /vw-data پڑھ سکتا ہے۔ اپنی compose file میں user: "1000:1000" کے ذریعے container کو غیر مراعات یافتہ user کے طور پر چلائیں، data folder کی ownership بھی اسی کے مطابق رکھیں، اور جس چیز میں container کو لکھنے کی ضرورت نہ ہو اسے :ro کے ذریعے read-only mount کریں۔ پھر بیرونی رسائی کا راستہ بند کریں: VPS پر SSH hardening میں صرف key کے ذریعے login اور password authentication کو disable کرنے کا طریقہ بیان کیا گیا ہے۔ یہی اقدامات اس عام حملے کو روکتے ہیں جو مذکورہ تمام حفاظتی اقدامات سے گزر جاتا ہے۔

FAQ

کیا Vaultwarden database چوری ہونے پر کوئی میرے passwords پڑھ سکتا ہے؟

براہِ راست نہیں۔ ہر vault item کو client میں master password سے اخذ کردہ key کے ذریعے encrypt کیا جاتا ہے، اس لیے db.sqlite3 میں ciphertext موجود ہوتا ہے۔ حملہ آور کو فوری طور پر ہر account کا email address، KDF settings، login اور device metadata، اور twofactor table میں موجود two-factor secrets ملتے ہیں۔ یہ secrets unencrypted stored ہوتے ہیں، کیونکہ server کو expected code compute کرنا ہوتا ہے۔ حملہ آور vault ciphertext پر offline attack بھی اپنی مرضی تک جاری رکھ سکتا ہے۔ اسی لیے master password کی length نتیجے کا فیصلہ کرنے والا اہم عامل ہے۔

کیا مجھے ADMIN_TOKEN استعمال کرنا چاہیے یا admin page مکمل طور پر disable کر دینا چاہیے؟

اگر ممکن ہو تو اسے disable کر دیں، کیونکہ زیادہ تر instances کو SMTP configure کرنے اور users کو invite کرنے کے لیے یہ صرف ایک بار درکار ہوتا ہے۔ اسے disable کرنے کے لیے نہ ADMIN_TOKEN set کریں نہ DISABLE_ADMIN_TOKEN، config.json سے ہر "admin_token" key remove کریں، پھر container دوبارہ create کریں۔ صرف environment variable remove کرنا کافی نہیں، کیونکہ admin page سے لکھی گئی settings config.json میں موجود رہتی ہیں اور انہیں precedence حاصل ہوتی ہے۔ اگر page فعال رکھیں تو token کو plaintext random string کے بجائے vaultwarden hash سے تیار کردہ Argon2 hash کے طور پر store کریں، اور ADMIN_RATELIMIT_MAX_BURST=3 set کریں۔

میرا ADMIN_TOKEN درست ہے، لیکن /admin اسے reject کرتا ہے۔ مسئلہ کیا ہے؟

تقریباً ہمیشہ مسئلہ $ interpolation کا ہوتا ہے۔ Argon2 PHC string میں کئی $ characters ہوتے ہیں، اور Docker Compose انہیں docker-compose.yml environment: block کے اندر variables کے طور پر expand کرتا ہے۔ اس کے نتیجے میں container کو mangled value ملتی ہے، اگرچہ file درست دکھائی دیتی ہے۔ Compose file میں ہر $ کو $$ کر دیں، یا value کو single quotes میں لپٹی ہوئی .env file میں منتقل کریں، جہاں escaping کی ضرورت نہیں ہوتی۔ اس کے بعد container دوبارہ create کریں، کیونکہ restart کے بعد environment changes لاگو نہیں ہوتیں۔

کیا notifications کے لیے اب بھی port 3012 کھولنا ضروری ہے؟

نہیں۔ Vaultwarden 1.31.0 میں port 3012 پر WebSocket traffic کی support ختم کر دی گئی، کیونکہ notifications کو main HTTP port پر منتقل کر دیا گیا تھا، اور WEBSOCKET_ENABLED اور WEBSOCKET_PORT کو 1.29.0 سے نظرانداز کیا جا رہا ہے۔ موجودہ setting ENABLE_WEBSOCKET ہے، جو default طور پر true ہوتی ہے۔ Firewall میں 3012 بند کریں اور اسے اپنی compose file سے delete کریں۔ اس کے بعد یقینی بنائیں کہ reverse proxy Upgrade اور Connection headers forward کرتا ہے، کیونکہ اب real-time sync اسی پر منحصر ہے۔