Stas Malyshev wrote:
Helping to solve the problem would also help everybody else upgrade TO PHP5.4?
OK, so what help do you require?
PEAR and PECL that work with PHP5.4 out of the box?
At least the core of PEAR that does not throw strict warnings from a stock
install of PHP5.4 as E_STRICT is o
Hi!
> The current raft of PHP problems arise from the fact that "we actually put a
> lot
> of emphasis on not breaking backward compatibility" seems just to be lip
> service
> to the real problem ... Taking stuff out in PHP5.4 would be fine if people
> are
So what would happen if it would b
Rasmus Lerdorf wrote:
Having just been helping another unsophisticated user, the growing
>problem of incompatibility between versions is starting to hit harder.
>So can developers please start taking a little more care with the
>support of existing users!
Lester, we get it. Your job is to mainta
Dear Stan:
On 01 Aug 2012, at 01:23, Stan Vass wrote:
>
> 1. Name collisions between a trait method and a class method using the trait
> go unreported, the class silently shadowing the trait method:
> --
hi!
On Mon, Jul 30, 2012 at 9:13 AM, Stas Malyshev wrote:
> Hi!
>
> I was running PHP tests on my freshly installed CentOS instance and I
> noticed that two XML tests were failing: ext/xml/tests/bug35447.phpt and
> ext/xml/tests/xml011.phpt. Looks like for some reason XML parser when
> parsing so
I'd like to point out some puzzling behaviors in Traits as they exist in the
production releases of PHP 5.4.
1. Name collisions between a trait method and a class method using the trait go
unreported, the class silently
On 31 July 2012 22:02, Anthony Ferrara wrote:
> Peter,
>
> On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind wrote:
>>
>> On 31 July 2012 18:21, Anthony Ferrara wrote:
>>
>> *snip*
>>
>> >
>> > Also, be aware that BCrypt only uses the first 72 characters of the
>> > password field. So if you use a hex
Peter,
On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind wrote:
> On 31 July 2012 18:21, Anthony Ferrara wrote:
>
> *snip*
>
> >
> > Also, be aware that BCrypt only uses the first 72 characters of the
> > password field. So if you use a hex encoded sha512 output, a good deal of
> > entropy would be l
On 31 July 2012 18:21, Anthony Ferrara wrote:
*snip*
>
> Also, be aware that BCrypt only uses the first 72 characters of the
> password field. So if you use a hex encoded sha512 output, a good deal of
> entropy would be lost (almost half of it)...
>
Seeing as the hashing function will default (
On 31/07/12 18:21, Anthony Ferrara wrote:
> Jonathan,
>
> On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron
> wrote:
>> Sure managing keys properly can be hard, simple cases:
>> $secret = MY_KEY;
>> $secret = file_get_contents('/security/key.pem');
>>
> Actually, that's not properly managing t
Jonathan,
On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron wrote:
> On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
> >
> > On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron >
> > I strongly disagree with this, the 'pepper' IMHO is a best practice
> > for web applications.
> >
> > Again,
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
>
> On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron
> I strongly disagree with this, the 'pepper' IMHO is a best practice
> for web applications.
>
> Again, I have not seen this being said by any security or cryptography
> expert.
>
Like
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron wrote:
> >
> > RFC:
> > https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
> >
>
> Thanks, I missed it...
>
> I strongly disagree with this, the 'pepper' IMHO is a best practice for web
> applications.
>
Again, I have not s
On Tue, Jul 31, 2012 at 4:28 PM, Jonathan Bond-Caron wrote:
> Thanks, I missed it...
>
> I strongly disagree with this, the 'pepper' IMHO is a best practice for web
> applications.
>
> I prefer to live with the idea that an attacker may comprise some
> database(s) in the 'cloud' but not the physic
>
> RFC:
> https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
>
Thanks, I missed it...
I strongly disagree with this, the 'pepper' IMHO is a best practice for web
applications.
I prefer to live with the idea that an attacker may comprise some
database(s) in the 'cloud' bu
Jonathan,
On Tue, Jul 31, 2012 at 8:32 AM, Jonathan Bond-Caron wrote:
> On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
> >
> > > https://wiki.php.net/rfc/password_hash
>
>
> -- password_hash()
>
> password_hash_rfc(string $password, int $algo, array $options = array())
>
> My personal opinion is
> Say you have:
> define('MY_HASHING_SECRET', 'hhtrg54~%$%4long'); $password =
> '1234';
>
> password_hash_rfc($password . MY_HASHING_SECRET,
> PASSWORD_METHOD_BCRYPT); password_hash($password, MY_HASHING_SECRET);
>
> Note here that in both cases we let crypt() generate a random salt that
>
On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
>
> > https://wiki.php.net/rfc/password_hash
-- password_hash()
password_hash_rfc(string $password, int $algo, array $options = array())
My personal opinion is the api should be:
password_hash(string $password, string $secret = '', array $options
hi,
On Tue, Jul 31, 2012 at 2:02 PM, Jonathan Bond-Caron wrote:
> On Wed Jun 27 12:32 PM, Arvids Godjuks wrote:
> a) In terms of 'effort' to break many passwords, there's a benefit to the
> salt stored in the hash itself.
> It's not 'more secure' but 'better/recommended' since the attacker woul
On Wed Jun 27 12:32 PM, Arvids Godjuks wrote:
> because at the moment i do not understand how salt stored in the hash itself
> makes hash more
> secure than an unsalted one.
a) In terms of 'effort' to break many passwords, there's a benefit to the salt
stored in the hash itself.
It's not 'more
20 matches
Mail list logo
