Nickserv password in webadmin is entered in plaintext (<input type="text">) #329

New Issue

2026-10-05T04:13:31+02:00

adam commented

2026-10-05 04:13:31 +02:00

Like the arguments fields for all of the other modules in webadmin, the arguments for nickserv are entered in an input field of type "text" ( <input type="text">).

After it is entered, it shows up as <hidden> when the page is viewed again; however, most browsers will automatically (and silently!) store form data for text fields. Anybody else using the same browser will be able to determine the password that was entered later on, unless the user knows this and explicitly clears form data.

I recommend changing this to <input type="password">. I was going to do this myself and submit a pull request if it had been a quick fix, but I see that these fields are autogenerated, and my C++ is a bit rusty. Before I go through the effort of figuring out how to special-case this one, I figured I'd file this ticket here for input.

Does anyone know of a reason to keep this in plaintext, or know the simplest way to generate a "password" type for this input field instead of "text"?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2108726-nickserv-password-in-webadmin-is-entered-in-plaintext-input-type-text?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

Like the `arguments` fields for all of the other modules in webadmin, the arguments for nickserv are entered in an input field of type "text" ( `<input type="text">`). After it is entered, it shows up as `<hidden>` when the page is viewed again; however, most browsers will automatically (and silently!) store form data for `text` fields. Anybody else using the same browser will be able to determine the password that was entered later on, unless the user knows this and explicitly clears form data. I recommend changing this to `<input type="password">`. I was going to do this myself and submit a pull request if it had been a quick fix, but I see that these fields are autogenerated, and my C++ is a bit rusty. Before I go through the effort of figuring out how to special-case this one, I figured I'd file this ticket here for input. Does anyone know of a reason to keep this in plaintext, or know the simplest way to generate a "password" type for this input field instead of "text"? ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2108726-nickserv-password-in-webadmin-is-entered-in-plaintext-input-type-text?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:13:32 +02:00

As I recall, what actually happens is that the nickserv module reads its argument, stores that to its .registry file, and then clears its argument, which is why the password doesn't show on subsequent page loads.

With regard to fixing this, something like dgw@9aee996 is probably adequate. It stops the immediate issue, though admittedly by brute force (never allowing module arguments to autocomplete). But it is a much simpler solution than adding a module attribute that conditionally switches autocomplete off or changes the input field to a password type.

I'll submit that as a PR if that's an acceptable solution, at least for the immediate future.

As I recall, what actually happens is that the nickserv module reads its argument, stores that to its .registry file, and then clears its argument, which is why the password doesn't show on subsequent page loads. With regard to fixing this, something like dgw@9aee996 is probably adequate. It stops the immediate issue, though admittedly by brute force (never allowing module arguments to autocomplete). But it is a much simpler solution than adding a module attribute that conditionally switches autocomplete off or changes the input field to a password type. I'll submit that as a PR if that's an acceptable solution, at least for the immediate future.

adam commented

2026-10-05 04:13:33 +02:00

I was going to point out that Chromium ignores "autocomplete=off", but apparently that's only for password fields (https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/zhhj7hCip5c), so I think that would work.

(It still feels a little weird to have a password field that's visible in plaintext as it's being typed, but I guess I can live with that here).

Please do submit this as a pull request - thanks!

I was going to point out that Chromium ignores "autocomplete=off", but apparently that's only for password fields (https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/zhhj7hCip5c), so I think that would work. (It still feels a little weird to have a password field that's visible in plaintext as it's being typed, but I guess I can live with that here). Please do submit this as a pull request - thanks!

adam commented

2026-10-05 04:13:34 +02:00

#549 is only partial solution.
When modules get the ability to describe behavior of their Arguments field, some modules should switch back to text box with autocompletion, some should have some select box, or maybe combination of several fields…
Or maybe we should just get rid of arguments, and use only NV

#549 is only partial solution. When modules get the ability to describe behavior of their Arguments field, some modules should switch back to text box with autocompletion, some should have some select box, or maybe combination of several fields… Or maybe we should just get rid of arguments, and use only NV

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#329