Jump to content

0x00

Members
  • Content Count

    120
  • Joined

  • Last visited

Community Reputation

3 Neutral

About 0x00

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. 0x00

    Encryption

    Stupid... lol you're a funny one!
  2. 0x00

    Encryption

    A) PHP-FPM TBH I dunno! The rest yes We've discussed them B) But that's a different thread somewhere... C) No that's for hashes n such but it is for data tampering... N) Why not, I use a web portal for many webApp related api features, great for scoreboards n settings n such.
  3. 0x00

    Encryption

    And that's the point, on a fully compromised system, all the files are accessible too, even the root file used when starting up the database. * You refer to the key, so you can have numerous keys for different purposes (https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html#function_des-encrypt ). I did wonder about the concept of rewriting the keyfile but that would require sudo privileges on the file that we're trying to protect, cyclic madness 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). As you said, manipulating a site key with db user keys would provide a level of protection in the scenario of database compromise only.
  4. 0x00

    Encryption

    Even simple encoding would defeat many script kiddies... What would you suggest then? Some block modes use the previous block as an input, so if they are changed then what's after becomes useless, I'll read up as to which later, but see CBC here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation No, I wasn't saying it did, quite the opposite in fact.
  5. 0x00

    Encryption

    I know its limitations and would prefer to use blowfish and have my choice of block mode (been a while I checked to see what algorithms mycrypt has, but it does give control over block mode). As for perfectly random IV, well, I'll guarantee it to be unique for the key. Data manipulation can be prevented using the right block mode! As you say, storing in session files isn't secure, hence the initial question. Also the single application key is vulnerable to all the aforementioned if has root privileges (if considering key is initialised at mysql startup, e.g. when chrooted) Even if using a standard package, say PGP, the key is required or required to be stored and encrypted by another...
  6. 0x00

    Encryption

    The login system is already as you two are describing, using one way hashing algorithms as signatures for passwords. 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.) The issue is, if say use the login password (or some derivative of it) to encrypt / decrypt then it must be stored somewhere to be used after login, but the issue is the same if use a different password (e.g. at login use user pass to decrypt their encryption password), where to store it, especially with "stay logged in" situations. I understand hashing and that its not actually encryption (as is generally banded about). Here I'm trying to protect user data even if the system is breached at the shell level with escalated root privileges (i.e. they can grab sessions files from /tmp or otherwise). e.g. how to store (non login) passwords on a compromised system? Or even a protocol which keeps them secure from general DB or script hacks (e.g. with file IO as server user / group)
  7. 0x00

    Encryption

    No this is for encryption of stored user content, not hashing.
  8. 0x00

    Encryption

    So, just had a quick play with the built in mysql encryption functions, here's the initial premise: $tn=$db->prefix."priv_store"; $db->table_insert($tn, "'','Title 1',DES_ENCRYPT('my text data','password'),0"); // 1 $a=$db->raw("SELECT * FROM ".$tn.""); foreach($a as $e){ echo "".$e['title']." :: ".htmlspecialchars($e['content'],ENT_QUOTES)."<br />\n"; } echo "<br /><br />\n"; $a=$db->raw("SELECT title, DES_DECRYPT(content,'password') AS content FROM ".$tn.""); foreach($a as $e){ echo "".$e['title']." :: ".htmlspecialchars($e['content'],ENT_QUOTES)."<br />\n"; } When the data is first selected (without password), nothing is retrieved. Which at first glance is probably a good thing. However, at some point I want to offer backup features... To start with when considering key storage my first thought was, if I store users passwords in the database then I may as well not encrypt the data... So my second thought was generate the key based on the users password as they log in and store this key in their session, but that blows the backup question out of the water because nothing is returned if incorrect password passed. I also wondered at the possibility of the case where a cracker has full access to the server and can grab the session files directly (?), also in some cases I do want to offer "stay logged in" feature. Any ideas for this type of protocol? e.g. is it better to use mcrypt with PHP and store the result in the DB, even though that handles the backup situation it doesn't cover the session files. Am I wrong about not being able to get the encrypted data from the DB for backup? etc, etc...
  9. $_GET['number'], etc... others may include $_POST (for items submitted by a form) and $_REQUEST (does both GET or POST in one)
  10. A) Use a cron job to periodically crop the list B) As users add the script also deletes, by... C) Use a last update time, if time over limit then ignore (or in above delete)
  11. No, no globals, a single static class and then everything else comes as functions and classes (except views?). Another reason why I thought of doing this was so I can scan core files for non library usage of functions, as I already do for file access functions (which I wrap anyway.) ... lol I feel bad as I've just used define for 12 ints for request variable type names, but not sure in reality how many percentage of page requests parse form data, I'm sorta just guessing its enough to warrant them...
  12. I'm thinking of replacing all instances of include_once() and writing my own wrapper for it so I can log file usage (for application study only I believe). 1) Is there so little overhead involved that yes wrap and log them. 2) Should I write the include_once() lines in a way that I can easily replace with some regex * There are 69 includes overall according to grep and wc -l
  13. idiosyncrasies Just like with the Sistine Chapel's Genesis fingers, the Devil is in the detail... Happy Hallows’
  14. I believe it works on the next page load, you need to unset variables on this calling. I use set_cookie_params() for some reason I can't remember, but I also generate a new session id, unset the old vars and then refresh the page, just to make sure. // DESTROY SESSION COOKIE by setting expiry date to past session_set_cookie_params(0, $this->cParams["path"], $this->cParams["domain"], false, true); session_start(); // LOGGING ... // DESTROY SESSION, VARIABLES AND ID session_unset(); session_regenerate_id(true); //session_destroy(); header("Location: ".oops_path_self()); exit();
×
×
  • 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.