Not able send password value of form as encrypted value

I am developing a new page using HTML. Form has multiple text entry field values. ( Eg : multiple servers and their respective password.) Intention is to store all these data as a section in /etc/config.

On click of save , I am getting all form data and using an UCI set in order to store the values under config.

I am able to store data using UCI.set , but password is being sent as plain text by UCI.set and also stored as plain text.

Any option of not sending the password as plain text and also not storing it as plain text in /etc/config files.

No, as you will need to be able to decrypt it in order to use it. Unless of course you can work with one-way hashes, in this case you could try using a crypto library or something like uhttpd -m to turn the received plaintext value into crypted hash.

Since you did not mention any context or use-cases, it is impossible to answer your question properly.

Context is to accept the remote FTP details to upload the selective logs. Use case allows the users to add 2-3 server ip, username and password to login.

As mentioned previously, have created a config section, UI using HTML, read the form value and set using UCI.set.

Another option that has been provided is to updated the login user name and password for these servers

In all these cases, Password is being stored in the config file as plain text.

You will need to keep storing the password in plaintext then as you need to pass it in plain text to your FTP client as well.

Was more worried about the security risk with this... Because all passwords are present under /etc/config/ftpServers file as plain text.

Can anyone throw some light on how it is handled by OpenWRT for WiFi 802.1x RADIUS Auth authentication ? This will be a similar case where in the radius server secret keys will be entered by the user and these secret keys are later used by the client to connect to radius server for authentication.

They're stored in plain text as well. I don't understand how you expect to solve this. The system must be able to read and process these secrets, so it has to be able to decrypt them. Any "encryption solution" would imply the need to store the decryption keys on the device itself, which introduces security by obscurity at best.