Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Tuesday March 05 2019, @01:15PM   Printer-friendly
from the push-it dept.

You heard me. You know how weak your user’s passwords likely are. You know your users are almost certainly sharing their passwords with multiple sites. You know that a compromise of your database could lead to significant damage coming to them. You know this because it happens all the time, all over the web.

You have a duty to protect the security and privacy of your userbase. They’ve entrusted you with their data, and it is on you to keep it safe. So why aren’t you doing everything possible to accomplish that task? For this blog, we are going to talk exclusively about password storage.

If you ask just about any security professional in the world how best to store a password, you’re liable to hear something about using a cryptographically secure hashing function “with a salt.” Some will go so far as to mention algorithms like Bcrypt or Scrypt. Very few will make any mention to how password policy plays a significant part in ensuring the security of any stored values.

But almost none of them, will even mention the word “pepper.” Now I suspect this isn’t malicious, (obviously). I think even most security professionals simply aren’t informed enough to know or act with regard to this concept.

So today we’re gonna work on that…


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by bradley13 on Tuesday March 05 2019, @01:49PM (22 children)

    by bradley13 (3053) on Tuesday March 05 2019, @01:49PM (#810240) Homepage Journal

    Yes, and it's really not a bad idea. Not as earth shattering as TFA implies, but not bad at all. The trick would be to keep the pepper as secret as possible: read it from a protected file store or something. Joe Random Intern shouldn't have access to it.

    --
    Everyone is somebody else's weirdo.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Informative=1, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by isostatic on Tuesday March 05 2019, @02:01PM

    by isostatic (365) on Tuesday March 05 2019, @02:01PM (#810245) Journal

    Sure, as long as you also continue to salt it doesn't cause any harm, it's just of very little benefit

  • (Score: 3, Funny) by ElizabethGreene on Tuesday March 05 2019, @02:05PM (2 children)

    by ElizabethGreene (6748) Subscriber Badge on Tuesday March 05 2019, @02:05PM (#810246) Journal

    Another implementation option would be to create a SQL stored procedure to do this. It's another speedbump for the attacker.

    • (Score: 2) by isostatic on Tuesday March 05 2019, @02:08PM

      by isostatic (365) on Tuesday March 05 2019, @02:08PM (#810248) Journal

      A database dump would contain the stored procedure so you're back to square one

    • (Score: 2) by edIII on Wednesday March 06 2019, @05:40AM

      by edIII (791) on Wednesday March 06 2019, @05:40AM (#810585)

      Funny thing is, i pretty much do that. I turn off database logging in a postgres server for auth and use 14 rounds of bcrypt to generate a hash. The hash generation takes 4.7 seconds. That's a speedbump, literally. You're not brute forcing that.

      Bcrypt [postgresql.org]

      --
      Technically, lunchtime is at any moment. It's just a wave function.
  • (Score: 3, Interesting) by JoeMerchant on Tuesday March 05 2019, @02:33PM (17 children)

    by JoeMerchant (3937) on Tuesday March 05 2019, @02:33PM (#810250)

    It's a layer, and like all other layers it's a good thing to confuse the enemy.

    As layers go, it's pretty much a one-trick pony: a single secret applicable to the entire database. Instead of hard-coding this secret I would think it would be more secure to automatically generate a new random pepper value periodically, rebuild the live password database to use the new pepper and then switch it to live use. Still a single secret to obtain, but now you have to obtain the one that matches the database you have a(n ilicit) copy of.

    If you've already done everything else possible/practical to secure the database, then adding pepper is a worthwhile project.

    After adding pepper, you can go for some Habanero: multiple pepper application algorithms - maybe pick 6 of 7 possible pepper application hashing algorithms and apply them in a sequence to be determined by yet another hashing algorithm all based on a combination of the database rebuild's randomly selected key. Etc. etc.

    Yes, it is mostly security by obscurity - which is not a bad thing, as long as the algorithms applied are themselves secure: no algorithms which include a copy of secret data as plaintext, please... If the whole world goes around using a single "proven secure" algorithm, then the day that algorithm is broken, the whole world's secrets are exposed at-once.

    --
    🌻🌻 [google.com]
    • (Score: 0) by Anonymous Coward on Tuesday March 05 2019, @02:42PM

      by Anonymous Coward on Tuesday March 05 2019, @02:42PM (#810255)

      The most secure password is one that is never entered at all.

    • (Score: 2) by meustrus on Tuesday March 05 2019, @05:23PM (3 children)

      by meustrus (4961) on Tuesday March 05 2019, @05:23PM (#810317)

      I would think it would be more secure to automatically generate a new random pepper value periodically

      Not a good idea for this purpose. The goal is to make it harder for the attacker to turn password hashes into plain text. If you change the pepper periodically, an attacker with multiple database dumps will have multiple hashes, making each password and the peppers themselves theoretically easier to crack.

      --
      If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
      • (Score: 2) by JoeMerchant on Tuesday March 05 2019, @06:25PM (2 children)

        by JoeMerchant (3937) on Tuesday March 05 2019, @06:25PM (#810338)

        Not a good idea for this purpose.... an attacker with multiple database dumps will have multiple hashes, making each password and the peppers themselves theoretically easier to crack.

        I guess that depends on your definition of "good idea." My pre-requisite for spending resources on pepper is that the rest of the system is in good shape to start with, not that you use pepper as a band-aid to cover up horrible existing security problems. If your attackers are getting not only one, but multiple database dumps, and yet, somehow, your single pepper value remains secure, then yes, I agree that multiple secure pepper values would be "less secure" when the attacker has multiple database dumps. I would hope to dog that your pepper values are at least 128 bits, preferably 1024 bits or more... so, whereas an un-peppered database has 0 bits of pepper security, and a single 1024 bit peppered database has 1024 bits of security, if a rotating pepper changes daily and an attacker manages to get copies of the database every single day for 3 years running, that would reduce a 1024 bit pepper to roughly 1014 bits of security...

        My premise is rather that nothing, including your pepper values, are 100% secure, so, if you happen to exfiltrate a pepper value or two, and also manage to exfiltrate a copy of a peppered database (presumably this is harder to do without being noticed...), the probability of the pepper you have matching the database you have would be something less than 100% - net increased security vs a fixed pepper.

        Everything depends on circumstances.

        --
        🌻🌻 [google.com]
        • (Score: 2) by meustrus on Thursday March 07 2019, @03:32AM (1 child)

          by meustrus (4961) on Thursday March 07 2019, @03:32AM (#810996)

          Ah, the detail I was misunderstanding was stealing the pepper at a different time than the database. Rotating your pepper would indeed improve that situation.

          This just reminds me of how hard it is to do security right. Everything you can do has trade-offs, and it's not always obvious when doing something to make it more secure actually makes it less so. I'd be interested in a more in-depth discussion of the trade-offs inherent to protecting passwords in a database from leaks.

          --
          If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
          • (Score: 2) by JoeMerchant on Thursday March 07 2019, @04:18PM

            by JoeMerchant (3937) on Thursday March 07 2019, @04:18PM (#811174)

            As I closed with "everything depends on circumstances..."

            Someone else pointed out, quite correctly, that to rebuild the database with different peppers, if you are using non-reversible hashes then you will need to keep an un-peppered copy of the database somewhere... it's possible that this "somewhere" might be substantially more secure than where the live database is stored, or not...

            Of course one could simply apply the pepper as an XOR to the salted passwords in the database. Then, you would only need the current pepper and the new pepper in order to update the database to the new pepper. If multiple copies of the database are being illicitly obtained and the peppering pattern is known, this might make it easy to un-pepper the database, but with a little cleverness - such as a very large pepper (perhaps generated from a "secure" PRNG?) where only small parts of the pepper are applied to each salted password...

            The reality of the situation is: how widely is this algorithm being applied, and by extension: how many people are actively attempting to break it? If you're trying to secure your algorithm against an onslaught of thousands of determined and well resourced attackers, you'd better have a pretty large and clever team helping to design and test it. If you're running a single backwater corporate website that might have 10 or less attackers focused on it over the next several years, you'll probably get better security with a smaller team that has less "human factors" involved in protecting the secrets.

            --
            🌻🌻 [google.com]
    • (Score: 3, Funny) by bob_super on Tuesday March 05 2019, @05:44PM (5 children)

      by bob_super (1357) on Tuesday March 05 2019, @05:44PM (#810326)

      The trick is to have a webcam pointing at your wall.
      Every time you change the post-it with the pepper, have OCR read it and automatically update the password database.
      Repeat the process every time anyone tries to authenticate, never storing the pepper in a silly file, trusting the fan nearby to drop the post-it if you haven't updated recently enough.
      The post-it is both more secure from remote hacks, and allows you to shut down all remote accesses just by turning off the light.

      • (Score: 0) by Anonymous Coward on Tuesday March 05 2019, @05:51PM (1 child)

        by Anonymous Coward on Tuesday March 05 2019, @05:51PM (#810328)

        My office is in San Francisco, and my investment partners would like to hear more...

        • (Score: 2, Informative) by nitehawk214 on Tuesday March 05 2019, @06:59PM

          by nitehawk214 (1304) on Tuesday March 05 2019, @06:59PM (#810365)

          Cloudflare [youtube.com] is already doing this.

          --
          "Don't you ever miss the days when you used to be nostalgic?" -Loiosh
      • (Score: 2) by JoeMerchant on Tuesday March 05 2019, @06:28PM (2 children)

        by JoeMerchant (3937) on Tuesday March 05 2019, @06:28PM (#810340)

        I think your post-it lost its remote hack security the minute you pointed a webcam at it.

        Regardless, there is a certain amount of merit in the idea as an additional unexpected layer of security, and it sounds like a plot element in an upcoming Netflix tech-thriller.

        --
        🌻🌻 [google.com]
        • (Score: 2) by bob_super on Tuesday March 05 2019, @06:30PM (1 child)

          by bob_super (1357) on Tuesday March 05 2019, @06:30PM (#810341)

          > I think your post-it lost its remote hack security the minute you pointed a webcam at it.

          You haven't seen my wall.

          • (Score: 3, Funny) by JoeMerchant on Tuesday March 05 2019, @07:08PM

            by JoeMerchant (3937) on Tuesday March 05 2019, @07:08PM (#810368)

            I think your post-it lost its remote hack security the minute you pointed a webcam at it.

            You haven't seen my wall.

            So, you'll be offloading your OCR to Deep Blue?

            --
            🌻🌻 [google.com]
    • (Score: 0) by Anonymous Coward on Tuesday March 05 2019, @09:45PM (3 children)

      by Anonymous Coward on Tuesday March 05 2019, @09:45PM (#810433)

      the whole world's secrets are exposed at-once.

      And then there would be peace. Imagine... a surprise attack being impossible. I can hide all my pot plants before the cops show up. I'll know if my daughter is sneaking out with that good-for-nothing musician boyfriend of hers again! That sounds wonderful to me!

      I think it's time to reveal, all cryptology is broken. NSA has all the goods, and that's that.

      • (Score: 2) by JoeMerchant on Wednesday March 06 2019, @03:00AM (2 children)

        by JoeMerchant (3937) on Wednesday March 06 2019, @03:00AM (#810558)

        I can hide all my pot plants before the cops show up.

        I don't think you understand how this "all secrets are revealed" thing would work... the cops won't be showing up looking for your pot plants, they'll already know about them, they'll be coming to take you away.

        --
        🌻🌻 [google.com]
        • (Score: 0) by Anonymous Coward on Wednesday March 06 2019, @04:29PM (1 child)

          by Anonymous Coward on Wednesday March 06 2019, @04:29PM (#810748)

          ... HA HA!
          .
          .
          But the joke's on them, I'll be gone too. (Of course you don't think I'd be growing the plants at home, do you?)

          • (Score: 2) by maxwell demon on Wednesday March 06 2019, @09:17PM

            by maxwell demon (1608) on Wednesday March 06 2019, @09:17PM (#810872) Journal

            The joke's on you because they'll already know where you've gone.

            --
            The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 3, Insightful) by Muad'Dave on Wednesday March 06 2019, @12:59PM (1 child)

      by Muad'Dave (1413) on Wednesday March 06 2019, @12:59PM (#810686)

      > rebuild the live password database to use the new pepper and then switch it to live use.

      Given the algorithm of SHA256(password + salt + pepper), doesn't that require you to store the password in the clear? Hash functions are irreversible - you can't 'undo' the previous hash to generate a new one.

      If you do SHA256(SHA256(password + salt) + pepper), storing the inner SHA256 somewhere away from the double SHA value, then you could rebuild the DB, but now you're doubling the compute power needed. Plus, if an intruder gets access to the inner SHA values, he has what's essentially the password and must only guess the pepper.

      • (Score: 2) by JoeMerchant on Wednesday March 06 2019, @03:14PM

        by JoeMerchant (3937) on Wednesday March 06 2019, @03:14PM (#810718)

        Excellent point - surprised it took this long for somebody to catch it...

        There could be a "high security" salted password database somewhere, and the salt & pepper database could be the live use one that's presumably more vulnerable to exfiltration. That would work, but, you're right, it's on the lame side, since the "high security" password database is still lying somewhere with no pepper applied.

        As for doubling the compute power needed to compute the SHA256s - is that really a concern anywhere?

        I'm just distrustful of stale secrets, which a fixed pepper would become. The longer it is in use, the more people will end up knowing it.

        --
        🌻🌻 [google.com]