Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-10186

setupSecurityKey should check character count after whitespace has been stripped

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Trivial - P5
    • Resolution: Fixed
    • 2.4.5
    • 2.5.3
    • Security
    • Fully Compatible
    • ALL
    • Hide

      1)Run mongod with a keyfile produced by running: openssl rand 768 | base64 -w 0

      This key is exactly 1024 bytes long. The size of the output can be computed by (# input bytes) * 4 / 3. This formula comes from the fact that for every 3 bytes of input, 4 bytes of Base64 encoded output are produced.

      2) Run mongod with a similarly sized key with whitespace. This can be made with: openssl rand 768 | base64

      Show
      1)Run mongod with a keyfile produced by running: openssl rand 768 | base64 -w 0 This key is exactly 1024 bytes long. The size of the output can be computed by (# input bytes) * 4 / 3. This formula comes from the fact that for every 3 bytes of input, 4 bytes of Base64 encoded output are produced. 2) Run mongod with a similarly sized key with whitespace. This can be made with: openssl rand 768 | base64

    Description

      setupSecurityKey performs a check to ensure that the input keyFile is less than or equal to 1024 bytes. While processing the file, it will strip out whitespace it encounters. However, this whitespace will still count towards the size limit.

      I believe this is why Windows requires smaller Base64ed keys. Its CLRF encoded linebreaks take up more characters. This is documented at http://docs.mongodb.org/manual/tutorial/generate-key-file/

      Attachments

        Issue Links

          Activity

            People

              spencer@mongodb.com Spencer Brody (Inactive)
              spencer.jackson@mongodb.com Spencer Jackson
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: