Re: [Catalyst] Outcome of the Security issue with hashed passwords in C:P:A:Password?
On Sun, Apr 11, 2010 at 1:08 PM, Evan Carroll li...@evancarroll.com wrote: On Sun, Apr 11, 2010 at 12:31 AM, Andrew Rodland and...@cleverdomain.org wrote: Please, make some more public insults. snip. Guys, just fix or don't fix the broken or not broken problem and stop the crappy-crap-crap line noise. IMHO, with 19 years of experiance under my belt, hashed passowrds use a plaintext random salt pre or post concat (usually pre, so it is an easy and cheap index) with hash as a standard and has been well before sha or md5 (think lessons learned before crypt). In my mind, if that is not the default behavior anytime you expose the word hashed along with password there had better be a very loud callout in docs. I don't know what the fix is -- it seems like doc or code would work. -Wade With love, -- Evan Carroll ___ 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 don't know what the fix is -- it seems like doc or code would work. The patch is already on github, it needs tests and some other qualifications before it gets accepted. -- 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 Sun, Apr 11, 2010 at 12:31 AM, Andrew Rodland and...@cleverdomain.org wrote: Please, make some more public insults. Your modus operandi consists of acting authoritative and aggressive in the hopes of soliciting a negative reaction. I've never seen you be so direct before. I would be even further entertained if you would make more sweeping declarations about modules you didn't even read the documentation for and have never used in your life Would you point to a single accusation that I've been wrong on in this entire thread? and submitted some more patches that duplicate functionality poorly. Feel free to speak your points with patches at your own expense in time: I did. I also don't appreciate you calling my contributions poor, or anyone else's for that matter. You can put on a show all you like for these people. If you keep it up, you can even get me to quit just to avoid your toxic presence. But I know you far too well. You're going to quit what? Mailing list? Tread? Community involvement? Development with Catalyst? Just because you entered into a conversation where you have, so far as I can see, given me little but insults. Ok, lets start the show and select only statements from Andrew Rodland's (hobbs) posts *on this thread about the issue I filed on RT.* We can start with one from this letter: -- Last post Please, make some more public insults. You'll never convince me that you're doing anything but trolling. On that topic, when did you stop being banned on this list? I'm guessing never. -- April 10 * complexity of storing them separately * Why would you add duplicate functionality that's inferior to what it duplicates? -- March 24 (first post, and your personal introduction to the topic) * It would be if anything you said were true; fortunately it's not * both available methods of doing salted passwords with ... Catalyst::Plugin::Authentication do salt entirely the correct way. * Your unncecessary and condescending lectures are, however, greatly appreciated as usual. Ok, March 24, was kind of dude, I probably should have just block quoted the whole response rather than breaking it up into ad hominem statements. I still have your original response from RT. -- RT March 24 * I have no idea what distribution you intended to file this bug against, but it's obviously not the one you *did* file against, which does nothing even vaguely resembling reading salt from a config file. Yea, I'm putting on a show: I'm calling you out. That's me being direct. I've acted hostile to you in the past to my own detriment. In my own mind - and maybe I'm wrong -- I doubt there are many unbiased readers sitting on your side. Oh, and I've never been banned from this list, not even for a second, perhaps you're confusing me for someone else? By any means, wrong again. With love, -- 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 Friday 09 April 2010 09:49:24 am Evan Carroll wrote: 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? Why would you want the complexity of storing them separately when you could do it the way every other system on the planet does it? Why would you add duplicate functionality that's inferior to what it duplicates? ___ 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?
Why would you want the complexity of storing them separately when you could do
it the way every other system on the planet does it? Why would you add
duplicate functionality that's inferior to what it duplicates?
The crypt method might be popular in some applications and in some
libraries; but, it looks to be more code here, and more complexity.
How do you use the crypt message in Bash? How do you, from your DB,
use the crypt method? How would you interface PHP or some other
horridly crappy language into this? Just the work of finding a
respective crypt module looks worse then this:
use Digest::SHA qw(sha1_hex)
sha1_hex( input.password . row.salt ) eq row.salthash
vs, what?
use Crypt::SaltedHash;
my $csh = Crypt::SaltedHash-new('algorithm' = 'SHA-1' );
$csv-validate( row.salthash, input.password, 4 );
Using my method, all I need is a sha1 hash function. This isn't the
best hash, but it works fairly well.
Also, I should point out that Crypt::SaltedHash permits the same
stupid idea of a static, non-random salt set up in the constructor.
This makes it slightly more fishy: why would you ever want to use this
module to do what I just did without it?
# salt: You can specify your on salt. You can either specify it as a
sequence of charactres or as a hex encoded string of the form
HEX{...}. If the argument is missing, a random seed is provided for
you (recommended).
--
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 Saturday 10 April 2010 11:21:27 am Evan Carroll wrote:
Also, I should point out that Crypt::SaltedHash permits the same
stupid idea of a static, non-random salt set up in the constructor.
This makes it slightly more fishy: why would you ever want to use this
module to do what I just did without it?
# salt: You can specify your on salt. You can either specify it as a
sequence of charactres or as a hex encoded string of the form
HEX{...}. If the argument is missing, a random seed is provided for
you (recommended).
That's not why that argument exists, that's not how it gets used, and that's
not how C::A::Cred::Password uses it. If you'd thought for half a second, it
might have occurred to you that that calling convention actually exists to
support exactly what you're asking for -- storing the hash and salt separately
for some bizarre reason despite that each is entirely useless without the
other.
___
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 Sat, Apr 10, 2010 at 5:37 PM, Andrew Rodland and...@cleverdomain.org wrote: That's not why that argument exists, that's not how it gets used, and that's not how C::A::Cred::Password uses it. If you'd thought for half a second, it might have occurred to you that that calling convention actually exists to support exactly what you're asking for -- storing the hash and salt separately for some bizarre reason despite that each is entirely useless without the other. That documentation wasn't from C:A:Cred:Password, it was from Crypt::SH. And, I'm not sure why you would want to use that module IF you're doing things my way (please read previous post). With that said, I'd assume you're right, and that is what the intention is; but, it certainly doesn't seem to make the task at hand any more simple. I'm really only siding with you, because the alternative is to remove the benefit of doubt and assume that the intention was to permit a static salt for all applications of Crypt:SH. Storing things seperate is a bad thing? It actually 1NF. I gave you the bizarre reason for my doing this: you've chosen not to address it on the merits. I've also though for half a second: and, Andrew, I think you should stop responding to my posts. Your inability to behave in a civil fashion is annoying and unbecoming. And, to boot every time you've addressed me on these threads *you've* been wrong. With love, -- 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?
Please, make some more public insults. I would be even further entertained if you would make more sweeping declarations about modules you didn't even read the documentation for and have never used in your life, and submitted some more patches that duplicate functionality poorly. You can put on a show all you like for these people. If you keep it up, you can even get me to quit just to avoid your toxic presence. But I know you far too well. You'll never convince me that you're doing anything but trolling. On that topic, when did you stop being banned on this list? I'm guessing never. ___ 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] Outcome of the Security issue with hashed passwords in C:P:A:Password?
* 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. * Which versions were vulnerable, and if any, at what version were they fixed, if any? All versions. hashed shouldn't be used except by those who have broken and stupid user databases; fixing it isn't possible. What we perhaps *should* do is warn when it's used, and do a better job of marking it as unsuitable for use in the perldoc. * What mitigating factors can be applied to existing systems to reduce their vulnerability to the attack? * Use password_type = salted_hash to get salted hashes. * Or use password_type = self_check and a store that provides secure password handling via the user object, e.g. Catalyst::Authentication::Store::DBIx::Class w/ DBIx::Class::EncodedColumn on the user table, or Catalyst::Authentication::Store::LDAP (plus a suitable configuration on your LDAP server; some of them will allow you to do stupid things like plaintext passwords, but we can't help that). * If you have a user database that uses plain hashed passwords, start figuring out how to change over to a proper method and how to force all of your users to reset their passwords. ___ 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/
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] Outcome of the Security issue with hashed passwords in C:P:A:Password?
So, a while back there was some.. slightly heated.. discussion about security issues with C-P-A-Password.. or perhaps one of the modules it uses internally.. in certain cases, if certain options are, or are not, set. Then it quietened down without any apparent conclusion being reached. Now that some time has passed, I wondered if someone could provide a synopsis of the outcome of these investigations and discussions? In short: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * Which versions were vulnerable, and if any, at what version were they fixed, if any? * What mitigating factors can be applied to existing systems to reduce their vulnerability to the attack? Thanks, Toby ___ 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 Wed, Apr 7, 2010 at 6:15 PM, Toby Corkindale toby.corkind...@strategicdata.com.au wrote: So, a while back there was some.. slightly heated.. discussion about security issues with C-P-A-Password.. or perhaps one of the modules it uses internally.. in certain cases, if certain options are, or are not, set. Then it quietened down without any apparent conclusion being reached. Now that some time has passed, I wondered if someone could provide a synopsis of the outcome of these investigations and discussions? In short: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * Which versions were vulnerable, and if any, at what version were they fixed, if any? * What mitigating factors can be applied to existing systems to reduce their vulnerability to the attack? Thanks, Toby In my opinion, a non-issue from the start unless you specifically enable the I want a weak crypt option. C::P::A defers to Crypt::SaltedHash, which handles everything fine. The ticket is still open because Evan is going to look into it further. You can follow the ticket at https://rt.cpan.org/Public/Bug/Display.html?id=55850 -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/
