| *** Joins: dhx1 (~anonymous@60-242-247-232.static.tpgi.com.au) | 00:34 | |
| *** Joins: paulr (~IceChat09@cpc1-enfi15-2-0-cust580.hari.cable.virginmedia.com) | 01:44 | |
| *** Quits: dhx1 (~anonymous@60-242-247-232.static.tpgi.com.au) (Remote host closed the connection) | 04:21 | |
| GitHub36 | [mantisbt] rombert pushed 1 new commit to master-1.2.x: http://git.io/5DpY3Q | 04:21 |
|---|---|---|
| GitHub36 | [mantisbt/master-1.2.x] Fix #13415: cloning issue with attachments doesn't work - Robert Munteanu | 04:21 |
| GitHub31 | [mantisbt] rombert pushed 1 new commit to master: http://git.io/1osfDQ | 04:21 |
| GitHub31 | [mantisbt/master] Fix #13415: cloning issue with attachments doesn't work - Robert Munteanu | 04:21 |
| *** Joins: dhx1 (~anonymous@60-242-247-232.static.tpgi.com.au) | 04:22 | |
| *** Quits: nextgens (~florent@freenet/developer/nextgens) (Quit: Reconnecting) | 08:26 | |
| *** Joins: nextgens1 (~florent@95.154.209.46) | 08:26 | |
| *** Quits: nextgens1 (~florent@95.154.209.46) (Client Quit) | 08:26 | |
| *** Joins: nextgens (~florent@freenet/developer/nextgens) | 08:28 | |
| nextgens | dhx1> I have a few questions regarding the PBKDF2 patch | 08:29 |
| dhx1 | nextgens: hi | 08:30 |
| dhx1 | nextgens: fire away :) | 08:30 |
| nextgens | should the number of iterations increase over time (taking into consideration moore's law)? | 08:30 |
| nextgens | is it acceptable for mantis will get slower and slower? - on the same hardware | 08:30 |
| dhx1 | nextgens: my primary concern is avoiding a DoS attack (also see the reasoning by DJB's use of elliptic curve cryptography in DNSCurve) | 08:31 |
| nextgens | well | 08:32 |
| dhx1 | nextgens: at the rate technology improves, I'd rather we just encourage users to upgrade frequently | 08:32 |
| dhx1 | nextgens: it is reasonable to expect that new security features in browsers/web applications will be produced fairly regularly | 08:33 |
| dhx1 | nextgens: thus I'd rather we encourage users towards the path of remaining current with the times (this same philosophy holds true for the Linux kernel too) | 08:33 |
| nextgens | while I agree with you in theory, my experience has shown me that people don't upgrade | 08:34 |
| nextgens | hence I'm asking whether such a 'feature' makes sense | 08:34 |
| dhx1 | I see where you're coming from | 08:34 |
| nextgens | http://code.bulix.org/m5ub4m-81667 | 08:34 |
| nextgens | that being said, I'd perfectly understand that some people feel that it'd be unacceptable for mantis to be gradually slower over time (on purpose) | 08:35 |
| nextgens | the above is part of the patch I'm using | 08:36 |
| dhx1 | nextgens: do you have an aim for the number of milliseconds worth of work that the key strengthening process uses? | 08:36 |
| nextgens | no, not right now | 08:36 |
| dhx1 | *stretching | 08:36 |
| nextgens | I just use that formula | 08:36 |
| nextgens | php's crypto is awfully slow | 08:37 |
| dhx1 | indeed | 08:37 |
| nextgens | and it won't get PBKDF2 until 5.5 according to what I've read on php-dev recently | 08:37 |
| nextgens | and openssl's bindings suck | 08:37 |
| nextgens | (as in they're both incomplete and slow too) | 08:38 |
| nextgens | now, from a practical standpoint, it'd be way easier to hardcode the number of iterations (so that I don't have to store it) | 08:38 |
| nextgens | but then I feel that chosing what it should be will lead to heated debates | 08:39 |
| dhx1 | nextgens: a good idea -- but also quite complex to implement -- would be to generate the iteration count based on: | 08:39 |
| nextgens | (how many cpu cycles should one consider wasting to handle a login attempt?) | 08:39 |
| dhx1 | 1. maximum calculated compute speed of the server | 08:39 |
| dhx1 | 2. required password validations/second (when also factoring in other workload on the server) | 08:39 |
| dhx1 | or 2b. historical trends for validations/second... a self-learning algorithm | 08:40 |
| paulr | wow | 08:41 |
| paulr | your up late | 08:41 |
| dhx1 | paulr: yes :) | 08:41 |
| nextgens | I've seen people use (1) in other software; personally I don't think it makes any sense | 08:41 |
| paulr | dhx1: when would make sense to release 2.0? | 08:41 |
| paulr | 20/12/2012? :P | 08:41 |
| dhx1 | nextgens: indeed, it is almost impossible to calculate in any meaningful way | 08:41 |
| nextgens | as what really matters is how much horsepower you should assume the attacker to have, rather than how much you're willing to spend | 08:42 |
| nextgens | not to mention that it'll vary over time (or rather it'll be difficult to get an accurate measurement) | 08:42 |
| nextgens | there's also a third approach that I've seen used | 08:43 |
| nextgens | hardcode the number of iterations and 'factor-in' your safety margin | 08:43 |
| dhx1 | I prefer that approach of factoring in a safety margin for the next X years in advance | 08:43 |
| nextgens | ie: assume the software will be deployed and not upgraded for X years, use that iteration count all the time | 08:43 |
| nextgens | ok | 08:44 |
| dhx1 | I just wish BASIC authentication was useful in some way so that browsers could do the busy work | 08:44 |
| nextgens | so that makes things simpler and leads to next question: what should be X and how many iterations does that give us? :p | 08:44 |
| nextgens | there's some schemes like that | 08:45 |
| nextgens | where you can make the client/browser solve a hashcash per authentication attempt | 08:45 |
| nextgens | that's how you solve the DoS problem | 08:45 |
| dhx1 | yep | 08:45 |
| * nextgens suggests to cross that bridge if that becomes a problem, not now | 08:46 | |
| dhx1 | I'm just concerned with putting a huge amount of security (very performance heavy) around the storage of passwords within MantisBT's database | 08:48 |
| nextgens | time php test.php | 08:48 |
| nextgens | real0m0.404s | 08:48 |
| nextgens | that's 10k iterations of sha512 here on a slowish 32bits vm | 08:48 |
| nextgens | with php 5.3 | 08:48 |
| nextgens | I think that's more than affordable, how much 'safety' margin do we want on top? | 08:48 |
| dhx1 | when the more realistic threat is that an attacker can just read the passwords in cleartext (usually /var/www/example.com/mantisbt/... would be fairly easy for an attacker to modify) | 08:49 |
| dhx1 | I'm concerned that 0.404s limits a MantisBT installation to a login rate of 1 attempt per second per core/CPU | 08:50 |
| nextgens | dhx1> I think that mantis should do its due dilligence to ensure that it's non-trivial for someone who gets hold of the db to crack all of the hashes | 08:50 |
| dhx1 | (providing 60% overhead for other work the server is performing) | 08:50 |
| dhx1 | agreed | 08:50 |
| nextgens | but then again, in a typical workflow, users login only once | 08:50 |
| nextgens | and thanks to <other> bugs, they'll stay logged in forever | 08:51 |
| nextgens | it only starts to become a problem under active attack (online bruteforce) or really big setups | 08:51 |
| dhx1 | 65k iterations is about 16 bits of added entropy | 08:51 |
| nextgens | that takes 2s here | 08:52 |
| dhx1 | I should try to work out what the entropy rate of real world passwords is | 08:52 |
| nextgens | I'm not sure how you find out 'added entropy' compared to 'number of iterations' | 08:52 |
| nextgens | it's unrelated I think | 08:53 |
| nextgens | unless you assume the attacker has the same 'cost' than you do | 08:53 |
| nextgens | which he obviously doesn't | 08:53 |
| nextgens | he won't spend 60% of his ressources somewhere else, he won't use PHP | 08:53 |
| dhx1 | entropy is actually the wrong word to use | 08:53 |
| dhx1 | the point is that the size of a hardware cracking circuit (and more importantly, the cost) expands with a higher number of iterations | 08:54 |
| nextgens | how big is the biggest known setup of mantis? how many users are registered? how many genuine logins/hour does such a system handle? | 08:54 |
| dhx1 | so it'll take longer or be significantly more expensive, statistically speaking, to crack an average password | 08:54 |
| nextgens | dhx1> only linearly | 08:54 |
| dhx1 | nextgens: indeed | 08:55 |
| nextgens | whereas increasing the password's entropy increases the complexity exponentially | 08:55 |
| nextgens | but users (don't/can't) do that | 08:55 |
| dhx1 | nextgens: it won't be very high... open source bug trackers would be lucky to have over 100k bug reports... and most viewers will be anonymous | 08:55 |
| dhx1 | nextgens: we're more database bound than anything else | 08:56 |
| nextgens | ok | 08:56 |
| nextgens | so we can afford a high number of iterations | 08:56 |
| dhx1 | yep | 08:56 |
| * nextgens tries 100k | 08:56 | |
| dhx1 | :o | 08:56 |
| nextgens | that's ~3s here | 08:56 |
| dhx1 | if MantisBT was a C++ FastCGI application I'd be happier with 100k | 08:57 |
| dhx1 | at this stage I would like to aim for 100ms calculation time on an average VPS node | 08:58 |
| nextgens | hmm | 08:58 |
| dhx1 | the user could override if necessary | 08:59 |
| nextgens | that'll be a very low amount of iterations | 08:59 |
| nextgens | dhx1> the idea was not to store that value | 08:59 |
| nextgens | (to make the patch simpler/less intrusive) | 08:59 |
| dhx1 | I agree actually... I wouldn't make it a setting because it gets into the realm of micromanagement | 09:00 |
| dhx1 | but a user could still hack the code themselves if they really wanted to (just boost the hardcoded iteration count) | 09:00 |
| nextgens | .1s is ~900 iterations here | 09:00 |
| nextgens | that's very low by today's standards | 09:01 |
| dhx1 | ugh, PHP = :( | 09:01 |
| nextgens | rfc2898 said use 1k in 2000 | 09:01 |
| nextgens | (for another hash method, but still) | 09:01 |
| * nextgens would really like to see more than 10k iterations | 09:02 | |
| nextgens | 50k is 1.5s here (slow 32bits vm) | 09:03 |
| nextgens | sha512 is faster on 64bits | 09:03 |
| nextgens | as long as it's under 2s, I think that users won't notice | 09:03 |
| dhx1 | for a typical MantisBT installation it should be OK | 09:04 |
| nextgens | ok. sorted then. :) | 09:04 |
| dhx1 | given that most users will be logged in via cookie | 09:04 |
| dhx1 | (or anonymous) | 09:04 |
| nextgens | next question | 09:05 |
| nextgens | the salt: | 09:05 |
| nextgens | same thing, I'd like to avoid having to store it | 09:05 |
| dhx1 | and in terms of DoS protection -- there are far more expensive calls an anonymous user could do (resulting in database queries) | 09:05 |
| dhx1 | the salt should be per-user though | 09:05 |
| nextgens | I was thinking hmac(magic_secret,username) | 09:05 |
| nextgens | any other idea? | 09:05 |
| dhx1 | hmm | 09:05 |
| nextgens | where magic secret is a per-installation value | 09:06 |
| nextgens | the username is immutable, right? | 09:06 |
| nextgens | alternatively I could use the row_id (an auto-increment field) | 09:06 |
| dhx1 | nextgens: we don't provide a means in the UI to rename a user... but it would still be possible behind the scenes to do a rename | 09:07 |
| dhx1 | the user_id is a better value to use | 09:07 |
| nextgens | security wise, the salt is there to prevent rainbow-table attacks, it doesn't have to be random | 09:07 |
| nextgens | it has to be non-predictable, that's all | 09:07 |
| dhx1 | yep | 09:07 |
| nextgens | dhx1> my scheme would let you rename the user, provided you reset his password | 09:08 |
| nextgens | (or know it) | 09:08 |
| nextgens | the reason I didn't consider user_id is because code-wise it's a little less intrusive to use the username | 09:09 |
| nextgens | (the row is inserted in create_user, with the current patch I don't change that method at all) | 09:09 |
| dhx1 | $g_crypto_master_salt already exists in the 'master' branch and is used as a secret key for the entire installation | 09:09 |
| nextgens | but I'm happy to change the patch if you feel it's required | 09:10 |
| nextgens | yeah, that's the key of the hmac | 09:10 |
| nextgens | I don't think it's a good idea to use it as-is | 09:10 |
| dhx1 | I think it'd be better to use user_id to prevent any future issues with renaming users, etc... a lot easier in the long run | 09:10 |
| nextgens | and we really want the salt to be different for each user | 09:10 |
| dhx1 | nextgens: the idea of $g_crypto_master_salt was that it would never be used on it's own... it would always be used to derive other salts/etc | 09:11 |
| nextgens | yeah, makes sense | 09:12 |
| nextgens | ok, so hmac(master_salt,user_id) is fine by me | 09:12 |
| nextgens | I'll update the patch accordingly | 09:12 |
| dhx1 | nextgens: now you reminded me that I have to check we're using hmac() instead of just a standard hash function elsewhere in MantisBT for deriving values from $g_crypto_master_salt | 09:12 |
| nextgens | dhx1> I've got two things I'd like to see corrected (will submit different patches) | 09:13 |
| dhx1 | nextgens: we're currently using the Whirlpool hash function (AES-like) | 09:13 |
| nextgens | 1) new password generation is weak | 09:13 |
| dhx1 | nextgens: I assume you're referring to 1.2.x for (1)? | 09:14 |
| nextgens | any specific reason? | 09:14 |
| nextgens | yeah, on 1.2 | 09:16 |
| nextgens | auth_generate_confirm_hash is a case where you should use hmac rather than hash | 09:16 |
| dhx1 | nextgens: something different... + it was recommended by the NESSIE project | 09:16 |
| nextgens | (on 1.3) | 09:17 |
| dhx1 | yep | 09:17 |
| nextgens | not to mention that 384bit of entropy is a waste | 09:17 |
| dhx1 | nextgens: it's more of a convenience that divides nicely into a base64 encoded string that doesn't need any padding | 09:18 |
| dhx1 | 64 characters of base64 encoded output | 09:18 |
| dhx1 | 192bit is probably better though (32 characters output) | 09:19 |
| dhx1 | (in base64 encoding) | 09:19 |
| nextgens | dhx1> it's a slow hash function with no obvious additional security property to SHA-2 candidates | 09:20 |
| nextgens | i'd use sha512 if I were you | 09:20 |
| nextgens | dhx1> anything above 128bits is good enough, shorter URLs/cookies are better | 09:20 |
| nextgens | the cookie will have to be sent for every single request | 09:21 |
| dhx1 | http://www.cryptopp.com/benchmarks.html | 09:21 |
| nextgens | really, you want it small ranther than big | 09:21 |
| dhx1 | Whirlpool = 57MiB/s, SHA-512 = 99MiB/s in that test | 09:21 |
| dhx1 | yes | 09:21 |
| nextgens | that's c++ on old cpus | 09:22 |
| dhx1 | indeed... but still demonstrates relative differences | 09:22 |
| nextgens | sha512 is twice faster ;) | 09:23 |
| dhx1 | ... and also far more likely to have a vectorised x86_64 implementation :) | 09:23 |
| nextgens | I'd understand the choice if we were talking about the password-storage (where we want it slow), but not the 'unique-url' generation | 09:23 |
| nextgens | I'm happy to use whirlpool for password storage if you think it's usefull | 09:24 |
| dhx1 | I'd rather switch to SHA-2 | 09:24 |
| nextgens | ok | 09:24 |
| nextgens | will send a patch for that too then | 09:25 |
| dhx1 | but really don't care too much :) | 09:25 |
| nextgens | there's no dependancy here, it's easy | 09:25 |
| dhx1 | yep | 09:25 |
| nextgens | ok, I'm out of questions for now, thanks for the input | 09:25 |
| nextgens | :) | 09:25 |
| dhx1 | sounds good so far :) | 09:25 |
| dhx1 | I was playing around with PostgreSQL's RBAC (role based access control) features the other day... not sure it's flexible enough for use with MantisBT though | 09:26 |
| dhx1 | + we really need row-level access control for private bugs | 09:27 |
| dhx1 | I've got to head off for now | 09:30 |
| dhx1 | will be back later if you have further questions | 09:31 |
| dhx1 | what you've done so far sounds very promising :) | 09:31 |
| dhx1 | thanks | 09:31 |
| *** Joins: dregad (~dregad@239-26.76-83.cust.bluewin.ch) | 14:43 | |
| *** Quits: dregad (~dregad@239-26.76-83.cust.bluewin.ch) (Quit: We be chillin - IceChat style) | 15:29 | |
| *** Joins: dregad (~damien@239-26.76-83.cust.bluewin.ch) | 15:39 | |
| *** Quits: dregad (~damien@239-26.76-83.cust.bluewin.ch) (Client Quit) | 15:42 | |
| *** Joins: dregad (~damien@239-26.76-83.cust.bluewin.ch) | 15:59 | |
| *** Quits: dregad (~damien@239-26.76-83.cust.bluewin.ch) (Remote host closed the connection) | 15:59 | |
| *** Joins: dregad (~damien@239-26.76-83.cust.bluewin.ch) | 15:59 | |
| *** Quits: dregad (~damien@239-26.76-83.cust.bluewin.ch) (Quit: Ex-Chat) | 16:31 | |
| *** Quits: paulr (~IceChat09@cpc1-enfi15-2-0-cust580.hari.cable.virginmedia.com) (Quit: Friends help you move. Real friends help you move bodies.) | 16:34 | |
| *** Quits: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 17:00 | |
| *** Joins: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) | 17:00 | |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!