SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 96
  1. #1
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)

    Let's talk security

    Let's assume for a moment that an intruder has rooted your server. A hacker now has access to your DB which has salted user credentials in it. Assuming you store a unique salt string in each record, you are semi-protected as the hacker would then have to use a library of hashes for each record using the records salt to see if it gets a hit, which I guess is quite a pain but obtainable.

    Certain frameworks such as CakePHP use a static salt string. As the intruder I could then very easily convert my library to that salt and have a go with your users. If something such as ionCube were used on top of CakePHP, would that just about lock it up for an attacker or would they have ability to still obtain some source code?

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    If an attacker has root access to your servers...you have bigger problems then some user passwords.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,061
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    If an attacker has root access to your servers...you have bigger problems then some user passwords.
    What if the attacker only has root access to your database server.

    @K. Wolfe ;, I plan to get to this later today or at worst, sometime this week. I think this could be an interesting topic.
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  4. #4
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by logic_earth View Post
    If an attacker has root access to your servers...you have bigger problems then some user passwords.
    I do? I'd figure a disprut in business would be less painfull than also losing users data.

  5. #5
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Indeed. Though I'm looking at keeping users data safe before my own server.
    That is backwards, you cannot keep user data safe if your own servers are not. You must start with a strong foundation, security must be implemented at the lowest levels (sever, network) before your work on the higher levels (application).
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  6. #6
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by logic_earth View Post
    That is backwards, you cannot keep user data safe if your own servers are not.
    I edited after posting I agree whole heartily, but sometimes that is not always in your control, such as the case with shared hosting.

  7. #7
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,196
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    As logic_earth says, in the event your server has been rooted (which is actually the worst nightmare we can have in this business), you are seriously screwed.

    In these scenarios it is best to actually think about this as the person breaking in, compared to as the developer writing the script. Let's setup a few cases and what could happen.

    1. You have used ioncube or zend on the files.
    This does protect your files from being initially reviewed, and of course the salt string to be shown.

    However, it will not take too long with some investigation and using debugging + use of reflection to get the information you need. Of course by having root access, you would have put these files into a tarball and downloaded them. Please note that no matter the restrictions you have on the encrypted files/license, it wont be a problem to manipulate yourself around those and run the files on a local server.

    In addition you would of course dump the information you needed from the database, so you have it for the future.

    2. You have left the files open.
    In this case the person has access to review the files and get the salt string right away without too much work. And of course he would then get the database information.


    As you can see out of the two, the first one will give you a little more protection, especially if the rooting was done by a script kiddie. But only then.

    In addition, in both cases as the intruder I would be updating your system so that it would leave me a backdoor in case I lose root, but also update it so it would also store your users passwords in clear text the next time they logged in. That way I don't need to brute force some of them.

    Please note that this is just as SIMPLE to do no matter if the files are encrypted or not. In the event they are encrypted all you need to do is rename the real file to a new filename, and create a new file where you store the content of the POST first, and then include the real file.


    So in short, if the server get rooted/breached you are really screwed since that equal to give the intruder access to everything, and your code can be as secure as possible but unless the server is also updated and secured, it is not really worth that much. If you do not trust a hosting service, I would stay far away from it if your planning to host anything else than personal websites.

  8. #8
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    As I understand it, ionCube converts PHP source into byte code. With a little time, and the help of an automated tool, that byte code can be converted back into human readable source. And if the attacker doesn't need the entire source, just one string, then it's even easier.

    Short answer, ionCube will delay, but not stop, an attacker.

    Even better answer... If anyone is using a static salt, slap 'em upside the head.
    "First make it work. Then make it better."

  9. #9
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,061
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    This is where I believe having separate Database and Application servers makes sense. If a hacker gets a hold of one, they still have to work to get a hold of the other. Likewise, limit the access of your database user. For example, deny all direct access to tables, instead grant access to stored procedures and views (if and only if the view does not contain sensitive information).

    If you have a variable salt, yes the hacker may have the source code, but does not have direct access to the database. If the attacker has access to the database, and you salted your passwords (and did not store it in a table), then he is limited in trying to guess the salts to crack the passwords.

    In the end, if an attack has access to a server, you are likely only buying yourself time as he works to figure out how to get the information he wants/needs. Chances are in time he'll figure it out, but hopefully by then you could have adjusted your code and servers accordingly to keep your users better protected.
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  10. #10
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,196
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Even better answer... If anyone is using a static salt, slap 'em upside the head.
    Since a intruder don't need to read your code, in the event a file is encoded using ioncube/zend, all you need is to write some reflection code together with using some debugging tools.

    In the end all use of "salts" when hashing passwords are "static", and no matter how you implement it there is no way around the fact that with a server breach it wont help you squat. It only helps when other parts of the system has been breached.

    Quote Originally Posted by cpradio View Post
    This is where I believe having separate Database and Application servers makes sense. If a hacker gets a hold of one, they still have to work to get a hold of the other. Likewise, limit the access of your database user. For example, deny all direct access to tables, instead grant access to stored procedures and views (if and only if the view does not contain sensitive information).
    Yes, this is something that is recommended on all larger sites or if you store vital information.

    Normally a database cluster will be located on a private network or behind closed down hardware firewalls, so getting access to those servers are usually more difficult than the actual web servers.

    However, in the event your web server is breached you are not really any more protected, other that they wont be able to dump the database. Since your web server will need to be able to get the data from the database, the intruder will be able as well.

    In addition by installing a sniffer software, they can in worst case also get further access to the internal network and servers.

  11. #11
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Even better answer... If anyone is using a static salt, slap 'em upside the head.
    I thought of this while I was setting up CakePHP for a test run. Static encryption and encoding salts..

  12. #12
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,786
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by TheRedDevil View Post
    In the end all use of "salts" when hashing passwords are "static", and no matter how you implement it there is no way around the fact that with a server breach it wont help you squat. It only helps when other parts of the system has been breached.
    Also it shouldn't make a difference to your security if someone can read the salt unless they already have a rainbow table that includes that salt. The fact that there is something added to the password before it is hashed is what "protects" the password - not whether the attacker knows what that extra value is or not.
    Last edited by spikeZ; Nov 1, 2012 at 12:44.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  13. #13
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,196
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Also it shouldn't make a difference to your security if someone can read the salt unless they already have a rainbow table that includes that salt. The fact that there is something added to the password before it is hashed is what "protects" the password - not whether the attacker knows what that extra value is or not.
    That is true, but knowing the salt and the way it is applied does help if your trying to brute force. Since by knowing that you can limit your brute forcing to for example 16 characters in max length, since few people have longer passwords, while if you try to brute force without knowing the salt or how its applied, you would need to set the brute forcing to at least 100-200 characters max length.

    So resource wise, knowing the salt and not least how it is applied does help a lot even if it wont give you the passwords directly.

  14. #14
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TheRedDevil View Post
    In the end all use of "salts" when hashing passwords are "static"
    In the context of this conversation, when we say "static salt", we mean the same salt is used for every password. A "dynamic salt" would mean every password has its own unique salt.
    "First make it work. Then make it better."

  15. #15
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    If were are going to talk about salting now...I'll add my two bits. I'm in the camp that does both, a single site-wide salt that is applied to everyone, a user-specific salt where every user has their own salt, I refer to it as salting and peppering.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  16. #16
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,786
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by TheRedDevil View Post
    That is true, but knowing the salt and the way it is applied does help if your trying to brute force. Since by knowing that you can limit your brute forcing to for example 16 characters in max length, since few people have longer passwords, while if you try to brute force without knowing the salt or how its applied, you would need to set the brute forcing to at least 100-200 characters max length.
    Knowing the salt doesn't change the length of password you need to test for. The attacker is looking for a value that will produce the desired hash to get them in - whether that is the password that the owner uses or a different value that maps to the same hash is irrelevant. For a brute force approach the number of possible values needing testing is determined by the type of hash used and is not affected by any salt and/or pepper that is applied.

    Applying a salt prevents the use of rainbow tables to find a value that will work as the password - since all that is required to find a value that will produce a given hash is to simply record values and their hashes until you have a value for every possible hash and then you can do a reverse lookup of that data to get a value that will work as a password for any unsalted password using that hashing algorithm. When you add a salt then you'd need to repeat the entire process using that salt in order to build a rainbow table for that salt.

    Using a brute force attack instead would take the same number of tries on average regardless of any salt or not.

    Using a pepper instead of or as well as the salt means that finding a rainbow table to get you into one account doesn't also get you into all the others.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  17. #17
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Using a pepper instead of or as well as the salt means that finding a rainbow table to get you into one account doesn't also get you into all the others.
    Using a unique salt for each password is what prevents a rainbow table from being reused for other passwords. A pepper is more like encryption, where the pepper is a private key, and it prevents attackers from brute-forcing passwords, because they won't know the pepper to mix it with before hashing.
    "First make it work. Then make it better."

  18. #18
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by felgall View Post
    Also it shouldn't make a difference to your security if someone can read the salt unless they already have a rainbow table that includes that salt. The fact that there is something added to the password before it is hashed is what "protects" the password - not whether the attacker knows what that extra value is or not.
    Creating a new column with your sites static salted md5s is no task at all. If I have salted all my user passwords with the same salt, an attacker can take their rainbow table and apply that salt to his dictionary probably in a matter of hours. However, if the salt is unique to each record, he would then have to do the same for each record in your db. That is a bit more of a task with today's computing power.


    So we've learned that something like Zends Encryption or ionCube is just a slight delay to the inevitable. It's best to not use a static salt thats stored in your source code anyway and create a unique salt for each record in your table...

    How strong is a unique salt? Do we need more? I wonder if creating some sort of compiled executible for password handling would help. Inside of this executible would be a second salt on top of the one stored in the record. Without seeing the source of this executable, there should be no possibility of using a rainbow table. Can compiled C++ executibles be encoded to be unreadable better than PHP?

  19. #19
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    How strong is a unique salt? Do we need more?
    In the crypto world, a solution is considered secure if the only option available to an attacker is to guess keys or passwords one by one until they happen to stumble across the right one. After implementing a unique salt, you'll have a secure solution. At that point, all an attacker can do is guess passwords one by one per user until he finds the correct one.

    It certainly doesn't hurt to add on top compiling or obfuscating or peppering, but all those are just gravy once you have the cryptographically secure solution.
    "First make it work. Then make it better."

  20. #20
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    In the crypto world, a solution is considered secure if the only option available to an attacker is to guess keys or passwords one by one until they happen to stumble across the right one. After implementing a unique salt, you'll have a secure solution. At that point, all an attacker can do is guess passwords one by one per user until he finds the correct one.

    It certainly doesn't hurt to add on top compiling or obfuscating or peppering, but all those are just gravy once you have the cryptographically secure solution.
    Are we sure that with today's computing power, one couldn't create a rainbow table for each record in the table using the records salt on the fly?

  21. #21
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,061
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    I think the point is, you don't store the salt anywhere, so that the hacker would have to guess it.

    Example of a random/yet reproducible salt: Part of the Username, Part of another required field for registration = salt.

    Granted you need to make sure those fields can't be updated without updating the password (or verifying the current password so you can re-hash their existing password)
    Be sure to congratulate Patche on earning July's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  22. #22
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cpradio View Post
    I think the point is, you don't store the salt anywhere, so that the hacker would have to guess it.

    Example of a random/yet reproducible salt: Part of the Username, Part of another required field for registration = salt.

    Granted you need to make sure those fields can't be updated without updating the password (or verifying the current password so you can re-hash their existing password)
    Right, so this would be just about the same as a random salt stored in the same record. However I'm assuming that the hacker has root and has viewing rights to the PHP file and could potentially read what the salt is or where its taken from.

  23. #23
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Are we sure that with today's computing power, one couldn't create a rainbow table for each record in the table using the records salt on the fly?
    If it's being computed on the fly, then it's not a rainbow table. "Rainbow table" is just a fancy name for a table of pre-computed hashes. And a pre-computed table that has to be computed on the fly is not a pre-computed table at all.
    "First make it work. Then make it better."

  24. #24
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,178
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    If it's being computed on the fly, then it's not a rainbow table. "Rainbow table" is just a fancy name for a table of pre-computed hashes. And a pre-computed table that has to be computed on the fly is not a pre-computed table at all.
    Right, pre computed hashes. So if i know the salt for the entire db, I rehash my dictionary with that salt. How long will that take? One could write a pretty simple application that takes the salt from each record, re hashes the dictionary for that single record, checks for a match, moves on to the next.

    Does anyone know how large dictionaries usually are and how long it might take to rehash the entire db once through on a decent machine?

  25. #25
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,786
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Right, pre computed hashes. So if i know the salt for the entire db, I rehash my dictionary with that salt. How long will that take? One could write a pretty simple application that takes the salt from each record, re hashes the dictionary for that single record, checks for a match, moves on to the next.

    Does anyone know how large dictionaries usually are and how long it might take to rehash the entire db once through on a decent machine?

    How long it would take depends on the hashing algorithm used. An MD5 hash could have the table for a single salt built in a relatively short time whereas with current computing power a top end hash would take trillions of years per salt/pepper.

    If you were going to calculate the all the values at the time of the attack then a brute force approach would be quicker because it would be able to stop when it found a value that worked. A brute force approach is not affected by the application of any salt or pepper as it just runs through values until it finds one that works.


    Also if you have access to the server you can already see all the data other than the original value of the password and so you don't need to work out the password to access someone's data on this site. The only reason you'd be trying to work out their password is in the hope of being able to use it in some other site to access their data there if they were stupid enough to use the same password in both places and if the first value found that works as a password on this site turns out to be their real password and not some other string that maps to the same hash.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •