Proposal: Validation for breached passwords #2
Comments
|
@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) |
|
Thank you @Ocramius, I will provide a solid solution Originally posted by @DragonBe at zendframework/zend-validator#259 (comment) |
|
I'm contemplating on naming conventions. The service is called "Have I been pwned?", but not everyone will recognise I was thinking about the following names:
Where Originally posted by @DragonBe at zendframework/zend-validator#259 (comment) |
|
PasswordWasNotDisclosed or such? On Fri, 5 Apr 2019, 19:31 Michelangelo van Dam, notifications@github.com
Originally posted by @Ocramius at zendframework/zend-validator#259 (comment) |
|
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) |
|
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) |
|
@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. 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) |
|
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) |
|
I raised zendframework/maintainers#59 about this Originally posted by @Ocramius at zendframework/zend-validator#259 (comment) |
|
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) |
|
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) |
|
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) |
|
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) |
|
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) |
|
That would be the consulting work to be done 😜 Originally posted by @Ocramius at zendframework/zend-validator#259 (comment) |
|
Minor comment: in case you missed it, Symfony ultimately renamed it from Originally posted by @javiereguiluz at zendframework/zend-validator#259 (comment) |
|
@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) |
|
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 zendframework/zend-validator#259
The text was updated successfully, but these errors were encountered: