Backups publicly accessible!

The random hash is has secure as any password long of 40 characters … I believe that you sql password is not as long : therefore the security of the sql file is more secure than you actual database ??

The presence of the files is normal as it should be created before being saved on the ftp: you may reduce the time before these file are deleted to one day if you want in the parameters

Perhaps the default delete time should be one?

A person, or a bot, could quickly establish that Backup Scheduler is installed as a plugin on a website. For example:

https://www.[insertdomainhere].com/wp-content/plugins/backup-scheduler/readme.txt

If I can read that file or one of the many other .txt, .png, .nfo, .css, .js files that exist in every Backup Scheduler installation, it’s a sure sign the site is using Backup Scheduler.

The first 22 characters of the backup filename are easily predictable to the month:
BackupScheduler_20160201021729_abcde12345.zip

It’s not uncommon for backups to occur on the first of the month, but the date range is presumably 01 – 31:
BackupScheduler_20160201021729_abcde12345.zip

By default they start at midnight, but the range is presumably 00 – 23.
BackupScheduler_20160201021729_abcde12345.zip

May take a few minutes for a backup, so probably a low number. Range is presumably 00 – 59.
BackupScheduler_20160201021729_abcde12345.zip

Seconds. The range is presumably 00 – 59 also.
BackupScheduler_20160201021729_abcde12345.zip

Predictable underscore.
BackupScheduler_20160201021729_abcde12345.zip

It would not be hard for a bot to very quickly establish the filename up to this point, through a relatively small brute force test. At a rough estimate, approx 300 to 9300 attempts if defaults are used. Best case scenario for us with more random backup times and dates, up to 2678400 attempts, a figure that’s not unrealistic with bot attacks.

So I’m not sure I feel confident considering the characters up to this point part of the random password. Certainly not the first 22. That leaves now only 10.

The random string, vastly improves our odds. However, it too is to some extent, predictable. It’s always 10 lowercase/numerical characters. It’d take time and luck for a bot to brute force it, but I would not say it’s especially difficult. By default it has 42 days to find the file before it’s removed, or if one misunderstands the meaning of that setting like I did, they may change it to a higher number, like 365. (I thought it represented the length of time the file would stay on my FTP server.)
BackupScheduler_20160201021729_abcde12345.zip

I fully understand your point

Even if you consider that the 10 last characters are the only random part, il leaves 36^10 possibilities (i.e. 3?656?158?440?062?976 possibilities) if you consider that an attacker can test 10 passwords per seconds (on a web server it is hard to be quicker) it will takes 4?231?664?861 days to be sure to guess your random number.

I agree that the real number is in fact less than the above number because it only statistical you cannot say it takes 42 days to guess the 10 random last characters .

Even 365 days should be fine

If I am mistaken please tell me

Let s say that an attacker can test 1000 combinations per second (if you have a web server which can handle this amount of queries but I doubt of it) it leave you plenty of time

Are we good ? or do you believe that there is a biais in my reasoning ?