generated passwords are lovecraftian nightmares.

[nimbius]

Just tried generating a password during provisioner creation and was greeted with this 32 character unholiness:
unrA%[d(`D0JmwaB)}z];fuJ'AN0U;

reasons this is yucky and awful:

• some of these are escape characters.
• some SQL and financial systems barf on certain characters. :(
• makes a lot of assumptions about the sanity of inputs for automated systems :(
• makes developers in a remote console with limited access to a paste buffer cry.

cool idea to make passwords cool and also neat:

• deprecate passwords.
• the awesome dudes at openwall have a library that generates passphrases
• https://www.openwall.com/passwdqc/
• its got go bindings. yay go!
• its a library supported by security people from name brands like openbsd

[sswastik02]

Hi @hslatman,
Is this issue still valid? If so, I would like to work on it.

[dopey]

Hey @sswastik02 👋. Yes, I believe this issue is still valid, and we'd love for someone from the community to take it on!

[sswastik02]

Thanks for your reply @dopey
Could you please give hints where edits would me made? As I am new to this repository.

[dopey]

https://github.com/smallstep/cli/blob/master/command/ca/init.go#L655, https://github.com/smallstep/cli-utils/blob/main/ui/ui.go#L217-L231

I think that's where you'd start poking around. You could probably just replace randutil.ASCII with randutil.Alphanumeric.

If you install step and run step ca init, fill in the first few prompts you'll see:

Choose a password for your CA keys and first provisioner.
✔ [leave empty and we'll generate one]: █
error reading password: ^C

Which I believe is what this issue is about. The default generated password can be quite ugly.

[sswastik02]

Hi @dopey,

Thank you for bringing up the file, and I appreciate your insight. Indeed, substituting randutil.ASCII with randutil.Alphanumeric produces a notably easier-to-read password. Here's the output for reference:

    Choose a password for your CA keys and first provisioner.
    ✔ [leave empty and we'll generate one]: █
    ✔ Password: gG9Uv72FrSPxRUR2eiifh97KYD69wT8u

While this change improves readability, I'm curious if it adequately addresses our needs. Do you think integrating passwdqc's functionality, as outlined in its function, would be beneficial? It could provide us with more robust password generation capabilities, allowing for custom configurations. However, it's worth noting that implementing this approach would necessitate the installation of libpasswdqc.

What are your thoughts on this?

[hslatman]

Hey @sswastik02, we'd like the CLI to remain pure Go, so relying on libpasswdqc is going to be problematic. If it provides sufficient value it could be put behind a build tag, but it likely won't be supported in the releases we produce. Note that relying on the library could even be seen as a security vulnerability if it gets replaced with something malicious.

There might be alternative solutions providing similar functionality in Go. Those would be preferred. For this issue, changing the generated passwords to something that's more friendly in terminals seems sufficient, so it's not something that necessarily needs to be implemented, imo.

[sswastik02]

Hi @hslatman,
Your point is well taken. Would you recommend that I move forward by initiating a pull request in the appropriate repository? This would involve implementing the transition from ASCII to alphanumeric and properly referencing this issue.

[hslatman]

@sswastik02 sounds like a great way forward 🙂