Lead On Setting A Standard For Password Recipe Publication

huffalumpy

There are very few popular password managers. How about if you guys take the lead, and announce at next year's DefCon or BlackHat or whatever, that you have a new standard for publishing password restrictions for websites so that password managers can use the recipe to build strong passwords? It could be a RegEx formula that's hidden from view inside of a tag or part of a URI, that says "Click Here to Use Our Password Restrictions With Your Password Manager".

AGAlumB

@huffalumpy: I like the idea, but the problem with that is for it to be a standard, we couldn't really create and promulgate it all by ourselves. And I'm afraid there isn't a lot of incentive for developers (app and web) to get on board with something like this.

But wow, such a cool idea! I also wish there were an accepted standard for password salting and hashing and secure storage so that we weren't hearing about a new breach every week. I can dream, can't I? :eh:

huffalumpy

It all starts with SOMEONE (e.g. you folks) throwing it out there. Maybe it will gain wide acceptance, and maybe it won't, but it doesn't happen until someone says "here it is". Heck, you could get in with a couple competitors, develop it, and release it together.

MrC

All ideas are worth discussing. Yet I think this proposal misses the forest for the trees.

There already is a "standard" for passwords - it is a virtually unlimited sequence of characters without restrictions. Yet, it is clear that many systems do not abide by this "standard", and instead go about placing all sorts of restrictions on their passwords (due to compute intensity, back-end server limitations, legacy systems, UI issues, etc.).

So it doesn't seem logical to propose yet another "standard" that these folks won't / can't follow anyway (remember: back-end server limitations, legacy systems), and for those systems that have no restrictions, they are already in "compliance" anyway.

AGAlumB

Fair enough. It's certainly something we can consider in the future, because you're right — you never really know until you put it out there! :)

huffalumpy

Mr. C,

I am not proposing a password standard, I am proposing the developmeant of a standard for a way to publish the recipe so that password managers that can generate passwords, like 1p, know what they must do while generating the strongest password possible. For instance, perhaps a site demands that the first character be alpha, and special characters not include single and double quotes, ampersands, and forward slashes. Instead of my reading the password that 1P has generated, then going through it to make sure it meets all the requirements, 1P could do it, while ensuring that it produces the strongest score when passed through 1P's scoring algorithm.

AGAlumB

I am proposing the developmeant of a standard for a way to publish the recipe so that password managers that can generate passwords, like 1p, know what they must do while generating the strongest password possible.

Indeed. I think thats a succinct way of putting it. :) :+1:

RichardPayne

@huffalumpy

For instance, perhaps a site demands that the first character be alpha, and special characters not include single and double quotes, ampersands, and forward slashes.

I think what @MrC was getting at is that there's no good reason for sites to place any restrictions on what is allowed a password. Vendors would have to update their software to comply with your idea but if they're changing software then they should just remove the restrictions instead.

Megan

Hi @huffalumpy ,

Thanks for clarifying! I have to say, I agree with MrC here:

So it doesn't seem logical to propose yet another "standard" that these folks won't / can't follow anyway

The best password policy is to have no restrictions on what users can create as a password. That is the type of campaign that we want to take the lead on ... and something that we would love to be louder about. :)

huffalumpy

No, they don't have to change the software, i.e. the code that drives the webserver. All they really have to do is have someone change the HTML, which can be done with any text editor or word processor.

There are good reasons for restrictions, and those reasons are technical. Some of the reasons have to do with the nature of the back-end database engine, some to do with the script interpreter/parser, and some to do with analysis of passwords and how script kiddies and true hackers go about breaking them or reverse-engineering hashes. Even with salting and multiple SHA rounds, dictionaries exist for most-common passwords. The new trick is analyzing dumps and developing formulas for most likely patterns. If I know my craft, I will set restrictions to try to minimize those risks, and SQL-injection, etc.

RichardPayne

@huffalumpy

No, they don't have to change the software, i.e. the code that drives the webserver. All they really have to do is have someone change the HTML, which can be done with any text editor or word processor.

It's nothing to do with HTML. If you're doing password validation client-side only then you're doing it wrong. In fact, that applies to any data validation. The front end can do validation but it is only done there as a convenience to the user to avoid round tripping to the server. The real validation is done server side.

There are good reasons for restrictions, and those reasons are technical. Some of the reasons have to do with the nature of the back-end database engine, some to do with the script interpreter/parser,

Wrong. The database will not be dictating password policy. Lazy programming on the server code will do that and like I just explained, if your script parser is placing restrictions on you then you're doing it wrong.

and some to do with analysis of passwords and how script kiddies and true hackers go about breaking them or reverse-engineering hashes. Even with salting and multiple SHA rounds, dictionaries exist for most-common passwords. The new trick is analyzing dumps and developing formulas for most likely patterns.

Granted, you need some restrictions to prevent use of common dictionary terms but that's not what we're talking about. We're talking about restrictions on password length or restricting the available characters.

If I know my craft, I will set restrictions to try to minimize those risks, and SQL-injection, etc.

Can I assume that when you start talking about SQL injection in connection to password limitations that you're talking about preventing the use of double quotes or semi-colons? If so, then if you know your craft then you'd be using parameterised DB queries which automatically protect you for such problems.

rob

@RichardPayne @huffalumpy

It's nothing to do with HTML. If you're doing password validation client-side only then you're doing it wrong. In fact, that applies to any data validation. The front end can do validation but it is only done there as a convenience to the user to avoid round tripping to the server. The real validation is done server side.

To be fair, removing or changing the validation would be a server-side change, but implementing the idea huffalumpy proposed – adding a hidden attribute in the HTML that details current validation requirements in a format readable by password managers – would not need to be afaict.

However, I have to agree with Richard's other points. There's no good reason for sites that care about security to limit available characters or where those characters can be placed. Guarding against common passwords is possible without limiting strong passwords. A site's password restrictions actually help crackers build rules to crack those passwords faster.

As for SQL injection, maybe I misunderstand, but that would only be a concern if you were storing passwords in plaintext, no? And that's just plain ignorance. Maybe worse.

But @Megan emphasized a great positive. We do want to send a message to websites: "Stop limiting strong passwords!" That will be the best change they could make for the security of their users.

RichardPayne

To be fair, removing or changing the validation would be a server-side change, but implementing the idea huffalumpy proposed – adding a hidden attribute in the HTML that details current validation requirements in a format readable by password managers – would not need to be afaict.

You're correct that the restriction information would need to be embedded in the HTML for transmission to the client but it shouldn't be a static piece of text. That would likely get out of sync with the actual rules whenever they are changed. It should be generated by the server code based on the current rules. It can then in be included in unit tests too.

rob

Well, I guess that's a possibility and maybe ideal, but it would take quite a bit of work to get that text to be generated by a list of validations (depending on the format of your validation code and the proposed standard of communicating it – obviously if both were a regex string it'd be pretty easy…). Much easier to just put it in as static text, especially since those restrictions don't change that often. Plus, I doubt very many sites that currently use password restrictions and display those as a static list in a popup or whatever are generating that list on the server using the actual validation code. :-)

RichardPayne

Plus, I doubt very many sites that currently use password restrictions and display those as a static list in a popup or whatever are generating that list on the server using the actual validation code. :-)

I agree, which is why I see so many sites where the two mismatch! I agree it's easier to hard code but easier is not better if the quality is worse.

jpgoldberg

There has been some talk of this nature in the past. I don't know how much of this appears in Steve Werby's talk from PasswordsCon13 Las Vegas,

https://youtu.be/GgXaGCrJoXA

But this was definitely something that came up in the discussion that followed.

While something like that would definitely be a Good Thing™, my fear is that it wouldn't be worth the effort. Quite simply, anyone who would notice and follow those recommendations would already be following the must more useful advise about reducing many of their restrictions in the first place.

(Perhaps I'm feeling a bit pessimistic today.)

RichardPayne

@Rob I just realised that I forgot to reply to this:

As for SQL injection, maybe I misunderstand, but that would only be a concern if you were storing passwords in plaintext, no?

Not necessarily. Like I said, validation should be server side and if you are checking the password against a stored dictionary then it is quite conceivable that you would be executing queries against the plain text password.

rob

Good point, I didn't think about that …obviously :)

mynumbersplease

I believe the most successful would just be to have a system for the site to have a publishable recipe that the password store reads and generates, then requiring customization by the user within the constraints of the site. This could be open sourced so it might be adopted a bit more broadly, obviously that reduces the marketing benefits but it sure would make our lives easier.

Megan

Hi @mynumbersplease,

Thanks so much for sharing your thoughts here! As is mentioned earlier in this thread, the problem is that the best standards for password generation is for the site to have no restrictions on what they allow for passwords. Implementing a different type of standard might not help, since this would also be a standard that websites would have to choose to adopt.

If we're going to encourage any sort of standards, it will be that websites should remove password restrictions from their sites altogether. :)

mynumbersplease

I did not mean to suggest developing a standard, my guess only one percent would agree and that would create some difficulty with having it machine hackable, my thought is just to have a machine readable recipe format that was open sourced for the password generators to read and then force the user to customize the generated password to increase the complexity.

rob

@mynumbersplease, I believe that what you mean by "machine readable recipe format" and what @Megan means by "standard" are the same thing. In order for there to be a machine-readable recipe on the site, the site developers would have to implement that and conform to that format "standard". Adoption would likely be minimal, and pushing adoption of that would detract from our preferred message that sites should simply remove restrictions on secure passwords.

mynumbersplease

I don't believe that there would have to be a standard but a standard for publishing it. I also did not say it would be easy, to implement, but likewise it would not be impossible.
I would be satisfied with a more intelligent generator but if we can send men to the moon on 16 bits and explorers out to beyond the solar system on 32 than it should be possible to have a machine readable published recipe(that allows for an enormous amount of variation that everyone would adopt.
If no one has ever said it the generator that 1password had before was better than the one that you have now.

rob

a standard for publishing it

Right, that's the standard we're talking about

that everyone would adopt

And this is the part that we aren't sure is worth the effort it would take. A much better thing for everyone to adopt would be "Lose the restrictions on strong passwords." That's the message we're trying to send.

if we can send men to the moon on 16 bits and explorers out to beyond the solar system on 32 than it should be possible

Anything is possible when you control the whole system. If we could implement it ourselves, we would have done so, but getting the support of every site on the Internet is not possible, and getting the support of a large number of them is more work than it's worth when it's not as good for security as simply removing the requirements.

If no one has ever said it the generator that 1password had before was better than the one that you have now.

I'm sorry about that. We continue to work on our password generator and we have several ideas to make it better (some already in progress).