> While my opinion of you is not favorable, I do believe that we should
> always look at reports without seeing who filed them and react
> accordingly.
duly noted.
> The option for 'hashed' does what you are talking about, and the
> documentation clearly lists the differences here.
Yes, well I d
On Wed, Mar 24, 2010 at 11:13 AM, Evan Carroll wrote:
>> It would be if anything you said were true; fortunately it's not, and both
>> available methods of doing salted passwords with
>> Catalyst::Plugin::Authentication do salt entirely the correct way.
>>
>> Your unncecessary and condescending le
> It would be if anything you said were true; fortunately it's not, and both
> available methods of doing salted passwords with
> Catalyst::Plugin::Authentication do salt entirely the correct way.
>
> Your unncecessary and condescending lectures are, however, greatly appreciated
> as usual.
While
> I'll still chase this up tonight so that we're all clear if there is a
> potential (but very limited) issue or not :)
The issue here is the implementation of salt gives you a false sense
of security. If you aren't worried about rainbow attacks simply don't
use salt at all. It should be noted tha
> P.S. Yes, I appreciate that the attack surface is fairly limited here, bit I
> feel the point still holds.
I disagree, I wouldn't want to extend my fame into publicizing a
massive security vulnerability. I think this one stems from a
misunderstanding of salting. I've forked C:P:A on gitpan and I
Tomas Doran wrote:
P.P.S. I expect to be uploading a fix this in the next 24-48 hours for
anyone who concerned that evil people in possession of their application
configuration are generating the relevant rainbow tables right now...
Well, having read the other followups (bah, my home internet
On 23 Mar 2010, at 20:17, Evan Carroll wrote:
This is broken implementation. Hard coding salt in a config file only
protects you from a rainbow table without that salt. It still doesn't
solve the problem of cached hashings.
Thanks for the responsible disclosure of a potential security
vulner
On Tuesday 23 March 2010 03:17:17 pm Evan Carroll wrote:
> This is broken implementation.
It would be if anything you said were true; fortunately it's not, and both
available methods of doing salted passwords with
Catalyst::Plugin::Authentication do salt entirely the correct way.
Your unncecess
https://rt.cpan.org/Ticket/Display.html?id=55850&results=a52c3c931cac70fddd2e1926e2f4280a
The purpose of salt is to reduce the ability for a single (pre-calculated)
rainbow table of passwords and hashes to compromise the whole store. If
your salt isn't a random function, or specific to the user th
