At 10:41 AM -0600 2/9/09, Boyd, Todd M. wrote:
> -----Original Message-----
> From: tedd [mailto:tedd.sperling@xxxxxxxxx]
> Granted, there are things here that are above my head -- I am not
passing myself off as an expert but rather as someone proposing ideas
to see if they pass or fail.
I don't think "Security By Obscurity" gets a fair shake anymore in
today's security world. Sure, it would be horrible to employ it
exclusively, but I think the added layer of abstraction that comes along
with it is a wonderful benefit to any application's security procedures.
The salt itself could be considered security by obscurity, since it is
being passed through the same algorithm as what you're hashing to begin
with. This might be a stretch, though. :)
I say, "Huzzah, tedd. Good idea."
Hash + Obscurity > Hash + Nothing
I understand, but a hash is nothing more than an algorithm. An
algorithm is nothing more that a standardized way of doing something
-- it's the same as a function.
If I add a suffix, or prefix, to a password and use that, it's just
another step in the algorithm process. I have not obscured the
process, I've just added another step to it.
Over the years I have seen all sorts of ways to transmit data from
one point to another, and that's really what we are doing here. We
are just trying to protect the data from when it's exposed to a third
party. There are many ways to do that.
I think the MD5() hash is a pretty good way and if the weakness is
the user's lack of uniqueness in determining their passwords, then we
can focus on that problem instead of looking to another hash. And
besides, the solution presented was to create a salt and use that --
that's just another step in the algorithm process not much different
than what I propose.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
