SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 96 of 96
  1. #76
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    It would make no difference if it were feasible to encode a binary executable (?) but the important thing to note is that a hacker could easily 'wrap' that application and monitor all outgoing/incoming information whilst it's in use. Not only that, but any users logging in whilst the server is compromised are auto-magically screwed.

    The best thing you can do if your server has been infiltrated? Ring up your host - tell them to remove the plug and send you the hard drives via FedEx. Put up a 'maintenance' page. Do this as fast as possible - more than a day of infiltration and you've pretty much lost all hope of being able to prevent them using the data they've already downloaded to their own servers.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  2. #77
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jake Arkinstall View Post
    The best thing you can do if your server has been infiltrated?
    The more interesting question would be how do I know that my server has been infiltrated?

  3. #78
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,271
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    I just want to make sure everyone knows that "security by obscurity" is supposed to be a dirty word. If your site wasn't secure before applying an obscurity solution, then it still won't be secure after. And if your site was already secure, then the obscurity is redundant.

    If you want to store credit cards or other sensitive info, then encrypt using AES. The only question now is where to keep the key. It has to be somewhere the application can access, so keeping it in the admin's e-mail is ruled out. Keeping it with the database should be obviously bad. Keeping it with the application makes sense. Of course, you could try moving the key to some deep, dark, obscure corner of the world, but remember that no matter how obscure, the application still needs access to it, and if an attacker has rooted your application server, then he still has access to the key, no matter how obscure you tried to make it.

    Shorter answer: Encrypt with AES; keep key with application. If database server is rooted, you're OK. If application server is rooted, you're hosed, but there's no way around that.
    "First make it work. Then make it better."

  4. #79
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    65 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    I just want to make sure everyone knows that "security by obscurity" is supposed to be a dirty word. If your site wasn't secure before applying an obscurity solution, then it still won't be secure after. And if your site was already secure, then the obscurity is redundant.

    If you want to store credit cards or other sensitive info, then encrypt using AES. The only question now is where to keep the key. It has to be somewhere the application can access, so keeping it in the admin's e-mail is ruled out. Keeping it with the database should be obviously bad. Keeping it with the application makes sense. Of course, you could try moving the key to some deep, dark, obscure corner of the world, but remember that no matter how obscure, the application still needs access to it, and if an attacker has rooted your application server, then he still has access to the key, no matter how obscure you tried to make it.

    Shorter answer: Encrypt with AES; keep key with application. If database server is rooted, you're OK. If application server is rooted, you're hosed, but there's no way around that.
    We've moved on to encoding, so security by obscurity is all there is really. This whole thread is running under the hypothetical "your hosed" situation. You still want to have your data in the best possible status to prevent extraction.

  5. #80
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,271
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Ahh, I didn't realize we were specifically looking for an obscurity solution. In that case, probably your best bet is Lemon's suggestion a ways back to move the salt/key one more server away.
    "First make it work. Then make it better."

  6. #81
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    We've moved on to encoding, so security by obscurity is all there is really. This whole thread is running under the hypothetical "your hosed" situation. You still want to have your data in the best possible status to prevent extraction.
    I may have an idea then. Make the encrytpion keys for each user very long and scatter them across many tables, databases (on the same or separate machines) and use different types of encryption for each scattered piece and of course set up a large number of various programs, services, scripts, deamons - possibly in different programming languages with as much obfuscated, compiled and encrypted code as possible - each of these programs will process its piece in its own unique convoluted way (hashing, encrypting, encoding, shuffling, transposing, xoring, etc). Then the only way to get a user's key would be to actually run the ultra-complicated mess of thousands of obscure and obfuscated mechanisms on your server that after passing the data back and forth thousands of times and processing them in unexpected ways would eventually end up spitting out the correct key. Then set up appropriate logging mechanisms in all those mechanisms and use them to monitor if they are all executed in the proper and intended way (sequence, time, parameters, etc.). Of course, obfuscate them as much as possible. Additionally, set up services on your server that will monitor how certain system components are run, how files are accessed, etc. and set up traps so that if something is accessed in an unexpected way or any other unusual activity occurs then a specially crafted and encrypted self-desctruct executable is run that immediately destroys all the sensitive data and essential system components so the attacker is made literally helpless in a destroyed and dead system. Don't forget to document all the traps thoroughly for your own use so that you don't destroy your system by a careless mistake. If this happens, hopefully you have your backups - and hopefully the attacker does not.

  7. #82
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    65 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Ahh, I didn't realize we were specifically looking for an obscurity solution. In that case, probably your best bet is Lemon's suggestion a ways back to move the salt/key one more server away.
    No, if there is anything better then I would like to know about it. I want this thread to bring out the best possible solutions.

  8. #83
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    65 Post(s)
    Tagged
    2 Thread(s)
    Looping through the hash multiple times over kill?

    http://alias.io/2010/01/store-passwo...php-and-mysql/

    Also I'm still very interested in discussing encoding data so that it can be read from again.

  9. #84
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,271
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Iteratively re-hashing is not overkill. In fact, that's the core of how key strengtheners work.

    If you want to encode your source code, then probably your best bet is to convert to C++ with hiphop and compile. That way, attackers would have to reverse engineer machine code (or just extract strings, if that's all they need). As a bonus, your code will run significantly faster.
    "First make it work. Then make it better."

  10. #85
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,815
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Let's assume I'm storing credit card information. My web server has been rooted. What are your takes on how this data should have been handled? The encode / decode script?
    Any server where credit card data is stored is NOT ALLOWED to be connected to the internet and so the data will only be accessible to internal staff. This means that encryption of the data is not as important as the other intenal security measures that you need to have in place to prevent your staff misusing the data that they have access to in order to do their jobs.
    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="^$">

  11. #86
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    65 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by felgall View Post
    Any server where credit card data is stored is NOT ALLOWED to be connected to the internet and so the data will only be accessible to internal staff. This means that encryption of the data is not as important as the other intenal security measures that you need to have in place to prevent your staff misusing the data that they have access to in order to do their jobs.
    I thought this was the case. What is the ideal setup so that this information can be stored and used though through a web system (storing credit card for use again)

  12. #87
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,815
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    I thought this was the case. What is the ideal setup so that this information can be stored and used though through a web system (storing credit card for use again)
    Unless you are a bank the simplest solution is to sign up with a merchant facility provider and let them worry about the huge compliance costs involved in credit card processing. (the cost if you have a security breach can easily run into multi-millions).

    Then your sole involvement is in either passing control to a page on their server for the credit card to be entered or if you are collecting it on your HTTPS page your form with the encrypted credit card data gets posted to their facility immediately so that it never gets sent to your server at all and all you need worry about is making sure that you have a valid security certificate for the domain where you have the page with the form.

    See https://www.pcisecuritystandards.org/ for more info on all the things you would need to comply with in order to process credit cards via your own site.
    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. #88
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    65 Post(s)
    Tagged
    2 Thread(s)

  14. #89
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,271
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    By and large, that article is demonstrating brute-forcing using fast clusters of computers. I hate to beat a dead horse, but... key strengthening! Key strengthening will always bypass Moore's law, because you're using computing power to counter computing power. As computers get faster, simply increase the strengthening iteration count.
    "First make it work. Then make it better."

  15. #90
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Its not that simple, just increasing the iteration on key stretching. You will need a transition between the old key stretching and the new. Even then that does not mean you can add a few more iterations to keep up with new hardware unless you also update your server in relation to computer power. You are more then likely to kill your own servers by trying to keep the number of iterations in level with current hardware. Assuming you can even migrate the old passwords.

    In order to keep up with current levels of hardware with key stretching you are going to need the same level of hardware that is used to brute force. This is not something a run of the mill server handling thousands of users every day is going to be able to handle. A resource intensive key stretching would kill your server. Is all about balance.

    This is why I use minor level of key stretching with large, complex keys and salting and peppering. It gives me enough security against brute forcing* without killing my servers.

    * Assuming the attacker manages to get my password database.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  16. #91
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,271
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Well, yes, migrating old passwords adds complexity. But if you're building a new app, then it really is as simple as just increasing the iteration count. And, ideally, you'll implement it in such a way that it's easy to harden an already-strengthened password. I don't think it will kill the servers because you need to perform that slow computation only once when a user creates or changes their password, whereas brute-force attackers will need to iterate that slow computation billions or trillions of times per password.
    "First make it work. Then make it better."

  17. #92
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,815
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    By and large, that article is demonstrating brute-forcing using fast clusters of computers.
    If you lock an account for five seconds after an invalid password has been entered or an attempt has been made to enter a password while the account is locked then a user typing to log in will take long enough to rekey their password that they will not notice the lock but any brute force attempt that didn't have a five second delay between attempts would lock the account if the first guess was wrong and it would then stay locked and ignore even the correct password until five seconds after the last attempt to break in was made. One computer could easily handle making a guess every six seconds so as to get around the lock so adding a trillion more computers to it would not make it any easier to break in.
    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="^$">

  18. #93
    . 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 Jeff Mott View Post
    I don't think it will kill the servers because you need to perform that slow computation only once when a user creates or changes their password...
    And every single time the user logs into their account. That might be fine of small site that have no users, but once you get to the size of Twitter and Facebook, its a much different story.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  19. #94
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    65 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by felgall View Post
    If you lock an account for five seconds after an invalid password has been entered or an attempt has been made to enter a password while the account is locked then a user typing to log in will take long enough to rekey their password that they will not notice the lock but any brute force attempt that didn't have a five second delay between attempts would lock the account if the first guess was wrong and it would then stay locked and ignore even the correct password until five seconds after the last attempt to break in was made. One computer could easily handle making a guess every six seconds so as to get around the lock so adding a trillion more computers to it would not make it any easier to break in.
    Brute forcing as I understand it is not really a problem unless the data has been brought to the local machine, as it was done in the case of the article I posted.

  20. #95
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    And every single time the user logs into their account. That might be fine of small site that have no users, but once you get to the size of Twitter and Facebook, its a much different story.
    I wonder - hasn't anyone made a hardware card for password hashing for example using bcrypt? For busy sites I imagine a whole separate server would be needed just to handle password hashing - if it was possible to simply install such a card that would have some fast chip on it then it would be a very convenient and possibly cheap solution.

  21. #96
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Probably, but the whole idea behind bcrypt and those like it is to prevent hardware acceleration, its purposefully designed to be computationally intensive (aka, super slow).
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.



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
  •