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: 0) by Anonymous Coward on Tuesday March 05 2019, @08:40PM

    by Anonymous Coward on Tuesday March 05 2019, @08:40PM (#810412)

    The security steps you take sort of depends on what level you can be compromised.
    My design assumes the application itself and even the webserver have all been compromised. Because this is a thing I've seen happen numerous times.

    I made this assumption because SQL injection is rarely a standalone vulnerability, it's just low hanging fruit and people tend to compromise themselves in ways they don't expect anyways.

    If you upload the source code of your app to a webserver, I can promise that at some point that source code will be available to the attacker.
    If you're storing the salt and/or DB password on the server in a file or as an environment variable, then it leaks the moment your webserver is compromised.
    If you're storing the salt and/or DB password in source code then it's in your git repo. If you're generating any of it on the fly, then it is also in your git repo, just mildly obfuscated.

    Thus salting anywhere in the application layer is a futile exercise, at best you're slowing down the attacker while giving yourself a false sense of security.

    By keeping the DB on a separate physical box, connected to specific secured applications via VPN and limiting your web facing app to only interacting with a couple of DB facing apps and not the DB itself, you break the link and can do more granular things security wise.

    Keeping keys clientside, and only caching a copy of the public key in the DB, attached to an ACL will stop an attacker dead in their tracks if they manage to dump the DB and get a copy of the source code (or engineer enough of it from the error dumps your webapp leaks when they overflow it).

    Imagine how you would do design this if you believed there was a chance that some employee at the datacenter could be compromised at any moment? They might just image the whole drive as part of their daily tasks, and accidentally sell an extra copy to the highest bidder.

    Keep them separate, and make sure no single employee has access to multiple boxen.