How to stop flow backup file being generated?

[dr_cave_dweller]

I have seen alot of historical posts here about creating and automating flow backups, but nothing about stopping it from being generated.

Can someone please clarify when a flow.backup is created in Node-Red? Does it happen automatically in anyway or is it generated only after you press the deploy button?

If you want to prevent tampering of the flow then I assume you lockdown Node-Red using $node-red-admin hash-pw but then you must also manually delete the flow.backup file and this will not be generated again?

[dceejay]

It’s created when you hit the deploy button. If the admin is locked down so you can’t hit deploy then it won’t get written.

[Colin]

@dr_cave_dweller

you must also manually delete the flow.backup file

Why do you need to delete it?

[dr_cave_dweller]

Seems a moot point to generate an encrypted key, lock down Node-Red but leave a flow backup in the .node-red folder. Couldn't anyone with just a little Node-Red experience open the backup file, copy the flow, rename the host and redeploy in Node-Red, then make whatever changes they want including generating a new password?

That seems easy to do, probably alot of product floating around with that opening if true. Maybe Node-Red guys should add a comment to security page that you have to delete the flow backup after final deployment and after logging the user out, delete it from the .node-red folder AND then permanent delete from the trash to 100% ensure code remains secure.

Hopefully I am wrong and I have misunderstood something (highly likely!)

[Colin]

@dr_cave_dweller

Seems a moot point to generate an encrypted key, lock down Node-Red but leave a flow backup in the .node-red folder.

The key does not, as far as I know, encrypt the flows file, it just prevents access to the node-red editor unless you have the username/pwd. It is the password that is encrypted, not the flows file. It does not prevent anyone with read access to the .node-red directory from seeing the flows file, or even editing it if they have write access to the folder.

[dr_cave_dweller]

Hmmmm.... It seems I have completely misunderstood that then. I dont really understand the point of locking down the node-red editor if someone could just copy the flow, reset the host name and redeploy. That doesn't seem very secure.

I must be missing something. So how can you prevent someone from modifying flows?

[dceejay]

if the editor is locked down then how are you going to remotely access the flow to copy it ? If you have physical access to the machine and it's login password then all bets are off anyway.

[dr_cave_dweller]

I am running a touchscreen and chromium webpage kiosk interface running the dashboard - kind of like a PLC and touchscreen - which is reading sensors and controlling relays. There is no remote access, SSH and wifi all turned off. Node-Red and chromium in Kiosk mode start on boot. So sounds like I am out of luck. That is a shame, I completely misunderstood how the security functions, I thought it locked the flow out.

[Colin]

Who are you trying to prevent from accessing it, and why? The answers may help us in our efforts to suggest a solution.

[dr_cave_dweller]

Trying to prevent anyone but me accessing it, and the reason is as soon as people mess with things they dont understand they will break it, then I will need to fix it. Basically the use case is to mimic a PLC system, for PLC it is common to lockdown your code/flow so people can't mess with it.

[Colin]

In what way might they mess with it that you are trying to stop? How would they access it?
What hardware/OS are you running on?

[dr_cave_dweller]

Raspberry Pi. Probably as easy as plugging in a keyboard and mouse, kill the chromium kiosk, launch command line and away you go. The touchscreen is supposed to grant access to parameters they can alter and data they can view, everything else should be a no-go.

[Colin]

Change the default user on the pi to something other than pi, with a strong password, which you should do as a matter of course anyway. Then they won't be able to use the command line.

[dr_cave_dweller]

Thanks for the advice, I am still learning so appreciate you answering my dumb questions!

[Colin]

They could still take the SD card out, put it into a reader on a PC and hack it in any way they want. Whether that is a problem for you I don't know.