Re: [Fetchmail-users] Planned Google authentication changes

[Matthias A. <mat...@gm...>]

Am 06.03.22 um 09:43 schrieb Andrew C Aitchison:
>
>> I am quite unhappy to put it politely that the Big Tech badmouth (not to
>> say libel) apps using established password logins through TLS and that
>> offer TLS certificates and others means as "less secure apps". What do
>> they think they are doing with asking browser-like client feature sets
>> to obtaining a ticket for logging into another system? How many security
>> fixes are needed in browsers for each and every release again, to be
>> sure nobody steals that token through some phishing or cracking?
>
> Sadly, I think *their systems* are more secure if they turn off IMAP/TLS
> and rely on just one authentication system.
> There may also be merit in device- and app-specific authentication
> tokens.

That would even be grosser if they were shifting their own blame to
somebody else.
We have some SASL and GSSAPI (Kerberos)...


>
> Plus TLS doesn't save passwords from the boot-strap problem. This
> fancy new stuff may help to get a new password agreed between both
> ends securely.

...in place for authentication, why did we have to reinvent Kerberos if
not by the Big Tech to exert control where it does not belong?

I am happy to add new SASL mechanisms if they don't require registering
the application or reading through hundreds of pages of specs that then
still leave many questions open as to some service's particular
implementation quirks and idiosyncrasies.

> Frankly, I am as worried about losing an account through a disk crash
> as having it hacked. If I really care about the information being secure
> I don't want it on the internet in the first place.

Well, true enough, and then there is client-side encryption to make sure
you need not trust some storage provider to keep your data safe.

And there are encrypted backup systems to avert data loss in case of
disk crashes. There seems to be a decent choice of incremental or
deduplicating or history-preserving backups, some built on keeping file
history with hardlinks and forward or reverse diffs (rsync based
backups, or rsnapshot - these usually without encryption last time I'd
checked), some encrypting and block deduplicating (such as borg backup
or restic, borg with optional compression which, however, seems to be
less effective than deduplication in my personal practice), and others
(for instance duplicity and its wrappers). Some systems (for instance,
borg backup and restic) permit mounting of backups through FUSE.

Regards,
Matthias