SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 96

Hybrid View

  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,069
    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
    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..

  10. #10
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,069
    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

  11. #11
    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.

  12. #12
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    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
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    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="^$">

  15. #15
    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?

  16. #16
    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."

  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 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."

  18. #18
    . 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.


  19. #19
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,069
    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

  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 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.

  21. #21
    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
    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?
    If the DB has only a static salt, then here's what an attacker would probably do: hash(Salt + common password such as "abc123"), then search the database for that hash. If any user in your entire DB used that password, then in one fell swoop, the attacker would have identified the password for one or maybe multiple users. But if every user has a unique salt, then the attacker can't check all passwords at once. He would need to re-compute the hash for each user.

    How much time it would take depends on the objective and password strength. If the attacker is looking for any random user with a weak password so that he can exploit that user on other sites, then it probably won't take much time. Let's say he has a list of 5 thousand most common passwords, 1 million users in your DB, and 1 ms to compute a hash, then it would take about 2 months to identify the users with weak passwords. (Though, password strengthening can increase that compute time by 100x or 1000x.) On the other hand, if the objective were to attack your site specifically by brute-forcing the admin password (hopefully a strong password of at least 8 mixed case, numbers and symbols) then it would take a couple hundred thousand years.
    "First make it work. Then make it better."

  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 Jeff Mott View Post
    If the DB has only a static salt, then here's what an attacker would probably do: hash(Salt + common password such as "abc123"), then search the database for that hash. If any user in your entire DB used that password, then in one fell swoop, the attacker would have identified the password for one or maybe multiple users. But if every user has a unique salt, then the attacker can't check all passwords at once. He would need to re-compute the hash for each user.

    How much time it would take depends on the objective and password strength. If the attacker is looking for any random user with a weak password so that he can exploit that user on other sites, then it probably won't take much time. Let's say he has a list of 5 thousand most common passwords, 1 million users in your DB, and 1 ms to compute a hash, then it would take about 2 months to identify the users with weak passwords. (Though, password strengthening can increase that compute time by 100x or 1000x.) On the other hand, if the objective were to attack your site specifically by brute-forcing the admin password (hopefully a strong password of at least 8 mixed case, numbers and symbols) then it would take a couple hundred thousand years.
    Assuming the hacker has read access to your source code since he rooted you. He can found out where your salt is being applied before hashing:

    ..Actually.. After starting to write out a loop I realized this can probably be done with one query once syntax was worked out.

    Code:
    select
    u.user_name, u.hashed_password, u.salt, h.common_pass
    from
    common_passes h
    inner join users u on md5(h.common_pass||u.salt) = u.hashed_password
    Not sure if you can access u.salt in this way, but I'm positive there's some way of doing it, perhaps with some sub queries, or a WITH clause. (I think I hear @r937 ; coming)

  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)
    I'm not at all suggesting that you try to hide the salt. If the attacker has access to both your DB and your code, then it wouldn't do any good anyway.
    "First make it work. Then make it better."

  24. #24
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    I have an idea for increasing password security and I wonder what you think about it as I've never seen anyone mention anything like it. Basically, I would not store the salt either in the application code nor in the database so the intruder would not find it there. The salt would be stored on a separate remote server, most probably in a different location, and the main site would contact (for example a php page through https) the remote server for the user's salt each time it is required during authentication. Therefore the salt is not stored anywhere except in PHP memory for a split second of the script duration. Obviously, the intruder would see the PHP code needed to retrieve the salt and he would know the remote URL so he could run it himself but the remote code would check the requester's IP and user agent and if it doesn't match the one specific to the main server then a wrong salt would be sent back without any warning to the intruder, however the remote script would immediately notify the site admin of a possible attack attempt.

    This would work provided the attacker tries to contact the salt server using his own methods since the IP and user agent will be wrong and so he would get wrong salts. When he has wrong salts then he might waste a lot of time trying to brute force a password unsuccessfully. But what if he uses the attacked server to request the salt? I have come up with a second line of defense:

    Each time a user tries to log in their login attempt is logged in the database of the main site. Each time the main site requests a salt from the remote server the remote server stores this request in its own database. So as you can see there are 2 databases with separate logs but these two logs have to match. One login attempt means one request for a salt therefore if the remote database contains salt requests that haven't been logged in the main database then it means someone is trying to break the system. A cron job could be run by the remote server (or any other off-site server) that would compare the logs every couple of minutes and notify the admin of any suspect activity. If the admin can act fairly quickly he may then take appropriate steps to secure his system before any serious damage is done.

    Of course there's the question "what happens in the intruder gets the remote salts in the same way as the original authentication script with storing login attempts in the main database?". I think it would be very unlikely because first he would need to know that storing login logs is essential not to be caught red handed - how would he know that if the hidden detector is not on this server at all? He would need to break to the other server as well but he may not even think he needs to. Second, an intruder most probably doesn't want to leave any trace of his activities so he would certainly craft his script to fetch the salts without storing his actions in the log.

    This solution would certainly require a separate secure and reliable server for keeping and serving salts but in my opinion it would make his job a lot more harder compared to a situation where all passwords and salts are available after breaking into the main server. The main help would be in having a mechanizm that notifies the admin that someone is trying to get to the passwords. What do you think about it? This is entirely my own idea and I wonder if it is any good

  25. #25
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Seems like we keep moving the salt one more server away. First the salt was in the database. But what if the database server is rooted? Move the salt to the application. But what if the application server is rooted? Move the salt to some other remote server. But what if....

    None of these solutions have fundamentally fixed the problem, because the problem is: "What if your servers are compromised." In that kind of scenario, you have to assume that the attacker knows everything and has access to everything.
    "First make it work. Then make it better."


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
  •