Closed weierophinney closed 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
Thank you @Ocramius, I will provide a solid solution
Originally posted by @DragonBe at https://github.com/zendframework/zend-validator/issues/259#issuecomment-480311288
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
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
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
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
@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
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
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
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
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
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
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
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
That would be the consulting work to be done 😜
Originally posted by @Ocramius at https://github.com/zendframework/zend-validator/issues/259#issuecomment-482900976
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
@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
Added in version 2.13.0: https://github.com/laminas/laminas-validator/releases/tag/2.13.0
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