Issue #22: Clear password after login button got pressed

[philipp-reinhardt]

No description provided.

[GleammerRay]

entered passwords stay in memory and could be read out by an attacker

I believe that if an attacker is able to read user's program's memory, it's a security misconfiguration issue and not directly related to the security of Passy. Passy does not provide any interface for inter-process communication, therefore making it insusceptible to this kind of attacks. If an attacker has admin access to a machine it should be clear that all passwords currently loaded in Passy will be exposed to the attacker once the user opens the program, just like it is with any other program or password manager.

Currently Passy is using a custom CSV format which is then encrypted to store data, with all data being loaded at all times after user logs in. Separate password entries are stored at separate lines, even after encryption.

As a possible improvement, passwords could have only their nickname, username and tags (and possibly email) loaded at all times, with the rest of the data loaded on demand, so that only one password is exposed at a time.

The concrete implementation I have in mind is storing passwords metadata in a file (namely passwords_meta.enc). Because there is one password per line in passwords.enc, it is possible to store their line index in that metadata file, so that they can be loaded on demand from that file.

Same idea can be applied to the rest of the data (notes, cards, IDs, identities).

[GleammerRay]

As for the screen caching, I don't think there is any, however can't confirm since I don't know the inner workings of the Flutter engine. I would consider it safe to assume that there isn't any, since:

1. Flutter engineers have been trying to make Flutter as universal as possible, for all kinds of applications, secure or not.
2. Making variable value caches does not make sense in the context of Flutter's state engine, the whole point of it was to separate UI from logic, making such variable caches useless for performance.

[philipp-reinhardt]

Hi @GleammerRay ,
thanks for your detailed response.
I was just thinking to reduce the attack vector by having as little as possible data unencrypted in the memory at a time. I like the idea to have such data in memory only on demand 👍

Regarding caching: I just remembered plain old android activity which can be kept in memory until it is used again. Not sure how flutter is translated into the android world though.

Thanks

[GleammerRay]

No problem.

I'm pretty sure Flutter only uses one activity for an app. In my case its two because I also have an autofill activity. I think that flutter uses its own screen management instead of relying on Android's implementation.

[GleammerRay]

entered passwords stay in memory and could be read out by an attacker

I believe that if an attacker is able to read user's program's memory, it's a security misconfiguration issue and not directly related to the security of Passy. Passy does not provide any interface for inter-process communication, therefore making it insusceptible to this kind of attacks. If an attacker has admin access to a machine it should be clear that all passwords currently loaded in Passy will be exposed to the attacker once the user opens the program, just like it is with any other program or password manager.

Currently Passy is using a custom CSV format which is then encrypted to store data, with all data being loaded at all times after user logs in. Separate password entries are stored at separate lines, even after encryption.

As a possible improvement, passwords could have only their nickname, username and tags (and possibly email) loaded at all times, with the rest of the data loaded on demand, so that only one password is exposed at a time.

The concrete implementation I have in mind is storing passwords metadata in a file (namely passwords_meta.enc). Because there is one password per line in passwords.enc, it is possible to store their line index in that metadata file, so that they can be loaded on demand from that file.

Same idea can be applied to the rest of the data (notes, cards, IDs, identities).

Continuing the conversation regarding random data access at #25