does private key go to a ssl certificate? I am new to SSL certs and trying to self sign the certs from forwarder to indexers:
https://docs.splunk.com/Documentation/Splunk/8.1.3/Security/HowtoprepareyoursignedcertificatesforSplunk
cat myServerCertificate.pem myServerPrivateKey.key myCACertificate.pem > myNewServerCertificate.pem
why will private keys go to a certificate. Per my understanding the only time private key is used is to sign the certs. During the handshake protocol, will the server send private key to client?
Thanks

TLDR
Private key is not a part of certificate. A certificate is a confirmation of some trusted party (CA) that particular public key belongs to particular party.
The documentation of Splunk that you refer uses wrong wording. The file that they create is not a certificate.
Details
Here the documentation says:

Combine your server certificate and public certificate, in that order,
into a single PEM file.

This sentence is correct. The resulting file is just a PEM file. But it is not a certificate, it is not a certificate chain, it is just a PEM file that stores different cryptographic objects, in this case it is a private key and one or more certificates from the same certificate chain. There is no common term for this. (And no, a key store is also not a proper name for this store.) There are standard formats for that. For instance, PKCS allows to store bundles of private keys and related certificates (e.g. it could be used to store server certificate and corresponding private key), also it allows to store separate certificates (in case of Splunk this would be a certificate of the CA that issued this certificate, or the chain of CA certificates up to the root CA).
But because of some reason the developers of Splunk decided to use a home grown format. PEM is of course a standard, but the Splunk requirement that this file should contain, in the following order ... in decreasing order of hierarchy, up to the root can make it actually more fragile (in PKCS the order of adding certificates to the store has no meaning at all), can increase the number of configuration errors and thus increase the maintenance costs. On the other hand, if the number of objects in the PEM file is small, like 3-5, it is easy to work with it in any text editor, which maybe easier than dealing with PKCS.
Then the Splunk documentation says:

Here's an example of a properly concatenated certificate:

This sentence is wrong. What they show in documentation is not a certificate.
And this:

the completed certificate file might look like this:

Also this sentence is wrong. What they show in documentation is not a certificate.
The other page looks at the first glance fine. But when you read "Copy the server certificate" or "Absolute path to the certificate" and you remember the previous page, you may be in doubt: Do they mean a certificate file in the common sense, e.g. a file that contains a single certificate, or do they mean "certificate" in the Splunk special wording and actually they mean "a file containing a mix of private key and certificate chain"? From this documentation you cannot know it. Either you need to find better documentation, or try different files to find out what they actually mean.


How to test for NoSQL injections? How to test for NoSQL injections? Considering that the structure (or actually the non-structure) of NoSQL databases is very different from structured databases like MySQL, MSSQL or PostgreSQL.

Are their known tools, payload lists, tricks or other common practices (other then using a creative hackers-mindset), in order to test if a application is vulnerable to NoSQL injections?

A very-basic NoSQL injection can be studied here -- https://ckarande.gitbooks.io/owasp-nodegoat-tutorial/content/tutorial/a1_-_sql_and_nosql_injection.html -- which is available from your testing tools if you install the purposely-insecure Nodegoat application.

This blog posts a discussion and video around a Node.js framework called Meteor that uses a backend NoSQL database, MongoDB -- http://blog.east5th.co/2016/03/21/nosql-injection-in-modern-web-applications/

The princples should apply to other NoSQL databases. For more on penetrating MongoDB (and other NoSQL data stores such as Redis, HBase, CouchDB, and Cassandra), check out this StackExchange answer -- https://security.stackexchange.com/a/96593/140 -- with another blog post specifically on MongoDB to check out here -- http://www.technopy.com/mongodb-injection-how-to-hack-mongodb-html/

For additional details with payload lists (aka wordlists), see this project -- https://github.com/fuzzdb-project/fuzzdb/tree/master/attack/no-sql-injection


How to handle data-dependent Claims? This question is about Claims-Based Authorization and Windows Identity Foundation (unfortunately I lack the priviledge to create a tag for this).

Consider the following simple use case:

I have a class User and a class Project,
(for the sake of simplicity) each project has exactly one assigned User,
The access control policy is that

  A user can only read data of projects he is assigned to.

I am trying to model this using WIF and Claims-Based Authorization.

So I have the following method for which I want to check the access:

public Project ReadProject(int id)

To do this, I would have to make a call to the ClaimsAuthorizationManager with an AuthorizationContext containing the principal (=the user) and Claims for resources he wants to access and actions he want to perform on these resources.

What I am not clear on:
In the above use case, the permission is based on the fact project.AssignedUserID == user.ID. What would the Claims look like?

Is this requirement a Claim on the User/Principal, like "User has access project ID X", that I have to set before calling the ClaimsAuthorizationManager? If yes, at which point would I assign that Claim to the User? And would that not screw up the whole point of having centralized place to declare and check policies?
Is it rather something that the ClaimsAuthorizationManager would check by looking up the database? If so, how would I translate the fact which project he wants to access into a Claim?

Most examples I find for CBA are based on attributes about the user (e.g. what country he is from), so I have no idea how to perform checks on the User-Data relation.

Well there are a couple options here. The first is to reverse it such that your user has a collection of claims that define which projects they have access to:

Claims:

Project: 123
Project: 124
Project: 125
Project: 129

This could be unmanageable depending on how often the projects are created and the number of projects per user as you'd have to refresh the claims any time something changes.

You could do a database check in CAM but that gets noisy quickly, and can potentially slow down the system considerably as the CAM is designed to be called often. If possible it should only make its decisions based on the claims present in the principal.

Alternatively you can pass in a composite resource like "project:{id}:{assignedUserId}" and your CAM could parse it out so if the resource begins with "project" you can parse out the project ID and assigned user ID and do a check to see if the principals claims contains something like 'UserId: 123'. The project Id wouldn't necessarily be needed in this case but if you're sticking logging into the CAM it might be useful to include the project Id too.


How to hide or obfuscate the type of OS? I get the OS type of a remote host by:

connecting to an open port (telnet <host> 22);
using Nmap (nmap -A <host>).

What are techniques and how to hide or change the information about OS? I would like to get answers with respect to GNU/Linux or (and) BSD OS.

You can hide from Telnet by changing the welcome banner of each service you're worried about (some of these will be easy to change, others will be hard).
You can make Nmap's OS detection less reliable by configuring your firewall to drop all packets to closed ports: Nmap works best if it can find both an open port and a closed port to probe.


For two-factor authentication is it a security issue to have phone authentication and Google Titan Security Key? I am trying to setup my Google account to have some proper security.  But I'm finding parts of it confusing.  I used to just use my phone as my 2FA device.  Where I would get a texted code.  Then I read about how someone could intercept that and that it wasn't a good method.  Then I bought a Google Titan Security key.  My google account allows me to add my phone and Titan key.  But should I disable the phone for the reason mention above? Thanks!

Your threat model may be different from other people's, but generally speaking, if you have hardware keys but SMS can still be used to reset access, then SMS is the "weakest link in the chain" and could be exploited.

You could disable SMS to mitigate this. Google offers a pre-configured approach to move to require only strong second factors, called the Advanced Protection Program. In this approach, after you provide two hardware security keys, all other authentication methods are automatically disabled. Note that this makes it harder to reset your access if you ever need to - that's the tradeoff. To mitigate some of that risk, you can add a third key (or even more), and keep alternate keys in safe locations.


Securing data on a mobile device (even from the user/owner)? I am writing an application to generate OTP codes for two factor authentication where I need to securely store data locally. This data must be secure from both the owner/user as well as intruders. I have been thinking of encrypting the data, but the key to that data is also stored on the mobile device.  The application will not access the internet.  It just displays a code that changes over a given time interval, similar to an RSA SecurID token.  The data to be stored is the token key and the key to decrypt it.  I have read about possible solutions that it may be possible to store this information on the SIM card or other secure store on the device.  What are industry best practices for such a scenario?

The important point is that you cannot hide secrets in software: if some software runs on the hardware owned by the attacker (here, the user and his smartphone), then the attacker can reverse-engineer the application code and extract the secret. If it was possible to protect software from that, then there would be no software or video piracy. Media industry would be very interested; they have looked high and low for a solution, and spent a lot of money on the subject, and did not find anything really robust.

So you need tamper-resistant hardware, i.e. hardware which will prevent reverse-engineering. In a smartphone, this indeed points at the SIM card: smart cards are, by design, tamper-resistant. In fact, the SIM card is the only tamper-resistant piece of hardware that can be found in a typical smartphone, so you have to use it. However, there will be additional challenges:

For proper protection, you must not use the SIM card only as storage; the point of tamper resistance is to never let the key exit the card. If the card just handed the key over to whoever asks for it, the attacker would have no trouble extracting it. So the complete computation must occur within the card. Depending on how programmable the card is, this may or may not be easy; in any case, the card vendor and the phone operator will have to be involved.
There is no clock in a smart card. If the algorithm depends on the current time, then that time must be obtained from the outside, and that "outside" is the phone, under full control of the attacker. The phone may lie. This would allow the attacker to generate the codes for, say, the complete next year. Depending on what you do with the codes, this may or may not be a problem for you; but you have to take that into account in your security model.

The clock issue might be avoided if you generate your codes not with a clock, but with a counter, like what is done with HOTP. A feature of RSA SecurID tokens is indeed that they include an internal battery powered clock that the user cannot tamper with; this is an expensive feature which explains both the size (substantially bigger than a smart card chip) and the price of these tokens.

Another way to avoid the clock issue is to use the network. The code in the smart card would generate a random challenge (say, 16 random bytes), send that to the phone; the phone would then talk to a Time Stamp Authority who would sign the challenge along with the current date and time, and send back the signature. The smart card would still have to verify that signature, and check that the response indeed contains the correct challenge value. This process ensures that the card obtains an untampered-with notion of the current time with decent accuracy. But the protocol has become quite complex, and involves network access (not necessarily easy, especially when the phone owner is in a foreign country) and a trusted server (which has to be maintained).


How is revoking a CA cert possible? From what I understand, the cert is created using a private key ONLY ONCE, and once it's issued to a website, it stays on that website's server. As a retrospective measure, how can a CA make this cert invalid again if it can't remove the cert from someone else's server, and it can't change the public/private keys which will make all other sites invalid as well?

This is accomplished via a revocation list vis. RFC 5280.  The client can request a CRL (certificate Revocation List) from the CA (certificate Authority).  The CRL is signed and timestamped by the CA. The client can check against this list during the handshake (note that certain browsers have been lazy historically about checking this because of increased latency).  To avoid added latency OCSP stapling is an option which passes the CRL to the client by the server during the handshake.

https://en.wikipedia.org/wiki/Certificate_revocation_list

https://www.digicert.com/util/utility-test-ocsp-and-crl-access-from-a-server.htm

https://tools.ietf.org/html/rfc5280


What data should I validate when validating  X.509 certificates using Java? Well I began with PKI a year ago with RFID system at school. Now I'm asked to implement this in my job. I understand most part of the idea. The doubt is about the certificate validation.

I know it has a valid date "Not before" and "Not after". Is this enough to say that the certificate is valid? This is because the certificates are changed every year and I want to be sure that the data signed was signed with a valid key. How can I implement this on Java?

The other question is about revocation, I don't understand what's it for, can anyone explain me?

Certificate validation is, huh, a bit more than looking at the dates.

Have a look at RFC 5280. It would be an utter delusion to believe that you could implement certificate validation with any kind of security, and decent interoperability, if you do not read several times and wholly understand that document. A lot of crud has accumulated on the X.509-related standards, which makes implementation of certificate validation a daunting endeavour. The X.509 style guide is a must-read (although now a bit dated, it still gives the right impression about the state of things in the X.509 world).

Really, if your boss told you to implement X.509 validation, then either he mocked you, or he is seriously disconnected from reality.

Your best bet is to use some existing library which already does the job. Fortunately, Java itself comes with some code for that; look it up in the java.security.cert package. Peruse the Java PKI Programmer's Guide and the adjacent note.

Revocation is the PKI equivalent of "Whoops, sorry, disregard my previous message". It is used to declare that a given certificate shall not be used, even though all the paraphernalia of signatures and name constraints and policy trees and key usages says that everything is fine with it. Revocation status checking involves downloading potentially huge lists of revocation (CRL) and/or talking to online servers who assert the status of some certificates (OCSP); either way, it is expensive, bulky, and it will work only insofar as the corresponding Certification Authority publishes revocation information in a proper and standard-compliant way, i.e. not that often.


Email instead of username I am wondering about the security implications of using email as the main identifier via which a user logs in (with an associated password, of course). Can I treat it as I would a normal username or should extra precautions be taken, like 'sanitizing' the email address before comparing it for uniqueness by removing any + parts (e.g. somebody+note@example.org)?

The one true implication I can think of right away is to be careful not to make it publicly checkable whether an email was registered in the system (e.g. by failed password checks).

The email is usually a good thing as a username because:

the user remembers it;
it is unique worldwide, thus simplifying the management of collisions (if one user wants to use the same login name as another, then one of them did a mistake);
it can be coupled with an "email verification" system which is convenient if you want the server to be able to contact users in case of emergency.

Nominally, at least the right half of the email address (the domain name, after the "@" sign) is case-insensitive, so you should normalize that part to lowercase, which is easy, since it is supposed to be a valid domain name, hence limited to a subset of ASCII (Note: you will want to take care to use what .NET calls the invariant culture, and Java terms the root locale; otherwise, your code will break in Turkey).

For what is on the left, case sensitivity depends on the receiving site. Most sites are case insensitive for that part too, and it seems "reasonable" to do lowercase normalization, because it is improbable that a given site is both case sensitive and uses case to distinguish between distinct people (i.e. that bob@example.com and BOB@example.com are both valid addresses for two different Bobs). Thus, I suggest lowercase normalization of the whole address for comparison purposes (i.e. to decide which user we are talking about); but keep the address "as is" if you ever want to send back an email to the user, or even if you want to show it to the user (e.g. as a "Welcome, Bob@example.com" banner -- Bob might be quite fond of his uppercase 'B').

About the "+" sign: From your point of view, that's part of the address. This "+" is handled on some sites as a way for each user to generate a lot of functionally equivalent addresses: Bob will be able to use bob+work@example.com, bob+home@example.com, bob+the-ultimate-warlord@example.com... all emails sent to any of these addresses end in Bob's mailbox, but, in the eye of Bob, they still are distinct addresses which Bob types as such. Bob expects the addresses to be considered distinct. So your handling of the "+" depends on what you really want:

If you just want a unique "login name" so that management of collisions is easy, then leave the address "as is"; don't do anything special with the "+".
If you want to enforce uniqueness of accounts per human user (i.e. you don't want Bob to be able to create one million distinct accounts), you may want to remove characters from the "+" sign to the "@" sign, there again for comparison purposes. But don't believe this rule will deter most Bobs; obtaining zillions of email addresses without a "+" is easy and cheap (the ultimate way being to buy a domain and rent a server to host it).

Summary: keep the address as entered at registration time and use it "as is" for display and for sending emails. For comparisons (i.e. locating the user entry in the table of users, e.g. upon login), normalize the email to lowercase (with an invariant culture).


Can the GlobalProtect VPN of my company track websites when Disabled? I just installed the Global Protect VPN from my company on my local machine so I can access our servers remotely.  I just "agreed" to the following statement:

  VPN Connected

  This system is for the use of authorized users only. Individuals using
  this computer system without authority, or in excess of their
  authority, are subject to having all of their activities on this
  system monitored and recorded by system personnel. In the course of
  monitoring individuals improperly using this system, or in the course
  of system maintenance, the activities of authorized users may also be
  monitored. Anyone using this system expressly consents to such
  monitoring and is advised that if such monitoring reveals possible
  evidence of criminal activity, system personnel may provide the
  evidence of such monitoring to law enforcement officials.

I understand that they can (and should?) monitor all of my traffic while the VPN is enabled.

My question is if they can monitor all of my web traffic when the VPN is Disabled?

The above statement doesn't seem like it limits the monitoring to just when the VPN is Enabled.

When you say "disabled" I will assume you mean "disconnected" from the VPN. I will also assume this is a company asset and not a personal asset.

You can't be completely sure based on the information you gave, but I would say generally no based on the research I've done and based on my manual poking around our Palo Alto admin console (and local log examination). They can (and hopefully will) monitor your traffic while you are connected to the corporate network, whether you are on-premises or connected via VPN. Also, here is a list of PA GlobalProtect features you can reference to get an idea of what is seen/logged. If you disconnect or disable your VPN and visit your bank, when you reconnect, this shouldn't be available in the Palo Alto logs.

However -- here are a few other things to consider:

You may be violating the company Acceptable Use Policy (AUP) whether or not you are connected via VPN. Don't violate the AUP.
There are many other ways security and infrastructure teams monitor user activity. A good example would be an endpoint agent that logs your activity and then pushes it to the syslog servers once it's connected.


Firewall Considerations with PGP Universal The PGP Universal server is a fairly complex piece of work that provides several different services. When constructing firewall rules I am trying to determine what implications there are for opening up the various components.

For example, it stands to reason that the key server bit (ports 389/636) needs to be open fairly broadly so that the public keys of your clients are accessible. What about the port (https over 443) used by the Desktop application to download updates and policies? What would be the implications of opening this up globally?

To be honest, opening these ports on your firewall doesn't present that much risk at all, especially if you consider the tightest possible cases:

The key server ports - this is an outbound rule that can be limited to specific keyservers, but even if it isn't limited, it is still an outbound rule, so an attacker would have to ascertain sequence numbers and spoof a reply.

Similarly, opening port 443 presents the same risk as opening for desktop users.

Your most likely risks are presented from misconfiguration (as it is a complicated behemoth), but the firewall rules aspect is actually pretty straightforward.


How do browsers negotiate SSL/TLS connection parameters? For the purpose of this question, let assume that an SSL/TLS connection has 4 parameters:

protocol,
symmetric encryption method,
asymmetric encryption method,
MAC.

During the negotiation of SSL parameters, a browser tries to achieve the best possible parameters. So, my questions are:

What is the proper order of the previous list?  I know that all of them important (needed). But I assume that in the code one of them is chosen as the first, then there is second, third and fourth. I believe that choosing TLSv1.2 with DES is more secure than SSLv3 with AES256. So the question is how it is implemented in the browser.
Where does browser store this information and whether it can be changed by user?

I know that there can be probably couple of browser-dependent answers, but maybe there are some general rules enforced by SSL/TLS protocol.

In SSL, the key exchange, symmetric encryption and MAC algorithm are all grouped together into a single aggregate notion called a cipher suite.

In the initial handshake, the client sends:

the highest protocol version that it supports;
the list of cipher suites that it supports, in order of preference;
other things which are not relevant here.

Then the server selects the protocol version and the cipher suite that will be used. The theory is that a courteous server will choose the protocol version that is the highest that both client and server support, and will honour the client's preferences by selecting the first cipher suite in the client list that the server also supports. Existing servers are not all courteous.

Note that the protocol version is not wholly independent of the cipher suite: some cipher suites work only with some protocol versions (e.g. cipher suites with AES/GCM as encryption+MAC work only with TLS 1.2).

In any case, there is no independent selection of key exchange, symmetric encryption and MAC: the protocol is not orthogonal in that respect. Not all combinations make sense; and not all combinations that make sense are actually defined, i.e. have an allocated cipher suite identifier.

For more information on this process, you may start by reading this answer.

Browsers are more or less configurable with regards to the cipher suites they support and the order in which they send them. Usually you can activate or deactivate cipher suites (e.g. see this) but the order is under control of the browser's logic (which can change depending on the version). In any case, the server ultimately chooses, not the client (though of course the client can always force the use of a specific cipher suite by sending a list restricted to that single cipher suite).

It can be argued that the notion of "order of preference" has little meaning. In practice, the client sends a list of cipher suites that it is willing to use, and thus any of them is usable. If a cipher suite is "weak" then the client should not put it down enough in its list of preference so that the server, hopefully, will not select it; instead, the client should not include it at all. Weak is weak.


Indexing encrypted data for efficient searching I have implemented encryption for certain columns in a database. In some cases it may be necessary to search by these columns, either for exact matches or for substrings. At the moment, there is less than 10000 rows to search through (at most). However this will probably change in the future so I am anticipating efficency problems.

The data will remain encrypted in the database, but when retrieved by the application, it can then be decrypted. This means that the retrieval does not have to be 100% accurate, it can retrieve more records than actually match the query, and the application itself can discard the non-matching records.

With this in mind I came up with the following solutions:

For exact text match, hash the encrypted data and modulo this with a relatively low number (2^16 perhaps), and store that value in an additional column. When querying the database, it is only necessary to perform the same operation on the input string, and retrieve all records with matching hash value.
For finding substrings, hash each letter and mod 32 the result. Then set the corresponding bit in an integer. Perform the same operation on the query string. Thus it is only necessary to retrieve records where the result of a binary AND on the query with the stored value is greater than 0. This could also be done using each pair of letters, perhaps with a 64-bit or longer integer to allow for more records to be discarded.

My question is, would either of these techniques have a real impact on the security of the data in the encrypted columns? The encryption scheme is AES-256.

Ability to narrow searches tends to be in direct opposition with the confidentiality that you seek through encryption. For instance, if you store your "16-bit hash" in an extra column then that hash reveals 16 bits of the data -- 16 indirect bits, but 16 bits nonetheless. An attacker who sees the database may try to guess (brute force) the record contents, and the 16 bits will allow him to detect 65535/65536th of bad guesses: this is a substantial advantage.

Ability to do substring searches is even worse, since it necessarily reveals information that allows the brute force attack to proceed in gradual steps (this is in fact the same problem as partial password authentication).

At best, what you could do is to implement deterministic encryption, such that encryption of a given record value always yields the same encrypted result. This leaks a modicus of information (if two records have the same contents then this will show, despite the encryption layer); on the other hand, it allows for exact searches: you encrypt the value to search, and use the index on the encrypted values. Substring searches, however, should be avoided at all costs.

I think a better method would be to revisit your assumptions:

  However this will probably change in the future so I am anticipating efficency problems.

Usually, performance issues don't exist until having been actually encountered (at least in a test platform, if not in production) and duly measured. As Donald Knuth once wrote: premature optimization is the root of all evil.

Even if the envisioned performance issue is real and you know how much it will cost, some alternate methods might be applicable. For instance, you could read all the records in the RAM of the application, decrypt them all, and keep them in RAM. This would allow very fast searches without even going to the SQL level. Modern servers have a lot of RAM. As an example, the servers that maintain the StackExchange sites (all of them) are reputed to have been sufficiently boosted in RAM (a few hundred gigabytes) so that all the data can be cached, and the servers can perform all read accesses at RAM speed.

If your records are, say, no longer than 100 bytes (e.g. they are the names of some people), then you can store 10 millions of value in a mere gigabyte of RAM. What is a gigabyte ? Even your phone has more RAM than that.


How public key is exported from a JWT On this https://jwt.io/ application, you can paste a jwt and it returns you a public key. How is this public key generated, and how is it exported? Is it contained inside the JWT, and if it is, then how? In raw format?

The UI does not make this all too transparent, but no public key is exported.
You should see an invalid signature info message below the left input field.
This means, that while jwt.io was able to read your token, it was not able to verify the signature. You can, however, provide the website with your secret (depending on the algorithm, a public and private key or shared secret): with this information, it is now able to verify the signature.
A JSON Web Token consists of three parts: a header, a body and a signature.
These are highlighted in three colors by the jwt.io website.
Word of advise: never give out production level keys or tokens.


Are there any public examples of an encrypted attribute in a Verisign-issued certificate? This Credentica- UProve paper describes how Verisign issues (or did issue in the past) certs with encrypted attributes:

  "VeriSign issues certiﬁcates that contain encrypted attributes that can
  be unlocked only by veriﬁers that meet the qualiﬁcations necessary to
  receive the required decryption key from a trusted third party"

Are there any public examples of this being used?
What are some use cases that would require this attribute?
Is it unreasonable to assume that I could embed similar attributes in my own CA?  (MSFT or otherwise)

This comment seems to talk about an old VeriSign extension called CZAG. It appeared to have been relatively common a dozen years ago, but I am not sure it is still used. Indeed, it seems that the encryption system was extremely sloppy; this article (published at Usenix in 2002) describes the extension, what it contains, and what it leaks through really poor use of cryptography.

Searching the extension OID (2.16.840.1.113733.1.6.3) on Google uncovers some examples of certificates containing that extension, e.g. this one (this is a GitHub URL, I am not sure how long it will be valid).

It seems that the use case for this extension was of the kind "VeriSign wants to make money". The commercial promise was that users, with CZAG-enabled certificates, could register on some Web sites, the site automatically extracting the user's demographics ("Country, Zip, Age and Gender") without requiring the user to enter the information themselves. For some reason, back in these days, people thought that it was cool to have random Web sites automatically access their private information without control. Anyway, it was an opt-out system, so it can be assumed that most users were simply unaware of these shenanigans.

Most of the references to CZAG I find are from before the 2002 article, so my guess is that this extension was discreetly removed from VeriSign's procedures once it was demonstrated how weak the obfuscation was.


Password cracking speeds according to Hashcat from the site: http://www.netmux.com/blog/how-to-build-a-password-cracking-rig - they used 4 GPUs:

Hashtype: Keepass 1 (AES/Twofish) and Keepass 2 (AES) Speed.Dev.#*.....: 416.5 kH/s

Hashtype: sha512crypt, SHA512(Unix) Speed.Dev.#*.....:  52.4 kH/s

Hashtype: bcrypt, Blowfish(OpenBSD) Speed.Dev.#*.....: 43551 H/s

Hashtype: WPA/WPA2 Speed.Dev.#*.....: 1190.5 kH/s

Hashtype: MD5 Speed.Dev.#*.....: 76526.9 MH/s

Does this mean that with 1 GPU we can brute-force (at least try to brute) 452.4 × 1000 ÷ 4 = ~113100 passwords (stored in sha512crypt) per second?

The / 4 is ok is "H/s" the same as "P/s"? or do we need further calculations for getting the passwords/sec? (asking because there are rounds/iterations in sha512crypt)

Yes.  The Dev.#* they list is Hashcat's way of showing the combined cracking speed of all GPU devices.  Normally the Hashcat benchmark output would look like this:

Hashtype: sha512crypt, SHA512(Unix)

Speed.Dev.#1.:   147.5 kH/s (103.12ms)
Speed.Dev.#2.:   138.1 kH/s (102.84ms)
Speed.Dev.#3.:   148.0 kH/s (102.83ms)
Speed.Dev.#4.:   148.3 kH/s (102.57ms)
Speed.Dev.#*.:   581.9 kH/s

Which better shows the individual device speeds as well as the combined speed.

You're also correct that kH/s means the associated number represents thousands of hashes per second, with MH/s representing millions, GH/s representing billions, etc.  And yes, the H/s measures how many different password guess to hash conversions are made every second.  So your H/S will be slower for an algorithm like sha512crypt, compared to MD5, because it's measuring the time it takes to complete the entire hash conversion and not just one round/iteration.


Why is DHCP considered insecure? Most places I've worked at consider DHCP to be a bad idea for management networks, or "secured" networks. I'm curious as to why that is.

Consider this scenario...

There is an ISCSI storage network, say, 10.1.1.0/24
Clients have an interface for external communication, and a second interface on this ISCSI storage network to access storage volumes.

Am I not just adding extra complexity to the provisioning process by requiring humans to manage and assign IP addresses? It seems much easier to me to use an existing technology for this purpose.

My logic is that if a malicious actor is able to connect to the "secure" network and get an IP address, you have much bigger problems from a security standpoint than DHCP. Regardless, the malicious device could just self assign an IP address, since most networks have a gateway at x.x.x.1 and subnet mask of /24.

My logic is that if a malicious actor is able to connect to the "secure" network and get an IP address, you have much bigger problems from a security standpoint than DHCP

I partially agree with that but from a network-security point of view, DHCP can be an extra possible attacking vector for the internal network so it is considered a risk. I guess DHCP is considered insecure cause it can be abused by attackers. Two well known DHCP related attacks are the following:

DHCP starvation attack
DHCP spoofing which leads to MITM

In most cases through DHCP an attacker may be able to obtain or in some cases modify useful information (not only trivial things like the gateway ip) like:

the DNS servers (e.g. can be useful for DNS spoofing attacks)
the domain name
client host names (e.g. that might be useful for targeted attacks)

Also in some networks other things might also be configured through DHCP server like NetworkManager, NETBIOS servers, NIS servers, NTP servers etc...So for example, by abusing/exploiting DHCP you might be able to also abuse those services. An other example is shellshock, which can also be exploited over DHCP.

So I guess since DHCP is known to be usefull for attackers, it is considered one more possible attacking vector and that is why it may be considered a risk.


openssl s_server is expecting key and certificate in case of PSK cipher test I am new to security domain,

In case of PSK why openssl s_server is expecting certificate and key. If I don't give then it gives error like below.

$ openssl s_server -psk fcc56e7668194a4775e5b36e2735551a -accept 1440
-cipher PSK-AES128-CBC-SHA

Error opening server certificate private key file server.pem 139623549462168:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('server.pem','r')

139623549462168:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400: unable to load server certificate private key file

If I provide certificate then openssl s_server starts .

$ openssl s_server -psk fcc56e7668194a4775e5b36e2735551a -key key.pem
-accept 1440 -cipher PSK-AES128-CBC-SHA -psk_hint Client_identity

openssl s_client doesn't need ceritificate

$ openssl s_client -connect localhost:1440 -psk fcc56e7668194a4775e5b36e2735551a

I have following questions ?

certificate and key is not going to be used in client, only PSK will be used then why s_server need certificate ?
Is this right approach to test PSK using openssl server and client.
I am using RSA key in case of openssl server to verify PSK-AES128-CBC-SHA cipher, is this right key format for this cipher to verify.

You have to explicitly use the -nocert option so that it will not try to load the default certificate:

$ openssl s_server -psk fcc56e7668194a4775e5b36e2735551a -accept 1440 \
   -cipher PSK-AES128-CBC-SHA \
   -nocert
Using default temp DH parameters
ACCEPT

  certificate and key is not going to be used in client, only PSK will be used then why s_server need certificate ?

A TLS server is usually used with a certificate and therefore s_server expects one by default (and has a default path where it expects it). A TLS client is usually used without a certificate and therefore s_client does not expect one.

  Is this right approach to test PSK using openssl server and client.

Apart from adding the -nocert option and omitting the certificate, yes.

  I am using RSA key in case of openssl server to verify PSK-AES128-CBC-SHA cipher, is this right key format for this cipher to verify.

No certificate is used when using PSK which means no RSA key is used too.


Wifi usage and control Can my messages and files either sent or received be seen by the wifi owner while am using their wifi? I am I'm some ones house and am using their wifi network for everything I do on Internet including charting on all social media and other general sites.

In theory, yes.  Wifi encryption (if present), only protects data sent from your PC to their access point.  After this it is sent without additional encryption so messages could be read and captured if the Wifi owner really wanted to do that.  In practice, even capturing unencrypted data and reading it requires a higher level skill, beyond the regular systems administration skillset.  If you're a spy or access personal banking information you should worry about it and avoid using untrusted Wifi without additional encryption like a VPN.  If you are just posting social messages, chances are no one wants to try hard enough to read them.

In addition to possible Wifi encryption, your applications could be encrypting your login, password, and the data as well.  For example using an HTTPS browser URL means the data is encrypted between your PC and the system that serves the page, regardless if Wifi provides any protection.  Encrypted data can be captured but not read, in most cases.  If the URL starts with HTTP then there is no encryption and Wifi owner could eavesdrop on your messages.  On top of that, DNS queries which reveal which sites you visit will be visible.

Wifi Encryption relevance:
WEP: extremely easy to crack
WPA: easy to crack
WPA2: cracked in 2017 but patched Access Points should prevent most of the risk.

When applications don't use the browser the question is harder to answer.  You should research if your non-browser applications encrypt credentials and data and then you will know if Wifi owner has any means to capture and read your messages.


Encrypting files securely using user supplied password I'm currently trying to build a (sort of) secure, desktop based RTF text editor written for node-webkit using node.js. Based on some answers that I read here, such as How can I securely convert a "string" password to a key used in AES? and Recommended # of iterations when using PKBDF2-SHA256?, amongst others, I've come up with the following system. However, I'm rather unsure about the manner in which I've combined these algorithms, and I was hoping someone could check the system.

On first time application initialization:

Generate 1024 cryptographically secure pseudorandom bytes (k)
Generate 256 more ^ as a salt (s)
Ask for user password (p)
Stretch p using PBKDF-2 using s as salt, 64K rounds (n = number of rounds) to a length of 512 bytes (length = l) (P) (takes a little over a second on my system)
Encrypt k using AES-CBC with P as key (K)
Store s||n||l||K on disk

For encrypting and then saving a new file:

Ask for user password (p)
Read s||n||l||K from disk
As in step 3 above, stretch p to P using s, n and l from step 2
Decrypt K using P
Use k to encrypt file data using AES CBC; save to disk

Possible concerns (keeping in mind that this is supposed to be usable on a modern laptop/desktop) include:

magic numbers (64K, 512, 1024)
no IV (not sure if it's necessary)
something about some combination of algorithms
some other stupid mistake

My observations are as follows:

Storing the value of l is pointless. You should store n instead. You should be aware that PBKDF2 doesn't produce different sequences for different values of l, but rather extends the sequence longer.
Generating 1024 bytes for k and 512 bytes for P seems odd, since AES accepts no larger than a 256-bit (32 byte) key.
In step 5 of the encryption, you say that k is encrypted using AES-CBC, but do not mention how the IV is selected. This isn't hugely important here, since k won't have duplicate blocks, but it's good practice to use the cipher mode properly.
In step 5 of the decryption, you again mention AES-CBC without specifying the IV. This is critical - improperly selecting the IV may completely break the system.
You provide no authenticity on the file or the stored metadata. This is actually important, because AES-CBC is malleable (i.e. ciphertext can be modified in ways that affect the plaintext, without needing to know the key) and your construction could be particularly susceptible.

Your general construction is actually alright, but it's missing the details that separate a secure construction from a weak one.

Here's how I'd do it:

let p be the user's password.
let kd (data key) be a random 128-bit value.
let s (salt) be a random be a random 128-bit value.
let c be the iteration count, e.g. 1,000,000.
let km (master key) and ka (authenticity key) be computed as two 16 byte (128-bit) halves of PBKDF2(p, s, c, 32), i.e. PBKDF2 of the user password and salt, with the defined iteration count, and an output length of 32 bytes.
let k'd (encrypted data key) be computed as AES(kd, km), using 128-bit AES in ECB mode.
let IV be the initialisation vector for use when encrypting the file data.
let Q (metadata) be the concatenated values s | c | k'd | IV.
let aQ be the authenticity record for Q, defined as H(Q, ka), where H is a cryptographic hash function in a HMAC construction, e.g. HMAC-SHA256.
store Q and aQ in the file header.

Since 128-bit keys are being used, and AES has a block size of 128 bits, only one block need be encrypted when computing k'd and therefore AES in ECB mode is safe; the additional complexity of using CBC or another mode is unnecessary.

Providing an authenticity record for the metadata helps prevent an attacker from "tweaking" the parameters needed to decrypt the file. Most critically, it provides authenticity of the IV, which is a prime target for modification as xor'ing it with a value will result in the first block of plaintext also being xor'ed with that value upon decryption. This property is known as malleability. For partially known (e.g. structured) plaintexts, this can have devastating effects.

You should be able to extrapolate the rest of the file encryption and decryption process from here. One addition I would make is to compute a HMAC hash of the encrypted data, then store that in the header, to ensure authenticity of the encrypted data.


How can one restrict Windows shared folders access to specific applications? There are few shared folders in my company that are accessed by applications from different branches across the country for different transactions. Hence they are kept "open". During a recent PT exercise, this was reported as a finding. Though no write access is given, I understand that this is a security risk. The application owners claim that securing the shared folders would disrupt the normal running of the applications. I was wondering if there can be a secure set up so that only the designated applications can access these shares?

You could try to run the applications with application specific user accounts and then restrict access to only them.


Is it better to have a secure channel or secure PIN entry for Smartcards? Assume I do own a computer, a USB-connected keyboard and a USB-connected contact-based (trusted) chipcard reader with a hardware pinpad.

There are now two types of smartcards relevant to this question

The ones that establish a secure channel (TLS-like for APDU transport) between the middleware on the computer and the card. They require keyboard based PIN entry.
The others don't establish a secure channel between the middleware and the card. They can use the HW pinpad of the chipcard reader.

Which of the two approaches provide less attack surface e.g. is likely to be more secure?

The trade-off I see here is the following:

The cards without a secure channel may be vulnerable to malicious modification of APDUs in-transfer and to eavesdropping on computation results and especially malicious modification of what is being signed by the card
The cards with a secure channel suffer from the standard threat of key-loggers and similar software and thus would allow for unlimited legitimate use of the card while it's inserted

Note: The fact that there are less possible PINs (= passwords) with pinpads shall not matter to this question as well as the remote usage scenario of such a card. The secure channel may be assumed to be actually secure and the middleware may be assumed to have been coded properly, but the PIN would still be supplied from a (potentially buggy) user application (like Firefox, pkcs11-tool, Windows, ...) using their own dialogues.

The attack surface is smaller with the hardware PIN pad. The secure channel between the smart card driver and the card can't protect against snooping over USB between the keyboard and the computer, nor can it protect the key presses from being read when they reach the OS before going to the smart card driver and then the secure channel. Both of these threats fall under the key logger attacks you mentioned, and both are mitigated strongly by hardware PIN entry because there's no pluggable USB path to monitor, nor is there a complex kernel and driver infrastructure handling each key press. Some hardware PIN devices even have tamper-evident housing to reveal if someone tried to implant monitoring in the pad itself.

Regardless of how the PIN reaches the card, there is still the threat of malicious challenges being signed by the card after the PIN has unlocked the signing function. Aside from using air-gap security, one way to detect malicious behavior is knowing how many things you're intending to sign (possibly with an audit log) and matching the expected signatures against the counter on the card, which is like an odometer for signing operations.

A hardware PIN pad can also make malicious signing requests obvious because an attacker would have to make your card sign their data instead of yours, which would then require another signature to happen for your data. Hardware PIN pads help here by always requiring PIN entry for each signature. If you enter your PIN, something gets signed, and it's not the thing you needed signed, something fishy may be going on. While you can configure something like GnuPG to require a PIN for each signature or challenge, you're at risk of an attacker re-enabling PIN caching to sign both the malicious data and your own with one PIN entry.

Devices like the YubiKey 4 have a lighter version of this protection where you have to tap the card for each signature. This still provides a good way to detect someone maliciously having their data signed instead of yours (because you'd tap, and something would get signed, but your data would not yet be signed).

I don't think the secure channel is enough to prevent malicious signatures from being created because it only closes the attack between the driver and the card, while something outside that system has to initiate the signature process. Malware on the same OS would still be able to request signatures.

On the other hand, without the secure channel, an attacker might be able to monitor signatures over the USB interface to the reader, but that's the same attack that could capture a PIN entry from a standard keyboard and then directly request signatures from the card. The PIN capture attack is the easier one, too. I can buy a key logger off Amazon.com, but I doubt I'd be easily able to get my hands on a pre-made tool to intercept smart card signing traffic. Once I have the PIN, I could run a USB host connected to the card reader via something like a Raspberry Pi, and I'd be able to sign away the next time the card gets inserted.

In summary, a hardware PIN pad provides effective protection against malicious PIN capture as well as easy detection of malicious signing requests (via one PIN entry = one signature). Barring air-gap security and heavy audit procedures, that's the best you can do.


How can you test Mutual Auth connections? We're trying to migrate our system from a private data center to a public one (AWS).  There are other systems we have no control over that communicate with the one in the private data center.  They communicate to us using Mutual Authentication.  We want to make the migration have as little effect on them as possible.

One of my biggest concerns is that they won't be able to communicate with our system in the new data center for security reasons.  I'm looking for a way of testing that we accept their calls in the new environment before we cut over to it so that we can minimize the risk and find issues without it effecting people.

I'm unsure of my options, given that this is Mutual Auth/SSL.  Ideally (from a risk mitigation perspective), I would be able to capture some of requests sent by them to our existing proxy and replay it on our new proxy and see if it accepts the traffic.  But, I have a feeling that this wouldn't work because it would be a security vulnerability to replay networking traffic.  But, I'm no security expert.  They will not share their private keys with us.

What are some ways I could test that Mutual Auth connections that work in one environment still work in a new environment?

So you're essentially doing a MiTM for mutual TLS connections.  For this you need 2 things:

You'd need the private key of the client, which is used to encrypt data with.
You need to intercept their connections to your proxy endpoint.  This could mean that you need to accept your proxy certificate as a valid CA.

This ways, you would be able to decrypt it (they're connected to you, you're the endpoint, it's encrypted with your public key), "Analyze it", re-encrypt it (with the private key from the clients) and send it to the real endpoint.


Circumventing disadvantage of IP-based account lockout So we're trying to prevent brute-force attacks on our web server login page--currently we just do IP-based locking if x failed attempts from IP address Y occur over z time period. After a security review we realized that we might be locking out users sharing an IP, which the OWASP article on the subject confirmed is a legitimate issue. We are now considering changing the algorithm to restrict by username as well as IP address- is this a bad idea? I'm not terribly worried about an attacker on the same IP as the victim intentionally trying to lock out the victim's account, but perhaps that is easier than I realize?

psuedocode for new algorithm:

username = x
ipAddress = y
// if we're here, user has entered bad credentials

if( tooManyAttempts( x, y ) )
   lockAccount
else
   ...
end if

def tooManyAttempts (username, ipAddress)
   attemptsPerTime = getAttempts ( username, ipAddress )
   if( attemptsPerTime > attemptsAllowedPerTime )
      return true
   else
      return false
   end if
end

def getAttempts ( aUsername, anIpAddress)
   query database for attempts records
      where value in column username  equals aUsername AND
            value in column ipAddress equals anIpAddress
   return number of records
end

Any system that increases the amount of time for additional attempts will thwart brute-force attacks on your service. CAPTCHA as mentioned previously is a strong method for doing this, providing for a 5-10 second timeout period between attempts after say, the third attempt and escalating the timeout period by following some progression can easily thwart any brute force attempt. You can even have it cap at say 5 minutes, and if an attempt comes in within that period merely resets the period even IF it is a valid login. (Checking at most 12 passwords an hour for example makes brute forcing pretty much impossible.)

IP-based bans would be ineffective against a large-scale attack, like against a botnet perhaps, unless the IP-ban was account-specific.

As an idea, cookies could be used to thwart some attackers, if cookie usage is required you could generate a random hash of some sort that authenticates their /location/ as valid and any attempt that doesn't come from that location is subject to a CAPTCHA process or 2FA. (Successful authentication could allow them to add the cookie.) Following this method, you could IP ban an entire segment from authenticating for X minutes or hours UNLESS they have the cookie. Which would only result in a victim being banned if the attacker was utilizing their machine, OR stole the cookie.

Fun times.


Are there any PCI compliant firewalls that can be installed on Linux through normal means and not through an ISO? We are trying to install a PCI compliant firewall on our Azure Vnet. The problem is, that ones like opnsense can only be installed through an iso, having to install it on a local VM and then having to upload around a 4GB disk to Azure create a VM from. With our internet connection it's not a viable option.

So my question is, are there any viable firewalls that we can install normally on a Linux distribution as normal software?

Firewalls aren't PCI compliant but rather the manner in which network traffic is managed can support PCI compliance/security validation. Network rules must be stateful and only permit traffic with a technical and business justification. Configuration of Azure's network containers with relevant, required rules using change control and performing periodic ruleset reviews will support your compliance efforts. You don't require additional network infrastructure beyond that provided by the cloud service provider unless you have other network requirements.


Difference between SSH Tunnel / Proxy and VPN in terms of security What benefits does a VPN have over just using a regular SSH Tunnel?

I'm considering setting up OpenVPN on a server, but was wondering what benefits that would have over just using that same server as an SSH Tunnel which is very easy to setup and allows connecting via SOCKS5 which is already supported everywhere.
Wouldn't both show the same IP address as source anyways in which case you're no longer anonymous?

SSH Tunnel seems to be much easier, just open an SSH tunnel and setup the computer to connect to that port via localhost and a SOCKS5 proxy.

ssh -D 1723 -f -C -q -N user@server.com

VPN on the other hand seems like a bit more work to setup and I'm unable to see what benefits it offers over just a simple SSH Tunnel.

People often speak of SSH tunneling as a poor man's VPN. It is exactly the same on a feature and security point of view: you establish a secure tunnel between the client and a relay host and let a communication go unencrypted past the relay. The way the tunnel is established and secured may vary per VPN system but all serious ones can use standard up to date protocols, as can do SSH (and all can be equally configured with some work to use unsecure protocols).

The main difference is in usability. SSH goal is to establish a secure connection between a client and a host, and it does a nice job for it with clean and neat human interfaces. It can transport additional communications inside its tunnel, but as it is not its main goal, the commands are not really straightforward. Whereas a VPN goal is to provide transparent relaying of various protocols so it is much easier to use for that goal.


What is the use of different types of shellcode? I was browsing the shellcode page in exploit-db website. What is the use of all these different shellcode programs and why should we write them?

The tldr version is:

Shellcode is just a series of commands that return a command shell. It's highly dependent on what you're attacking.

Longer explanation:

So shellcode is unique. It's like a fingerprint. What it is highly depends on what you're attempting to shell. Many factors come into play. OS Version, application type, application version, supported languages, certain chars you might need to not use because the application won't accept them, etc etc etc

For example, if you're attempting to exploit a website, shell code might be php that you've injected. Whereas, if you are exploiting a vulnerable windows service, your shellcode might be bytecode.

It all depends on what you're attempting to do.

From Wikipedia - Shellcode

  In hacking, a shellcode is a small piece of code used as the payload
  in the exploitation of a software vulnerability. It is called
  "shellcode" because it typically starts a command shell from which the
  attacker can control the compromised machine, but any piece of code
  that performs a similar task can be called shellcode. Because the
  function of a payload is not limited to merely spawning a shell, some
  have suggested that the name shellcode is insufficient.2 However,
  attempts at replacing the term have not gained wide acceptance.
  Shellcode is commonly written in machine code.

Further reading:

I'd recommend you check out what msfvenom is and all its features. It might clear up a little what these payloads are and what they do.

What is MSFVenom?


Use john to crack passwords with X alphanums and Y symbols I'd like to use john to crack passwords that has 3 chars and 1 symbol in it, e.g 123$

If I use mask mode I will have to specify it 3 times,

-mask='[a-z0-9]?s[a-z0-9][a-z0-9]'
-mask='[a-z0-9][a-z0-9]?s[a-z0-9]'
-mask='[a-z0-9][a-z0-9][a-z0-9]?s'

Is there anything better than this?

The logic of masks does not allow for this. If you want only a certain number of a certain character set in more than one position, then you have to permute the options yourself, either by what you have done or by creating a wordlist.


Which security measures make sense for a static web site? I have a static web site. Users cannot log in or perform any other actions. Which of the common HTTP security measures make sense for my site?

Do I need any of these?

HTTPS
Strict transport security
Content security policy
Certificate pinning
Clickjacking protection
Content sniffing protection

The common web application attack vectors don't apply to a strictly static website. Without interactive elements there are no accounts to hijack or cookies to steal. Nonetheless, you should provide your visitors with encrypted access - even if you're not hosting delicate content.

TL;DR

Use HTTPS with HSTS to ensure some degree privacy and the integrity of your content to visitors. Adding HPKP to a static site might be unnecessarily paranoid and you have to be careful when deploying it. The other discussed security measures are mostly irrelevant for a static site, but they are so simple to implement that you might still decide to use them.

HTTPS

Yes, do it. With free SSL certificate providers like Let's Encrypt you need a very good reason not to switch. HTTPS protects privacy and integrity of the transmitted data which is desirable even with static content.

Scenario for an integrity violation: If you offer downloads, a man-in-the-middle attacker could tamper with the files to deliver malware. Example of a privacy violation: My employer, the owner the WiFi hotspot I'm connected to or my ISP could all see which exact articles I'm reading and content I'm downloading from your site. With HTTPS however, I would mostly expose metadata (the IP address I'm connected to, the hostname due to SNI, etc.).

HTTP Strict Transport Security

Yes, do it. HSTS helps to enforce that users only use HTTPS to connect to your website, thereby preventing SSL stripping attacks. If you roll out HTTPS, it makes a lot of sense to follow up with HSTS. It's easily implemented by adding an additional response header, like this:

Strict-Transport-Security: max-age=31536000

Since HSTS only takes effect from the first time a user encounters the header (TOFU model) and until the max-age timeout is reached, you might even want to submit your site to the HSTS preload list. This has the effect that users will start connecting via HTTPS from their very first visit.

Be aware that it's troublesome to switch back to plain HTTP after enabling HSTS.

HTTP Public Key Pinning ("Certificate Pinning")

It depends. While HSTS tells the browser to strictly use HTTPS for a given time, a HPKP header specifies which certificates the browser should trust in the future. Pinning public keys from the certificate chain protects users against an attacker replacing your certificate with a rogue one. Such an attack is very unlikely since the adversary would need to compromise a CA to be able to issue rogue certificates (although that has happened before). Additionally, you have to be careful when setting up HPKP since a defective deployment could make your site unavailable to previous users.

Detectify Labs have an excellent article on HPKP with a more optimistic conclusion:

  So should you use HPKP? Yes, you should. If you pin correctly, the
  chance of everything going south is pretty small.

Content Security Policy

Yes, but you might not really need it. The CSP was created to mitigate XSS and related attacks by limiting which resource type from which origin is allowed to be loaded by your site. Since you have a purely static website and probably don't embed external sources at all, it might not be an actual attack vector. A sensible policy would depend on which kind of resources you are loading. For example, this restrictive policy header only allows content from the same origin:

Content-Security-Policy: default-src 'self'

Clickjacking protection

Yes, why not. Clickjacking attacks trick a user into unwittingly interacting with your website through a disguised frame. If you have no interactive elements however, there is no actual damage to be done. (In a better world cross-origin frames would be an opt-in feature, though.) The implementation is straightforward. This example disallows any frame embedding at all:

X-Frame-Options: Deny

Note that the XFO header has been declared obsolete in favor of the frame-ancestors CSP directive:

Content-Security-Policy: frame-ancestors 'none'

Content sniffing protection

Yes, why not. If you don't correctly declare content types, browsers might guess (sniff) the type (although that behavior has become less common). This is particularly dangerous with user content that is supposed to be non-executable but determined to be an executable format after sniffing due to a missing content type. With your static site that will hardly become an issue. Just to be safe you could add the following header to prevent sniffing (but it's not a replacement for properly declared MIME types):

X-Content-Type-Options: nosniff

See also: Does X-Content-Type-Options really prevent content sniffing attacks?

Also have a look at the OWASP Secure Headers Project for more details on security-relevant headers with some real-life examples.


Specificity of ECDHE in a TLS handshake It's just a short question, but I haven't find a clear answer yet...

It's in the frame of a TLS-ECDHE handshake.

Where does the specificity of the ECDHE, over the DHE, appears ?

At which point do we use the Elliptical Curves ?

To compute the PreMasterKey, or also before that ?

The key exchange algorithm is used to compute the "master secret", usually by way of computing another key known as the "pre-master secret" which is then expanded into the actual "master secret" with the PRF. DHE uses Diffie-Hellman as key exchange algorithm; ECDHE uses a variant of Diffie-Hellman that involves an elliptic curve.

In both cases, the server must send the "DH parameters" (the definition of the group in which the Diffie-Hellman will be performed -- in the case of ECDH or ECDHE, that group is an elliptic curve) and its "DH public key" (the server's half of the DH key exchange). When using DH or ECDH cipher suites, these information (group definition and server public key) are part of the server's certificate; when using DHE or ECDHE cipher suites, they are not part of the server's certificate, and are instead sent as a stand-alone ServerKeyExchange message.

In practice, DH and ECDH are very rarely used, because certificates with DH or ECDH keys are a rarity. Instead, DHE and ECDHE are used.


Password reset vs change My webapp has "password reset" and "password change" functionality.

Password "reset" is typical: user clicks "I forgot my password", enters his email, one-time link emailed there, he visits a form to choose a new password.

Password "change" is more complicated. There are two approaches:

Some sites use a one-step process: user logs in, clicks "change password", enters old password, chooses new password.
Other sites use a two-step process with an email loop: user logs in (HTTPS), clicks "change password", link mailed to his email, he visits a form that asks for a new password. His current password is not requested. This is done (possibly) without even logging in!

These two are very similar, but there are tradeoffs.

Option (1) is simpler. BUT, if the user's device is stolen (or let's say he just steps away from his desk for some coffee), and he uses a browser with a password manager, then the attacker doesn't need to know the password.

Option (2) doesn't even ask for his current password, because it verifies him via email. BUT, if the attacker has his device, then he probably has access to the email anyway. And if I ask for the current password, and a password manager is installed, then the email loop accomplishes nothing anyway.

Also the "reset" workflow is so easy to use, that if I over-engineer the "change" workflow then the user (and an attacker) could use the reset form instead.

So it seems to me that this is not a security problem, but an UX problem only. The two-step "feels" more secure, but I think that is an illusion.

Which is better for security (rather than UX)? Are there considerations I've neglected?

To "Option (2) doesn't even ask for his current password": I don't understand how can it be. To request password change, user has to log in into his profile. For this a password is required. May be you mean that user doesn't use master password in the password manager and effectively log in without entering any password. If this is your case, then you are right saying "but I think that is an illusion".

What should you consider?

Use multi-factor authentication. A popular 2-factor authentication is based on a  password (what user knows) and on the usage of the smartphone (what user possesses). Usage of smartphone can vary: this can be SMS, push notifications that request confirmation, OTP generator, photo-TAN. Smartphone should secured, via PIN or fingerprint or face-ID.

Actually you do have 2-factor authentication. But if user compromises it (by not using password or by not caring about locking the smartphone), it is useless.

Instead of one of these factors you can use hardware token like Google Titan or Yubikey, e.g. [password + hardware token] or [smartphone + hardware] token. But again, if user does not care about the token, he is not in safety.

When choosing the solution, compare the price of compromising user account with the price of implementing a particular security.
If you are developing a web site for local bowling club, may be simple 1-factor password authentication is sufficient. If you are developing an online banking application, then you may want to allow critical operations like password change only after user is authenticated by service desk via video. Compare price and value.


Ensuring all network services on a device use strong TLS cipher suites (This is hypothetical, but based on a real-life problem I've had)

Context:

I am developing an (embedded) device which includes a few exposed network services. I'm responsible for security, not developing these services, so I don't know how they're built.

I do some testing (send targeted Client Hello messages to the device services with specific cipher suites) and find that some of these services accept weak TLS cipher suites.

Problem:

I am now tasked with addressing this problem, preferably by fixing the problem as far back in the stack as possible (e.g. I would prefer to avoid having to look at the code/configuration of each individual application and would instead like to fix it at the system level).

Assumptions:

I know that OpenSSL is the only crypto library/program in use on the system.

Now some questions:

What options do I have for preventing network services from allowing weak TLS ciphers? (e.g. change OpenSSL itself, change OpenSSL configuration files, change OS configuration, etc.)
Which options are reasonably "safe"? e.g. I suppose I could modify the OpenSSL code and remove every mention of these cipher suites, recompile, and integrate. This would prevent applications from sending the suites (even if they ask for them). However, this seems like a dangerous solution and difficult to maintain long term.
Is this even possible, or do I necessarily need to look at each service?

What options do I have for preventing network services from allowing weak TLS ciphers?

Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.

Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.

You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.

Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.

Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.


Should you let users know if an email has been taken during registration validation? In many web applications, email is required to be a unique field, and users aren't allowed to register an account if their email already exists in the database.

When performing validation on the registration form, you would presumably check if an email has been taken, and let the user know if it has since they can either pick a different one or try to reset their password.

However, if you are providing this feedback, it seems like malicious users could test to see if users exist in the database.  Someone could plausibly test your site against leaked data from big-name hacks, and if the users are reusing their passwords across sites, then your site is potentially vulnerable.

The solution to this could be simply giving more generic feedback about what went wrong without specifically mentioning email, although that could be frustrating for the average user trying to sign up.  And if your sign up form simply requires an email and password, it is still pretty obvious that if any error is encountered it is likely that the email already exists in the database.

What is the best way from a security perspective to handle informing a user that an email has already been taken upon registration?

An intuitive and simple solution is to make sure that an automated script (malicious script) cannot try to register with a list of e-mails in order to figure out which ones are registered. For example, use CAPTCHA challenge as part of registeration to make sure it is a human trying to register an account. In this way, even if few user e-mails are tried, a massive number cannot be checked. Note we are assuming strong CAPTCHA cannot be easily broken.

But if it is super sensitive and you must hide who is registered at the target website even from human users, then finish the registration and do not show any error message to the user that the e-mail is already registered; and just inform the user at the end of the process that now they have to confirm the e-mail belongs to them, please go and check your e-mail; In the backend, if the e-mail is already registered, then do nothing; just send an e-mail to the owner of the e-mail and inform them: seems you tried to re-register at our service again, if you have forgotten you have an account with us, this is your username, and if you cannot remember your password, go to the password reset page. To be at the safe side, you can mention that if you did not try to register with us again, please ignore this e-mail.

If the e-mail is not registered in the database, in the backend, create a random one-time use token in a URL and send to the new e-mail registered and ask them to confirm the new account if they meant to create a new account.

This way is you absolutely hide everything from the bad guys;


How do I secure my home Wi-Fi network in light of KRACK? Now that KRACK has been discovered to exploit WPA2, is it still possible to secure my home Wi-Fi network?  If so, what steps should I take to secure it against KRACK attacks?  Will there now be a need for a new "WPA3" protocol?

The simple answer as shown in the question below is generally to patch it, but in this case, it appears there are no patches yet for certain devices, but it is unclear what devices do and don't have patches available.  I am thinking, if there is a patch available, install it, but what do I do if there isn't?

I don't consider this a duplicate of the linked question below because this explores what to do where the patch is not available.  There is some good discussion under the linked question as well, and I recommend checking it out:

To sufficiently protect against KRACK is patching the client, the AP, or both, required?

The answer is generally to patch, but in this case, a patch is not yet available for many devices.

While researching a particular device, the site basically said to update the firmware if the patch is available.  Otherwise (from NETGEAR's site):

  Until a firmware fix is available for your product, NETGEAR recommends that you follow these workaround procedures:
  For Wireless Routers in Bridge Mode: disable Bridge Mode or power off the bridge router.

I am not sure how broadly this workaround will apply.


Securely build a list of trusted CAs Some distributions of the cURL bundle include a utility mk-ca-bundle.pl which compiles a ca-bundle.crt from Mozilla's root certificate store for use as a list of trusted authorities. The script prints the following warnings:

  Using http is subject to man in the middle attack of certdata content
  Default to 'release', but more recent updates may be found in other trees
  certdata.txt file format may change, lag time to update this script
  Generally unwise to blindly trust CAs without manual review & verification
  Mozilla apps use additional security checks aren't represented in certdata
  Use of this script will make a security engineer grind his teeth and swear at you

Exactly what is the concern referenced by #4 and how can I compile an updated version of ca-bundle.crt securely?

The concern is that each CA included has the organizational power to break your security, and will use that under different and hard to predict circumstance.  The "manual review" step is intended as a reminder that you need to have some process or criteria of which CAs you want to include.

What exactly that should include is subject to ongoing debate by experts.

For example, Google's review process has caused them to kick out a subset of Symantec's certificates.  (https://googleonlinesecurity.blogspot.ro/2015/12/proactive-measures-in-digital.html).  Another example is Tor not trusting CyberRoam  (https://blog.torproject.org/category/tags/ca-certificates)  Microsoft essentially outsources the decision to a group called the CA Browser Forum.

So there is not a specific list of steps you can take in #4 that will satisfy #6.


Why don't web apps use custom security questions? From my own reading, security questions on websites seem to have a reputation in the industry for being outdated and insecure, the basic information they need being easily available to anyone who can Google, unlike in the '80s when they were first developed for the banking field.

However, it occurs to me that a huge part of this has to be due to the fact that most security questions are canned and re-used on virtually every site that uses them, thereby hugely narrowing the list of potential answers. Surely, giving users the option to create their own custom security questions with custom answers would solve this problem? I know I'd be a lot more likely to remember an answer to a basic question I devised myself, and a hacker is less likely to be able to find out what my favourite car is than my mother's maiden name. So why isn't this common practice in the industry, and why do web apps insist on using the same canned questions?

The main problem with security questions is how easy it can be to obtain the answers, no matter what the actual question is.

You've raised 2 examples which sound equally as bad to me:

Favorite car: Can be extremely trivial to obtain. What if you know the person's username which he also uses on a car forum which turns out to display what his favorite car is?
Mother's maiden name: We're in an era where people mindlessly share personal information through social media. Depending on the system, it could be very easy to figure out the person's name and a quick browse on their Facebook page could reveal this information.

Also, these are highly vulnerable to social engineering attacks. Let's take an online multiplayer game for example. A user could casually ask you questions and then without noticing, you could be answering questions that would allow the user to recover your account.

Finally, letting the user decide the question is a huge responsibility that he most-likely wouldn't be aware of. You can't expect the user to enter a question that nobody will ever know the answer of when passwords such as Password1 can still be seen in the wild.

To conclude

For these reasons, it is hard to justify the use of security questions and would suggest to implement email recovery instead, which requires the attacker to either control your email address or successfully conduct phishing to recover your password.


What is the use of stolen credit card details? What can a person with stolen credit card details do?

Buy porn?
Buy tons of server resources to perform an attack?

What else? I'm sure that if he buys books, shoes and bicycles or transfer funds to his account they'll eventually find and arrest him.

I'm not an expert at using stolen credit cards... but from what I know:

You could resell the numbers on the black market.
You could buy stuff and have it shipped to a rube who reships it to you.
You could "quickswap" on eBay. (Use the credit card to purchase an item that is shipped directly to the auction winner, and you pocket the money from the auction sale.)
Buy prepaid cards / gift certificates.
And probably many others.

It's basically money laundering, so many of the strategies that would apply to other forms of money laundering would apply here.


Security team making the firewall opening, good pratice? I'm currently requested in my enterprise to do myself (security team) the firewall overtures requests in TUFIN (firewall workflow), instead of our local IT team. it's for simplicity and saving costs.

These opening are at the end done by the network team of our IT provider with the control of the security team of the IT provider.

In terms of good pratice, do you think it could matter ?

In a first view :

I'm controling what i'm doing (self judge), bad pratice.
I'm are losing the 4 eyes principle control. Even if the IT provider could be considered as a kind of second eyes, it's sound not to be the same thing.

What's your opinion ?

As always, it comes down to which trade-offs you are willing to make. We can give you the best practice approach here, but to deviate from the recommendation can be OK, given the circumstances.

The security team usually wants to be the second or third line of defense, defining and overseeing the security practices in the organisation. This means for your scenario, that you should define and document, how firewall configuration takes place and what the approval process for new rules look like. You also want to audit the implementation of your defined procedure. For highly critical rule changes - what this means for your organisation has to be defined by you as well - it makes sense to have a representative of the security team in the decision board.

And to answer your question - separation of duties is crucial here. You cannot oversee yourself, especially when it comes to security. So it is not recommended to have the security team perform first line of defense activities.


Safely generate a non-log file within an application server How does one go about safely write a temporary file to a location within  an application server that is publicly accessible?

It depends on "safely". If you want to avoid read or write access from other users of the same machine, then you should rely on the access rights provided by the operating system (if the OS is hostile, then you already lost). On Unix-like systems, use the mkstemp() function, but take care to use an OS where the access rights are set sanely. E.g., with Linux, mkstemp() does things correctly beginning with glibc-2.07, but previous versions made the file readable and writeable by all users on the machine, which was inconvenient (the problem could be mitigated by doing a fchmod() immediately afterwards, but this was still vulnerable to a race condition).


Designing and managing a captive portal I'd like to learn more about how a captive portal works, especially the management system regarding usage, security monitoring, billing, security architecture etc.

Does anybody know any good resources for this? I either find cheap sales-talk, or installation guides...

There are a large number of open source hotspot software suites available. EasyHotSpot has an integrated billing system.  I have not audited these applications and i have no idea how secure they are.

From a security perspective, "captive portals" break ssl pretty badly. Convergence,  which is the Anti-MITM addon for firefox will detect captive portals as being a MITM attack.  Which is true,  it is a MITM attack thats trying to get money from you.

There is a fundamental flaw in all of these "pay to use" wireless networks in that they are authenticating paying customers via a MAC address. Unfortunately with wireless networks,  the attacker can see every user's MAC address and just spoof their own.

Other security concerns are that non-paying customers should never be able to route packets to the open Internet.  Sometimes these networks will route DNS traffic,  and its possible to route IP over DNS.  Or route IP over just about any other protocol (In fact I can't name a protocol above layer 1 that can't be used...).

A PHP remote file include vulnerability in your captive portal software could allow the attacker to gain access to the open Internet (as well as remote code execution on your box :-).  SQL Injection should also be a concern as it could an attacker to authenticate as a paying customer.


Moving Services to the Cloud Our company has made the decision to switch from an internally hosted Jabber-based chat system to a more modern, cloud-based chat solution. Hosting our own chat servers and software presented the standard maintenance and issues that tend to come with any self-hosted stack but the system did work and generated few complaints. From a security perspective, having data in our control and subject to our security standards and controls seems to be a great added bonus. Who knows what kind of sensitive data is floating around in 1:1 chat histories.

The security implications of putting our chat servers, logs, etc. in the cloud with little control should terrify me as a security professional but when I step back and think about everything is transforming and I find myself more and more evaluating new tools that actually do promise the type of security I'd demand out of my own network. This has become a big part of my job-investigating the security implications from going in-house to a managed service.

This is more of a philosophical question to everyone out there who is doing security in a modern company that's trying to provide internal tools that can sometimes only be hosted in the cloud or the best option is to take it out of house. How do you weigh the benefits vs. risks of putting our potentially sensitive information out there to a third party? I have my own assessment methodologies that I've learned over the years but I'm curious what everyone out there is doing, how are you vetting our cloud infrastructure when people want to move things out of your control?

I infer you're interpreting the cloud as a "tenant based" instance where you are on a hosted server, with 100s of other companies. This is not always the case. Using AWS as an example, or Softlayer, you can throw up your instances and use the same principles to lock things down. E.g., throw on a firewall ACL ONLY allowing connections to your instance from sources you desire.

I have had issues with handing over keys to kingdoms to cloud providers. One thing I never do is trust pretty much anything they say. I go about locking down my instances the same way I would if they were physically present. The biggest issue I have even with that model is, people fail, services fail, so am I willing to take that chance?

Think about the following, you create an instance lock it down to the Nth degree. A rogue Softlayer employee takes a snapshot of your ESX guest, exports it. You'd never know no matter what you put on your guest. This is not to say someone at Softlayer or another company would, but there is that possibility. You're at the mercy of another organization, and you're hoping they are on top of their game with regards to security. THAT in itself is laughable considering the amount of companies that have been breached.

So for me... Had I do throw up a chat server, sure, it'd be encrypted on the wire, in transit, off-site logging, full lock down like everything else. Would I throw up say my databases storing mission critical stuff? No thanks. That's just me.


Securely signing a container package I have a desktop application that uses a kind of package format to load a blob and do something with it. To ensure the authenticity of the blob, I would like to add a digital signature. I researched the topic and there is one thing I do not understand.

If I distribute the public key with the package (having it available online counts as distribution) an attacker can just replace that key with his own public key and spoof a signed package (since the only way for me to validate the signature is to check it with the public key). Am I missing something? How can I sign a package in a truly secure way?

Digital signatures do not create trust; they just move it around and concentrate it. You are right: if you distribute the public key with the package, you have gained nothing.

What digital signatures give you is the ability to handle your trust separately. You still have to find a way for verifiers (the "desktop applications") to make sure that a given public key is indeed the right public key from the authentic signer. But a public key is somewhat shorter (typically a few hundred bytes), can be shared (you can sign several blobs with the same key), and can be distributed in advance (you can "give" the public key to the verifiers before signing the blobs -- even before knowing how many blobs you will ultimately sign).

Public key is not the only source of trust. Indeed, the code within the application which uses the public key to verify signatures on data blobs must also be part of the "trusted realm"; if an attacker can alter that code, he can replace the verification code with something which just always says "that signature is good". Come to that, he could also plant a virus or a keylogger in the application. So not only you have to start trust somewhere, but the problem is not exactly new either.

Therefore we may assume that you already solved the issue of making sure that when a user gets the application on his desktop system, he gets the "right one" and not a maliciously modified variant. There are several ways (e.g. Web distribution through HTTPS; or installation performed on-site by your personal). This leads us to the following solution: embed the public key within the application itself.

Operating System vendors have done that for years, to enable safe system updates. When a Windows decides that it must download and install an update, it actually verifies a digital signature on the update blob before applying it, and it does so relatively to a public key which is already embedded in the Windows code.

(The system can be made more complex with certificates if you want to support key rollover without a software update.)


Linux responds to ARP requests for other interfaces - could this be a security vulnerability? Linux responds to ARP requests on all interfaces by default.

To explain, say you have this setup:

Client 1 ---> [eth1] server [eth0] <--- Client 2

And the server's eth1 IP is 192.168.1.1 and eth0 IP is 192.168.250.1. These are on two separate, isolated networks.

If Client 1 sends an ARP request for the IP 192.168.250.1, by default the Linux server will respond with eth1's MAC address. This behaviour can be changed with the arp_filter setting:

arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.

0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.

arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise

Even with arp_filter set to 1, is it possible for Client 1 to send a normally restricted request to 192.168.250.1, and have the server answer?

For example, say there's a UDP listener on the server, listening on 192.168.250.1 port 123, which executes a command received in a sent packet. Is it possible for Client 1 to send a request to the server with the destination IP set as 192.168.250.1, but with eth1's MAC address in the ethernet header? Will the above setting affect this?

To explain this further, I'll expand upon the diagram:

Client 1 ---> [eth1 - 192.168.1.1] server [eth0 - 192.168.250.1] <--- Client 2

As the UDP listener is listening on 192.168.250.1:123 only, this should prevent anything on the 192.168.1.0/24 network from connecting to it. However, due to the above behaviour in regards to ARP responses, does this also mean that the server will accept connections to 192.168.250.1 over eth1?

What is the best way to test for this vulnerability, and what would it be classed as?

Yes, this is possible, even with arp_filter set to 0.

Server listening:

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...

Connection from Client 1 - Client 1 is set to route all traffic via server, so it does not need any ARP response for eth1:

# ncat -nvu 192.168.250.1 123
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.

Client 1 can now communicate with the server, even though it isn't on the network connected to eth1:

# ncat -nvu 192.168.250.1 123
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.
FOO
BAR

Communication shown on the server:

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...
connect to [192.168.250.1] from (UNKNOWN) [192.168.1.2] 57677
FOO
BAR

This is because Linux will accept connections for all configured IPs for all interfaces, even from interfaces that do not have the socket bound. arp_filter only affects whether this is advertised or not. If this is undesired behaviour, then IPTABLES can be used to prevent connections to IPs not configured on an interface.

This could be a vulnerability if the server's security was based upon the fact that only connections to services listening on one IP address could be connected to from that interface's subnet.


Can Sagan block active acts once they've been detected? I'm trying to determine if Sagan can do anything similar to fail2ban where detected attacks can be temporarily blacklisted, via a system's firewall (iptables). Does Sagan have any "countermeasures" or "active response" capabilities?

Googling I came upon this page titled: Snortsam - A Firewall Blocking Agent for Snort which is a plugin for Snort. According to this plugins page it can integrate with Sagan as well:

excerpt

  SnortSam has also been integrated with Sagan, which is a log analysis
  engine developed by Champ Clark. The Snortsam Output Plugin and
  related files (header, Twofish) are available at the Sagan GitHub
  repository.

  SnortSam itself consists of two pieces -- the output plugin within
  Snort™ and an intelligent agent that runs on the firewall, or a host
  near the firewall. The agent provides a variety of capabilities that
  go beyond other automated blocking mechanisms, such as:

  White-list support of IP addresses that will never be blocked.
  Time-override list.
  Maximum block time ceiling as well as minimum block time definition for reporting entities. Flexible, per rule blocking
  specification,    including rule dependent blocking time interval.
  A SID filter list of allowed or denied SIDs based on reporting entity.
  Misuse/Attack detection engine (including roll-back support) that attempts to mitigate the risk of a self-inflicted Denial-Of-Service
  in the IDS-Firewall integration.
  Repetitive (same IP) block prevention with customizable window to improve performance.
  TwoFish encrypted communication between Snort™ and the SnortSam agent.
  True OPSEC support using the Checkpoint SDK (opsec plugin).
  Block tracking and block expiration for firewalls that don't support timeouts.
  Multi-threading for faster processing and simultaneous block on multiple devices.
  File logging and email notification of events. ... and finally, using the client/server (snort/snortsam) architecture to build large,
  distributed response networks in a very scalable fashion.