Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61263
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKZjf5Tu=8QU5pQ-TfPU3+LKwa97CuHRH6W0=Loi_RPaK9YPiA@mail.gmail.com>
References: <CAAyV7nFRT24rksh6iDWxstfQwJ4+KdEC7Zs6EC8wBtJ8Zorf7w@mail.gmail.com>
	<CAKZjf5ROuK-Kt1GAPJm0A2-mksw2kJ7C4bOMtz1+dPrYheqzSA@mail.gmail.com>
	<CAAyV7nFBk1j20LiYvz--2K+BPNgm6_WEGPtY0t5oC57PhCupVg@mail.gmail.com>
	<4FFFF84D.9070202@rotorised.com>
	<5000990F.30105@gmail.com>
	<CAKZjf5SLGV92xrynnHdBRexczOhryuJBQVyZpbKsTnQ1iPx94g@mail.gmail.com>
	<CAN+gjSfuhkupfhV-fvZBMHTF8JQ_HF7KhOkj6j1we14mL1HCog@mail.gmail.com>
	<CAKZjf5Tj_3c7T9zZBv8Tztvqa5zeJRAHHe7_HQNpCijsUz-qtA@mail.gmail.com>
	<CAKZjf5Sf7FBqMwQwuoyLm6OEQLO3wBf0yHoVCCHE2envwqdSQQ@mail.gmail.com>
	<50033454.6080100@gmail.com>
	<CAKZjf5Tu=8QU5pQ-TfPU3+LKwa97CuHRH6W0=Loi_RPaK9YPiA@mail.gmail.com>
Date: Sun, 15 Jul 2012 20:13:11 -0400
Message-ID: <CAAyV7nEAJuprRBAG4+vqWVuTd1HAYF5TxAgJ7FUwM5GXqZhwuQ@mail.gmail.com>
To: Alex Aulbach <alex.aulbach@gmail.com>
Cc: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>, 
	internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf30363cd19cee1604c4e74b2a
Subject: Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified
 password hashing functions
From: ircmaxell@gmail.com (Anthony Ferrara)

--20cf30363cd19cee1604c4e74b2a
Content-Type: text/plain; charset=ISO-8859-1

Alex,

On Sun, Jul 15, 2012 at 7:19 PM, Alex Aulbach <alex.aulbach@gmail.com>wrote:

> Ok. I think, I go too much off topic. Sorry.
>
> But I want to repeat
> - we never know in which context the program will run. And good
> security means, thait it shouldn't care, in which context it runs.
>

Could you explain what you mean by context here? I'm not following...


> - everything, which can go wrong will go wrong (Murphy); if there is
> any chance to make it wrong, there will be someone, which make it
> wrong. (and in this case they will point to PHP: "see, I have said it
> is unsecure..." :) ).
> - in security context this means: The hashes will be stolen/we can
> login without password etc.
> - No documentation or any other thing can prevent that
>

You can not make something idiot proof. If you try, the universe will just
invent better idiots.

Instead, as long as the function works in a sane manner, and the
documentation reflects the edge-cases and concepts, I think it's fine.


> - So we need to do everything, which is possible to avoid it. The best
> thing would be, that we can guarantee, that it is not possible.
>

If that was the case, there would be no PHP or any other language for that
matter. You can't stop people from being stupid. What you can do however is
make the documentation and implementation so bloody easy to use that *I
didn't know* becomes the only sane excuse...


> - As positive side-effect we can have more possibilities in PHP :)
>
>
> More off topic:
> Let me explain that last sentence: I dont know exactly how this can be
> implemented, but I think every warning, error and so on could be an
> exception instead. Just an idea, but I think this can remove
> complexity, because - even if I think the current error-handling is
> quite well designed - it is a source of sercurity-problems (and some
> other more or less ugly things). I think about a default
> exception-handling which can be overridden (like the error-handlers).
> Could be an interesting concept. :) And of course its something which
> needs time.
>

The default exception handling can be overriden today:
http://us2.php.net/set_exception_handler

But I agree with your larger point. The only problem with it is that it
would take an engine wide shift to do. Which I think is out of scope for a
point release, and there's no reason (that I can see) to tie this
implementation to that shift. Let's implement this with the normal error
handling methods, and then handle it uniformly later...

Anthony

--20cf30363cd19cee1604c4e74b2a--