Vaultwarden güvenli mi? Kapsamlı güvenlik rehberi

Vaultwarden güvenli midir? Kısa cevap

Vaultwarden, en önemli noktada güvenlidir; çünkü her kasa öğesi sunucuya ulaşmadan önce cihazınızda şifrelenir. Sunucu, içeriğini okuyamadığı veri bloklarını saklar. Veritabanının tamamını kopyalayan bir kişi, anlamlı bir veriye ulaşmak için yine de ana parolaya ihtiyaç duyar.

Bu cevap oldukça kapsamlıdır; ancak sistemin zayıf noktaları sizin yapılandırdığınız kısımlardır. Tahmin edilebilir bir token ile korunan bir yönetici paneli, tüm internete açık bir container portu, düz metin halindeki bir config.json veya aynı sunucunun ana dizininde duran bir yedekleme arşivi. Bunların hiçbiri kriptografi sorunu değildir. Tüm bunlar, self-hosted kasaların boşaltılmasının temel nedenleridir.

Aşağıdaki her şey, çalışan bir kurulum varsayar. Eğer henüz bir kurulumunuz yoksa, önce VPS için Vaultwarden kurulum rehberi ile kurulumu tamamlayın, ardından geri dönüp bu listeyi sırasıyla uygulayın.

Sunucunun gerçekte depoladığı veriler

Vaultwarden, Bitwarden'ın veri modelini uygular. Bir kasa öğesinin adı, kullanıcı adı, parolası, notları ve URI'leri, herhangi bir istek gönderilmeden önce istemci tarafında ana parolanızdan türetilen bir anahtarla şifrelenir. Ek dosya içerikleri de aynı şekilde şifrelenir. Sunucu, kendisine eklenmiş bir UUID (evrensel benzersiz tanımlayıcı) ile birlikte opak veriler alır.

Bazı veriler şifreli metin değildir ve tam olarak hangilerinin şifreli olmadığını bilmeniz gerekir:

• Hesap e-posta adresiniz, düz metin olarak.
• KDF (anahtar türetme işlevi) ayarlarınız ve tuz (salt) değeriniz; çünkü istemcinin bir sonraki girişte anahtarı yeniden oluşturması için bunlara ihtiyacı vardır.
• İstemcinin gönderdiği ana parola özetinin sunucu tarafındaki özeti; giriş işleminin kimliğini doğrulamak için kullanılır.
• Meta veriler: organizasyon üyeliği, cihaz adları, son giriş zamanları.
• Vaultwarden girişini koruyan iki faktörlü kimlik doğrulama yönteminin gizli anahtarı. Bu veri twofactor tablosunda şifrelenmemiş olarak tutulur, çünkü sunucunun sizin girdiğiniz kodla karşılaştırmak için beklenen kodu hesaplaması gerekir. Bu, bir kasa öğesinin içinde sakladığınız ve diğer tüm alanlar gibi şifrelenmiş olan TOTP (zamana dayalı tek kullanımlık parola) gizli anahtarından farklıdır.

Veri klasörü küçüktür. Docker kurulumunda bu, /data dizinine bağladığınız yerdir.

sudo ls -l /vw-data/

db.sqlite3, durum bilgisinin neredeyse tamamını tutar. attachments/, UUID başına bir tane olacak şekilde yüklenen dosyaları tutar ve veritabanı tablolarında bulunmayan tek önemli veri sınıfıdır. sends/, Send eklerini tutar ve geçici olması amaçlanmıştır. icon_cache/ atılabilir verilerdir. rsa_key.pem ve eşlik eden dosyalar, giriş yapmış kullanıcıların JWT'lerini (JSON web belirteçleri) imzalar; bu nedenle bu özel anahtarın bir kopyası, bir kasa giriş oturumunu taklit etmek için kullanılabilir. config.json yalnızca yönetici sayfasını etkinleştirdiğinizde oluşur ve proje bu konuda nettir: yönetici belirtecini ve SMTP kimlik bilgilerinizi düz metin olarak tutar.

Bu nedenle pratik tehdit modeli ağ şifrelemesi değil, dosya sistemi erişimidir. Bu dizine okuma erişimi; her kullanıcının e-posta adresini, giriş 2FA gizli anahtarlarını, oturumları taklit eden bir anahtarı ve boş zamanlarda saldırılabilecek her kasanın çevrimdışı bir kopyasını ele geçirmenize olanak tanır. Aşağıdaki her adım, kişileri bu dizinden uzak tutmak için mevcuttur.

Yönetici belirtecini öncelikle düzeltin

/admin; kullanıcı listesi, davetiyeler, silme işlemleri ve tüm çalışma zamanı ayarlarını içeren tam kapsamlı bir kontrol panelidir. Bu panel, tek bir paylaşılan gizli anahtar ile korunur; başka hiçbir koruması yoktur. Kullanıcı adı bulunmaz. Kullanıcı bazlı iki faktörlü kimlik doğrulama desteklenmez.

Eski kılavuzlar, ADMIN_TOKEN değerini openssl rand -base64 48 ile oluşturmanızı önerir. Bu yöntem çalışır ancak gizli anahtarı düz metin olarak config.json dosyasına ve compose dosyanıza yazar. Vaultwarden, Argon2 PHC (password hashing competition) dizgilerini de kabul eder; bu sayede depolanan değer bir parola değil, bir hash'tir. Çalışan bir container üzerinde hash oluşturmak için:

docker exec -it vaultwarden /vaultwarden hash

Veya çalışan container'a hiç dokunmadan:

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

Sistem sizden iki kez parola ister ve ardından $argon2id$ ile başlayan bir satır çıktısı verir. Bare-metal kurulumlarda ./vaultwarden hash komutunu çalıştırın. Eğer doğrudan argon2 CLI aracını kullanmak isterseniz, proje dokümantasyonunda belirtilen OWASP minimum parametrelerini kullanın:

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

Şimdi ise kullanıcıların saatlerini kaybetmesine neden olan tuzağa gelelim. Bir PHC dizgisi çok sayıda $ karakteri içerir ve Docker Compose, $ karakterini değişken enterpolasyonu (variable interpolation) olarak işler. Eğer bu değeri kaçış karakteri kullanmadan bir environment: bloğuna yapıştırırsanız, container'a ulaşan değer bozulur ve /admin doğru olduğunu bildiğiniz belirteci reddeder. İki güvenli yöntem mevcuttur. docker-compose.yml içinde, her $ karakterini ikiye katlayın:

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

Bir .env dosyasında kaçış karakterine gerek yoktur, ancak tek tırnak kullanın:

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

Ardından panel için hız sınırlaması (rate limit) getirin ve oturum süresini kısaltın:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Beş dakika içinde üç hatalı deneme yapıldığında panel, ilgili istemciye yanıt vermeyi durdurur. Yönetici oturumu, 20 dakika boyunca işlem yapılmadığında zaman aşımına uğrar.

Tüm bunlardan daha iyi bir yöntem ise sayfayı tamamen kapatmaktır. Çoğu kurulumda bu sayfaya yalnızca SMTP ayarlarını yapılandırmak ve ilk kullanıcıları davet etmek için ihtiyaç duyulur; sonrasında sayfaya gerek kalmaz. Devre dışı bırakmak için ADMIN_TOKEN veya DISABLE_ADMIN_TOKEN değişkenlerini ayarlamayın, config.json dosyasından herhangi bir "admin_token" anahtarını kaldırın ve ardından container'ı yeniden oluşturun. Anahtarı dosyadan silmek önemlidir çünkü yönetici sayfası ayarları oraya yazar ve config.json içindeki değer, ortam değişkenlerine göre önceliklidir. Sadece değişkeni kaldırmak, sayfanın açık kalmasına neden olur.

Alan adını kimse bulmadan kayıtları kapatın

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED varsayılan olarak true değerindedir. Bu şekilde bırakırsanız alan adınıza ulaşan herkes bir hesap oluşturabilir ve verileri sizinkiyle aynı db.sqlite3 içinde saklanır. Bu ayarı false olarak değiştirin ve kullanıcıları, çalışan bir SMTP gerektiren yönetici sayfasındaki davetiyeler aracılığıyla ekleyin. INVITATIONS_ALLOWED de varsayılan olarak true durumundadır ve organizasyon sahiplerinin başkalarını davet etmesine olanak tanır. Kullanıcılarınıza güvendiğiniz durumlarda bu uygundur, ancak tek kullanıcılı bir kurulumda false olarak ayarlanmalıdır. Yalnızca belirli alan adlarından kayıt alınması isteniyorsa, SIGNUPS_DOMAINS_WHITELIST=example.com seçeneği açık kayıt sisteminden daha kısıtlayıcıdır ancak davetiye sisteminden çok daha zayıftır.

SHOW_PASSWORD_HINT varsayılan olarak false durumundadır ve bu şekilde kalmalıdır. Bu özellik açıkken, giriş formuna geçerli bir e-posta adresi yazıldığında o hesabın ana parola ipucu görüntülenir; bu durum hem ipucunun sızmasına hem de e-posta adresinin sistemde kayıtlı olduğunun doğrulanmasına neden olur.

Eğer kurulumunuz bir süre boyunca kayıt almaya açık kaldıysa, sistemde tek kullanıcı olduğunuzu varsaymadan önce yönetici sayfasını açın ve kullanıcı listesini kontrol edin.

İstemeden dışarı açtığınız port

Docker imajı, container içerisinde 80 numaralı portu dinler. Çıplak metal (bare-metal) kurulumlarda varsayılan değer ROCKET_PORT=8000 şeklindedir. Belgelenmiş çalıştırma komutu, portu şu şekilde dışarı açar:

--publish 127.0.0.1:8000:80

127.0.0.1: ön eki, konunun temelidir. Bunun yerine -p 8000:80 yazdığınızda Docker, 0.0.0.0 adresine bağlanır ve bunu nat tablosuna DNAT (hedef ağ adresi çevirisi) kuralları yazarak yapar. Bu kurallar, ufw tarafından yönetilen filter zincirlerinden önce değerlendirilir; bu nedenle ufw status portu reddedilmiş olarak raporlasa da port internete açık bir şekilde yanıt vermeye devam eder. Mekanizmanın tamamı Docker portlarının ufw'yi atlamasına dair rehber içerisinde okunmalıdır.

Gerçekte neyin dinlendiğini kontrol edin:

sudo ss -tlnp | grep 8000

Sağlıklı bir sonuç, yalnızca 127.0.0.1:8000 adresine bağlı tek bir satırdır. 0.0.0.0:8000 adresine bağlı bir satır, vault'un doğrudan dışarıya açık olduğu anlamına gelir. Eşleştirmeyi düzeltin ve ardından container'ı yeniden oluşturun; çünkü port eşleştirmesi container oluşturulduğu anda sabitlenir ve docker compose restart bunu değiştirmeyecektir:

docker compose up -d --force-recreate

Eski rehberlerde bir port daha varlığını sürdürmektedir: ayrı bir WebSocket portu olan 3012. Bildirim trafiği ana HTTP portuna taşındığı için Vaultwarden 1.31.0 sürümünde bu porta verilen destek kaldırılmıştır. WEBSOCKET_ENABLED ve WEBSOCKET_PORT parametreleri 1.29.0 sürümünden beri göz ardı edilmektedir. Mevcut anahtar ENABLE_WEBSOCKET olup varsayılan değeri true şeklindedir. Güvenlik duvarınız veya compose dosyanız hala 3012 portunu açık tutuyorsa, bu portu kapatın.

TLS termination işlemini Rocket yerine bir reverse proxy üzerinde gerçekleştirin

Vaultwarden, web çatısı olan Rocket aracılığıyla TLS (transport layer security) hizmetini kendisi sunabilir; ancak proje, üretim ortamlarında bunun yapılmamasını tavsiye eder. Rocket'in yerleşik TLS desteği, sıkı bir SNI (server name indication) desteğinden yoksundur; bu nedenle güvenlik önerileri, örneğinize hiçbir zaman çıplak IP adresi ile değil, her zaman ana bilgisayar adı (hostname) ile erişmeniz gerektiğini belirtir. Genel IP aralıkları sürekli taranır; IP adresi üzerinden yanıt veren bir kasa, keşfedilmeye açık bir kasadır.

Bir nginx sunucu bloğunun önemli kısımları şunlardır:

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 varsayılan olarak client_max_body_size değerini 1 MB olarak ayarlar; bu satır olmadan, bir eklenti yüklemesi nginx hata günlüğünde 413 Request Entity Too Large hatasıyla başarısız olurken, Vaultwarden günlüklerinde hiçbir şey görünmez. Upgrade ve Connection başlıkları, WebSocket el sıkışmasını /notifications/hub adresine taşır. Bu başlıkları kaldırırsanız kasa çalışmaya devam eder, ancak sayfayı manuel olarak yenileyene kadar değişiklikler diğer cihazlarınızda görünmez hale gelir.

Caddy daha kısa bir yapılandırmaya sahiptir ve sertifikayı kendi başına alır:

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

Ardından bu durumu Vaultwarden'a bildirin:

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

IP_HEADER zaten varsayılan olarak X-Real-IP değerindedir; bu nedenle yapılması gereken, proxy'nin bu başlığı doğru şekilde ayarladığından emin olmaktır. Eğer ayarlanmazsa, her günlük satırı ve her giriş hızı sınırlaması, proxy'nin kendisi olan 127.0.0.1 adresini görür; bu da bir saldırganın başarısızlıklarının, örnekteki tüm kullanıcıların hanesine yazılması anlamına gelir. DOMAIN değerini de gerçek https URL'sine ayarlayın; çünkü Vaultwarden davet ve parola sıfırlama bağlantılarını bu adrese göre oluşturur ve WebAuthn güvenlik anahtarları bu kaynağa (origin) bağlıdır.

İnsanların gözden kaçırdığı bir detay: WebSocket bağlantısı, oturum belirtecini (session token) sorgu dizisinde /notifications/hub?access_token=[JWT] olarak iletir. Bu veri, proxy erişim günlüğünüze açık metin olarak düşer. Günlük formatında access_token parametresini gizleyin veya bu günlüklerin kontrolünüz altında olmayan hiçbir yere gönderilmediğinden emin olun.

Giriş uç noktasında kaba kuvvet saldırılarını engelleme

Hız sınırlamaları varsayılan olarak etkindir (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Bu sınırlamalar saldırganı yavaşlatır ancak durdurmaz. fail2ban bu saldırıları durdurabilir, ancak Vaultwarden'ın öncelikle bir günlük dosyası yazması gerekir ve bu özellik varsayılan olarak etkin değildir:

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

Başarısız bir giriş denemesi tam olarak bir satır oluşturur ve filtrenizin eşleşmesi gereken dizge şudur:

[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.

Filtreyi /etc/fail2ban/filter.d/vaultwarden.local dosyasına yazın:

[INCLUDES]
before = common.conf

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

Ve jail yapılandırmasını /etc/fail2ban/jail.d/vaultwarden.local dosyasına ekleyin:

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

Eğer yönetici sayfasını tuttuysanız, failregex değeri ^.*Invalid admin token\. IP: <ADDR>.*$ olan ikinci bir jail ekleyin; çünkü yönetici hataları farklı bir mesajla günlüğe kaydedilir ve giriş filtresi bunları göremez. Ardından çalışmanızı kontrol edin:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Çalışan bir jail, günlük dosyanızı File list altında listeler ve Currently failed: 0 değerini raporlar. Farklı bir ağdan üç kez yanlış parola girin; sayaç artacak ve ardından adres Banned IP list altında görünecektir. Eğer sayaç hiç artmıyorsa, bunun yaygın nedeni logpath değeridir: bu değer, container içindeki /data/... yolu değil, ana makinedeki dosya yolu olmalıdır. İkinci yaygın neden ise eksik bir X-Real-IP ayarıdır; bu durum her engellemenin kendi proxy'nizi hedeflemesine neden olur. Halihazırda çalıştırıyor olmanız gereken SSH jail dahil olmak üzere kurulumun geri kalanı Ubuntu 24.04 için fail2ban rehberi içinde yer almaktadır.

Ana parola hala tüm sistemin temelidir

İstemci tarafında şifreleme, ana parolanın anahtar olduğu anlamına gelir. Bir saldırganın veritabanını kopyaladığı bir örnekteki kısa bir ana parola, bu yazıdaki hiçbir şey tarafından korunmaz; çünkü saldırganlar bu kopyaya kendi donanımlarının izin verdiği hızda çevrimdışı saldırı düzenlerler. Hiçbir sunucu ayarı, saldırganın kendi makinesine erişemez.

PASSWORD_ITERATIONS=600000, kullanıcılar yeni bir hesap oluşturduklarında istemcilere iletilen KDF yineleme sayısıdır. Mevcut hesaplar, oluşturuldukları sırada sahip oldukları değeri korurlar; bu nedenle bu değeri yükseltmek, geçen yıl kaydolan kullanıcılar için hiçbir şeyi değiştirmez. Kullanıcıların bunu web kasası güvenlik ayarlarından kendilerinin değiştirmesi gerekir; bu işlem anahtarlarını yeniden şifreler. Kullanıcıları bu konuda bilgilendirin, çünkü arayüzde bunu belirten hiçbir uyarı bulunmamaktadır.

Ardından her hesap için iki faktörlü kimlik doğrulamayı etkinleştirin. Bu işlem şifreli metni korumaz, çünkü kasa anahtarı yalnızca ana paroladan türetilir. Ancak çalınan bir parolanın giriş yapmak ve bir kopya eşitlemek için yeterli olmasını engeller. REQUIRE_DEVICE_EMAIL=true, bir hesap tanınmayan bir cihazdan ilk kez giriş yaptığında e-posta ile doğrulama adımı ekler.

Yedeklemeler, self-hosted kasaların hata yaptığı noktadır

Aynı VPS üzerindeki bir ev dizininde bırakılan veri klasörünün tar czf dosyası, yukarıdaki tüm adımları geçersiz kılar. Bu arşiv; her kullanıcının şifreli metnini içeren db.sqlite3 dosyasını, oturumları taklit etmeye yarayan rsa_key.pem dosyasını ve yönetici belirteci ile SMTP parolasını düz metin olarak barındıran config.json dosyasını tutar. O dosyaya okuma erişimi, kasaya tam erişim anlamına gelir.

Bu durum iki kural ile yönetilir. Arşivi sunucudan dışarı çıkarın. Sunucudan çıkmadan önce şifreleyin.

Ayrıca bir doğruluk sorunu da mevcuttur. Servis çalışırken db.sqlite3 dosyasını cp ile kopyalamak, yazma işlemi sırasında yarım kalmış ve açılamayacak bir dosya oluşturabilir; bunu da ancak geri yükleme yaparken fark edersiniz. Bunun yerine SQLite'ın kendi anlık görüntü alma özelliğini kullanın:

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

Kimsenin test etmediği diğer yarı olan geri yükleme süreci, Vaultwarden yedekleme ve geri yükleme kılavuzu içerisinde açıklanmıştır.

Barındırılan Bitwarden yerine kendi kurulumunuzu yaptığınızda vazgeçtikleriniz

Dürüst bir değerlendirme yapmak gerekirse; Bitwarden'ın barındırılan hizmeti, işi sadece bu hizmeti yönetmek olan profesyoneller tarafından yürütülür. Bu hizmet, yayınlanmış üçüncü taraf denetimlerine sahiptir ve gece saat 03:00'te bile müdahale edebilecek bir ekip tarafından desteklenir. Kendi kendine barındırma (self-hosting) yönteminde ise bu güvenceyi kendi yama takviminizle değiştirmiş olursunuz.

Vaultwarden, güvenlik düzeltmelerini standart sürümler halinde yayınlar. 24 Temmuz 2026 tarihinde yayınlanan 1.37.0 sürümü, Ağustos 2026 itibarıyla günceldir ve sürüm notları kullanıcıların mümkün olan en kısa sürede güncelleme yapmasını tavsiye eder. Bir yıl önce kurduğunuz ve unuttuğunuz bir örnek, bir yıllık kodla çalışmaya devam eder. latest etiketi tek başına çözüm sağlamaz: çalışan bir container, siz docker compose pull komutunu çalıştırıp onu yeniden oluşturana kadar başladığı imajı kullanmaya devam eder. Ana makine paketleri için Ubuntu üzerinde otomatik güncellemeleri yapılandırın ve container güncellemesini mutlaka okuyacağınız bir takvim hatırlatıcısına ekleyin.

Dürüst bir okuyucunun çıkarması gereken sonuç şudur: buradaki kriptografi Bitwarden'ın tasarımıdır ve güvenlidir; ancak operasyonel risk tamamen size geçer. Eğer yamaları düzenli yapar ve verilerinizi başka bir yere yedeklerseniz, kontrolünüz altındaki bir VPS üzerinde çalışan Vaultwarden örneği, parolalarınızı saklamak için makul bir yerdir. Eğer bu iki alışkanlığı sürdüremeyecekseniz, barındırılan hizmet için ödeme yapın ve dikkatinizi başka konulara verin. Özellik bazlı karşılaştırma Vaultwarden ve kendi kendine barındırılan Bitwarden karşılaştırması bölümünde yer almaktadır.

Konteynerin altındaki ana makineyi güçlendirme

Vaultwarden, Linux sunucusu üzerinde çalışan tek bir süreçtir ve uygulama nasıl yapılandırılmış olursa olsun, sunucudaki root kullanıcısı /vw-data dosyasını okuyabilir. Konteyneri, compose dosyanızda user: "1000:1000" kullanarak yetkisiz bir kullanıcı olarak çalıştırın, veri klasörünün sahipliğini buna göre ayarlayın ve konteynerin yazmadığı her şeyi :ro ile salt okunur olarak bağlayın. Ardından ana girişi kapatın: VPS üzerinde SSH güçlendirme rehberi, yukarıdakilerin tümünü aşan sıradan saldırıları durdurmak için anahtar tabanlı girişi ve parola kimlik doğrulamasını devre dışı bırakmayı kapsar.

FAQ

Vaultwarden veritabanını çalarlarsa parolalarımı okuyabilirler mi?

Doğrudan okuyamazlar. Her kasa öğesi, istemci tarafında ana paroladan türetilen bir anahtarla şifrelenir; bu nedenle db.sqlite3 yalnızca şifreli metin (ciphertext) içerir. Saldırganın anında elde edeceği veriler; her hesabın e-posta adresi, KDF ayarları, giriş ve cihaz meta verileri ile twofactor tablosundaki iki faktörlü doğrulama anahtarlarıdır. Bu anahtarlar şifrelenmemiş halde tutulur çünkü sunucunun beklenen kodu hesaplaması gerekir. Saldırganlar kasa şifreli metnine çevrimdışı olarak istedikleri kadar saldırabilirler; bu nedenle ana parolanın uzunluğu, sonucun ne olacağını belirleyen temel faktördür.

ADMIN_TOKEN kullanmalı mıyım yoksa yönetici sayfasını tamamen devre dışı mı bırakmalıyım?

Mümkünse devre dışı bırakın; çünkü çoğu kurulumda bu sayfa yalnızca SMTP ayarlarını yapılandırmak ve kullanıcıları davet etmek için bir kez kullanılır, sonrasında ihtiyaç duyulmaz. Devre dışı bırakmak için ADMIN_TOKEN veya DISABLE_ADMIN_TOKEN değişkenlerini ayarlamayın, config.json içindeki tüm "admin_token" anahtarlarını kaldırın ve ardından container'ı yeniden oluşturun. Yalnızca ortam değişkenini kaldırmak yeterli değildir; çünkü yönetici sayfası tarafından yazılan ayarlar config.json dosyasında saklanır ve önceliklidir. Sayfayı tutmanız gerekiyorsa, token'ı düz metin bir rastgele dizi yerine vaultwarden hash ile üretilmiş bir Argon2 hash'i olarak saklayın ve ADMIN_RATELIMIT_MAX_BURST=3 değerini ayarlayın.

ADMIN_TOKEN doğru olmasına rağmen /admin sayfası reddediyor. Sorun nedir?

Sorun neredeyse her zaman $ enterpolasyonundan kaynaklanır. Bir Argon2 PHC dizisi birkaç $ karakteri içerir ve Docker Compose bunları bir docker-compose.yml environment: bloğu içinde değişken olarak genişletir. Bu nedenle, dosyanız doğru görünse bile container bozuk bir değer alır. Compose dosyasındaki her $ karakterini $$ ile değiştirerek ikiye katlayın veya değeri, kaçış karakterine ihtiyaç duyulmayan tek tırnak içine alınmış bir .env dosyasına taşıyın. Ortam değişiklikleri yeniden başlatma ile algılanmadığından, işlem sonrasında container'ı mutlaka yeniden oluşturun.

Bildirimler için hala 3012 numaralı portu açmam gerekiyor mu?

Hayır. Bildirimler ana HTTP portuna taşındığı için 3012 numaralı port üzerindeki WebSocket trafiği desteği Vaultwarden 1.31.0 sürümünde kaldırılmıştır. Ayrıca WEBSOCKET_ENABLED ve WEBSOCKET_PORT ayarları 1.29.0 sürümünden beri dikkate alınmamaktadır. Mevcut ayar, varsayılan olarak true olan ENABLE_WEBSOCKET değeridir. Güvenlik duvarınızda 3012 numaralı portu kapatın ve compose dosyanızdan silin. Ardından, reverse proxy'nizin Upgrade ve Connection başlıklarını ilettiğinden emin olun; çünkü gerçek zamanlı senkronizasyon artık tamamen buna bağlıdır.