Implement features added to the original version about zxcvbn-php HOT 17 CLOSED

We need a more granular/responsive feedback to users on password strength failure: ie: "contains a dictionary word", "contains this year" -- as they get frustrated when "safe2016" fails, when they have been using it "everywhere for years". Hopefully I can leverage the issues into a learning opportunity for the users.
I expect I will be working in the core code a bit and the lists, so if @Mondane has something around that, I will look at it. I do have a compressed time frame. ;)

from zxcvbn-php.

I don't monitor the JS version for changes so if there's specific features that exist there that aren't here please create new issues here for them and we can evaluate adding them. Comparing via unit tests is a good suggestion, thanks.

In general I don't think it should be a goal to keep these two projects 100% in sync as the nature of their environment has differences that make it difficult to strive for 100% in sync, client vs server. Also, if someone wants to have the exact same code running on server and client IMO they should use the JS lib via npm and wrap in a process call from PHP or whatever existing system they use on the server.

from zxcvbn-php.

I need to fork this to enhance reporting for our clients, do you have a prioritized list of those features? I may be able to add them into my fork.

from zxcvbn-php.

@Mondane what features specifically?

from zxcvbn-php.

@Moring Thanks for your response. You're welcome to fork and modify but I'd encourage you to make a PR for exposing further match information to support how you need to expose it. ZxcvbnPHP shouldn't be responsible for much user-facing text but should be helpful for creating that text, so if the matches on a password can help provide name and token so you can construct that user-facing text please elaborate on how and ideally via a PR.

from zxcvbn-php.

I don't know which exactly, but as I see a lot of commits happening in https://github.com/bjeavons/zxcvbn-php/commits/master , surely there must be new features that have to be ported to the PHP version.

Maybe what I really need to ask is, do you monitor the JavaScript version for changes that need to be ported to the PHP version?

Maybe it's easiest to keep their and your unit test in sync if you aren't doing so already, see https://github.com/dropbox/zxcvbn/tree/master/test .

from zxcvbn-php.

We use the latest JS version, and it is less restrictive (secure) than this version. So words passing via JS are not allowed in the PHP (IE: "bigluge2016?", scores 3 here, 4 with JS) -- this is likely due to the more extensive word lists in the PHP version. Relevant to this thread--or are you looking just at PHP version?

from zxcvbn-php.

@bjeavons do you still feel that you should not or could not get the same results using the JS library and the PHP library? I think a major use case here is client side and server side validation where the expectation is that a password shouldn't pass validation on the client side but fail on the server side (or vice versa). I recently completed a port to python with the intention of creating matching results. I had intended to create a PR here as well, but if that is not the direction you wish to go with this project I may just fork. Let me know your thoughts.

from zxcvbn-php.

@dwolfhub this issue created a lot of confusion with users, created a support nightmare. We were using the JS version at the client, and this version in the backend. The zxcvbn JS version was approving all kinds of passwords that this version will not.
Even if this code was tracked to the JS (less secure) version development wise, there could be a gap or lag, and you are spending money on support hours.
The only way we found to avoid this is to build a server based REST endpoint that will score the passwords as they are typed in at the browser, and tie endpoint scores to a browser front-end script visual bar.

from zxcvbn-php.

@Moring yea, that is what I'm talking about. Your solution is good, but that's obviously not ideal. It sounds like there is at least some interest in what I'm proposing. Thanks!

from zxcvbn-php.

I still feel the same as my prior comment. If you're striving for 100% consistent results you should use the same code. Or, if someone wanted to do the ongoing work of keeping this project in sync with the JS lib I'd be happy to consider adding you as a collaborator. Unfortunately I can't commit to that level of effort at this time.

from zxcvbn-php.

@Moring what about proposing MR to the JS version so that one becomes more strict?

from zxcvbn-php.

@bjeavons I understand it's a huge commitment. I feel like as I've just finished a similar project I'm in a good place to do the work. I'm going to spend some time poking around to see how much of an undertaking it would be.

@Moring I doubt you'll be able to make changes to logic in the JS version without some pushback from those contributors.

from zxcvbn-php.

@dwolfhub, @Mondane just to be clear, I vastly prefer the @bjeavons version.

The JS version was letting through some pretty obvious passwords, ie: "DrSmith'sDentistOffice" for a practice named "Dr Smith's Dentist Office". So JS version users do run a higher risk of successful attack.

The features we would add to the PHP version would be:

• A "details" hash from the algorithm on failure, to drive a detail panel, ie: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html
• Elegant way to add more words to the dictionary (IE: drop in a properties of an client record) (we do this via wrapper code now)

That way users could see why the passwords failed. It is really important to remember the huge knowledge gap here on secure password design for the user--we not only have to secure a system, but educate the user on how to build a strong password and why that is important.

from zxcvbn-php.

@Moring I agree it's a good thing the PHP library is more strict. Being able to see why a password fails is a very good addition.

from zxcvbn-php.

I think #15 is better issue to discuss and plan for how to address inconsistencies between the front-end (original JS implementation) and back-end password measurement. OK to close this ticket in favor of #15?

from zxcvbn-php.

Seems legit :) . Issue closed.

from zxcvbn-php.