RFC: Create new obfuscated password storage module

[Mark Phippard <ma...@gmail.com>]

I was in the process of replying to Karl's email and why I do not
think his approach is the way to go when I had the following idea.

What if we add a new password storage module in the spirit of the
gnome-keyring, gpg modules that stores the password in some kind of
obfuscated format in the auth folder?

This module could be built by default on *nix but also support a
configure option to disable building it. Also if the library itself is
just not present at runtime then it would also not be available.

It would become a new password-stores option in the config file so we
already have a mechanism for enabling or disabling it via that file as
well.

For purposes of all of the other warnings we still support this would
NOT be considered a plain text password.

How we obfuscate would be up to whoever writes the code. I think
Base64 would be fine but we could also use something like AES where we
use the realm-string or some other value we know as the key. This
would not be truly secure but it does help protect against trivial
observation and discovery.

This would make password storage available by default on Linux, but
still give Disto maintainers and anyone else maintaining a system
options to completely disable it if that is their desire.

I will also still reply to Karl's email

Thanks

Mark

Re: RFC: Create new obfuscated password storage module

[Mark Phippard <ma...@gmail.com>]

On Thu, Jan 20, 2022 at 1:01 PM Daniel Sahlberg
<da...@gmail.com> wrote:
>
> Den tors 20 jan. 2022 kl 14:57 skrev Mark Phippard <ma...@gmail.com>:
>>
>> I was in the process of replying to Karl's email and why I do not
>> think his approach is the way to go when I had the following idea.
>>
>> What if we add a new password storage module in the spirit of the
>> gnome-keyring, gpg modules that stores the password in some kind of
>> obfuscated format in the auth folder?
>>
>> This module could be built by default on *nix but also support a
>> configure option to disable building it. Also if the library itself is
>> just not present at runtime then it would also not be available.
>>
>> It would become a new password-stores option in the config file so we
>> already have a mechanism for enabling or disabling it via that file as
>> well.
>>
>> For purposes of all of the other warnings we still support this would
>> NOT be considered a plain text password.
>>
>> How we obfuscate would be up to whoever writes the code. I think
>> Base64 would be fine but we could also use something like AES where we
>> use the realm-string or some other value we know as the key. This
>> would not be truly secure but it does help protect against trivial
>> observation and discovery.
>>
>> This would make password storage available by default on Linux, but
>> still give Disto maintainers and anyone else maintaining a system
>> options to completely disable it if that is their desire.
>>
>> I will also still reply to Karl's email
>>
>> Thanks
>>
>> Mark
>
>
> Is this something that can be added to / merged with issue 4145[1]: Master passphrase and encrypted credentials cache

/shrug

I really do not know. That issue is another idea for solving the same
fundamental problem I suppose but other than that it is a different
idea and approach. I think the reason that idea did not work out is
that it would require some kind of daemon like ssh-agent to hold your
passphrase in memory, otherwise our CLI would just have to constantly
prompt you for your passphrase so it could decrypt the data. This
approach would be secure but it does not solve the usability problems
we have.

Mark

Re: RFC: Create new obfuscated password storage module

[Daniel Sahlberg <da...@gmail.com>]

Den tors 20 jan. 2022 kl 14:57 skrev Mark Phippard <ma...@gmail.com>:

> I was in the process of replying to Karl's email and why I do not
> think his approach is the way to go when I had the following idea.
>
> What if we add a new password storage module in the spirit of the
> gnome-keyring, gpg modules that stores the password in some kind of
> obfuscated format in the auth folder?
>
> This module could be built by default on *nix but also support a
> configure option to disable building it. Also if the library itself is
> just not present at runtime then it would also not be available.
>
> It would become a new password-stores option in the config file so we
> already have a mechanism for enabling or disabling it via that file as
> well.
>
> For purposes of all of the other warnings we still support this would
> NOT be considered a plain text password.
>
> How we obfuscate would be up to whoever writes the code. I think
> Base64 would be fine but we could also use something like AES where we
> use the realm-string or some other value we know as the key. This
> would not be truly secure but it does help protect against trivial
> observation and discovery.
>
> This would make password storage available by default on Linux, but
> still give Disto maintainers and anyone else maintaining a system
> options to completely disable it if that is their desire.
>
> I will also still reply to Karl's email
>
> Thanks
>
> Mark
>

Is this something that can be added to / merged with issue 4145[1]: Master
passphrase and encrypted credentials cache

/Daniel Sahlberg

[1] https://issues.apache.org/jira/browse/SVN-4145