[30, 64] Generated password length is capped at 64

Hey there! Thanks so much for 1) testing out our beta and 2) submitting some great feedback :smile: I've asked our engineering team to track down a historical answer for you but in the meantime I'm curious to hear a little bit more about your use case for creating a password longer than 64 characters. I checked our client apps and it looks like we cap that generation at 100 characters so I think there's definitely a good reason to consider increasing that for the sake of consistency. However, I would love to hear more about why you ran into that character limit in the first place if you are ok with sharing!

It's simple - why not? :)
I think I once saw an ad for 1P with the tag line that "you'll only need to remember one password", and building on that I always tend to use 70-90 (or more) character passwords everywhere it's accepted (it's another topic some sites put a cap on your password length, I mean, you hash it anyway, so what's the matter...)

Thanks for the additional feedback! I'll have a chat with our engineering team this week and look into what we can do here! If anyone else is seeing this thread, we'd love to hear your thoughts as well.

Just chiming in here to say that I think the password length cap should at least be consistent between all the apps. So if it's 100 for the client apps, then it should be 100 for CLI as well. 100 characters is probably more than enough for most people, especially if you're only using the client apps.

But the CLI is probably mostly used by people who might have other requirements than the average person. So I see no problem with removing the cap when you explicitly add a recipe to --generate-password. Maybe even adding some kind of setting or preference to configure the default setting to something else than "a 32 character password consisting of letters, digits, and symbols".

Hey @Backspaze

Thanks for your ideas.

I also agree having parity across the clients makes sense. In this case, I believe that 64 chars was chosen for the CLI because it is the max char value in the web client at 1password.com! Having said that, It might be a good time to get all of the clients on the same page, and we appreciate the reminder.

We currently have an internal ticket tracking the issue of increasing the max to 100 chars and are still in the process of discussing the correct approach so hang tight!

Regarding your idea of being able to modify the default recipe, I want to create a ticket for that as well as I think it'd be a great feature. What do you think about setting an environment variable that would override the default password recipe?

For example:

export OP_DEFAULT_PASSWORD_RECIPE=64,letters,digits

@"Justin.Yoon_1P" I don't have a better suggestion at the moment, so as long as the feature is able to be implemented in some way it'll probably be good enough.

Hi @Backspaze,

Are there any special password requirements that you have use cases for? I'd love to hear about them and make sure we cover your use case when allowing more control over the password recipe.

@1P_Simon I can't think of any real use cases at the moment. But as I said earlier, having parity across all clients and 100 chars as default is probably good enough for most, and you already have a ticket for that so that part will soon(?) be a non issue.

But in all the other apps there's a min and max value to the length slider, and no possibility to set at custom value. So 1Password CLI is the only app (so far) where you can set a custom length, by using a recipe, and it seems counterintuitive to me to put a cap on it. If someone wants to do create a ridiculously long password of 500 chars, just let them do it. There are services like Tutanota, who https://tutanota.com/faq/#choose-password, and while such services may be few and far between it would be great to take advantage of that if one wants to.