Toby Corkindale <[email protected]> writes:
> On 08/04/10 16:21, Andrew Rodland wrote:
>>> * In what circumstances was an attack possible?
>>> ie. What combination of modules, options, auth methods.
>>
>> * You use Catalyst::Authentication::Credential::Password.
>> * With the "hashed" password_type.
>> * And your database is compromised.
>
> I'd like to follow up that last point, regarding the DB being compromised.
> Is that definitely a requirement for the vulnerability?
Unless you are passing the hashed passwords around as authentication tokens,
yes. Plus, at that point you have already lost.
> I ask because, in many cases, if your DB is compromised, then the horse has
> already bolted.
>
> I understand that isn't the case for everyone, such as payment processors,
> online shops, etc. where actions can be carried out by logged in users that
> cause external effects.. but in some cases, the database IS the website, and
> if you've stolen it, then there's no point logging in as another user
> artificially.
...but your lost database *also* exposed user account/password pairs, which
can now be tried against other services, since people usually use the same
weak password and username all over the place.
>From the app-dev perspective, though, you already lost. :)
> But, yes, it's still worth looking into fixing then I think.
*nod* Unix did, decades back, for much the same reasons other people have
given here.
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
