1. 03 Sep, 2014 1 commit
    • Alex Vandiver's avatar
      Standardize on the stricter Encode::encode("UTF-8", ...) everywhere · 1d18663b
      Alex Vandiver authored
      This is not only for code consistency, but also for consistency of
      output.  Encode::encode_utf8(...) is equivalent to
      Encode::encode("utf8",...) which is the non-"strict" form of UTF-8.
      Strict UTF-8 encoding differs in that (from `perldoc Encode`):
      
          ...its range is much narrower (0 ..  0x10_FFFF to cover only 21 bits
          instead of 32 or 64 bits) and some sequences are not allowed, like
          those used in surrogate pairs, the 31 non-character code points
          0xFDD0 .. 0xFDEF, the last two code points in any plane (0xXX_FFFE
          and 0xXX_FFFF), all non-shortest encodings, etc.
      
      RT deals with interchange with databases, email, and other systems.  In
      dealing with encodings, it should ensure that it does not produce byte
      sequences that are invalid according to official Unicode standards.
      1d18663b
  2. 05 May, 2014 1 commit
    • Alex Vandiver's avatar
      Use quant, even when the value is guaranteedly plural · af16b084
      Alex Vandiver authored
      While in all of these cases, the number in question is guaranteedly
      plural, non-English languages may have more interesting rules for
      pluralization nouns than simply "singular" or "plural."  As such, use
      quant() even when the value in noun form is invariant in English.
      af16b084
  3. 03 Apr, 2014 1 commit
  4. 24 Feb, 2014 1 commit
  5. 07 Jan, 2014 1 commit
  6. 06 Jan, 2014 2 commits
  7. 05 Dec, 2013 1 commit
    • Jim Brandt's avatar
      Store created principal id for use by User and Group · 16cafe40
      Jim Brandt authored
      Principal ids should be the same as their associated user or
      group id, so save the id of newly created principals in the
      RT::User and RT::Group PreInflate calls to be used when the
      user or group record is created.
      16cafe40
  8. 08 Nov, 2013 1 commit
  9. 04 Sep, 2013 3 commits
    • Alex Vandiver's avatar
    • Alex Vandiver's avatar
      SHA-512 passwords before passing to bcrypt for key derivation · 87cf33b8
      Alex Vandiver authored
      The bcrypt key derivation function only uses the first 72 bytes of the
      input; when used directly on a password, this effectively limits
      password length to 72 characters.
      
      Allow for arbitrarily long passwords by hashing the password using
      SHA-512 (which produces 512 bits, or 64 bytes, of output) before passing
      it to bcrypt.
      87cf33b8
    • Alex Vandiver's avatar
      Switch to Blowfish-based bcrypt for password hashing · b0e494c6
      Alex Vandiver authored
      A SHA-512 with a 16-character salt, drawn from 64 possible characters,
      yields 2^96 possible salts.  While this makes rainbow tables unrealistic
      given modern hardware (the failure mode of RT 3.8's MD5 hashing), it
      does very little to deter against offline brute force attacks on the
      database.
      
      Specifically, given the complete hashed password and salt from the
      database, a dictionary of weak passwords can be hashed with the stored
      salt to attempt to find matches.  Given that a single round of the
      SHA-512 hash is not designed to be computationally expensive, possible
      passwords may be hashed and checked very quickly.
      
      The bcrypt hashing function is designed to be computationally expensive
      to mitigate these types of attacks.  For instance, on a development
      laptop:
      
                         Rate   bcrypt  sha-512
              bcrypt   3.34/s       --    -100%
              sha-512 36850/s 1102153%       --
      
      That is, bcrypt is four orders of magnitude slower to compute, thus
      notably increasing the computational cost of brute-forcing passwords.
      bcrypt also includes a tuning parameter, the number of "rounds" to run,
      which allows the same algorithm to be increase the computational cost
      required as computers continue to grow faster.  We use the standard
      value of 10 here, but allow for higher values to be used later.
      b0e494c6
  10. 03 Sep, 2013 6 commits
  11. 20 Aug, 2013 1 commit
  12. 01 Jul, 2013 2 commits
  13. 29 Jun, 2013 1 commit
    • Thomas Sibley's avatar
      Limit User/Watcher subfields for grouping to public attributes · c0b94a16
      Thomas Sibley authored
      At the same time, make a few more useful attributes public under the
      assumption that if you're putting it into RT, you want to be able to use
      it.  The public accessible check still lets _LocalAccessible overlays
      specify public => 0.  We start with a static set of fields rather than
      RT::User->ReadableAttributes since most of the user attributes are
      ~useless for grouping.
      c0b94a16
  14. 10 Jun, 2013 1 commit
  15. 28 May, 2013 2 commits
  16. 23 Apr, 2013 1 commit
  17. 19 Apr, 2013 1 commit
  18. 01 Apr, 2013 1 commit
  19. 28 Mar, 2013 1 commit
    • Alex Vandiver's avatar
      Add a user format between concise and verbose based on Privileged · b12af0df
      Alex Vandiver authored
      The "concise" format, when originally introduced in 07ec5dc4, contained
      similar logic which depended on the state of ->Privileged.  However,
      this was removed in 20d879f2, after it appeared to incur a notable
      performance penalty.
      
      However, upon closer analysis, much of the penalty was incurred by the
      need to render the names of several hundred users for the ShowUser
      dropdown -- a configuration which causes performance penalties
      regardless.
      
      At a possible minor performance cost, use the Privileged bit to control
      how users are displayed.
      b12af0df
  20. 07 Jan, 2013 1 commit
  21. 19 Dec, 2012 1 commit
  22. 23 Nov, 2012 1 commit
  23. 25 Sep, 2012 1 commit
  24. 31 Aug, 2012 1 commit
    • Alex Vandiver's avatar
      Require AdminUser to set PGP private key IDs, not merely ModifySelf · 8ce033b3
      Alex Vandiver authored
      Be explicit that modification of the PrivateKey pseudo-column requires
      admin rights -- namely, AdminUser, not just ModifySelf.  While the page
      that controlls that property is in /Admin/Users/GnuPG.html, accessing
      that page requires only the ShowConfigTab right, and modifying the
      property on yourself required only ModifySelf.  Combined with the
      ability (also granted by ModifySelf) for users to change their own email
      addresses, this opened the possibility for users to claim arbitrary
      private keys as their own, for use in signing.
      8ce033b3
  25. 30 May, 2012 2 commits
  26. 04 Apr, 2012 1 commit
    • Alex Vandiver's avatar
      Ensure that all joins through CachedGroupMembers limits to non-disabled rows · fbef48d9
      Alex Vandiver authored
      When a group becomes disabled in RT, we mark all CGM rows that existed
      because of that group as 'Disabled'.  Unfortunately, many joins through
      CGM neglected to take the Disabled column into account, leading to users
      possibly having rights that they should not, due to having them by way
      of a disabled group.
      
      This addresses CVE-2011-4459.
      fbef48d9
  27. 30 Mar, 2012 2 commits
  28. 14 Mar, 2012 1 commit