Proposal: Validation for breached passwords about laminas-validator HOT 18 CLOSED

@DragonBe I'd say "go ahead and implement" - this is very valuable.

As a note: please consider using a PSR-18 client as a dependency of the HIBP validator 👍

Originally posted by @Ocramius at zendframework/zend-validator#259 (comment)

from laminas-validator.

Thank you @Ocramius, I will provide a solid solution

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

I'm contemplating on naming conventions. The service is called "Have I been pwned?", but not everyone will recognise hibp as a reference to this service. Symfony called it NotPwned but that's not in line with the naming conventions for validators.

I was thinking about the following names:

• passwordBreach
• compromisedCredentials
• commonUsedPassword

Where passwordBreach is my personal favourite. Any suggestions?

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

PasswordWasNotDisclosed or such?

On Fri, 5 Apr 2019, 19:31 Michelangelo van Dam, [email protected]
wrote:

I'm contemplating on naming conventions. The service is called "Have I
been pwned?", but not everyone will recognise hibp as a reference to this
service. Symfony called it NotPwned but that's not in line with the
naming conventions for validators.

I was thinking about the following names:

• passwordBreach
• compromisedCredentials
• commonUsedPassword

Where passwordBreach is my personal favourite. Any suggestions?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
zendframework/zend-validator#259 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakOuiNiu_cVT5oIUbYFIVOBy98ZD4ks5vd4hqgaJpZM4cfD7S
.

Originally posted by @Ocramius at zendframework/zend-validator#259 (comment)

from laminas-validator.

Let's turn your proposal into a subject form "UndisclosedPassword" to match the other validators.

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

Hey @Ocramius,

I've got a first PoC as a test provided. In this use case I'm using my own hibp package to prevent maintaining 2 versions. I need to update my package first to ensure it implements PSR-7 and PSR-18 so users can make use of their own clients instead of the provided GuzzleHttp that's part of my package. Is this an approach you find OK or do you prefer to have all that logic build as a separate zend component?

How far do you want this component to deliver validation? The basic functionality is to use the provided API by Have I been pwned, but there's also an offline validation possible using downloaded password hash files. This functionality is for users who want to prevent sending password hash snippets over the wire.

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

@Ocramius I have an issue for your suggestion implementing PSR18 for PHP 5.6. Since 5.6 is still a version supported by Zend Framework, I consider this a serious issue.

  [InvalidArgumentException]
  Package psr/http-client at version  has a PHP requirement incompatible with your PHP version (5.6.40)

Do you want me to remove the dependency for http-client or is support for 5.6 planned to be removed from ZF? Please advice.

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

As mentioned in #264, I think we're long overdue with a PHP requirement bump. It is needed and it should just be done, but I'll still need @zendframework/community-review-team to ACK on it, since there is a policy (that I strongly disagree with) to keep the PHP dependency pinned until new major releases are performed.

Originally posted by @Ocramius at zendframework/zend-validator#259 (comment)

from laminas-validator.

I raised zendframework/maintainers#59 about this

Originally posted by @Ocramius at zendframework/zend-validator#259 (comment)

from laminas-validator.

I also requested in php-fig/http-client#12 to provide support for both php 5.6 as for 7.x as not everyone has the luxury to upgrade their systems. I know, it's a cheap shot, but if the minimum for 5.6 would have been supported like with http-message requiring a minimum of PHP 5.3.0 than at least everyone with older systems could make use of new features. 🤷‍♂️

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

I disagree with actively supporting anything below 7.2 to date: old software should stick to old dependencies, or receive a brush-up like anything else.

I've noted that downgrading the dependencies is also not possible, since you'd have a major BC break in the interface: https://github.com/php-fig/http-client/issues/12#issuecomment-482897797

Originally posted by @Ocramius at zendframework/zend-validator#259 (comment)

from laminas-validator.

I follow your chain of thoughts completely and I would love to agree with it fully. My experience is that most companies hire consultants/dev-teams for development of projects and have their hosting outsourced where requirement changes take months to accomplish if that's even the case. And most projects have been abandoned after delivery so no upgrades from those ends allows such an organisation to migrate over to the latest greatest. This is a process of decades, not years.

BTW, nothing prevents them to roll out a version 0.0.1 which doesn't break BC because it precedes it.

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

What you just described is something I am extremely familiar with: trying to help by backporting is exactly like lending money to a gambling addict, sorry.

Originally posted by @Ocramius at zendframework/zend-validator#259 (comment)

from laminas-validator.

No apologies needed, you make a fair point. 😄

I was looking more from the point of view where you were mowing the lawn of your neighbour because they lost their legs in a hit-and-run car accident and you just want to help out.

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

That would be the consulting work to be done 😜

Originally posted by @Ocramius at zendframework/zend-validator#259 (comment)

from laminas-validator.

Minor comment: in case you missed it, Symfony ultimately renamed it from NotPwned to NotCompromisedPassword. Reference: symfony/symfony#30901

Originally posted by @javiereguiluz at zendframework/zend-validator#259 (comment)

from laminas-validator.

@javiereguiluz most likely for the same reason we renamed our validator to "UndisclosedPassword", to make the name more meaningful for less tech savy users.

Originally posted by @DragonBe at zendframework/zend-validator#259 (comment)

from laminas-validator.

Added in version 2.13.0: https://github.com/laminas/laminas-validator/releases/tag/2.13.0

from laminas-validator.