Jump to content

scootstah

Staff Alumni
  • Posts

    3,858
  • Joined

  • Last visited

  • Days Won

    29

Posts posted by scootstah

  1. Either of these:

     

    https://github.com/mailhog/MailHog

    http://mailcatcher.me/

     

    Super easy to install and configure, and it provides a web interface on an alternate HTTP port for viewing mail. You can send mail to any email address and they will be captured in one big list in the web interface.

     

    I've used a couple different solutions over the years, including Postfix setups with Squirrelmail or some other web client, but this is far, far better.

  2. I was following through this article here

     

    Well I was going to quote that site but it seems to be down? odd...

     

    If I search opensource xss filters online, many come up, this was suggested by the article

    So you're probably talking about sanitizing output to include some safe HTML, yeah? Allowing any HTML at all should really be avoided. There are better alternatives such as markdown or bbcode.

    • Like 1
  3. However, storing a key in a file does protect in the case of only the db being compromised, not if they can write to php files or execute arbitrary code (or shell).

    Of course not. If your physical box or codebase is compromised then all bets are off. If your app can encrypt/decrypt, then attackers can encrypt/decrypt too (if they have access to your box). There's not really any way to get around that, except to not let attackers compromise your box.

     

    You have to take a step back and assess your realistic threat model here. What exactly are you protecting your data from? If you just want to protect data in your database and over-the-wire, then basic encryption as I've described should be sufficient. If you want to protect your server from NSA scrutiny, then no, you're in way over your head.

  4. Linux distributions maintain their own packages in their own repositories. You will never have the latest version when using default repositories. When the distro maintainers decide that a package version is stable enough and fit for distribution, it will be updated in the repository.

     

    You don't need to bother trying to achieve the latest hot-off-the-press version of software on Linux. If that's what you wanted, you would probably have to compile from source at that point, and then continue doing that every single day for any new releases. Usually you can find newer major versions maintained in third-party repositories, such as for PHP7, which is very easy to install.

     

    But if you just want Apache 2.4, use whatever the distro gives you. If you just want PHP 5.6, use whatever the distro gives you.

  5. Here I'm encrypting (not hashing) actual data which will require to be decrypted, for this a password is required, the question is about how / where to store the user / site encryption password(s). (Personally I'd prefer passwords for each user.)

    You could just store it in the database. But, you'll need to add the user's key to a static, secret site key in some way. If you simply use the user's key from the database to encrypt/decrypt, then the encryption is effectively useless because if there was a database breach, the attackers could just decrypt the data with the stored user key. If you add the user's key to a static site key, they would also have to compromise that key in order to decrypt.

  6. Then you would have to publish your code for people to pay,  download and install on their website; Then someone could do the same and make changes to your extension's code and make it look different and upload to the marketplace to compete against your own product in which it was originally your own.

    Then use proper licensing. If that is too much risk for you then you might as well not bother writing any extensions.

    • Like 1
  7. However what is stopping a developer from taking an entire piece of code and editing every aspect of the file to make it his own?

    Nothing is stopping anyone from doing that. If you can show that code is sufficiently different to the original works, then you legally didn't copy it. Who's to say you didn't both come up with the same idea and just implement it slightly differently? That's why you can't patent code.

  8. In addition, if you try to pull your BS terms of service I'd like to point out the contradiction in it.

     

    "The Company, and agents hereof, will at any given time be allowed to modify, move, or delete your content (including any accounts you may have) and that they in general have full control over your content."

     

    Then you later state.

     

    "By no means will any staff member change a user's account name or delete a user account. So do not ask."

    Just because we can doesn't mean we will.

    • Like 1
  9. Doesn't websockets by default use 80 and 443?  I don't claim to know, and base this on https://en.wikipedia.org/wiki/WebSocket.

    No, websockets do not default to anything. The protocol does not mention implementation details such as port numbers.

     

    If so, could a server that responds to websockets not act as a webserver?

    Sure, you could bind your socket daemon to listen on port 80 or 443. But then you can't run a webserver like Apache.

  10. This is possible with PHP, yes. You don't need to use WebSockets though unless you plan on having a web browser client. You could just use a regular TCP/UDP socket instead.

     

    The firewall would need to allow communication on the selected port.

     

    Start with the manual.

  11. The whole point of hashing properly is if your database is stolen it's not worth it to try and work out the passwords. If you have a salt per password and use something like bcrypt with a decent strength (unlike something like MD5 or SHA1) you're going to be pretty safe.

    Yes, you are correct. Unfortunately, lots of the distributed applications written in PHP make poor decisions such as this.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.