[GNC] Recommendations for hosting gnucash file - Google Drive, Microsoft 365, Local server?

[Kalpesh Patel]

Technology has advanced since UNIX's /etc/passwd came into existence (in nineteen sixties?). There are newer algorithms that have replaced that are far superior to it and even though /etc/passwd is there, it is just a place holder in most part and the actual password from it not used, but underneath it there is another AAA sub-system at work that handles that task transparently to the user.

As for "... how do they tell if a bunch of 0s and 1s have been correctly decrypted? ...", encrypt a known header pattern and then during decrypt check existence of that known pattern -- no need to store the password. If it matches then you are successful at decrypting the data.

You have to encrypt the entire file before resting it on a persistence storage, not just simply password protect it, in order to make sure no beans, not even partial, are spilled from it by other means (like hex or in old time, Commodore PET times, sector editor) when the program has exited. 

-----Original Message-----
From: R Losey <rlosey at gmail.com> 
Sent: Wednesday, September 11, 2024 11:06 AM
To: Fred at mandfb.me.uk
Cc: gnucash-user at lists.gnucash.org
Subject: Re: [GNC] Recommendations for hosting gnucash file - Google Drive, Microsoft 365, Local server?

On Wed, Sep 11, 2024 at 9:56 AM Fred Bone <Fred at mandfb.me.uk> wrote:

> On 10 September 2024 at 14:09, R Losey said:
>
> > Well, but think about it... after the password is entered, THEN 
> > what? The "correct" password would have to be stored somewhere so 
> > that GnuCash
> could
> > verify what is entered is correct, and clearly saving the password 
> > in clear text is not secure. Because the software is open source, 
> > anyone could read the steps taken to secure the password, and that 
> > would be a huge help in breaking the password.
>
> Clearly you don't know anything about how password protected files are 
> handled.
>
> The password is NOT stored anywhere. It doesn't need to be. So there 
> is no code taking "steps to secure the password".
>
> The program doesn't need to "verify what is entered is correct", 
> beyond attempting to use it to decrypt the data. That either works or 
> it doesn't.
>

It's certainly possible that Im am lacking knowledge... I was thinking of the *nix passwords which are (used to be) stored in encrypted form in the /etc/passwd file.

I assume that if a file is protected by a password (or encrypted, for that matter), there must be some way of verifying that what the user enters at a password prompt is correct. You write that they attempt to decrypt the data
-- fine, but in a file, how do they tell if a bunch of 0s and 1s have been correctly decrypted?

--
_________________________________
Richard Losey
rlosey at gmail.com
Micah 6:8