Vaultwarden सुरक्षित आहे का? सुरक्षा मजबूत करण्याची यादी

Vaultwarden सुरक्षित आहे का? थोडक्यात उत्तर

Vaultwarden सर्वात महत्त्वाच्या ठिकाणी सुरक्षित आहे, कारण प्रत्येक vault item सर्व्हरवर पोहोचण्यापूर्वी तुमच्या device वर encrypt केला जातो. सर्व्हर असे blobs साठवतो जे तो वाचू शकत नाही. एखाद्याने संपूर्ण database ची प्रत घेतली तरी त्यातून उपयुक्त माहिती मिळवण्यासाठी त्याला master password आवश्यक असेल.

या उत्तरात अनेक बाबी गृहीत धरल्या आहेत. प्रत्यक्षात बिघाड तुम्ही केलेल्या configuration मुळे होतो. सहज अंदाज लावता येणाऱ्या token मागे ठेवलेले admin panel. संपूर्ण internet साठी प्रकाशित केलेला container port. Plaintext config.json. त्याच box वरील home directory मध्ये ठेवलेला backup tarball. यापैकी कोणतीही बाब cryptography ची समस्या नाही. Self-hosted vaults रिकामे होण्याचे कारण या सर्व बाबी आहेत.

खालील सर्व माहिती कार्यरत install गृहीत धरते. तुमच्याकडे अद्याप install नसेल, तर आधी VPS साठी Vaultwarden install guide वापरून ते सेट करा. त्यानंतर या यादीवर क्रमाने पुढे जा.

सर्व्हर प्रत्यक्षात काय साठवतो

Vaultwarden, Bitwarden चे data model वापरतो. vault item चे नाव, username, password, notes आणि URIs हे कोणतीही request पाठवण्यापूर्वी client मध्ये तुमच्या master password पासून तयार केलेल्या key ने encrypt केले जातात. Attachment file contents देखील याच पद्धतीने encrypt केले जातात. सर्व्हरला UUID (universally unique identifier) जोडलेला opaque data मिळतो.

काही गोष्टी ciphertext नसतात. त्यापैकी नेमक्या कोणत्या आहेत हे समजून घेणे आवश्यक आहे:

• तुमचा account email address plaintext स्वरूपात.
• तुमची KDF (key derivation function) settings आणि salt, कारण पुढील login वेळी key पुन्हा तयार करण्यासाठी client ला त्यांची आवश्यकता असते.
• login चे authentication करण्यासाठी client कडून पाठवलेल्या master password hash चा server-side hash.
• Metadata: organisation membership, device names, last login times.
• Vaultwarden login चे संरक्षण करणाऱ्या two-factor method साठीचे secret. ते twofactor table मध्ये unencrypted स्वरूपात असते, कारण तुमच्याशी तुलना करण्यासाठी अपेक्षित code मोजणे सर्व्हरला आवश्यक असते. हे vault item मध्ये साठवलेल्या TOTP (time-based one-time password) secret सारखे नाही. इतर कोणत्याही field प्रमाणे ते encrypted असते.

Data folder लहान असतो. Docker install मध्ये तो /data येथे तुम्ही mount केलेला folder असतो.

sudo ls -l /vw-data/

db.sqlite3 मध्ये जवळजवळ संपूर्ण state असतो. attachments/ मध्ये upload केलेल्या files असतात; प्रत्येक file एका UUID शी संबंधित असते. Database tables मध्ये नसलेल्या महत्त्वाच्या data पैकी हा एकमेव प्रकार आहे. sends/ मध्ये Send attachments असतात आणि हा folder temporary असण्यासाठीच आहे. icon_cache/ मधील data टाकून देता येतो. rsa_key.pem आणि त्याच्यासोबतच्या files logged-in users चे JWTs (JSON web tokens) sign करतात. त्यामुळे त्या private key ची copy वापरून बनावट vault login session तयार करता येते. Admin page enable केल्यानंतरच config.json तयार होते. प्रकल्पाच्या स्पष्ट वर्णनानुसार, त्यात admin token आणि तुमचे SMTP credentials plaintext स्वरूपात असतात.

त्यामुळे व्यावहारिक threat model network cryptography नसून filesystem access हा आहे. त्या एका directory साठी read access मिळाल्यास प्रत्येक user चा email address, त्यांचे login 2FA secrets, sessions बनावट तयार करण्यासाठी वापरता येणारी key आणि प्रत्येक vault ची offline copy मिळते. त्यानंतर ती माहिती तुमच्या सोयीने तपासता किंवा crack करण्याचा प्रयत्न करता येतो. खालील प्रत्येक पायरीचा उद्देश लोकांना त्या directory पासून दूर ठेवणे हा आहे.

प्रशासकीय टोकन प्रथम सुरक्षित करा

/admin हे संपूर्ण नियंत्रण पटल आहे: वापरकर्त्यांची यादी, आमंत्रणे, हटवणे आणि प्रत्येक runtime setting. ते फक्त एका सामायिक secret ने सुरक्षित आहे. त्याशिवाय कोणतेही संरक्षण नाही. username नाही. प्रत्येक वापरकर्त्यासाठी स्वतंत्र two-factor authentication नाही.

जुन्या मार्गदर्शकांमध्ये openssl rand -base64 48 वापरून ADMIN_TOKEN तयार करण्यास सांगितले जाते. ते कार्य करते. मात्र, त्यामुळे secret साध्या मजकुरात config.json आणि तुमच्या compose file मध्ये लिहिला जातो. Vaultwarden Argon2 PHC (password hashing competition) string देखील स्वीकारते. त्यामुळे साठवलेली value hash असते. चालू container विरुद्ध ती तयार करा:

docker exec -it vaultwarden /vaultwarden hash

किंवा चालू container ला स्पर्श न करता:

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

यात password दोनदा विचारला जातो. त्यानंतर $argon2id$ ने सुरू होणारी ओळ छापली जाते. bare-metal install वर ./vaultwarden hash चालवा. तुम्हाला argon2 CLI थेट वापरायचा असल्यास, project मध्ये OWASP चे किमान parameters दिले आहेत:

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

आता एका तासाचा त्रास देणारा मुद्दा पाहू. PHC string मध्ये अनेक $ characters असतात. Docker Compose $ ला variable interpolation म्हणून हाताळते. ते unescaped स्वरूपात environment: block मध्ये paste केल्यास container पर्यंत पोहोचणारी value बदलते. त्यामुळे /admin बरोबर असलेले token नाकारते. यासाठी दोन सुरक्षित पद्धती आहेत. 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

पाच मिनिटांच्या आत तीन अयशस्वी प्रयत्न झाल्यास त्या client ला panel उत्तर देणे थांबवते. 20 मिनिटे कोणतीही activity नसल्यास admin session संपते.

यापेक्षा चांगला उपाय म्हणजे हे page बंद करणे. बहुतेक instances मध्ये SMTP configure करण्यासाठी आणि पहिले users invite करण्यासाठी ते एकदाच आवश्यक असते. त्यानंतर त्याची गरज नसते. ते disable करण्यासाठी ADMIN_TOKEN किंवा DISABLE_ADMIN_TOKEN पैकी कोणतेही सेट करू नका. config.json मधून कोणतीही "admin_token" key काढून टाका. त्यानंतर container पुन्हा तयार करा. 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 तुमच्या data प्रमाणेच db.sqlite3 मध्ये साठवला जातो. ते false वर सेट करा आणि admin page वरील invitations द्वारे लोकांना जोडा. यासाठी कार्यरत 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 मध्ये वैध email address टाइप केल्यावर त्या account चा master password hint दिसतो. त्यामुळे hint उघड होतो आणि तो address अस्तित्वात असल्याची पुष्टीही होते.

तुमच्या instance वर कोणत्याही कालावधीसाठी signups खुले असतील, तर तुम्ही त्यावर एकमेव account आहात असे गृहीत धरण्यापूर्वी admin page उघडा आणि user list तपासा.

तुम्हाला प्रकाशित करायचा नव्हता तो पोर्ट

Docker image कंटेनरमध्ये port 80 वर ऐकते. Bare-metal install मध्ये डिफॉल्टनुसार ROCKET_PORT=8000 वापरले जाते. दस्तऐवजीकरणातील run command हा port अशा प्रकारे publish करते:

--publish 127.0.0.1:8000:80

127.0.0.1: हा prefix अत्यावश्यक आहे. त्याऐवजी -p 8000:80 लिहिल्यास Docker 0.0.0.0 bind करते. हे करण्यासाठी Docker nat table मध्ये DNAT (destination network address translation) नियम लिहिते. हे नियम ufw व्यवस्थापित करत असलेल्या filter chains च्या आधी evaluate होतात. त्यामुळे ufw status port denied असल्याचे दाखवते, परंतु तो port इंटरनेटवरून प्रत्यक्ष प्रतिसाद देत राहतो. या संपूर्ण यंत्रणेबद्दल ufw ला bypass करणाऱ्या Docker ports वरील मार्गदर्शकात सविस्तर वाचा.

प्रत्यक्षात कोणते ports listening आहेत ते तपासा:

sudo ss -tlnp | grep 8000

निरोगी परिणामात 127.0.0.1:8000 ला bind असलेली एकच ओळ दिसते. 0.0.0.0:8000 ला bind असलेली ओळ म्हणजे vault थेट exposed आहे. Mapping दुरुस्त करा आणि त्यानंतर container पुन्हा तयार करा. Container तयार करताना port binding निश्चित होते आणि docker compose restart ती बदलणार नाही:

docker compose up -d --force-recreate

जुन्या मार्गदर्शकांमध्ये आणखी एक port आढळतो: 3012, हा स्वतंत्र WebSocket port आहे. Vaultwarden 1.31.0 मध्ये त्याचे support काढून टाकण्यात आले, कारण notification traffic मुख्य HTTP port वर हलवण्यात आला. WEBSOCKET_ENABLED आणि WEBSOCKET_PORT कडे 1.29.0 पासून दुर्लक्ष केले जात आहे. सध्याचा switch ENABLE_WEBSOCKET आहे आणि त्याचे default मूल्य true आहे. तुमच्या firewall किंवा compose file मध्ये अजूनही 3012 उघडलेला असल्यास, तो बंद करा.

reverse proxy वर TLS terminate करा, Rocket मध्ये नाही

Vaultwarden स्वतः Rocket या web framework द्वारे TLS (transport layer security) देऊ शकते. परंतु production मध्ये असे करू नका, असे प्रकल्पाच्या सूचनांमध्ये स्पष्टपणे सांगितले आहे. Rocket च्या built-in TLS मध्ये strict SNI (server name indication) support नाही. म्हणूनच hardening सल्ल्यानुसार तुमच्या instance ला hostname द्वारे access करा आणि कधीही थेट bare IP address द्वारे access करू नका. Public IP ranges सतत scan केले जातात. IP address वर प्रतिसाद देणारा vault सहज शोधला जातो.

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 मर्यादा 1 MB असते. त्यामुळे ती line नसल्यास attachment upload fail होतो. nginx error log मध्ये 413 Request Entity Too Large दिसते, परंतु Vaultwarden मध्ये कोणतीही log entry तयार होत नाही. Upgrade आणि Connection headers WebSocket handshake /notifications/hub कडे पाठवतात. ते काढून टाकल्यास vault चालू राहतो. मात्र page manually reload करेपर्यंत इतर devices वर बदल दिसत नाहीत.

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 मूल्य आधीच X-Real-IP असते. त्यामुळे proxy ने तो header प्रत्यक्षात set केला आहे याची खात्री करणे हे काम आहे. तसे न केल्यास प्रत्येक log line आणि प्रत्येक login rate limit मध्ये 127.0.0.1, म्हणजे proxy स्वतः, दिसेल. त्यामुळे एखाद्या attacker च्या login failures ची गणना instance वरील प्रत्येक user विरुद्ध केली जाईल. DOMAIN मध्ये वास्तविक https URL देखील set करा. Vaultwarden त्यावरून invitation आणि password reset links तयार करते. WebAuthn security keys देखील त्या origin शी बांधलेल्या असतात.

लोकांकडून अनेकदा दुर्लक्षित होणारा एक तपशील असा आहे: WebSocket connection session token query string मध्ये /notifications/hub?access_token=[JWT] म्हणून पाठवते. त्यामुळे तो 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 मध्ये नोंद लिहिणे आवश्यक आहे. ही सुविधा out of the box उपलब्ध नसते:

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

अयशस्वी लॉगिननंतर नेमकी एक ओळ तयार होते. तुमच्या filter ने जुळवायची string ही आहे:

[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 ठेवले असल्यास, failregex चे मूल्य ^.*Invalid admin token\. IP: <ADDR>.*$ असलेली दुसरी jail जोडा. Admin वरील अपयशांची नोंद वेगळ्या message सह केली जाते. त्यामुळे login filter त्यांना कधीही शोधणार नाही. त्यानंतर configuration तपासा:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

योग्यरीत्या कार्यरत jail मध्ये File list अंतर्गत तुमची log file दिसते आणि Currently failed: 0 अशी स्थिती दिसते. वेगळ्या network वरून चुकीचा password तीन वेळा टाका. त्यानंतर तो counter वाढतो आणि address Banned IP list अंतर्गत दिसतो. Counter कधीही वाढत नसेल, तर नेहमीचे कारण logpath असते. येथे host वरील file चा path असणे आवश्यक आहे; container मधील /data/... path नसावा. दुसरे सामान्य कारण म्हणजे X-Real-IP नसणे. त्यामुळे प्रत्येक ban तुमच्या स्वतःच्या proxy ला लागू होतो. SSH jail सह उर्वरित setup, जी तुम्ही आधीच चालू ठेवलेली असावी, Ubuntu 24.04 साठी fail2ban मार्गदर्शक मध्ये दिले आहे.

मास्टर पासवर्ड अजूनही संपूर्ण प्रणालीची सुरक्षा ठरवतो

Client-side encryption मध्ये master password हाच key असतो. ज्या instance चा database हल्लेखोराने कॉपी केला आहे, तिथे लहान master password चे संरक्षण या लेखातील कोणत्याही उपायाने होत नाही. हल्लेखोर त्या कॉपीवर offline पद्धतीने, त्याच्या hardware च्या क्षमतेनुसार, कितीही वेगाने हल्ला करू शकतो. हल्लेखोराच्या स्वतःच्या machine वर कोणतीही server setting प्रभाव टाकू शकत नाही.

PASSWORD_ITERATIONS=600000 हा client ने नवीन account तयार करताना वापरायचा KDF iteration count आहे. Existing accounts मध्ये account तयार करताना वापरलेली valueच राहते. त्यामुळे गेल्या वर्षी sign up केलेल्या users साठी ही value वाढवल्याने काहीही बदलत नाही. त्यांनी web vault मधील security settings मध्ये स्वतः ती बदलली पाहिजे. त्यामुळे त्यांची key पुन्हा encrypt केली जाते. त्यांना हे स्पष्टपणे सांगा, कारण interface स्वतःहून याची सूचना देणार नाही.

त्यानंतर प्रत्येक account साठी two-factor authentication enable करा. यामुळे ciphertext सुरक्षित होत नाही, कारण vault key केवळ master password मधून तयार होते. मात्र चोरीला गेलेला password वापरून login करून copy sync करणे यामुळे थांबते. REQUIRE_DEVICE_EMAIL=true मुळे account ने प्रथमच unrecognised device वरून login केल्यावर email confirmation ची पायरी जोडली जाते.

Self-hosted vaults मध्ये backups ही बाब अनेकदा चुकीची हाताळली जाते

घराच्या directory मध्ये त्याच VPS वर ठेवलेली data folder ची tar czf वरील सर्व प्रयत्न निष्फळ ठरवते. त्या archive मध्ये प्रत्येक वापरकर्त्याचा ciphertext असलेली db.sqlite3, login sessions बनावटरीत्या तयार करता येणारी rsa_key.pem आणि admin token तसेच SMTP password plaintext स्वरूपात असलेली config.json साठवलेली असते. त्या एका file ला read access मिळणे म्हणजे vault ला read access मिळणे होय.

दोन नियम पुरेसे आहेत. Archive त्या box च्या बाहेर ठेवा. तो बाहेर पाठवण्यापूर्वी encrypt करा.

यामध्ये correctness ची समस्याही आहे. सेवा सुरू असताना cp वापरून db.sqlite3 ची copy केल्यास write प्रक्रिया अर्धवट असलेली file तयार होऊ शकते. ती file उघडणार नाही. Restore करेपर्यंत हे लक्षात येणार नाही. त्याऐवजी SQLite चा स्वतःचा snapshot वापरा:

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

Restore ची बाजू, जिची कोणीही चाचणी घेत नाही, Vaultwarden backup आणि restore मार्गदर्शकात समाविष्ट केली आहे.

होस्ट केलेल्या Bitwarden च्या तुलनेत तुम्ही पुढे काय सोडता

प्रामाणिकपणे विचार करा. Bitwarden ची hosted सेवा अशा लोकांकडून चालवली जाते ज्यांचे पूर्णवेळ काम ती चालवणे आहे. तिचे तृतीय-पक्ष audit अहवाल प्रकाशित केलेले असतात आणि पहाटे 3 वाजताही कोणीतरी on-call असते. Self-hosting केल्यावर ही जबाबदारी तुमच्या स्वतःच्या patch cadence वर येते.

Vaultwarden security fixes नेहमीच्या releases म्हणून जारी करते. 24 July 2026 रोजी release झालेली Version 1.37.0 ही August 2026 पर्यंतची current आवृत्ती आहे. तिच्या notes मध्ये users ना शक्य तितक्या लवकर update करण्यास सांगितले आहे. तुम्ही वर्षभरापूर्वी setup केलेले आणि नंतर विसरलेले instance वर्षभर जुना code चालवत असते. latest tag स्वतःहून उपयोगी ठरत नाही: running container सुरू होताना वापरलेली image तशीच ठेवते, जोपर्यंत तुम्ही docker compose pull चालवून ते पुन्हा recreate करत नाही. Host packages साठी Ubuntu वर unattended upgrades लागू करा. Container update साठी तुम्ही प्रत्यक्षात पाहाल अशी calendar reminder सेट करा.

प्रामाणिक वाचकाने असा निष्कर्ष काढावा: येथील cryptography ही Bitwarden ची design आहे आणि ती सक्षम आहे. मात्र operational risk पूर्णपणे तुमच्यावर येतो. तुम्ही त्याला patch करत असाल आणि backup दुसऱ्या ठिकाणी ठेवत असाल, तर तुमच्या नियंत्रणातील VPS वरील Vaultwarden instance हे passwords ठेवण्यासाठी योग्य ठिकाण आहे. या दोन सवयी पाळल्या जाणार नसतील, तर hosted सेवा घेण्यासाठी पैसे द्या आणि तुमचे लक्ष इतर कामांकडे द्या. Feature-by-feature comparison Vaultwarden ची self-hosted Bitwarden सोबत तुलना येथे आहे.

कंटेनरच्या अंतर्गत होस्टला सुरक्षित करा

Vaultwarden ही Linux मशीनवरील एक process आहे. त्या मशीनवरील root खाते अनुप्रयोगाची configuration काहीही असली तरी /vw-data वाचू शकते. तुमच्या compose file मध्ये user: "1000:1000" वापरून container unprivileged user म्हणून चालवा. Data folder च्या मालकीचे अधिकारही त्यानुसार ठेवा. Container ने लिहायचे नसलेले सर्व काही :ro वापरून read only म्हणून mount करा. आता बाहेरील प्रवेशमार्ग सुरक्षित करा: VPS वरील SSH hardening मध्ये केवळ key वापरून login आणि password authentication बंद करणे समाविष्ट आहे. यामुळे वरील सर्व उपायांनंतरही होणारा सामान्य हल्ला रोखला जातो.

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 मिळतात. Server ला अपेक्षित code मोजता यावा म्हणून हे secrets unencrypted स्वरूपात साठवलेले असतात. ते vault ciphertext वर offline attack कितीही काळ करू शकतात. म्हणून master password ची length हा परिणाम ठरवणारा मुख्य घटक आहे.

मी ADMIN_TOKEN वापरावा का, की admin page पूर्णपणे disable करावे?

शक्य असल्यास ते disable करा. बहुतेक instances मध्ये SMTP configure करण्यासाठी आणि users ना invite करण्यासाठी admin page एकदाच लागते; त्यानंतर ती पुन्हा वापरली जात नाही. ते disable करण्यासाठी ADMIN_TOKEN आणि DISABLE_ADMIN_TOKEN पैकी काहीही set करू नका, config.json मधील कोणतीही "admin_token" key काढून टाका आणि त्यानंतर container पुन्हा तयार करा. फक्त environment variable काढणे पुरेसे नाही, कारण admin page ने लिहिलेल्या settings config.json मध्ये साठवल्या जातात आणि त्यांना precedence मिळते. Page सुरू ठेवायची असल्यास token plain-text random string म्हणून न ठेवता vaultwarden hash ने तयार केलेला Argon2 hash म्हणून साठवा आणि ADMIN_RATELIMIT_MAX_BURST=3 set करा.

माझा ADMIN_TOKEN योग्य आहे, पण /admin तो नाकारते. काय चूक आहे?

बहुतेक वेळा कारण $ interpolation असते. Argon2 PHC string मध्ये अनेक $ characters असतात. Docker Compose त्यांना docker-compose.yml environment: block मधील variables म्हणून expand करते. त्यामुळे तुमची file योग्य दिसत असली तरी container ला बदललेली value मिळते. Compose file मध्ये प्रत्येक $ चे रूपांतर $$ मध्ये करा किंवा value .env file मध्ये single quotes मध्ये ठेवा. अशा प्रकारे escaping आवश्यक राहत नाही. त्यानंतर container पुन्हा तयार करा, कारण restart केल्यावर environment मधील बदल लागू होत नाहीत.

Notifications साठी port 3012 अजूनही open करावा लागतो का?

नाही. Vaultwarden 1.31.0 मध्ये port 3012 वरील WebSocket traffic चे support काढून टाकण्यात आले, कारण notifications मुख्य HTTP port वर हलवण्यात आले. WEBSOCKET_ENABLED आणि WEBSOCKET_PORT हे 1.29.0 पासून दुर्लक्षित केले जातात. सध्याची setting ENABLE_WEBSOCKET आहे आणि तिची default value true आहे. Firewall मध्ये 3012 बंद करा आणि तुमच्या compose file मधून तो काढून टाका. त्यानंतर reverse proxy Upgrade आणि Connection headers forward करतो याची खात्री करा, कारण real-time sync आता यावरच अवलंबून आहे.