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

[Kalpesh Patel]

"Well, yes, that's inevitable, otherwise how could your password be checked! :-)" -- modern algorithms does away with storing anything that in one fashion or another stands in for the password. 

Conceptually store a known pattern that has been encrypted by using an algorithm that takes the key (password) as an input. During decryption time, key (password) is requested again as an input to the decryption algorithm and that known encrypted pattern is decrypted. If the pattern before encryption matches with the one after decryption then the same key (password) is entered.  

-----Original Message-----
From: Chris Green <cl at isbd.net> 
Sent: Thursday, September 12, 2024 2:04 AM
To: gnucash-user at gnucash.org
Subject: Re: [GNC] Recommendations for hosting gnucash file - Google Drive, Microsoft 365, Local server?

On Wed, Sep 11, 2024 at 04:04:50PM -0500, R Losey wrote:
> On Wed, Sep 11, 2024 at 10:47 AM Chris Green <cl at isbd.net> wrote:
> > No, they're not.  What's stored is the result of applying an 
> > algorithm to the password you supply.  So, you enter a password, the 
> > password is 'scaarmbled' by the password checking software and, if 
> > the resulting scramble matches your entry in the password file 
> > (actually the shadow file nowadays) you can log in.
> >
> > In reality it's even a bit more complicated than this, but anyway 
> > the password isn't stored in any way.
> >
> 
> Your last sentence gave me a laugh; it directly contradicts your 
> previous
> paragraph: "What's stored is the result of applying an algorithm to 
> the password you supply" -- so the password IS stored in some 
> encrypted fashion

No, it's impossible to get back to the password from the 'scrambled'
string.  The **only** way to validate your password is to encrypt the password you enter and then compare the result with the 'scrambled'
string.

In particular the only way to discover a password is to 'brute force'
it by trying zillions of possible passwords until one, when encryted, produces the required 'scrambled' string.

> -- at the very least something related to the password is indeed stored.

Well, yes, that's inevitable, otherwise how could your password be checked! :-)

More relevant to the original question is that it's even more difficult to break encryption like the above when the 'password' that you're trying to obtain is actually a large chunk of text.  Even if you happen to know it's (say) 1000 characters long brute forcing it is quite impossible.

--
Chris Green