Insecure password handling

maciek134 commented

2025-11-11 20:01:25 +00:00

(Migrated from github.com)

The app loads all of the passwords in clear-text into memory (and by all I mean the whole vault) - it should at least defer loading the password until the moment the copy/show button is pressed.

The other problem, which is not going to be fixable with plain Python/QML is that they are garbage-collected languages and there is no way of clearing the memory the password is in. If you must use Python, you should at least switch to bytearrays so you can clear them - but this is still NOT going to be secure, there is no way to have secure memory management in a language with no memory management.

The app loads all of the passwords in clear-text into memory (and by all I mean the whole vault) - it should at least defer loading the password until the moment the copy/show button is pressed. The other problem, which is not going to be fixable with plain Python/QML is that they are garbage-collected languages and there is no way of clearing the memory the password is in. If you must use Python, you should at least switch to bytearrays so you can clear them - but this is still NOT going to be secure, there is no way to have secure memory management in a language with no memory management.

sunweaver commented

2025-11-12 15:34:21 +00:00

(Migrated from github.com)

ouch!

brennoflavio commented

2025-12-26 20:44:02 +00:00

(Migrated from github.com)

Yes, there's a security compromise done in this app given how slow the CLI is to return responses, so all vault is kept in memory during app lifecycle, reducing the number of calls made to the CLI. Happy to defer password loading if there's a way to do it without compromisig user experience, altough I could not find any way to do so.

About using another language, feel free to fork and reimplement the backend, but won't be handled in the scope of this project

Yes, there's a security compromise done in this app given how slow the CLI is to return responses, so all vault is kept in memory during app lifecycle, reducing the number of calls made to the CLI. Happy to defer password loading if there's a way to do it without compromisig user experience, altough I could not find any way to do so. About using another language, feel free to fork and reimplement the backend, but won't be handled in the scope of this project

maciek134 commented

2025-12-26 21:05:51 +00:00

(Migrated from github.com)

We are talking about a password manager, if you put user experience over basic security we might as well use post-it notes on the monitor.

This is not an unsolvable problem, but if you refuse to solve it at least inform the users of your choice before they log in.

We are talking about a password manager, if you put user experience over basic security we might as well use post-it notes on the monitor. This is not an unsolvable problem, but if you refuse to solve it at least inform the users of your choice before they log in.

brennoflavio commented

2025-12-28 15:15:34 +00:00

(Migrated from github.com)

Since now the app uses an encrypted cache for performance, one possible route would be:

instead of storing the whole vault encrypted in the cache, store individual entries and cache by id instead
Also cache encrypted names with item id
load main screen by loading name cache, so no sensitive data at this step
load further screens by fetching the entry by id, which will load sensitive data into memory

Won't solve all issues, but looks a step forward

Since now the app uses an encrypted cache for performance, one possible route would be: - instead of storing the whole vault encrypted in the cache, store individual entries and cache by id instead - Also cache encrypted names with item id - load main screen by loading name cache, so no sensitive data at this step - load further screens by fetching the entry by id, which will load sensitive data into memory Won't solve all issues, but looks a step forward

maciek134 commented

2025-12-28 16:31:06 +00:00

(Migrated from github.com)

the encryption is kind of pointless when the key/password is still kept in memory (and it is, because that's how Python handles strings)
once you decrypt, that data will also be kept in memory
to encrypt the data you still have to load it, so now you have encrypted data next to unencrypted data when the vault is synced

Yes, what you suggest is better in the sense that (once the app is closed after syncing the vault) it only leaks passwords you copy. But it's not a step forward, you can't build on it to fix the underlying issue.

- the encryption is kind of pointless when the key/password is still kept in memory (and it is, because that's how Python handles strings) - once you decrypt, that data will also be kept in memory - to encrypt the data you still have to load it, so now you have encrypted data next to unencrypted data when the vault is synced Yes, what you suggest is better in the sense that (once the app is closed after syncing the vault) it only leaks passwords you copy. But it's not a step forward, you can't build on it to fix the underlying issue.

brennoflavio commented

2025-12-28 17:06:33 +00:00

(Migrated from github.com)

Security is not a binary definition where there's an ideal state and everything else is pointless. As an example, there's obviously advantage in having in disk encryption, so the data cannot be accessed while the app is closed. Even in this response it's possible to assert that, how something is not a step forward if it's better? Not encrypting at all would be a step backwards, suggesting that there's worse ways to do this.

Anyway, not gonna discuss this further, but will keep the issue open so people can be aware and work on it if they want. And implement the improvement suggested before

Security is not a binary definition where there's an ideal state and everything else is pointless. As an example, there's obviously advantage in having in disk encryption, so the data cannot be accessed while the app is closed. Even in this response it's possible to assert that, how something is not a step forward if it's better? Not encrypting at all would be a step backwards, suggesting that there's worse ways to do this. Anyway, not gonna discuss this further, but will keep the issue open so people can be aware and work on it if they want. And implement the improvement suggested before

maciek134 commented

2025-12-28 17:25:21 +00:00

(Migrated from github.com)

Security is not a binary definition where there's an ideal state and everything else is pointless.

Of course not, but if the base problem is that the data is kept indefinitely in plain-text in memory, then any attempts at securing the app that involve said data are going to be pointless.

Even in this response it's possible to assert that, how something is not a step forward if it's better?

I stated precisely why it's not a step forward - it's a negligible improvement that doesn't fix the underlying problem and can't be used as a stepping stone for an actual fix.

Not encrypting at all would be a step backwards.

Yes, and not storing the vault locally wouldn't. Storing it locally with compromised encryption at best makes no difference, at worst makes it more insecure and gives a false sense of security.

> Security is not a binary definition where there's an ideal state and everything else is pointless. Of course not, but if the base problem is that the data is kept indefinitely in plain-text in memory, then any attempts at securing the app that involve said data are going to be pointless. > Even in this response it's possible to assert that, how something is not a step forward if it's better? I stated precisely why it's not a step forward - it's a negligible improvement that doesn't fix the underlying problem and can't be used as a stepping stone for an actual fix. > Not encrypting at all would be a step backwards. Yes, and not storing the vault locally wouldn't. Storing it locally with compromised encryption at best makes no difference, at worst makes it more insecure and gives a false sense of security.

SolAZDev commented

2026-03-15 05:11:52 +00:00

(Migrated from github.com)

Has there been any updates on this matter?
I have not used the Bitwarden CLI, but I believe that a simple delay, is better than the entire vault exposed...
At the very least, while something safer is worked on.

Has there been any updates on this matter? I have not used the Bitwarden CLI, but I believe that a simple delay, is better than the entire vault exposed... At the very least, while something safer is worked on.

nBdYnl commented

2026-06-12 06:35:05 +00:00

(Migrated from github.com)

I was interested in trying it out, huge fan of the state of greenline already, but isnt there a way we can make one of the most important things to a user more safe? like a phone is in my pocket everytime i leave the house, so anyone accessing my device somehow is able to find all my passwords? that also might needs a warning in the openstore, better honest then sorry for leaking personal information

brennoflavio commented

2026-06-13 17:20:32 +00:00

(Migrated from github.com)

You absolutely can, just not in Python. It's a language limitation, and as stated, I'm not gonna maintain an app in a language I'm not comfortable with.

i leave the house, so anyone accessing my device somehow is able to find all my passwords

Your understanding of the issue is wrong tho, all your data is encrypted in disk, the leak happens in memory when you open the app and the vault is decrypted, so the attack can be done only after someone inputs the master password

You absolutely can, just not in Python. It's a language limitation, and as stated, I'm not gonna maintain an app in a language I'm not comfortable with. > i leave the house, so anyone accessing my device somehow is able to find all my passwords Your understanding of the issue is wrong tho, all your data is encrypted in disk, the leak happens in memory when you open the app and the vault is decrypted, so the attack can be done only after someone inputs the master password

nBdYnl commented

2026-06-13 21:53:06 +00:00

(Migrated from github.com)

You absolutely can, just not in Python. It's a language limitation, and as stated, I'm not gonna maintain an app in a language I'm not comfortable with.

Yes i understand that, i am just trying to understand the underlying problem that is stated before i expose myself to any unneeded security risks (which i probably already do with other things/apps).

Your understanding of the issue is wrong tho, all your data is encrypted in disk, the leak happens in memory when you open the app and the vault is decrypted, so the attack can be done only after someone inputs the master password

i see, that nuances a lot, and makes me think that i feel comfortable enough to try it out. thanks for clarifying.

So the major risk with python is that if someone has remote access to my device, and i put in my master password, they could read and extract that from the memory files? (like the Pegasus hack)

> You absolutely can, just not in Python. It's a language limitation, and as stated, I'm not gonna maintain an app in a language I'm not comfortable with. Yes i understand that, i am just trying to understand the underlying problem that is stated before i expose myself to any unneeded security risks (which i probably already do with other things/apps). > Your understanding of the issue is wrong tho, all your data is encrypted in disk, the leak happens in memory when you open the app and the vault is decrypted, so the attack can be done only after someone inputs the master password i see, that nuances a lot, and makes me think that i feel comfortable enough to try it out. thanks for clarifying. So the major risk with python is that if someone has remote access to my device, and i put in my master password, they could read and extract that from the memory files? (like the Pegasus hack)

brennoflavio commented

2026-06-14 01:38:27 +00:00

(Migrated from github.com)

So the major risk with python is that if someone has remote access to my device, and i put in my master password, they could read and extract that from the memory files?

Yes. Because while the app is opened and the vault is unlocked, the app loads your session key + all your vault to RAM, meaning that anyone with access to your device could read the RAM, get that session key, and do any operation to your vault. It's not unencrypted in a file, but in the RAM process.

Python being an interpreted language with a garbage collector does not offer a way to manage memory and clear this sensitive data on demand, so the best fix would be a fork of this project with a c++ or equivalent backend that can correctly manage the memory and only keep in memory the minimal amount of information to run the software.

> So the major risk with python is that if someone has remote access to my device, and i put in my master password, they could read and extract that from the memory files? Yes. Because while the app is opened and the vault is unlocked, the app loads your session key + all your vault to RAM, meaning that anyone with access to your device could read the RAM, get that session key, and do any operation to your vault. It's not unencrypted in a file, but in the RAM process. Python being an interpreted language with a garbage collector does not offer a way to manage memory and clear this sensitive data on demand, so the best fix would be a fork of this project with a c++ or equivalent backend that can correctly manage the memory and only keep in memory the minimal amount of information to run the software.

maciek134 commented

2026-06-23 13:52:26 +00:00

(Migrated from github.com)

Your understanding of the issue is wrong tho, all your data is encrypted in disk, the leak happens in memory when you open the app and the vault is decrypted, so the attack can be done only after someone inputs the master password

And it can be done at any time after the vault is decrypted, until you close the app AND the memory is reclaimed and used by something else. Hours, days, maybe weeks depending on how you use the device.

> Your understanding of the issue is wrong tho, all your data is encrypted in disk, the leak happens in memory when you open the app and the vault is decrypted, so the attack can be done only after someone inputs the master password And it can be done at any time after the vault is decrypted, until you close the app AND the memory is reclaimed and used by something else. Hours, days, maybe weeks depending on how you use the device.

Rows
Columns

Insecure password handling #2