[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] Re: Outcome of the Security issue with hashed passwords in C:P:A:Password?
Toby Corkindale toby.corkind...@strategicdata.com.au 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/
[Catalyst] Re: Debian recommendation
Octavian Râşniţă orasn...@gmail.com writes: From: Daniel Pittman dan...@rimspace.net Octavian Râşniţă orasn...@gmail.com writes: As a side note, Octavian, your mail client didn't quote any of my text, which made it quite tricky to work out what you and I both said. ;) I've seen a recommendation on this list for Debian for running perl apps, and recently I started to use this distro. I've seen that I can install perl modules very hard under Debian if I use the CPAN shell. If you forgive me descending into opinion, I think you are approaching this from a point of view that will make Debian, more or less, unhelpful to you. Installing Debian, then putting everything else in place from CPAN (at least system-wide) is going to cause problems in the longer term. Yes I think you are right. I think I would like a distro that allow me to install packages like libpng, libgd and others like these very easy, like yum and apt-get do, but also let me install perl modules with cpan because no distro's repository would be as well updated as CPAN directly. The solution seems to be to use Debian and install perl modules using local::lib. *nod* That, or perhaps investigate something with a ports-alike system, either on *BSD, or Gentoo, or perhaps some other Linux distro. Now, I've started to use a fresh installed Debian and I've installed very many CPAN modules using CPAN in the default perl modules location. What would you recommend me to do in this case? Can I just rename/delete the files and dirs installed into /usr/local/share/perl/5.10.0 and install them using local::lib? If you installed all the modules under /usr/local then you should be pretty OK; Debian deliberately keep that for local software installation, so no package will put things there. You could even keep installing things there if you want; it won't *break* anything — it just won't give you too much value from the Debian part of the equation either. ;) At this point I would suggest one of two things: 1. Delete /usr/local/share/perl/5.10.0/* entirely, and use local::lib 2. Just keep using /usr/local to install stuff system-wide, and accept that this is potentially going to make the wonderful stuff people say about Debian less applicable to your machine. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. ___ 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: Debian recommendation
Octavian Râşniţă orasn...@gmail.com writes: G'day Octavian. I've seen a recommendation on this list for Debian for running perl apps, and recently I started to use this distro. I've seen that I can install perl modules very hard under Debian if I use the CPAN shell. If you forgive me descending into opinion, I think you are approaching this from a point of view that will make Debian, more or less, unhelpful to you. Installing Debian, then putting everything else in place from CPAN (at least system-wide) is going to cause problems in the longer term. Debian has two key advantages over distributions: 1. It has a long stable release cycle, and strong assurances of security during that cycle. 2. It has a very big pool of packages (2,065 Perl libraries, presently) compared to many of the other distributions. The first means that you can safely keep updates in place and be confident that your system will stay working; this includes Perl modules that have security issues and the like, because Debian work very hard to backport security fixes to the same module version. (OTOH, it is also a drawback: if Debian/stable ships with version 1.23 it will still have version 1.23 two years later.) The second means that you have a huge selection of code that you know is going to work together, effectively, and be supported by someone else. If security issues come up, or a library changes incompatibly or whatever, Debian look after it for you. If you just install from CPAN directly then you lose those values: Debian don't do security stuff on your CPAN installed code, so point one is lost. You also don't get the compatibility stuff: the Debian packaging infrastructure and CPAN are not directly integrated, so you can't use a CPAN installed module to satisfy a Debian Perl dependency. That means that you actually have to do /more/ work if you upgrade an existing module under Debian with CPAN, not less, which /really/ misses the point. So, I strongly advise that for, say... [...] cpan install Class::MOP ...this, you instead use 'aptitude install libclass-mop-perl', which uses the Debian supplied version of Class::MOP. Then you can work with that specific version in your software, and know that for the next few years it will stay secure and stable. If you do need packages outside those in Debian, or to upgrade a Debian supplied Perl package, the best strategy is to build a platform package from the CPAN distribution, and manage it with the Debian tools — not the CPAN tool. There are a bunch of ways to do that, including dh-make-perl, dh-make, CPANPLUS::Dist::Deb, and hand-packaging[1]. Then, shove those hand-made packages into your own private Debian package repository, and it integrates nicely into the tools and everything. If you do just want to use cpan directly, either use local::lib, or use a distribution that makes direct installation from CPAN the standard mechanism for getting access to Perl. I understand that the BSDPAN tool, in *BSD ports, as well as Gentoo, offer very good tools in this regard, certainly better and easier than the Debian tools. I can't say much more, though, because I don't have enough deployment experience with them to comment — and there are doubtless other platforms that make CPAN(-alike) tools easier to integrate with the distribution. Regards, Daniel Footnotes: [1] This is probably surprisingly easy, actually, since CPAN packages are simple to configure, build and install, so Debian packages of them are correspondingly easy. Go Perl! -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. ___ 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: Debian recommendation
Paul Makepeace pa...@paulm.com writes: On Fri, Oct 16, 2009 at 7:01 PM, Daniel Pittman dan...@rimspace.net wrote: Octavian Râşniţă orasn...@gmail.com writes: I've seen a recommendation on this list for Debian for running perl apps, and recently I started to use this distro. I've seen that I can install perl modules very hard under Debian if I use the CPAN shell. If you forgive me descending into opinion, I think you are approaching this from a point of view that will make Debian, more or less, unhelpful to you. Installing Debian, then putting everything else in place from CPAN (at least system-wide) is going to cause problems in the longer term. There are a bunch of ways to do that, including dh-make-perl, dh-make, CPANPLUS::Dist::Deb, and hand-packaging[1]. Then, shove those hand-made packages into your own private Debian package repository, and it integrates nicely into the tools and everything. I recently have completely tossed using Debian's perl packages because, while I do love Debian and all its package awesomeness, there simply wasn't the package lib*-perl support in stable/lenny and even testing/squeeze didn't have all the goods needed for a (what I think is) fairly regular Catalyst install. Presumably the packaged Catalyst wasn't sufficient either. ;) So my question then is: given you've presumably done this, which of your quoted solutions do you like best? I tried dh-make-perl many moons ago and gave up due to annoyances around following dependencies. dh-make-perl or debhelper (= 7.0) are the nicest options, in terms of package quality, but don't do anything about following dependencies. dh-make-perl was unmaintained and awful in earlier releases; Lenny is better, and Sid (unstable) better still, but they are still not /great/. CPANPLUS::Dist::Deb is the easiest, but has some quirks; the biggest is that it doesn't check if a packaged-but-not-installed Perl module meets a dependency. Anyway, if it helps: the best answer is to hand the maintenance of the infrastructure to an appropriate expert in the company, and work with them. That may mean Debian packages, or something else, and it probably /also/ means that you can't just deploy the latest CPAN everything — which, yes, is a trade-off on all sorts of levels.[1] I'm hoping local::lib + cpan + git solves this but curious how Debian-integrated solutions work too. If you do want to go the Debian route, you are going to need someone who has a reasonably deep knowledge of Debian Perl packaging at some point, sadly.[2] I generally consider using the dh-make-perl / debhelper 7 tools and manually following dependencies to be a reasonable strategy. This is more work, but results in better considered and higher quality outcomes. (case in point: JSON 1 vs JSON 2, with their incompatible API. If you don't pay attention, upgrading can break other application deployments.) FWIW, local::lib (or the hand-rolled equivalent) is probably the best strategy I can identify for addressing this with the ability to use random CPAN stuff, without breaking other applications, and without the overheads of central management.[3] ...and, again FWIW, my original point was not that the Debian approach is necessarily the best approach, but rather than Debian won't return nearly the same value if you don't accept the costs of their approach. :) Daniel Footnotes: [1] ...and, yes, I do get annoyed by this when I wear a developer hat and all. Heck, for my own local utilities have something like 60 or so Perl modules hand-packaged on Debian/unstable. (Down from 80, because apparently upstream Debian/perl people have the same taste in CPAN modules that I do, so they keep packaging them for me. ;) [2] I strongly suspect this is true of cpan2rpm, and BSDPAN, and the Gentoo tools also, but I have not used them hard enough to find out. [3] I don't think this is actually worth the trade-off in the longer term, since you now have to address questions like deploying bug-fixes in modules for every application (server) independently, but YMMV. -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. ___ 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/
