# User/Password/Private Key clear text in /cfg/config.json

**URL:** <https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751>\
**Category:** Feature Requests\
**Tags:** bug-report, router, feature-request\
**Created:** [June 1, 2026, 5:25pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751 "2026-06-01T17:25:58Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![ttaidapos](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/ac8455/32.png) [@ttaidapos](https://forum.alta.inc/u/ttaidapos)\
**Post date:** [June 1, 2026, 5:25pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/1 "2026-06-01T17:25:58Z")

</div>

As the title suggests, username/password/private key is stored in clear text in /cfg/config.json. Can we get this in hash?

---

<div class="post-metadata">

**Author:** ![ttaidapos](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/ac8455/32.png) [@ttaidapos](https://forum.alta.inc/u/ttaidapos)\
**Post date:** [June 22, 2026, 2:05pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/2 "2026-06-22T14:05:11Z")

</div>

Surprised this hasn’t received any attention yet. Why are credentials being stored in clear text?

---

<div class="post-metadata">

**Author:** ![Chrisl154](https://forum.alta.inc/user_avatar/forum.alta.inc/chrisl154/32/1431_2.png) [@Chrisl154](https://forum.alta.inc/u/Chrisl154)\
**Post date:** [June 24, 2026, 4:47pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/3 "2026-06-24T16:47:53Z")

</div>

Alta can you confirm that this is showing in production? If so, This would be a vulnerability that could reach a CVE Database.

---

<div class="post-metadata">

**Author:** ![ttaidapos](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/ac8455/32.png) [@ttaidapos](https://forum.alta.inc/u/ttaidapos)\
**Post date:** [June 24, 2026, 4:57pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/4 "2026-06-24T16:57:49Z")

</div>

You can verify by ssh into the route 10 and confirm.

---

<div class="post-metadata">

**Author:** ![tfmm](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/c6cbf5/32.png) [@tfmm](https://forum.alta.inc/u/tfmm)\
**Post date:** [June 24, 2026, 6:36pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/5 "2026-06-24T18:36:05Z")

</div>

I can confirm the radius configs are all plaintext, including usernames, passwords, PSKs, and PrivateKeys.

@Alta-Jeff @Alta-Chase Is this at least being worked on?

---

<div class="post-metadata">

**Author:** ![ttaidapos](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/ac8455/32.png) [@ttaidapos](https://forum.alta.inc/u/ttaidapos)\
**Post date:** [June 24, 2026, 6:44pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/6 "2026-06-24T18:44:34Z")

</div>

@Alta-Jeff @Alta-Chase

Team, at the least a basic penetration test needs to be conducted and remediated. Additionally, basic hardening standards need to be applied.

---

<div class="post-metadata">

**Author:** ![Alta-Jeff](https://forum.alta.inc/user_avatar/forum.alta.inc/alta-jeff/32/56_2.png) [@Alta-Jeff](https://forum.alta.inc/u/Alta-Jeff)\
**Post date:** [June 25, 2026, 5:14am UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/7 "2026-06-25T05:14:13Z")

</div>

We have a bug bounty program, and have performed security penetration tests internally and externally, and there are no outstanding issues.

The Radius settings are stored in RAM only, and only accessible by the administrator. For access to the /cfg/config.json file, someone would need to have administrator access to the device already. We have considered encrypting the /cfg filesytem at rest, but to reiterate, someone would need to have administrator access to the device to access the contents anyway.

---

<div class="post-metadata">

**Author:** ![tfmm](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/c6cbf5/32.png) [@tfmm](https://forum.alta.inc/u/tfmm)\
**Post date:** [June 25, 2026, 12:43pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/8 "2026-06-25T12:43:08Z")

</div>

Passwords should _NEVER_ be stored in plain text. Ever.

Radius supports encrypted or hashed password storage in all current implementations.

---

<div class="post-metadata">

**Author:** ![tfmm](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/c6cbf5/32.png) [@tfmm](https://forum.alta.inc/u/tfmm)\
**Post date:** [June 25, 2026, 12:50pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/9 "2026-06-25T12:50:28Z")

</div>

Also the “requiring admin access to even see this” is not considered valid protections against bad practices like this in any modern compliance or security framework. What if there is a future bug or issue that allows remote privilege escalation or access? Boom, now everything is hosed.

These excuses are, frankly, inexcusable.

---

<div class="post-metadata">

**Author:** ![techtegrity](https://forum.alta.inc/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@techtegrity](https://forum.alta.inc/u/techtegrity)\
**Post date:** [June 25, 2026, 1:11pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/10 "2026-06-25T13:11:35Z")

</div>

That is extremely disappointing to hear. If I deployed even 1 switch at work without it being set to encrypt stored credentials I would be fired.

---

<div class="post-metadata">

**Author:** ![Alta-Jeff](https://forum.alta.inc/user_avatar/forum.alta.inc/alta-jeff/32/56_2.png) [@Alta-Jeff](https://forum.alta.inc/u/Alta-Jeff)\
**Post date:** [June 25, 2026, 1:13pm UTC](https://forum.alta.inc/t/user-password-private-key-clear-text-in-cfg-config-json/6751/11 "2026-06-25T13:13:36Z")

</div>

If you’ve ever implemented a password-authenticated RADIUS Server before, you will know that passwords must be stored in plaintext at some point. There is no way around it, other than to use other, more secure forms of authentication, such as certificates. This is common practice across other enterprise networking vendors, by the way.

Even if a non-administrative task is somehow compromised, the password files themselves are not accessible by non-administrator users. If you believe you have found an actual vulnerability, I encourage you to reach out to [security@alta.inc](mailto:security@alta.inc) or [support@alta.inc](mailto:support@alta.inc) to submit a bug report.
