Hi Anthony,
On Tue, Jul 22, 2014 at 11:27 PM, Anthony Ferrara
wrote:
> > However, I don't mind at all to write RFC raising E_NOTICE for
> > password_hash()
> > with PASSWORD_BCRYPT.
>
> Awesome, thanks!
>
I'll write it later.
> Although cryptgraphic hash functions are supposed work cryptgraph
Yasuo,
> However, I don't mind at all to write RFC raising E_NOTICE for
> password_hash()
> with PASSWORD_BCRYPT.
Awesome, thanks!
> Although cryptgraphic hash functions are supposed work cryptgraphic way, but
> many of them are failing. This was in real world and I aware of the risk.
It's le
Hi Anthony,
I noticed I've made silly mistakes in previous reply. I've added little
more.
Even if I remove text formatting, gmail insists strange formatting. It may
be hard to read...
Please disregard old one and read this.
On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
wrote:
>
> > E_NOTICE
Hi Yasuo,
On Tue, Jul 22, 2014 at 5:00 AM, Yasuo Ohgaki wrote:
> Hi Anthony,
>
> On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
> wrote:
>
>> > E_NOTICE for password larger than 72 is mandatory. Current
>> password_hash()
>> > works without any sign of problem even if it may not be working as
Hi Anthony,
On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
wrote:
> > E_NOTICE for password larger than 72 is mandatory. Current
> password_hash()
> > works without any sign of problem even if it may not be working as
> > authentication.
> > I'll add E_NOTICE as bug fix if there aren't any mo
Yasuo,
> E_NOTICE for password larger than 72 is mandatory. Current password_hash()
> works without any sign of problem even if it may not be working as
> authentication.
> I'll add E_NOTICE as bug fix if there aren't any more comments.
Could you please not.
I have asked you to draft an RFC to j
Hi all,
On Mon, Jul 21, 2014 at 3:17 PM, Yasuo Ohgaki wrote:
> In old days, crypt() was unusable securely. There are many
> users/developers that
> are used to have static slat. Code like below disables authentication
> completely.
>
> password_hash(hash('sha512', SOME_SECRET_SALT).$password, DE
Hi David,
On Mon, Jul 21, 2014 at 2:53 PM, David Muir wrote:
> Prehashing with sha512 means it is no longer blowfish. It is now a
> non-vetted DIY algorithm. The whole point of password_hash is to avoid this
> type of thing, and should be clearly discouraged in the documentation.
>
I agree. It'
On 21/07/2014, at 10:04 AM, Yasuo Ohgaki wrote:
> Hi Anthony,
>
> I want to finish and close this issue.
>
> On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki wrote:
>
>> Also, Deprecating crypt() without first discussing it (and having an
>>> RFC to vote on) is not cool (and has been reverted)
Hi Anthony,
I want to finish and close this issue.
On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki wrote:
> Also, Deprecating crypt() without first discussing it (and having an
>> RFC to vote on) is not cool (and has been reverted):
>>
>> http://svn.php.net/viewvc/phpdoc/en/trunk/reference/string
Hi Anthony,
On Sun, Jul 20, 2014 at 12:27 AM, Anthony Ferrara
wrote:
> > I'll suggest users to use SHA512 raw output as password to
> > remove 72 chars limitation if it is needed.
>
> Then you either misunderstood what I was saying, or completely ignored it.
>
SHA512 raw output may truncate byt
Yasuo
> I'll suggest users to use SHA512 raw output as password to
> remove 72 chars limitation if it is needed.
Then you either misunderstood what I was saying, or completely ignored it.
> Raising E_NOTICE for too long password for PASSWORD_BCRYPT
> makes sense. I'll add it later.
>
> https://b
Hi Anthony,
On Fri, Jul 18, 2014 at 6:56 AM, Anthony Ferrara
wrote:
> > Anthony, do you have suggestion for removing 72 char restriction of
> > PASSWORD_BCRYPT?
>
> My suggestion is to leave it there (it's no longer bcrypt if you do
> something to remove it). Here's a deeper explanation:
> http:
Yasuo
> Anthony, do you have suggestion for removing 72 char restriction of
> PASSWORD_BCRYPT?
My suggestion is to leave it there (it's no longer bcrypt if you do
something to remove it). Here's a deeper explanation:
http://stackoverflow.com/a/16597402/338665
Once scrypt (or yescrypt, or whateve
Hi all,
On Fri, Jul 18, 2014 at 4:38 AM, Anthony Ferrara
wrote:
> We internalized the algorithms in 5.3.2 at least partially because the
> system provided libraries were inconsistent at best (hence why many
> but not all 5.2 systems don't support bcrypt, it depended on the build
> of libcrypt yo
All,
Look at the issue, there's a line in there that is the crux of the issue:
> So problem isn't only in ROUNDS_MIN.
In fact, the overall algorithm changed.
Look at a quick example: http://3v4l.org/Eov3o
>From 5.3.2+ (when we pulled in our own implementation of crypt-sha256
and crypt-sha512,
On 16 July 2014 23:16, Tjerk Meesters wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
>
>> Hi Tjerk,
>>
>> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters > > wrote:
>>
>>> Why should `password_verify()` work on a hash that wasn't generated with
>>> `password_hash()`? The fact tha
Hi Tjerk,
On Thu, Jul 17, 2014 at 3:16 PM, Tjerk Meesters
wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
>
>> Hi Tjerk,
>>
>> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters <
>> tjerk.meest...@gmail.com> wrote:
>>
>>> Why should `password_verify()` work on a hash that wasn't g
On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
> Hi Tjerk,
>
> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters > wrote:
>
>> Why should `password_verify()` work on a hash that wasn't generated with
>> `password_hash()`? The fact that it uses `crypt()` internally should not
>> leak outsid
Hi Tjerk,
On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters
wrote:
> Why should `password_verify()` work on a hash that wasn't generated with
> `password_hash()`? The fact that it uses `crypt()` internally should not
> leak outside of its API, imho.
password_*() is designed as crypt() wrapper a
Hi,
On Thu, Jul 17, 2014 at 9:06 AM, Yasuo Ohgaki wrote:
> Hi Sara,
>
> On Thu, Jul 17, 2014 at 8:53 AM, Sara Golemon wrote:
>
> > At the risk of perhaps missing the point, wouldn't it be more useful
> > to encourage users in some way (perhaps through documentation only) to
> > use password_ha
Hi Sara,
On Thu, Jul 17, 2014 at 8:53 AM, Sara Golemon wrote:
> At the risk of perhaps missing the point, wouldn't it be more useful
> to encourage users in some way (perhaps through documentation only) to
> use password_hash()/password_verify() instead? It was designed with
> migration paths i
On Tue, Jul 15, 2014 at 5:46 PM, Yasuo Ohgaki wrote:
> crypt() has BC issue with older systems.
>
> https://bugs.php.net/bug.php?id=62372&edit=1
>
> The reason rounds became 1000 from 10 is hardcoded lower limit for newer
> PHPs.
> Generally speaking, developer should never use less than 1000 roun
Hi Andrea,
On Wed, Jul 16, 2014 at 10:47 AM, Andrea Faulds wrote:
> > This change was done while ago, so it would not worth the effort to relax
> > the requirement now. IMHO.
> >
> > We may add optional flag to relax the limitation, though.
> > I don't mind modifying crypt() or adding migration
On 16 Jul 2014, at 02:45, Yasuo Ohgaki wrote:
> This change was done while ago, so it would not worth the effort to relax
> the requirement now. IMHO.
>
> We may add optional flag to relax the limitation, though.
> I don't mind modifying crypt() or adding migration INI setting.
Yeah, that’s my
Hi Andrea,
On Wed, Jul 16, 2014 at 10:12 AM, Andrea Faulds wrote:
> > - Developer may use larger rounds and store updated hash when
> > user is authenticated with old PHP.
> > - Developer may ask users to reset password if password hash has
> > to fewer rounds than 1000 (i.e. outdated hash)
On 16 Jul 2014, at 01:46, Yasuo Ohgaki wrote:
> - Developer may use larger rounds and store updated hash when
> user is authenticated with old PHP.
> - Developer may ask users to reset password if password hash has
> to fewer rounds than 1000 (i.e. outdated hash) with new PHP.
Wait, doesn’t
Hi all,
crypt() has BC issue with older systems.
https://bugs.php.net/bug.php?id=62372&edit=1
The reason rounds became 1000 from 10 is hardcoded lower limit for newer
PHPs.
Generally speaking, developer should never use less than 1000 rounds and
better to have
at least few thousands rounds or mo
28 matches
Mail list logo
