Not easily as this is part of the node-red admin init "script" that can only run after install
Yes - also true of your gmail account, PayPal, X, instagram etc if you don't set a decent password. The init script does check for a minimum length password but yes I will change the PR to make that longer (8 -> 16)
things like this - or the suggestion to make each login take at least 2-3 seconds (which then wouldn't need a call to action IMHO) really need to be in the core - as they would be useful for all users.
As for the guide I posted, the boilerplate code can be apart of the default settings file?
But only enforce it, if they answer "yes" to "Do you wish to restrict access by IP"
if opting in, prompt for the IP's, ranges, subnets, and maybe auto add to the whitelist the local subnet of the Node RED instance
I think one suggestion was to keep the IP's in an external file, which will allow easy modifications after install.
Any future changes to this whitelist will require a restart to Node RED (currently) - but then to make changes to it during runtime should be trivial to allow.
just need to re-populate the array with the new IP's and re-run the for loop to add them to the blocklist class.
it uses blocklist in reverse of course , I'm using it as it takes care of evaluating if the visiting IP is in one of the ranges, subnets, ip's etc etc
it only applies to the httpAdminMiddleware (which the Editor/Admin API/Dashboard is attached to) but nothing stopping anyone using the same code block in httpNodeMiddleware - which will apply to all HTTP IN Nodes
Hi, IĀ“ve a reverse proxy to connect to my NR-Dashboard in my car.
Is a password with 11 letters/numbers for http basic auth really that insecure and can be cracked by bots within a short period of time? After this it would be easy to crack the NR-editor password...
I changed http(s) ports 80/443 to >8000.
BASIC is incredibly insecure, it can be "helped" / "Improved" whatever word will make sence here by
Using SSL
Not using words in the password (despite length) <-- applies to all protocols
A lot of brute force attacks are dictionary based, if using words in your password
will not take long for an army of bots to break it
A lot of cloud services these days actively disable BASIC.
There are online tools that you can use to test your password. Basic auth is really very simple to crack I believe. And of course, we are assuming that you are using TLS with recommended modern settings? A password with no TLS is worse than useless of course.
Interestingly, I generated a random 11 character password (2j5O&xD03N$) and put it into a number of checkers. I got results between a million years and 4 months to crack the password by brute force.
BTW: Another reason NEVER to use Kaspersky - its password checker told me that I needed to replace my password because it used "common words"!!!
As I say, Basic Auth is probably a bigger issue than 11 char passwords:
There are a few issues with HTTP Basic Auth:
The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).
The password is sent repeatedly, for each request. (Larger attack window)
The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).
The password may be stored permanently in the browser, if the user requests. (Same as previous point, in addition might be stolen by another user on a shared machine).
Of those, using SSL only solves the first. And even with that, SSL only protects until the webserver - any internal routing, server logging, etc, will see the plaintext password.
PS: The bigger issue you have with an in-car system is that the most likely security issue is going to be actual theft - either of the whole car or the device. Either way, someone now has the full device and all data. Most likely they will simply pawn the device but you will never be able to trust any password set on that device again.
Not quite entirely true. One way to get a memorable but very strong password - or rather passCODE is to use a sequence of words, ideally with some symbol in between.
This applys to internal networks!!!! I lost a few camera servers to this!!!! if they slip into your network (not me I'm not in charge of network security for that businesses) they can packet sniff all them old school device logins using http://theiphere@user:password/your_now_expletive
I thought I was fine ..... oh 2016 was a wake-up call.
a week of un-billable work (im a private contractor) for my system failing.
lesson learned.
Trust no one. Not even internal networks.
Allot of people get embarrassed by their failures .... I treat it as a learning experience and I'm willing to share my failures so others don't have to suffer them.
Speaking of that I'm working on plan to migrate my ingress to cloudflare as TotallyInformation has been trying to lead this horse to water. I'm sipping....its not like i can just dunk my head in the water bucket quite yet.
I do as well But some people much prefer that method - mostly those people incapable of reliably using a password manager!
A great share, thanks for that. "Smart" devices that force cloud connections are a constant weakness, especially for home networks. If you really have to allow them to talk to the outside world (HINT: FOR GODS-SAKE WHY BUY SUCH A THING!), segment the network so they can't see anything else that is happening.
@kevinGodell's suggestion above to use a higher cost hash algorithm steps up to the plate here for users with a Raspberry pi or other sbc exposed to the internet.
My PiZero 2 takes 14sec to generate a hash with cost = 16 and fractionally less to verify my login, a just about bearable delay.
I can't test on a Pi 5, sadly.
That would be a change in the bowels of red.js to generate, the login already validates the resulting hash OK.
I like this thread. it has allot of information for basic all the way up to intermediate level users to learn some security practice.
However If I had to sum up this entire thread its:
People in the industry who have suffered loss of time, money, and short term credibility, trying to help others not suffer security hack.
VS
Basic/Intermediate node red users who just want it to be secure out of the box not truly understanding how open source creator community works.
I really like how @dceejay has been doing this over the last year. I see a variation of this tactful line many times: "Happy for anyone wanting to enhance the node with a PR"
USERS of node-red. If you want to understand the mindset of the people who create this software please take the time to read the article above and: https://www.gnu.org/philosophy/free-sw.en.html
Words are great, as long as you use multiple. No dictionary is going to help here.
Combination of length + upper + lower + symbols + numbers is everything, have used 16 chars for years.
The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).
Sure, but you first need to be listening. Mass scanning of standard ports is easier than recording/decoding. If you are not on a default port ie > 10k, it raises the bar quite a bit.
Nevertheless, one should be sitting behind a secure connection, preferably with all ports closed, regardless what you are running on your home systems, vulnerabilities are everywhere.
Many many moons ago I was using words.
and this had the easy behaviour of using "favourite" words across multiple services.
Since the introduction of mangers, I don't actually know what any of my passwords are.
all I know is in their plain text form - they are cryptic as hell!
But yes, I do get your point. as long as they are somewhat... malformed (is that the right word?)
and highly random between services, its no harm.
But some people much prefer that method - mostly those people incapable of reliably using a password manager! 
