[Catalyst] Re: Outcome of the Security issue with hashed passwords in C:P:A:Password?
Andrew Rodland and...@cleverdomain.org 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/
[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/
Re: [Catalyst] Distributing and updating Cat apps
On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale toby.corkind...@strategicdata.com.au wrote: We package things up into Debian-style packages, and then upload those to a local repository of packages. Then servers can just be updated using the standard system tools (apt). Hi Toby, This is really the direction I'm heading now (although it's looking like CentOS and RPMs). Can you answer a few general questions? Are you using Template Toolkit? How (or really where) are the templates managed? Where do they get installed, how does the TT View know where to find them, etc? Do they end up in /usr/share/app/ for example? I'm sure you never have to roll-back a release, but I also assume you are prepared to roll-back if needed. How does that process work? What about your static content (css, js, images)? Where do those get installed? Any special tricks when using an app in development vs. production? (For example, under dev I use source css, js, but otherwise the app uses combined and compresses css and js. You have a choice of either packaging up every single Perl dependency into a Debian package too (which is a world of pain), or installing all your dependencies into a local directory that you ship with the application. I recommend the latter.. (you'll still need to include dependencies on things like the C libraries for your database client, etc though, in the debian control file.) We are doing a mix. But, for the most part we are creating single modules (packages). Mostly that was to encourage inclusions of unit tests and just more fine-grained management. But, it is more work, true. -- Bill Moseley mose...@hank.org ___ 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 9 Apr 2010, at 02:58, Evan Carroll wrote: 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. If you want a non-static salt, wouldn't you just use the 'salted_hash' password type in your config? I'd assume the whole point of the 'hashed' type is that you explictly want a common but hidden salt value regardless of how undesirable that is. As far as I can tell, the whole point of this patch is aimed at the 'hashed' password case only (rather than 'salted_hash'). - Mark ___ 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?
As far as I can tell, the whole point of this patch is aimed at the 'hashed' password case only (rather than 'salted_hash'). The vulnerability was never against salted_hash. I've since learned what Crypt::SaltedHash is I just don't believe I have a reason to use it. Why would I want to use something that serializes the hash and password into one database column when I can simply store them separately? Now, I have everything I want running locally. -- 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?
On Fri, Apr 9, 2010 at 12:53 AM, Tomas Doran bobtf...@bobtfish.net wrote: On 9 Apr 2010, at 03:05, Evan Carroll wrote: 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 This is actually a very unhelpful way to supply patches, as it makes the maintainer have to do a whole chunk of work to get as your patch. As such, given limited time, I haven't looked.. The repository URI is in the repository metadata - could you supply a patch (or patches) against the actual repository? Thanks in advance t0m Without any unnecessary commentary, here is the implementation of the password_(pre|post)_salt_field, without other features that should be patched separately. http://codepeek.com/paste/4bbf456c0ae3049443a742a2 I have a commit bit to C::P::A, just want peer review from the owners. I do not have a test in there yet, just wanted something quickly and I'll add some tests in shortly. -Jay ___ 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?
This is actually a very unhelpful way to supply patches, as it makes the maintainer have to do a whole chunk of work to get as your patch. As such, given limited time, I haven't looked.. Here is the patch range for review: http://github.com/EvanCarroll/Catalyst-Plugin-Authentication/compare/f3848f59f08687623cee58a3e5e392491890978b...133341ba8f45fecc3899fe41cc85e92fd20482cb Here are the 4 text diffs: http://github.com/EvanCarroll/Catalyst-Plugin-Authentication/commit/59b2438ca637b7478068f9b1e8aead6772aaa5cf.diff http://github.com/EvanCarroll/Catalyst-Plugin-Authentication/commit/4fae3ba9a5d37ede39e8c351200dd60d8b584f6f.diff http://github.com/EvanCarroll/Catalyst-Plugin-Authentication/commit/e0215b2bc93a2c5cf78a48c9b67fe5ef5196d918.diff http://github.com/EvanCarroll/Catalyst-Plugin-Authentication/commit/133341ba8f45fecc3899fe41cc85e92fd20482cb.diff GIthub also now has SVN support: http://github.com/blog/626-announcing-svn-support -- Evan Carroll System Lord of the Internets 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] Outcome of the Security issue with hashed passwords in C:P:A:Password?
On Fri, Apr 9, 2010 at 8:51 AM, Evan Carroll li...@evancarroll.com wrote: Without any unnecessary commentary, here is the implementation of the password_(pre|post)_salt_field, without other features that should be patched separately. http://codepeek.com/paste/4bbf456c0ae3049443a742a2 I appreciate your efforts. Without any unnecessary commentary (yes, it is all necessary) you can't pry code from my moosified version out, without reading what Moose was offering (namely, the methods you're using like get_config -- I take it you liked it). Your version is a slight disservice as you're ignoring the test patches and docs patches. So what I have 4 patches -- completely lacking negative criticism might I add -- they also put the dev team in the direction they want to go with Moose. Please provide a link to the tests, as I didn't see any modifications in the diffs. get_config could be easily applied. I wouldn't commit this until there are adequate tests, anyway. My specific problems with your patch is: 1) You arbitrarily change the style. It's difficult to find functional changes when every line in the diff is changed so you can change the way spaces are. You did this same thing with Catalyst::View::Email. If you want to propose stylistic changes, do that in a separate patch from functional changes. 2) Adding the salt from the database field doesn't require Mooseification. It does require tests. I didn't see tests. 3) There isn't a problem with going towards Moose. There is, however, a problem with doing 3 different things at once and just saying, It's a point release. This is due diligence, nothing more. I don't like to see large changes to any code I use. I've already had several points of breakage with DBIC (one severe) that are holding me back to previous versions (and still no tuits to fully chase it down beyond a ML post) Authentication is a big deal, and an important component, I want to see good patches go in but care needs to be taken. Understand that your method of submitting patches puts a huge burden on those accepting and integrating those patches. Your brazen attitude makes you easy to ignore, even if the point you raise is valid. ___ 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] Distributing and updating Cat apps
On Fri, Apr 9, 2010 at 4:11 PM, Bill Moseley mose...@hank.org wrote: On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale toby.corkind...@strategicdata.com.au wrote: We package things up into Debian-style packages, and then upload those to a local repository of packages. Then servers can just be updated using the standard system tools (apt). Hi Toby, This is really the direction I'm heading now (although it's looking like CentOS and RPMs). Can you answer a few general questions? Are you using Template Toolkit? How (or really where) are the templates managed? Where do they get installed, how does the TT View know where to find them, etc? Do they end up in /usr/share/app/ for example? I'm sure you never have to roll-back a release, but I also assume you are prepared to roll-back if needed. How does that process work? What about your static content (css, js, images)? Where do those get installed? Considering a Catalyst app is laid out like any standard Perl distribution, using dh-make-perl will generate a pretty standard debian package, so all the stuff in script/ goes to /usr/bin/, and all the other files go in /usr/share/perl5/Dist/Name. To properly include the templates I would just use something like: View::TT INCLUDE_PATH = __path_to(root)__ ... or similar. The static content lives in /usr/share/perl5/Dist/Name/root/static, if you use a caching reverse proxy (like varnish) you can just let Static::Simple serve them, otherwise just point your web server's /static location to that dir. Also, all the stuff produced by your application (uploaded file, whatever) should go in the correct paths (as per FHS), like /var/lib/app-name/ , /var/cache/app-name etc About rollback, it's as simple as installing the old version, all is replaced, but I don't know how you'd handle database schema changes (I use Schema::Versioned a lot, it can probably handle the rollback, but didn't try it so far) Any special tricks when using an app in development vs. production? (For example, under dev I use source css, js, but otherwise the app uses combined and compresses css and js. Handle all this logic from config files and env variables. Take a look at http://www.catalystframework.org/calendar/2009/11 I would argue on keeping outside of the external config files everything that is NOT related to configuration/deployment but is INTERNAL to your application. For instance all the View::TT config could very well be defined in TT.pm and kept in your code repo, while the Model::DB DSN should be in the config file. -- Bogdan Lucaciu http://www.sinapticode.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] Distributing and updating Cat apps
Bogdan Lucaciu wrote on 4/9/10 2:10 PM: To properly include the templates I would just use something like: View::TT INCLUDE_PATH = __path_to(root)__ ... or similar. The static content lives in /usr/share/perl5/Dist/Name/root/static, if you use a caching reverse proxy (like varnish) you can just let Static::Simple serve them, otherwise just point your web server's /static location to that dir. See also Catalyst::Plugin::Static::Simple::ByClass -- Peter Karman . http://peknet.com/ . pe...@peknet.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/
