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.
  2. 24 Feb, 2014 1 commit
  3. 04 Sep, 2013 2 commits
    • Alex Vandiver's avatar
    • 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
      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
                         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.
  4. 01 Nov, 2012 1 commit
  5. 18 Mar, 2011 1 commit
  6. 03 Jan, 2011 2 commits