[Catalyst] More Application or More Controllers

2010-04-08 Thread Amit Jha
Hi,

Can any body help me on finding out a best way:
I am planning to build an application on catalyst. I have 3 different module 
1. Admin Utility. 
2. Search Utility.
3. Index List Utility.

All modules have lots of jobs to perform.

My question is to create a separate catalyst app for each and put them under a 
directory 
 or 
in single app with different controllers to perform the job.

I am much concern about performance and scalability,

Thanks
Amit










   


  Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! 
http://downloads.yahoo.com/in/internetexplorer/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Re: Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

2010-04-08 Thread Daniel Pittman
Andrew Rodland  writes:
> On Thursday 08 April 2010 08:12:24 pm Toby Corkindale wrote:
>> On 08/04/10 22:49, Daniel Pittman wrote:
>> > ...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.
>> 
>> .. if they are using sufficiently weak passwords, such that they're
>> present in a rainbow table? (Or do such rainbow tables contain every
>> single possible SHA-1 value, ie. from random-looking strings that happen
>> to correspond to the same sha-1 as the actual password?)

The table of every possible 8-byte values is ~ 197MB, and only about 2.3PB for
all possible 12-byte values.  If you eliminate characters that are not going
to be present in passwords (since that is 12! permutations * 256 byte-values *
20 bytes of SHA1) you increase length for the same rainbow table.

So, yes, those contain everything.  You can even download pregenerated rainbow
tables for some lengths, or pay commercial companies for use of theirs, if you
wish.

> Or weak enough to brute-force. Not using salt reduces the difficulty of
> brute- forcing passwords by an order of magnitude (well, some number of
> orders of magnitude depending on the number of users you have) because you
> can make a single cracking run against *all users' passwords in parallel*
> rather than attacking each account individually.

*nod*  Also.
Daniel
-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

2010-04-08 Thread Evan Carroll
I already patched this with a fix, it is on github and I've linked to
it and posted it on rt. Janus told me he would give me maintenance to
post it on CPAN, and he hasn't followed through yet. It fixes the
problem by permitting you to pull in a non-static salt from the DB.

http://github.com/EvanCarroll/Catalyst-Authentication-Store-DBI

-- 
Evan Carroll
System Lord of the Internets

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

2010-04-08 Thread Evan Carroll
Gah, I posted the wrong URL.. If only we moved our mailing list to
AOL, I could undo the send.

http://github.com/EvanCarroll/Catalyst-Plugin-Authentication

Anyway, that's the repo -- Find the commits here:
http://github.com/EvanCarroll/Catalyst-Plugin-Authentication/commits/master

I'm not sure who has maint on C:P:A - i'd be happy to make a release though.

-- 
Evan Carroll
System Lord of the
http://www.evancarroll.com

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

2010-04-08 Thread Andrew Rodland
On Thursday 08 April 2010 08:12:24 pm Toby Corkindale wrote:
> On 08/04/10 22:49, Daniel Pittman wrote:
> > ...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.
> 
> .. if they are using sufficiently weak passwords, such that they're
> present in a rainbow table? (Or do such rainbow tables contain every
> single possible SHA-1 value, ie. from random-looking strings that happen
> to correspond to the same sha-1 as the actual password?)

Or weak enough to brute-force. Not using salt reduces the difficulty of brute-
forcing passwords by an order of magnitude (well, some number of orders of 
magnitude depending on the number of users you have) because you can make a 
single cracking run against *all users' passwords in parallel* rather than 
attacking each account individually.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

2010-04-08 Thread Toby Corkindale

On 08/04/10 22:49, Daniel Pittman wrote:

Toby Corkindale  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.


.. if they are using sufficiently weak passwords, such that they're 
present in a rainbow table? (Or do such rainbow tables contain every 
single possible SHA-1 value, ie. from random-looking strings that happen 
to correspond to the same sha-1 as the actual password?)




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


Although Unix had the problem that the /etc/passwd file was visible to 
all users on the machine, prior to the introduction of the shadowed 
version, and thus anyone could try and brute-force the password hashes.


In most (all) websites today, the authentication database is not 
user-visible.


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Re: Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

2010-04-08 Thread Daniel Pittman
Toby Corkindale  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✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

2010-04-08 Thread Toby Corkindale

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?
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, yes, it's still worth looking into fixing then I think.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/