laminas / laminas-validator

Validation classes for a wide range of domains, and the ability to chain validators to create complex validation criteria
https://docs.laminas.dev/laminas-validator/
BSD 3-Clause "New" or "Revised" License
126 stars 55 forks source link

Proposal: Validation for breached passwords #2

Closed weierophinney closed 4 years ago

weierophinney commented 4 years ago

Hi,

I'm maintainer of dragonbe/hibp, a composer package to validate passwords against the Have I been pwned? API service to see if a provided password was already used in a breach.

Today (April 5, 2019) Symfony announced they integrate the same service as a validation component in their 4.3 version and I see this as a good way to offer this functionality as part of the framework toolkit. Too bad they're not using my service though.

So I want to propose a validation rule to check provided passwords against HIBP API.


Originally posted by @DragonBe at https://github.com/zendframework/zend-validator/issues/259

weierophinney commented 4 years ago

@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 :+1:


Originally posted by @Ocramius at https://github.com/zendframework/zend-validator/issues/259#issuecomment-480302019

weierophinney commented 4 years ago

Thank you @Ocramius, I will provide a solid solution


Originally posted by @DragonBe at https://github.com/zendframework/zend-validator/issues/259#issuecomment-480311288

weierophinney commented 4 years ago

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:

Where passwordBreach is my personal favourite. Any suggestions?


Originally posted by @DragonBe at https://github.com/zendframework/zend-validator/issues/259#issuecomment-480358290

weierophinney commented 4 years ago

PasswordWasNotDisclosed or such?

On Fri, 5 Apr 2019, 19:31 Michelangelo van Dam, notifications@github.com 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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-480358290, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakOuiNiu_cVT5oIUbYFIVOBy98ZD4ks5vd4hqgaJpZM4cfD7S .


Originally posted by @Ocramius at https://github.com/zendframework/zend-validator/issues/259#issuecomment-480370735

weierophinney commented 4 years ago

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


Originally posted by @DragonBe at https://github.com/zendframework/zend-validator/issues/259#issuecomment-480517330

weierophinney commented 4 years ago

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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-480518670

weierophinney commented 4 years ago

@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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482839690

weierophinney commented 4 years ago

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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482892805

weierophinney commented 4 years ago

I raised https://github.com/zendframework/maintainers/issues/59 about this


Originally posted by @Ocramius at https://github.com/zendframework/zend-validator/issues/259#issuecomment-482894050

weierophinney commented 4 years ago

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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482897517

weierophinney commented 4 years ago

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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482897821

weierophinney commented 4 years ago

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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482898798

weierophinney commented 4 years ago

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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482898922

weierophinney commented 4 years ago

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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482900736

weierophinney commented 4 years ago

That would be the consulting work to be done 😜


Originally posted by @Ocramius at https://github.com/zendframework/zend-validator/issues/259#issuecomment-482900976

weierophinney commented 4 years ago

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


Originally posted by @javiereguiluz at https://github.com/zendframework/zend-validator/issues/259#issuecomment-482928424

weierophinney commented 4 years ago

@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 https://github.com/zendframework/zend-validator/issues/259#issuecomment-482940169

froschdesign commented 4 years ago

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