Open delovelady opened 3 years ago
Right above the password shadow in the config template file you can find the instructions.
Right above the password shadow in the config template file you can find the instructions.
@HcIX - My purpose here was to supplement the instruction that's not stated. What it all means. How it works. The example in config.txt (though it doesn't say so) merely makes the security exposure (a little) worse by ensuring there is only one password to get into all cameras (that use that example option). The intent here was to educate and help people make their own passwords, which is far beyond what the "instruction" provided in config.txt gives.
It's more than a little glamorous to call those four lines of vaguery "instruction."
@delovelady thank you for this - it helped me a lot to share this.
Thank you for this, feel free to add a section in README.md file and create a pull request.
You're welcome @HclX . I don't know the first thing about how to update/create github projects. I'm an old school developer (heavy emphasis on the "old" part, going back to the 60s). But I can learn. Is there a guide to do what you say?
Since telnetd is enabled by the WyzeHacks process, it's a good idea to add a little security by making the root password something that only you know. If the option is enabled in the last line of the default configuration (config.inc.TEMPLATE), the process will set the root password to the default password for Wyze V2 cameras. (That password is documented here: I don't need to be redundant.)
Within the config.inc file, there's a little hint for creating your own password, but a lot of it is vague, and therefore there's a warning that it's intended for advanced users. (Grumble omitted.)
It's actually pretty easy to set this to your own value, but the steps must be done very carefully. I've made an attempt here to establish an understanding of the process, and what worked for me.
Start by coming up with your own "salt" (or seed) value. Read here if you want to learn why this is important.
The value to be set into the config files' PASSWD_SHADOW variable works like this: 'root:$1$---saltvalue---$---hash---:10933:0:99999:7:::
We'll come up with a SALT value and generate a hash shortly, but first an explanation of the values.
Fields in this variable are separated by : ... so there are 9 fields, as follows:
Field 1 is the user name (root - don't mess with it). Field 2 is the hash Field 3 is the number of days after January 1 1970 that the password was changed. 10933 8-Dec-1999 is as good a value as any. Field 4 is the number of days we must wait before changing the password (0 means it may be changed at any time) Field 5 is the number of days after which password must be changed (about 274 years. Don't forget.) Field 6 is the number of days (7) to warn user before password change is required. Give 'em a week in case they forget...) Field 7 is the number of days after password expires that account is disabled Field 8 is the number of days since January 1, 1970 that an account has been disabled Field 8 is reserved field for possible future use
For our hash, we'll come up with an arbitrary SALT value, say PepperIsBetter We'll also use our own password value; in this example it will be UnBreaKable To generate our hash, as hinted by the config.inc file, use a commandline on a system that has openssl installed.
Execute the command: openssl passwd -1 -salt PepperIsBetter UnBreaKable
OpenSSL will respond with this hash. (Note: openssl trimmed our SALT to 8 characters. That's fine.) : $1$PepperIs$Hkyf280HtghK578XPKlGc1
This is the value we'd use as our second field in the command, so the whole command would be:
export PASSWD_SHADOW='root:$1$PepperIs$Hkyf280HtghK578XPKlGc1:10933:0:99999:7:::'
Now, if we run the script with this configuration, the root password will be the value UnBreaKable
I hope this helps.