[Catalyst] More Application or More Controllers
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"?
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"?
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"?
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"?
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"?
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"?
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"?
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/