Memory handling

[azukhatri]

Dear all, if you know how it handles the memory then it will be useful as many Password Managers are keeping data in memory in plain text which are security issues, does any one know how AliasVault handles memory? Thanks

[lanedirt]

Hi @azukhatri,

Thanks for your question!

AliasVault stores all data fully encrypted on the server. When you unlock your vault with your master password (or biometrics/PIN), the vault is decrypted in memory only on your local device. It is never persisted to disk in an unencrypted form.

For AliasVault to function (for example autofill and credential access), the decrypted data does temporarily exist in the local device's app’s memory while the vault is unlocked. This is normal behavior for password managers, since the application needs access to the decrypted data to operate.

However, AliasVault gives you control over how long the vault remains unlocked and how long decrypted data stays in memory. By default, the auto-lock timeout is set to 1 hour, but you can configure it to much shorter periods, such as 15 seconds, so decrypted contents are dropped from memory more quickly.

You can read more about AliasVault’s security architecture and threat model here:

AliasVault SECURITY.md

[azukhatri]

Thanks for prompt response, I understand that behavior, However, is it possible to keep the data encrypted (password and additional fields which are hidden in encrypted form and as and when required it will be decrypted on time to fill the login forms and again in split second those sensitive data can be scrambled or encrypted back again even vault is open in memory?

[lanedirt]

I understand your question, but what you describe would still require the password to be decrypted in memory at the exact moment autofill happens, so in practice it does not meaningfully change the security model. AliasVault therefore allows the user to minimize how long decrypted data remains in memory, for example by configuring very short auto-lock timeouts such as 5 seconds on mobile.

This is how AliasVault currently works and what its security model is designed around.

[azukhatri]

Ok Appreciated response in this regards, If I will find any issue, will come back

[yudin-s]

It is possible to reduce the lifetime of decrypted values, but there is an important limit: if the app can autofill or display a password, that password must exist in decrypted form somewhere at that moment.

The useful design is usually not “the whole vault is always plaintext while unlocked” vs “nothing is ever plaintext”. A middle ground is better:

vault key unlocked
  -> metadata/index available for search/listing
  -> sensitive fields stay encrypted
  -> password/secret field is decrypted only when reveal/copy/autofill is requested
  -> temporary value is cleared as soon as possible

That can reduce exposure, especially for hidden fields like passwords, notes, recovery codes, and TOTP seeds.

But there are caveats:

• in managed runtimes / browsers / mobile frameworks, securely zeroing memory is not fully guaranteed
• strings may be copied by the runtime, UI layer, clipboard, accessibility services, logs, crash dumps, or autofill bridge
• decrypting “for a split second” is still enough for malware with process memory access
• frequent decrypt/encrypt cycles can affect performance and battery, especially on mobile

So I would treat this as defense-in-depth, not a complete protection against a compromised local device.

A practical policy could be:

• keep list/search metadata available while unlocked
• keep hidden sensitive fields encrypted until reveal/copy/autofill
• clear revealed values on blur, timeout, app background, lock, and after autofill/copy timeout
• use the shortest auto-lock timeout the user can tolerate
• avoid putting decrypted secrets into long-lived app state when possible

That would improve memory hygiene without promising something a password manager cannot realistically guarantee once the local device is already compromised.

[azukhatri]

ok so basically all the memory data gone once vault is locked (not logout) right?

[lanedirt]

That is correct, yes 👍

[azukhatri]

Thank you for confirmation, Appreciated,