#1
  1. Crypto-Con
    Devshed Supreme Being (6500+ posts)

    Join Date
    Apr 2004
    Location
    Frisco, Texas
    Posts
    6,704
    Rep Power
    1236

    Security and Cryptography Community FAQ


    The security/crypto forum is old enough that I think we can identify many frequently asked questions. We have no FAQ yet, so I think it's time for one.

    ----------------------------

    FAQ Index
    * How should I manage encryption IVs?
    * How does SSL work and/or how can I keep my SSL server secure?
    * I think my webserver was hacked -- how can I be sure?

    Please do not post questions regarding these subjects or any posts in the FAQ -- start a thread for your specific question.

    Contributers
    To contribute, just add a post addressing a common question. Post one question/answer combo per post (so that each question can be linked to individually). Please bold the question you are answering at the top of your post to make the question you are answering obvious (or put the question as your post's subject). I will periodically update this top post to maintain an index of answered questions.

    Anyone can contribute an answer. Make sure it is thorough, but not excessively exhaustive. The goal should be to help the reader enough to either a) answer their question, or b) post a more detailed question.

    Outside links are welcome, but the bulk of an answer should be the author's own writing. After the answer, links to any existing threads on the topic are also welcome.

    Discussion of FAQ answers in this thread is welcome. If anyone has a point to raise about an answer, they may certainly do so. Authors of answers should feel free to edit/refine their posts to their liking if a discussion raises any new points. After a discussion about a topic has ended, however, all posts that are not specifically an answer an FAQ or that do not contain further necessary information are subject to deletion to preserve the clarity of the thread. (If it's extensive enough, the discussion could be split into its own thread.)

    Many questions that may belong here have no doubt already been answered in the forum. Feel free to copy a post you've already written as an answer to a question here. Or edit your answer a bit and then post it here -- whatever results in getting a good answer to an FAQ.

    Requested topics
    * (How) Should I store credit card numbers? -> (Fish: Feel free to copy from your previous answers.)
    Last edited by B-Con; August 20th, 2008 at 11:47 PM.
    - "Cryptographically secure linear feedback shift register based stream ciphers" -- a phrase that'll get any party started.
    - Why know the ordinary when you can understand the extraordinary?
    - Sponsor my caffeine addiction! (36.70 USD received so far -- Latest donor: Mark Foxvog.
    )
  2. #2
  3. Crypto-Con
    Devshed Supreme Being (6500+ posts)

    Join Date
    Apr 2004
    Location
    Frisco, Texas
    Posts
    6,704
    Rep Power
    1236

    How should I manage encryption IVs?


    How should I manage encryption IVs?

    If you have encrypted content, you should have used an IV in the process. An IV prevents two messages with the same key from encrypting to the same ciphertext, which protects the ciphertext from various cryptographic attacks that can exploit such an occurrence. Depending on whether the encryption algorithm you used is a block cipher (such as AES, DES, TwoFish, etc) with a certain <a href="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation">block feedback method</a>, or a stream cipher (like RC4) will dictate how the IV is used in the encryption process, but likely/hopefully you're using an encryption library and don't care about the details. As far as you, the developer, are concerned, you just have an IV to keep track of.

    Thus a common problem encountered by those writing code to manage encrypted content is how/where to store the IV. Since the IV will be an input to the decryption process it looks like sensitive information best kept a secret, so many developers may initially hesitant to include the IV in their output ciphertext file.

    However, due to the way that IVs are used, the IV is not sensitive information. It is standard, recommended practice to store the IV with the output ciphertext, usually as a header to the ciphertext. The technical details are not that complicated, but the simple reason is that the IV is used somewhere in the first step of encryption to make a random change to the encryption state. This change has no significance whatsoever but to ensure the . Tattoo it on your arm, its secrecy is irrelevant.
    Last edited by B-Con; August 20th, 2008 at 11:41 PM.
    - "Cryptographically secure linear feedback shift register based stream ciphers" -- a phrase that'll get any party started.
    - Why know the ordinary when you can understand the extraordinary?
    - Sponsor my caffeine addiction! (36.70 USD received so far -- Latest donor: Mark Foxvog.
    )
  4. #3
  5. Crypto-Con
    Devshed Supreme Being (6500+ posts)

    Join Date
    Apr 2004
    Location
    Frisco, Texas
    Posts
    6,704
    Rep Power
    1236

    How does SSL work and/or how can I keep my SSL server secure?


    How does SSL work and/or how can I keep my SSL server secure?

    In short, SSL uses a digital certificate to convince an arbitrary client that a server's public key is both authentic and secure. Then the client and server's public and private keys are used to exchange encrypted, randomly-generated symmetric keys, which are then used to encrypt the SSL-protected session data between the hosts. Symmetric keys are used for the encrypting of actual data because public key encryption is very slow, it is hundreds of times more efficient to just encrypt one small string with via public key and everything else via symmetric key than it is to encrypt the entire data stream with via public key. (Encrypting everything via public key would send popular SSL servers, like Amazon, to their graves, as their servers would spend possibly minutes encrypting each web page request.)

    Keeping the server's private key private is the key part of HTTPS, because an attacker who knows it can launch a successful man-in-the-middle attack. Once the server's private key is known, all security from SSL is lost. (Since the server doesn't care who connects to it the client's private key is arbitrary in a typical client-server HTTPS connection.)

    There are three ways to preserve the security of your SSL key:
    1) The best way is to keep the server itself secure. The SSL private key must be kept somewhere on the server, thus access to the server could lead to access to the key.
    2) The file in which the key is stored should be owned and readable only by the root user. If someone hacks into the system, they likely (hopefully?) won't start out with root privileges.
    3) You can also encrypt your key file. If the key file is encrypted, then you will have to supply the program (such as Apache) that reads the key file with the password to decrypt it every time it is restarted. Attackers will no longer be able to just waltz off with the key file, but you'll have to have access to the machine every time the server restarts.

    Security beyond that is specific to your website / web server, which is another topic.
    - "Cryptographically secure linear feedback shift register based stream ciphers" -- a phrase that'll get any party started.
    - Why know the ordinary when you can understand the extraordinary?
    - Sponsor my caffeine addiction! (36.70 USD received so far -- Latest donor: Mark Foxvog.
    )
  6. #4
  7. Crypto-Con
    Devshed Supreme Being (6500+ posts)

    Join Date
    Apr 2004
    Location
    Frisco, Texas
    Posts
    6,704
    Rep Power
    1236

    Q: I think my webserver was hacked -- how can I be sure?


    I think my webserver was hacked -- how can I be sure?

    Check your logs for attempted SSH, FTP, etc, logins. If you find a successful one that can't be accounted for, the conclusion is obvious. Even if you don't find any successful logins, if you find failed login attempts it may be evidence that an attacker -- with an unknown level of success -- does indeed exist.

    Check the "last modified" timestamps for all your files. If you know the last time you updated a certain source file for your website was last month, but it shows as having been modified in the last 12 hours, you may have a problem.

    Next, compare your remote backes (you do have remote backups, right?) to your backup source files. Unix utilities like "diff" are your friend in this case. (You *do* have remote backups, right?)

    Next, check to ensure that all passwords in the system (the operating system, the server software, and the web applications) have not been changed. It's possible the attacker gave himself access to a specific account to make re-entry easier. Also check to ensure there are no additional accounts in the system anywhere, such as your database, database management software, etc, that ought not be there.

    One thing you can do before the fact to detect unauthorized access is to "booby trap" something simple in the system. Like on a *nix system, replace the "ls" binary with a script that acts as a simple wrapper to the real "ls" but also, for example, updates the timestamp of some file that otherwise will never be updated ("touch /etc/X11/ls-time", for example). If you check the timestamp every day before you go about using the system and the timestamp was updated during a time that cannot be accounted for, you have problems. That's a very simple example, but that's the general idea. There exist "booby trap" software packages to help you set up more elaborate traps. I wouldn't worry too much about setting traps, and most certainly not at the expense of not spending time securing other things, but you can do so.

    There are many other ways to check your system for compromise, but they get more specific to the system/software. This list should help get you started.
    - "Cryptographically secure linear feedback shift register based stream ciphers" -- a phrase that'll get any party started.
    - Why know the ordinary when you can understand the extraordinary?
    - Sponsor my caffeine addiction! (36.70 USD received so far -- Latest donor: Mark Foxvog.
    )
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2012
    Posts
    1
    Rep Power
    0

    coop


    My name is Grzegorz Bialecki. I'm assistant of Hakin9 Magazin editor. We are looking for authors who could write for us about IT security. Would you like to get more details? Write me back on grzegorz (dot) bialecki (at) software (dot) com (dot) pl

IMN logo majestic logo threadwatch logo seochat tools logo