On Wed, Jun 27, 2012 at 11:37 AM, Galen Wright-Watson wrote:
>
> On Wed, Jun 27, 2012 at 6:07 AM, Solar Designer wrote:
>
>> [...]
>>
>> BTW, what version of PHP introduced the === comparison operator?
>> I guess this should become the minimum version for phpass since this is
>> highly desirable t
On Wed, Jun 27, 2012 at 6:07 AM, Solar Designer wrote:
> [...]
>
> BTW, what version of PHP introduced the === comparison operator?
> I guess this should become the minimum version for phpass since this is
> highly desirable to use.
>
=== was added on Oct 19, 1999. php_version.h gives the versio
Alexander,
> BTW, what version of PHP introduced the === comparison operator?
> I guess this should become the minimum version for phpass since this is
> highly desirable to use.
>
> http://www.php.net/manual/en/language.operators.comparison.php does not
> say anything about that.
>
That's been i
On Wed, Jun 27, 2012 at 07:51:38AM -0400, Anthony Ferrara wrote:
>
> > Note: _if_ you ask for a portable hash. What else should it do if you
> > ask it for just that?
>
> That's a fair point. I guess since the adoption of 5.3, and the fact
> that 5.2 is dead (yet alone php4), has me thinking tha
Alex,
> Thank you for the chance to comment, and sorry that I did not do so yet.
> I am busy with lots of other stuff. I'd appreciate it if you don't
> hurry to implement this stuff too much, and I likely will comment on it
> (that is, on the actual proposed API and implementation). Please keep
Hi all,
On Sat, Jun 16, 2012 at 03:39:35PM +0200, Pierre Joye wrote:
> Adding Alex to the loop as his insight will be unvaluable in this thread.
Thank you for the chance to comment, and sorry that I did not do so yet.
I am busy with lots of other stuff. I'd appreciate it if you don't
hurry to im
Hello again,
I have put together a quick proof-of-concept for the password API.
C:
https://github.com/ircmaxell/php-src/blob/hash_password/ext/standard/password.c
PHP (Implemented as a backwards-compatibility layer, so 5.3/5.4 users
can use the API earlier):
https://github.com/ircmaxell/passwo
Angel,
> I don't think the code is the most appropiate one, but I suppose that's
> not a final proposal.
Correct, it was just to fill out the interface a bit so that people
could play with it and see how the interface worked...
> The interfaces look good to me.
> I'd maybe set the default $algo
Hi Anthony,
I'm not sure about the idea to have a specific SPL for password hashing.
I like the idea to have a standard interface for that but maybe is
enough just a set of functions.
I see a valid argument to have a standard interface especially for the
password_register_algo().
Enrico
2012/6/1
On 18/06/12 18:54, Anthony Ferrara wrote:
> Pierre,
>
>> There is sadly only state-of-art-right-now password hashing methods.
>> We have to keep that in mind :)
> That's why the crypt() return format was designed. All of the options
> that are needed to validate the hash (algorithm, cost parameter,
Enrico
> I like your idea to offer a wrapper of crypt() with a better API
> (actually I used this approach in the ZF2 project:
> https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Password/Bcrypt.php).
Yeah, crypt() is really nice, and offers a lot of good things out of
the box.
2012/6/18 Anthony Ferrara :
>
> That's why the crypt() return format was designed. All of the options
> that are needed to validate the hash (algorithm, cost parameter, salt,
> etc) are fit right into the outputted string.
>
> I'd suggest that's what's done here. In fact, I'd make the functions
> j
Pierre,
> There is sadly only state-of-art-right-now password hashing methods.
> We have to keep that in mind :)
That's why the crypt() return format was designed. All of the options
that are needed to validate the hash (algorithm, cost parameter, salt,
etc) are fit right into the outputted strin
On 18.06.2012, at 19:42, Pierre Joye wrote:
It is BSD-licensed, so we can easily bundle it with PHP
>>>
>>> Maybe nice to have in pecl.'
>>
>> Sure, that's an option, but pecl won't help php to have default
>> "state-of-art" password hashing toolset ;)
>
> There is sadly only state-of-ar
hi,
On Mon, Jun 18, 2012 at 11:06 AM, Alexey Zakhlestin wrote:
> The post says, that SCrypt is better, because it is way harder to solve.
> Bcrypt requires a lot of CPU, but SCrypt requires a lot of CPU + a lot of RAM
Ah right, I read it the other way 'round...
>>> It is BSD-licensed, so we ca
On 18.06.2012, at 1:54, Pierre Joye wrote:
>> I guess SCrypt binding could be implemented.
>> http://www.tarsnap.com/scrypt.html
>
> Using yet another dependency for that? Not good.
That's easier and safer than implementing this on our own.
>
>> That's the best available option at the moment.
hi,
On Sun, Jun 17, 2012 at 3:58 PM, Alexey Zakhlestin wrote:
> I guess SCrypt binding could be implemented.
> http://www.tarsnap.com/scrypt.html
Using yet another dependency for that? Not good.
> That's the best available option at the moment.
> http://stackoverflow.com/questions/1226513/what
On 14.06.2012, at 1:31, Nikita Popov wrote:
> So, wouldn't it be better if PHP provided an easy to use API for
> secure password hashes natively? So you just have to call a single
> function, which magically handles everything for you (like salt
> generation).
>
> A simple sample API could be tw
On 16/06/12 15:39, Pierre Joye wrote:
> However the point here is not the implementation but the APIs.
>
> To be honest I am not a big fan of providing such an API in the core
> as no matter the default implementation, it will become obsolete soon
> or later. And changing the default brings its lot
hi Anthony,
Adding Alex to the loop as his insight will be unvaluable in this thread.
On Sat, Jun 16, 2012 at 2:41 PM, Anthony Ferrara wrote:
>> This userland library already solves all the issues you outlined with
>> bcrypt: http://www.openwall.com/phpass/
>
> That library is not without its i
Herman,
> This userland library already solves all the issues you outlined with
> bcrypt: http://www.openwall.com/phpass/
That library is not without its issues. For example, if you ask for a
portable hash, it gives you a custom algorithm instead of bcrypt.
That's because the library is php4 comp
hi!
hi!
On Fri, Jun 15, 2012 at 6:23 PM, Herman Radtke wrote:
> This userland library already solves all the issues you outlined with
> bcrypt: http://www.openwall.com/phpass/
>
> The API is very easy to use, has been around for a while and has a
> number of detailed articles that explain how to
This userland library already solves all the issues you outlined with
bcrypt: http://www.openwall.com/phpass/
The API is very easy to use, has been around for a while and has a
number of detailed articles that explain how to use it.
--
Herman Radtke
hermanrad...@gmail.com | http://hermanradtke.c
On Wed, Jun 13, 2012 at 2:31 PM, Nikita Popov wrote:
> Hi internals!
>
> Recent incidents have shown that even very large websites still don't
> get how to do password hashing properly. The sha1 hashes used by
> Linkedin et al can be easily cracked even by amateurs without special
> hardware.
>
L
On 14 June 2012 17:50, Ángel González wrote:
*snip*
> May I ask how would you end up at the situation where the attackers have
> the password hashes but not the salt?
>
> Any process which needs to read the password hashes will also need
> knowledge of the salt. Thus an attacker would most likel
On 14/06/12 16:26, Peter Lind wrote:
> I would say it really depends upon the project. The salt can not only
> protect against rainbow tables and password hash collisions, if it is
> unknown to an attacker then it essentially acts to further strengthen
> the hash by vastly expanding the keyspace. S
Peter,
> I would say it really depends upon the project. The salt can not only
> protect against rainbow tables and password hash collisions, if it is
> unknown to an attacker then it essentially acts to further strengthen
> the hash by vastly expanding the keyspace.
That's not true. There are tw
Thomas,
> This:
>
> http://barebonescms.com/documentation/csprng/
>
> Takes a different approach. Generate one or more stored root seeds and then
> use those seeds to generate as much data as is needed without risking loss
> of entropy. It also accepts extra entropy sources as input - even weak
On 14 June 2012 15:35, Anthony Ferrara wrote:
> Peter,
>
>> Whether or not a CSPRNG is needed depends on what you're doing, your
>> needed level of security. Perhaps add a parameter to control this, so
>> it would be possible to make use of this function even if you need the
>> maximum level of se
On 6/14/2012 6:11 AM, Anthony Ferrara wrote:
Daniel,
Stas has the right approach, not only should the methods be simplified and
platform/algorithm agnostic but have a proper salt built in (there are a
few CSPRNG implementations around), I've seen salts used from numbers to
md5's to just being s
Peter,
> Whether or not a CSPRNG is needed depends on what you're doing, your
> needed level of security. Perhaps add a parameter to control this, so
> it would be possible to make use of this function even if you need the
> maximum level of security? If it's not available, the function should
> f
* snip*
>> Stas has the right approach, not only should the methods be simplified and
>> platform/algorithm agnostic but have a proper salt built in (there are a
>> few CSPRNG implementations around), I've seen salts used from numbers to
>> md5's to just being skipped altogether.
>
> Well, just to
Daniel,
> However, I'd like to throw in scrypt as well. Thoughts?
Yes, that's something to include for sure. I've actually been working
on the side on an implementation of scrypt to sit next to my pbkdf2
proposal as hash_scrypt (as the native function, so that it can be
used natively (without the
Hi Nikita,
I think you might just get everyone behind this; easily!
However, I'd like to throw in scrypt as well. Thoughts?
Stas has the right approach, not only should the methods be simplified and
platform/algorithm agnostic but have a proper salt built in (there are a
few CSPRNG implementatio
On 6/13/2012 2:31 PM, Nikita Popov wrote:
Hi internals!
Recent incidents have shown that even very large websites still don't
get how to do password hashing properly. The sha1 hashes used by
Linkedin et al can be easily cracked even by amateurs without special
hardware.
What could be the reason
Hi!
> So, wouldn't it be better if PHP provided an easy to use API for
> secure password hashes natively? So you just have to call a single
> function, which magically handles everything for you (like salt
> generation).
Yes. The fact that crypt() doesn't allow to generate salt automatically
for
I would definetly like that a lot to be the case. bcrypt is kind'a cryptic
and information about cryptography on the internet is not so informative
and are not in abundance.
On Wed, Jun 13, 2012 at 5:31 PM, Nikita Popov wrote:
> Hi internals!
>
> Recent incidents have shown that even very large websites still don't
> get how to do password hashing properly. The sha1 hashes used by
> Linkedin et al can be easily cracked even by amateurs without special
> hardware.
>
>
Hi internals!
Recent incidents have shown that even very large websites still don't
get how to do password hashing properly. The sha1 hashes used by
Linkedin et al can be easily cracked even by amateurs without special
hardware.
What could be the reason for this? Why don't people use bcrypt? It i
39 matches
Mail list logo
