Absolutely unsecure

[redskate]

Thank you for publishing this :)

The software is very nice - uses itself mysqldump .
It produces a secure (compressed and encrypted) output but - due to the fact that everything is defined via plain text, included passwords, it is highly insecure.

Every developer / hacker is able to de-engineer it, to grasp the connection parametes, to use them to run a simple mysqldump, to steal DB data.

[cytopia]

@redskate thanks for raising the concern.

due to the fact that everything is defined via plain text, included passwords,

If you've been on any Debian machine with MySQL installed, you will notice that there is also a /etc/mysql/debian.cnf which contains MySQL credentials with root level access to DB. This is normal behaviour and the file has according file level permissions so that only the root user can access the file (with clear-text credentials). This is pretty mich the same with mysqldump-secure configuration files.

Usually also if you compromise the root user, you can always compromise the rest of the system.

Other than this, can you please elaborate how else a developer would steal the connection parameters?

[redskate]

Perfectly right, once an aggressor has root password, also the DB on that computer is lost. I was hoping - reading the word secure, that there could be more security even having root password. Why making then things “secure”? To feed an assurance? ;) For instance (my suggestions): 0) encrypt (and do not expose) .cnf information which should be given via terminal once 1) encapsulate mysqldump - using cnf + mysqldump a user can access and export everything but not entrcypted. 2) do not use /bin/sh (e.g. I remove /bin/sh from my docker containers to offer bash access) 100% security is never… but one-way-inputs could help avoiding decryption in some cases. E.g. if an aggressor needs too long to decrypt, (s)he will leave the project for another easier case ...

…

On 2 Jul 2021, at 10:18, cytopia ***@***.***> wrote: @redskate <https://github.com/redskate> thanks for raising the concern. due to the fact that everything is defined via plain text, included passwords, If you've been on any Debian machine with MySQL installed, you will notice that there is also a /etc/mysql/debian.cnf which contains MySQL credentials with root level access to DB. This is normal behaviour and the file has according file level permissions so that only the root user can access the file (with clear-text credentials). This is pretty mich the same with mysqldump-secure configuration files. Usually also if you compromise the root user, you can always compromise the rest of the system. Other than this, can you please elaborate how else a developer would steal the connection parameters? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOXLK4YI53SMWXATUYCLDTVVY4JANCNFSM47VI34FA>.

[viperzero]

I see that redskate has spent some time tinkering with sec. So basically all the public systems are exposed to db decrypting attempts if there is 1.) access to crypted db in time series 2.) infiltrator can add data to db between different encrypted backup db versions. So the known variables makes it a lot easier to decrypt without so much of computational power. I know this kind of techniques are widely used becaus R/R sometimes justifies infiltrators to use very bright (but still computationally expensive) algorithms.

So it makes redskates proposals somewhat useful on tighter security environments. At least I would not recommend publishing this kind of material in internet: un encrypted Mega backup tutorial , db backups are great but how you store them is a different thing.