Register

If this is your first visit, please click the Sign Up now button to begin the process of creating your account so you can begin posting on our forums! The Sign Up process will only take up about a minute of two of your time.

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 12
  1. #1
    Senior Member filburt1's Avatar
    Join Date
    Jul 2002
    Location
    Maryland, US
    Posts
    11,774
    Member #
    3
    Liked
    21 times
    I'm thinking of adding security to a database in the following way:
    • Encrypt some of the more sensitive columns (password, e-mail, etc.) using blowfish, 3DES, etc. (not a hashing algorithm like MD5 because the data must be kept intact)
    • Set a connection session variable that contains the private key
    • For every request to write to and to read from an encrypted column, have PostgreSQL automatically recognize that the request is for encrypted data, and appropriate encrypt/decrypt the request/response using the previously set private key.

    This way, the appropriate fields in the database are encrypted, so if the entire database is stolen or broken into, it's useless. Because the private key is set through a session variable and not actually stored anywhere in the database, the data is still effectively unreadable.

    However, I don't know if that last bullet point is doable. Can PostgreSQL or other RDBMSs "autobox" data like that (convert data from one form to another without explicitly being told to)?

    As a final example, this query:
    Code:
    UPDATE users SET password = 'foo' WHERE id = 1
    ...would implicitly update user ID 1's password to an encrypted form of 'foo' rather than the literal text 'foo.' Similarly, this query:
    Code:
    SELECT password FROM users WHERE id = 1
    ...would implicitly decrypt and return the password for user ID 1 rather than return his encrypted password.

    So, possible?
    filburt1, Web Design Forums.net founder
    Site of the Month contest: submit your site or vote for the winner!

  2.  

  3. #2
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    Er... But what happens if the session expires? Where does the private key reside in permanence? (I know I'm not addressing your direct question, but I'm trying to grasp how you want to make this work.)

  4. #3
    Senior Member filburt1's Avatar
    Join Date
    Jul 2002
    Location
    Maryland, US
    Posts
    11,774
    Member #
    3
    Liked
    21 times
    It's the database session, not a PHP session. What would happen:
    1. Database exists with encrypted data and no private key stored.
    2. My PHP application needs to run a query, so it connects to the database. A database connection session starts.
    3. The application runs a query to set a variable for this connection session containing the private key.
    4. The application runs whatever queries it needs for the page.
    5. The connection closes, and implicitly in the process, the session variable is destroyed.

    Therefore, the private key only exists during the life of the connection, so the only point of attack is through the application itself rather than directly through PostgreSQL.
    filburt1, Web Design Forums.net founder
    Site of the Month contest: submit your site or vote for the winner!

  5. #4
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    So you're storing the private key alongside the application on the web server, then? If so, what makes you think that a compromised database server doesn't mean a compromised web server?

  6. #5
    Senior Member filburt1's Avatar
    Join Date
    Jul 2002
    Location
    Maryland, US
    Posts
    11,774
    Member #
    3
    Liked
    21 times
    I can't really think of another way of storing the private key, which is the core problem.
    filburt1, Web Design Forums.net founder
    Site of the Month contest: submit your site or vote for the winner!

  7. #6
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    Well, yeah, that's always the problem Public-key cryptography operates on the assumption that the private key is kept under lock and key at all times. I'm not so sure it's suited to this particular class of problem. It seems like in this case using encryption would be more of a discouragement than a preventative measure. Sure, the person who's just ripping along doing whatever won't be able to get the data, but the guy who really wants to will. And the guy who's just doing whatever can be discouraged just as easily by a simpler method... Maybe even as simple as ROT-13 :-P

    Nonetheless, to address your original question -- I don't know of a way to do that, no. Though depending on Postgre's extensibility (I don't know what it is), maybe you could write a plugin or something?

  8. #7
    WDF Staff smoseley's Avatar
    Join Date
    Mar 2003
    Location
    Boston, MA
    Posts
    9,729
    Member #
    819
    Liked
    205 times
    Hash the password. There's no reason not to.

    As for email... if you must encrypt it, why not just store the key as a constant in your code?

    Maybe you should begin your security dilemma by eliminating the ability of people stealing your database.

  9. #8
    WDF Staff smoseley's Avatar
    Join Date
    Mar 2003
    Location
    Boston, MA
    Posts
    9,729
    Member #
    819
    Liked
    205 times
    Oh, btw, if this is in Java... just make an "Crypt" class that has static methods to encrypt and decrypt data... Crypt.encrypt() and Crypt.decrypt(). Put your key in there as a constant, compile it, and lose the source. Just don't forget the key!!!

  10. #9
    Senior Member filburt1's Avatar
    Join Date
    Jul 2002
    Location
    Maryland, US
    Posts
    11,774
    Member #
    3
    Liked
    21 times
    It's PHP.

    Obviously this is an extra layer of protection on top of other security. If I could 100% ensure that the database could never be accessed, I wouldn't even bother to encrypt things like passwords, but this is just extra insurance.

    (and things like e-mails can't be hashed, unlike passwords)
    filburt1, Web Design Forums.net founder
    Site of the Month contest: submit your site or vote for the winner!

  11. #10
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    Not to mention the fact that reverse-engineering compiled Java code and producing almost identical source-code is generally less-than-difficult. If someone's determined enough to go looking for a private key, then they're probably determined enough to reverse-engineer Java.

    Nonetheless, if you were to take that approach, you could just as easily use it from PHP by running the external Java application to do the encrypting/decrypting.

    I see why you'd do this -- especially with personal information like email. But I'm not sure that it will actually offer a significant security increase. It seems similar to how DRM in HDDVDs/Blu-Ray uses a private key that's already in the hands of the user in the form of a player for the relevant format. If the person can get to the key (and it's fair to assume that if they got to your database, they can probably get to the key)... That's it. It's really down to whether they're interested enough to decrypt the data, and if they aren't, then even simple encryption will likely discourage them. But then, I may be completely wrong.


Page 1 of 2 1 2 LastLast

Remove Ads

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT -6. The time now is 12:04 PM.
Powered by vBulletin® Version 4.2.3
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.
vBulletin Skin By: PurevB.com