SitePoint Sponsor

User Tag List

Results 1 to 12 of 12
  1. #1
    SitePoint Addict bronze trophy WolfShade's Avatar
    Join Date
    Mar 2014
    Location
    St. Louis, MO, USA
    Posts
    323
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)

    Question Best practice for storing encryption keys for secure logon

    Hello, everyone.

    What is the best practice for storing encryption keys for secure logons? For example, if I wanted to generate random encryption keys for each user of a web app, I'd need those keys to decrypt for the logon process and other things.

    Thank you,

    ^_^

  2. #2
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,863
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Where you store the encryption keys shouldn't matter. The security shouldn't need to rely on their being kept secret.
    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="^$">

  3. #3
    SitePoint Addict bronze trophy WolfShade's Avatar
    Join Date
    Mar 2014
    Location
    St. Louis, MO, USA
    Posts
    323
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    But, if I store them in the database and someone hacks the database, then they have the way to decrypt the data. How, then, does one encrypt the data so that the hypothetical situation doesn't happen?

    V/r,

    ^_^

  4. #4
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,240
    Mentioned
    194 Post(s)
    Tagged
    2 Thread(s)
    If you use a strong hash the chances that someone will bother to take all the time and resources to decrypt only to "maybe" suceed is extremely unlikely, use a "salt" and it's virtually impossible.

    Unless I'm mistaken, md5 is not preferred but sha1 or other algos are the better options.

  5. #5
    SitePoint Addict bronze trophy WolfShade's Avatar
    Join Date
    Mar 2014
    Location
    St. Louis, MO, USA
    Posts
    323
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    Thank you, felgall and Mittineague, for responding. But (as I understand it), hashing is one way, which is great for just checking that a password is correct. What about decrypting data?

  6. #6
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,240
    Mentioned
    194 Post(s)
    Tagged
    2 Thread(s)
    There's no need to. If someone forgets send a temp one to their email so they can log in and change it to something else if they prefer.

  7. #7
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by WolfShade View Post
    Thank you, felgall and Mittineague, for responding. But (as I understand it), hashing is one way, which is great for just checking that a password is correct. What about decrypting data?
    So it look like there is confusion of terms here, WolfeShade. http://www.danielmiessler.com/study/...ption_hashing/

    If you are looking to be able to read this data again, and you are worried about confidentiality, move this confidential data to a different source (in house) and use encryption. Who will be decrypting this data? What will it be used for? There's definitely no quick answer such as 'move it here and use this', it completely depends on what your dealing with.

    EDIT:

    Looking at your original, your looking at things for a login process, you want to use hashing. You have no need to know what the data actually is, just that it matches.

  8. #8
    SitePoint Addict bronze trophy WolfShade's Avatar
    Join Date
    Mar 2014
    Location
    St. Louis, MO, USA
    Posts
    323
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    So it look like there is confusion of terms here, WolfeShade. http://www.danielmiessler.com/study/...ption_hashing/

    If you are looking to be able to read this data again, and you are worried about confidentiality, move this confidential data to a different source (in house) and use encryption. Who will be decrypting this data? What will it be used for? There's definitely no quick answer such as 'move it here and use this', it completely depends on what your dealing with.

    EDIT:

    Looking at your original, your looking at things for a login process, you want to use hashing. You have no need to know what the data actually is, just that it matches.
    Hi, K. Wolfe,

    Thanks for your reply. Although I did, indeed, mention secure login in my original post, I was also thinking of keeping PII encrypted in case the database, itself, was compromised (name, address, phone, dob, security questions, etc.)

    There is no current project that I am asking about. Just for future reference, as I will soon be working on a project that may or may not have said information in the database.

    V/r,

    ^_^

  9. #9
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,313
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    For passwords, definitely hash.

    For other stuff, you can keep the keys in your application code. After all, your application ultimately needs the keys anyway in order to communicate with the database.
    "First make it work. Then make it better."

  10. #10
    SitePoint Addict bronze trophy WolfShade's Avatar
    Join Date
    Mar 2014
    Location
    St. Louis, MO, USA
    Posts
    323
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    For passwords, definitely hash.

    For other stuff, you can keep the keys in your application code. After all, your application ultimately needs the keys anyway in order to communicate with the database.
    Hi, Jeff,

    If using static key(s) and hard coding it/them into the application is the best way, then which is the most protected scope to put them in? I'm developing in ColdFusion 9/10. I was originally thinking of a random key for each user and somehow keeping something in the database, but I guess that's not really viable.

    V/r,

    ^_^

  11. #11
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by WolfShade View Post
    Hi, Jeff,

    If using static key(s) and hard coding it/them into the application is the best way, then which is the most protected scope to put them in? I'm developing in ColdFusion 9/10. I was originally thinking of a random key for each user and somehow keeping something in the database, but I guess that's not really viable.

    V/r,

    ^_^
    Feel free to also just parse a config file of some sort that is outside of your project directory that will include your credentials. This makes things much safer if your storing your project on a remote source control service (git, svn, etc)

  12. #12
    SitePoint Addict bronze trophy WolfShade's Avatar
    Join Date
    Mar 2014
    Location
    St. Louis, MO, USA
    Posts
    323
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Feel free to also just parse a config file of some sort that is outside of your project directory that will include your credentials. This makes things much safer if your storing your project on a remote source control service (git, svn, etc)
    Good thought. I'll need to start learning about how to access files below the root in CF.

    Thanks,

    ^_^


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
  •