How do poor-quality initialization vectors affect the security of CBC mode? (If the consensus is that this question belongs on crypto, rather than here, please feel free to [tell me to] migrate it.)

From what I have read (looking specifically at AES in Cipher Block Chaining mode), initialization vectors should be non-repeating, or better, under some circumstances at least, totally unpredictable. If we consider the following sequence of "weakening" IVs:

Cryptographically sound random number
Any old "random number"
A non-repeating, monotonically increasing, non-continuous counter (such as a high-resolution clock)
A 1-by-1 counter, large enough not to repeat in, say 10 times the expected usefulness of the protected data.
A constant IV
An all-zeros IV

Now, as we weaken the IV, what attacks become possible, and at what stage in the weakening? I am particularly interested in storing data "at rest", and for the moment, without authentication.

After two excellent answers, I'd like to refine the question a bit with regards to possible attacks. Here are some more pieces of my puzzle, and a supplementary question:

The encrypted data is a credit card number.
I have, let's say, client records, with each client's card or cards associated with that client's record.
My principal, final objective is that I don't leak credit card numbers in the clear.

Now, my supplementary question is this: as far as I can see, all an attacker can do with a constant IV and key is to say "Aha, Client A and Client B use the same credit card"; just how much damage can be done with that?

There are two distinct "dangers" with CBC. Remember that CBC works the following way: to encrypt a block, first XOR it with the previous encrypted block. The IV is just the "previous encrypted block" for the very first block to encrypt. The idea is that a block cipher is a deterministic permutation: with the same key and the same input block, you get the same output. The XOR with the previous encrypted block is meant as a "randomization". So the dangers are:

Block collisions.
Chosen-plaintext attacks.

Block collisions are when, through bad luck or lack of randomness, the XOR of a block with the previous block leads to a value which was already obtained beforehand.

For instance, if you use a fixed IV (all-zero or not, it does not matter), then two messages which begin with the same sequence of bytes will yield two encrypted streams which also begin with the same sequence of bytes. This allows outsiders ("attackers") to see that the two files were identical up to some point, which can be pinpointed with block granularity. This is considered a bad thing; encryption is supposed to prevent such kinds of leaks.

If using a counter as IV, you may still have such collisions, because counters have structure, and "normal" data also has structure. As an extreme case, suppose that the encrypted message also begins with a counter (e.g. it is part of a protocol in which messages have a header which begins with a sequence number): the counter-for-IV and that counter may cancel each other with the XOR, leading you back to the fixed-IV situation. This is bad. We really prefer it when encryption systems provide confidentiality without requiring some complex requirements on the plaintext format. A high-res clock as "counter" could also incur the same issue.

Chosen-plaintext attacks are when the attacker can choose part of the data that is to be encrypted. With CBC, if the attacker can predict the IV, then he can adjust his plaintext data to match it.

This is the basis of the BEAST attack. In the BEAST attack, the attacker tries to "see through" SSL. In SSL 3.0 and TLS 1.0, each record is encrypted with CBC, and the IV for each record is the last encrypted block of the previous record: an attacker observing the wire and in position to input some data in the stream can push just enough bytes to trigger emission of a record, observe it, and thus deduce the IV which will be used for the next record, whose contents will begin by the next byte the attacker will push.

Of all the IV generation methods you show, only the first one (IV generated with a cryptographically strong PRNG) will protect you against chosen-plaintext attacks. This is what was added to TLS 1.1.

On a specific situation like your credit cards in a database, some of the possible attacks may or may not apply. However, don't try to "cut corners" too much. If you put user data in the database, then chosen-plaintext attacks may apply: an attacker who can look at your database (e.g. with some SQL injection technique) may also act as a "basic user" to feed you with phony credit card numbers, just to see what shows up in the database.

In particular, in that scenario, if you use deterministic encryption (and that's exactly what you get with a fixed IV, be it all-zeros or not), then the attacker can simply brute-force credit card numbers: a number is 16 digits, but one of them is a checksum, and the first four or six digits are from the bank, and the remaining one are not necessarily "random", so such kinds of attacks can be effective.

Bottom-line is that if you use CBC, then you must use CBC properly, i.e. with a strongly random IV. If you prefer a monotonic counter (or clock), then don't use CBC; instead, use a mode which is known to be perfectly happy with a monotonic counter, e.g. GCM. It is already hard enough to achieve security when cryptographic algorithms are used by the book, so any "creativity" here is to be shunned.

And, of course, contents which has been encrypted with a given key is no more secret than the key itself. When an attacker has read access to your database, he might have read access to more than the database -- in particular, to the encryption key itself. It depends on where you store the key, and also on the extent of the attacker's access (SQL injection, stolen backup tape, front-end system complete hijack,...).


Should 2-factor authentication using SMS be deprecated? Google, Facebook and most of the important websites (banks, payment sites, etc...) use SMS as the major method for authorization (in case of 2 step auth) or for controlling the account (password reset, etc..).  However, already long ago was proven GSM technology to have the disclosed vulnerabilities:

SSL7 vulenrability
Unprotected A3/A5/A8 algorithms
old GSM end-user encryption-less technology, unchanged since the day when it has been implemented
NIST updates.
SMS-C vunlerability
SMS verification, is it secure?
Worst way
Does average Joe need to be worried about SMS interception?
etc..

A) That surely tells the world, that SMS-enabled services are really hackable (yes, it needs some money and resources, but as time goes, everything becomes cheaper). So, depending if you are important figure, or even if hacker targets you specifically, or even some bulk-hacker software might be written (who intercepts all SMS within radius), so your SMS can be interpreted easily.
B) That also means, that in some cases, having 2-FA (using SMS) can be WORSE, then being without 2-FA at all.
So I have 3 questions:

What is a foreseeable future - will worldwide GSM providers soon fix all the vulnerabilities and upgrade the technologies easily?

Who can force the major technology giants (Google,Twitter,FB,EBAY,AMAZON...) etc to allow us using 2-FA without SMS ? (At this moment, only Google and FB allow to remove phone-number as 2-FA, if you remove the phonenumber-entries from all places in your account, but such critical services, as LastPass, Authy, etc... doesn't yet allow)

Before GSM providers or websites will upgrade technologies, what steps can we do to avoid our SMS being intercepted? Can we have some "protected-sim-number" or program who will avoid autoswitching or detecting interception, or blocking it or whatever?

Bruce Schenier talks about this issue here.

To quote the article.

  Here are two new active attacks we're starting to see:

  Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank's real website. Done right, the user will never realize that he isn't at the bank's website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user's banking transactions while making his own transactions at the same time.
  Trojan attack. Attacker gets Trojan installed on user's computer. When user logs into his bank's website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

  See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

The problem with 2fa is that the password and the otp are both sniffed. Or just the password is sniffed and then the user taps the 'tap here to login' prompt. Either one allows the attacker in.

As mentioned by defalt. The proper way to authenticate a user (mathematically speaking) is to use strong mutual authentication like how yubikey's security key does.

  1) What is a foreseeable future - is it going to happen, that worldwide GSM providers will soon fix all the vulnerabilities and upgrade the technologies easily? And if they don't plan this, then what should we do?

Things take a very long time to change because of lock-in . Ipv4 was predicted to be dead by 2010. In 2019 ipv6 usage is about 25%. Rolling codes were created back in the 1980s but fixed code systems are still around in 2019. So sms will stick around for a long time to come.

The best thing you can do is utilize the strongest authentication that a website has available. There's not much an individual user can do beyond that. It's really up to the website to implement strong authentication.

  2) What is a foreseeable future of internet - does GOOGLE, BANKS and all others tend to deprecate SMS authentication soon, or that's not gonna happen, and we are will be still sticked with #1 problem?

Google and Yubico are working hard on upgrading user authentication for the internet in 2 ways. 1. delivering hardware based tokens and 2. making it easy for web servers to implement webauthn. These 2 ways are really just different sides of the same coin.

  3) And as a last note, of course,in our reality, 2 step auhorization(SMS based) increases security from most of hackers(i.e. in case our passwords are stolen) , but the reality turnes out to be, user who uses 2-step sms authorization (or, doesn't use 2step, but has entered own mobile number in his profile, as a recovery method) has increased security threat - for example,when hacker doesnt know your password, but is capable to hack sms (as opposed to the first category of hackers, when you have increased security instead). Quite a problematic dilemma.

A chain is only as strong as it's weakest link. If it's easier to hack someone's account directly or by "recovering" the account. The attacker doesn't care. A website needs a strong primary way of authenticating it's users, and if it chooses to implement recovery. That needs to be secure too.


Online Political Voting System What are the security flaws of this voting system ?

Let's say one month before the elections an offline machine auto-generates sealed envelopes for each voter which contain 3 unique GUID codes. The envelops are sent by mail to voters.

If a voter signs for receiving the envelope he can participate only in online voting. If he doesn't then he can only participate in offline voting.

The machine drops the codes for the people who did not sign and releases their voter identities for the offline vote. At this point the machine deletes the voter identity to ensure vote secrecy. The only place which still associates vote identity with the codes is the envelope found in possesion of the voter.

In voting day the user provides code 1 and the site answers with code 2, proving that it is not hacked. Then user provides code 3 which proves to the site that the user is legit. Then user can vote. The vote is associated with code 3, NOT the voter's identity, which does not even exist on the server.

The user can at any time check it's vote to see it's correct. If it's not (for whatever reason) he can go with the envelope (which has hard to reproduce security marks-like money) to a regular voting place, where his electronic codes are canceled and he can do a normal vote.

When the voting is done the machine publishes the full list of codes (the 3rd ones) and also the full list with all the codes that have voted. That way anyone with a bit of excel/data analysis knowledge can check that there are no extra codes , and count the results, acting like an observer.

PS. Of course all other security measuers still apply: a VPN room for every town, voters receive a CD/DVD with a dedicated secured virtual machine with the VPN preconfigured, etc

This system allows people to sell their votes.

Take the envelope and show it to the vote buyer, who now knows the voter's three numbers.
Vote.
The vote buyer can now check how you voted by checking each of the three numbers.
If you voted as the buyer wants, you get paid.

The flaw here is that it assumes that the voter wants to keep the voter's identity private.  But in a vote selling situation, that is not true.  The voter wants to let the buyer see the voter's vote.

The typical approach to avoid this with online verification is to arrange things so that the voter can change from the original plan and vote different numbers.  However, that is still subject to the problem that the vote buyer can usually detect the different numbers.  Because when the buyer checks the agreed combination, there's no vote there with the desired ballot.  But with your system, it's not even that difficult.  Each number is unique and only one of the three would count.  So a buyer can easily check all three.


X509 / SSL certificates in practise After learning the theory behind cryptography I'm having quite some problems understanding how SSL or X509 certificates works in practise and I simply cannot find useful information in the internet.

To my understanding, a webserver needs an SSL certificate to proof to the client that he is who is claiming to be (e.g. www.company.com). Beside that, I assume that it is also used for exchanging a temporary session key for symmetric encryption (probably AES) by some asymmetric key distribution system like diffie-helmann?

In that case: Does the certificate which the Webserver holds, contain multiple public keys for all these crypto systems, for example an RSA key for RSA Signatures, the DL parameters for Diffie-Hellmann? Or does he need multiple keys (also for multiple key sizes?)

I would be extremely thankful if anybody could tell me what exactly happens (step by step), when a client is connecting to a https address. Thank you so much!

No, there is only one public key in the certificate. Obviously the server should also have the private key that belongs to the public key in the certificate.

The session key is retrieved using key establishment. There are basically two ways:

the master secret is generated and then encrypted by the client using the public key of the server, the server can now decrypt the master secret and derive the session keys;
the master secret is derived using Diffie-Hellman key agreement, the frames required for the key agreement are then signed by the server using the private key and verified by the client to perform the authentication.
in principle the certificate can also contain a static Diffie-Hellman key but in practice this isn't used (much); in this case the key agreement is automatically verified.

The session keys are then derived from the master secret using key derivation with the PRF (identified at the end of the ciphersuite).

Type 1. is used by cipher suites starting with e.g. RSA_. Type 2. is used by ciphersuites starting with ECDHE_ or DHE_. Type 3 is identified with ECDH_ or DH_.

In case of client authentication the client should also perform authentication of the exchanged frames.

TLS 1.3 will only allow type 2 key establishment as it only relies on signature generation for the certificate. Furthermore it provides forward secrecy because the ephemeral (temporary) DH keys are destroyed after the key establishment has been performed. This makes it impossible to break the key establishment itself, re-calculate the session keys and decrypt the encrypted frames with the plaintext within the session.


Should websites be allowed to disable autocomplete on forms or fields? Currently, there is an HTML form/input attribute called autocomplete, which, when set to off, disables autocomplete/autofill for that form or element.

Some banks seem to use this to prevent password managers from working. These days sites like Yahoo Mail seem to do it as well because they feel that password managers are unsafe.

A few weeks ago I implemented a feature in Firefox that gives the user an option to override this for username/password fields only (i.e. to disable the password manager). There now is a request that is asking for it to override autocomplete=off by default. Quoting the issue:

  This behavior is a concession to sites that think password managers are harmful and thus want to prevent them from being effective. In aggregate, I think those sites are generally wrong, and shouldn't have that much control over our behavior.

This makes sense to me, for similar reasons as the ones in this comment by BenB.

  autocomplete=off has been abused a lot recently. Yahoo started using
  it for their login (including webmail and my.yahoo.com), which is why
  I stopped using Yahoo. Webmail apps - even some bigger providers - now
  use it, which was decidedly not the purpose. The admins are very
  self-righteous, and insist that the keep this "for security" because
  password saving "is unsafe".

  They are misguided, because

  keyboard loggers exist and are
  widespread, probably more widespread than malware that can read
  Firefox password store.
  even simple attacks by the little nephew
  exist: Just look over the shoulder
  possibly most importantly,
  forcing users to re-enter their password every time practically forces
  them to use a simple password - easy to remember, easy to type,
  probably even used on multiple websites. This obviously lowers
  overall security dramatically and thus poses a danger to security.

  So, autocomplete=off is actively harmful for security.

  And a massive pain for end users, without a recurse for them apart
  from severing entire customer relationships.

There have been many workarounds (usually bookmarklet-based) that have been posted on the Internet. IE11 has already removed support for autocomplete=off.

The question is twofold:

Is there any significant increase in security for a website when it uses autocomplete=off on password fields? Or is it actually harmful to security as per BenB's comment?
Should browsers allow this attribute by default and give this much control to the website? (This bit is subjective, feel free to not answer)

While my situation is specific to autocomplete=off for username/password fields (the code only affects the password manager), I do welcome input on the broader aspect of disabling autocomplete=off

The problem is that this one setting simultaneously controls the behavior of two similar but sufficiently dissimilar functions in the browser such that an optimal result is difficult to achieve.
First, we have what you might call "smart" or "naïve" or "automatic" auto-complete.
This is the original auto-complete technology. As you fill in forms on various sites, the browser watches the names of the forms and the contents you fill, and silently remembers the details. Then, when visiting another site with a similar-looking form, it "helpfully" fills in fields using the values it filched from your previous behavior on other sites.
The idea here is to save you time without any configuration or decision-making on your part. Filling in your name? We'll automatically fill in the name you used last time. Filling in a credit card? We'll fill in the credit card you used elsewhere.
In its zeal to be helpful, the browser is sharing your secrets from one site with all the others, just in case it's what you wanted. From a security perspective, this is a disaster for all the obvious reasons and for several non-obvious ones as well. It has to be disabled, and probably shouldn't have ever been implemented to begin with.
Second, we have "explicit" or "secure" or "configured" auto-complete
This is the world, primarily, of saved usernames and passwords. In this incarnation, the browser saves your form data only with your explicit approval. Ideally, it stores that data in an encrypted store, and most critically, the data is firmly associated with a single site. So your Facebook password stays with Facebook, and your Amazon address stays with Amazon.
This technique is critically different in that the browser is replaying saved behavior when the matching environment is detected. By comparison, the other technique is anticipating desired behavior automatically by looking for similarities.
When you visit the site and it presents a login form, your browser should helpfully auto-fill the data you had explicitly saved for that purpose. The interaction should be quick and thought-free for the user. And, critically, should absolutely BREAK in a phishing attempt. The browser should be so completely unwilling to deliver credentials to a phishing site such that it makes her stop and think about why the thing isn't working.
This feature is your primary line of defense against phishing. It has to work. You are unavoidably less secure if the user can't depend on this feature working transparently and effortlessly under normal conditions.
And while this is primarily used for credential storage, it's also a secure place to put other secure data as well, such as payment cards, address, security questions, etc. Such additional data probably won't be site-specific, but should probably not auto-fill without prompting.
One option to rule them all
The problem here is that in many implementations, the autocomplete=false option controls both behaviors. Both the one you want to keep, and the one you want to kill.
Ideally, "secure" auto-complete should never be disabled. We're relying on this feature to add safety, so misguided site operators shouldn't be allowed to jeopardize that.
And ideally, "automatic" auto-complete should be disabled by default, to be enabled only for those rare conditions (if any) where you actually want the browser to re-use your input from other sites.


Methods for determining if a file is encypted? I am working on a anti-ransomware project. It simply monitors the filesystem, and watches for files being created, and deleted. (also monitors for known ransomware file extensions.)

Basic Operation:  If (File X in Directory Y is created), and soon-after (File Z in Directory Y is deleted.)  Scan File X and try to determine if it is an encrypted file.

I am stuck because I have no idea how to determine if a file is encrypted or not. I have read through quite a few threads on SO, but I've still turned up empty.

My question is basically: What methods can be used to determine if a file is encrypted?

You could run ent to see how much entropy a file has, a file with high entropy is likely either compressed or encrypted (or both). A problem is that JPEG, XLSX and ZIP are compressed, so actually compressed files are very common.

If you suspect that X is an encrypted version of file Z then you could check if they have similar sizes, plus small delta for encryption headers.


Is it a bad idea using two firewalls on the same PC? If i'm using windows default firewall and a third-party firewall, is it represents a security issue or I have to worry just with possible conflicts? And what type of conflicts could exists?

Keep in mind that firewalls generally use one of two approaches to filter network traffic in Windows:

Classic way by installing own driver (used by, for example, Kaspersky).
By using OS mechanisms, specificaly "Windows Filtering Platform" - an internal, kernel-level packet filtering (similar concept to Linux NetFilter), which is available via API since Windows Vista (used by, for example, F-Secure).

In the first case, when you have two drivers installed, there could be a potential problems with prioritization and order of processing. Also, those drivers can install own hooks and do some other hacks which could result in incompatibility or system instability.

In the second case, when two firewalls use API, it will result in messing around the same, built-in mechanism.

In the third case, there will be an driver and Windows Filtering Platform.

It is good that you want to add another level of protection, but I suggest to do it on the edge of your network (or inside the network). Today everything is much more complicated than in the old times, so I wouldn't install two firewall's or antivirus programs on one system, because they are too critical system level applications which interfere with OS very much.

The best solution is to use Linux NetFilter or BSD's pf, but it generally requires another machine running. Take a look on MikroTik devices - they are essentially Linux boxes enclosed in small devices. They wouldn't be as good as native Linux, but are better than most other routers.


Cloud based private key storage for users Say I want to create a cloud based private key storage for users, which they can use to sign documents.

On the server side I would use a HSM to make the key storage more secure.

One option is that the signing happens on the server side. But, this way the server knows the private key of the user, which is not what I would want.

Another option is to have the user's private key wrapped in an symmetric key (for example AES) only known by the user, and store it on the HSM.

This AES key would be derived from the user's password. There are mechanisms like PBKDF2 to create a key from password.

Then, when user requests to sign a document, the server would send that users's private key encrypted by the AES key only known to that user.

The client side(which could be an android app, or webapp based on javascript) is used to make a signature.

Also, there would need to be a password change mechanism which would function something like this:

client requests his private key from the server(encrypted by his AES
key)
client decrypts the private key usign AES key derived from his
password
client generates a new key using his new password
client encrypts his private key with his AES key and sends it to the
server
server updates the wrapped user's private key with the new one

I don't know much about the HSM modules, but as I understand they have a similar functionality as a smart card( the key sould never leave the HSM and all the encryption should happen on it).

I read somewhere that some HSM's allow key extraction when PKCS#11 "CKA_EXTRACTABLE" is set at time of a key generation. But, wouldn't that, for the most part, defeat the sole purpose of the HSM.

Also, would I be able to implement the mechanism for password changing I described when using a HSM?

Another option would be that the signing happens on the HSM, and the private keys are wrapped by the AES key, generated from the user's password. HSM then unwraps the private key and sign the file, but the private key itself cannot be accessed by the cloud provider.

Would, in this case be possible to implement the password change mechanism I described?

Also, password-based key derivation mechanisms use salt to make rainbow table attacks more difficult.

How would salt be used in this case? Would it be stored on the server and then transferred to the client when using the service?

The requirement is that the user can use the service on any device(mobile, desktop) only knowing his username/password.

I would probably include 2FA by adding SMS verification when authenticating to the server.

Your scheme is workable, but it completely defeats the point of an HSM. You can do that with a plain database storage, too.

The point of a HSM (which is actually not much more than a huge and very fast smartcard) is that you can securely store (private) key material without anybody, including the administrator, being able to extract it.


How to "break" remote access on Windows and rooted Android? Let's say you want to "break" all remote access capabilities on your rooted Android phone and your Windows PC. What do you do or delete so remote access is truly broken and can't be used (by a hacker)?

I don't see much of a difference with your previous question How to close or block remote access backdoors? except that it now a bit more focused by asking only for Windows and Android.
It looks like you are not asking about disabling explicitly implemented remote access functionality but anything which might allow an attacker to allow remote access. Since this might also include bugs in the firmware and drivers the only way to disable remote access is to disable any network connectivity at all, i.e. disable network interfaces and/or put the device in some Faraday cage or similar. This includes everything which might be reachable by the hacker you envision, i.e. Ethernet, WiFi, Bluetooth, USB based networking and maybe even NFC.
Of course, this makes the devices kind of unusable for most modern use cases. Given that it may be questionable if it makes even sense to harden an existing device/OS this way, or if is better to use some more specialized device with a smaller attacker surface for this specific use case instead.


Is it safe to abandon a free webmail account that has been in use for a significant amount of time? I have a free webmail account that I have been using for around ten years now. Over the past two years I have almost phased out using this address.

I have concerns around accounts that I may have created on forums and other sites like eBay etc that I may have lost track of over the years that are either now inactive or "closed".

If I close this email account, then someone signs up using the same username then attempts to sign up to one of these sites, they might end up doing a password reset or reactivating my old account and getting my old history etc there?

Is it safe to close this account? Or would it be better to keep it active but not in use?

No. Never close email accounts that are associated with you or any other accounts you have/had.

After your address is free, somebody can take it and use it to recover other accounts, mess your relationships with old contacts, or even use it to commit illegal activities (death threats to politicians, subscriptions to child porn sites, etc..), and if the email address can be traced to you, you'll get yourself in troubles.

My advice is this:

Change your password to a randomly generated and long password. Save it in your password manager.
Learn your service provider's inactivity policy. Google will close accounts after 9 months, Hotmail after 360 days, Yahoo after 6 + 2x months (x is the age of your account in years).
Schedule a repeated event in your calender to remind you to login to your accounts so they don't expire on their own.


Secure HTTP Headers - where should be implemented, WAF or code level? I have a REST API exposed to the Internet and another application with form-based authentication. These apps are behind a Web Application Firewall.

Question is, where I should implement the below security HTTP headers, in the WAF or at the code level?

X-XSS-Protection
X-Frame-Options
X-Content-Type-Options
X-Permitted-Cross-Domain-Policies
HTTP Strict Transport Security
HTTP Public Key Pinning
Content Security Policy
Referrer Policy
Feature-Policy

Second question:
What if the header is configured on code level and as well on WAF level?
I will get header twice, but is it wrong?

From the perspective of the client, it does not matter where these headers are implemented; only whether they are implemented at all.

But, from the perspective of deployment, a WAF should be treated only as an additional line of defense and not as the single line of defense. This means that proper input checking should be done in the web application itself and proper setting of security headers too, at least for most of the headers: HPKP can of course only be set on the TLS endpoint owning the certificates which might be the WAF (if it should be set at all since it is deprecated).

Setting the security headers in the web application itself is also better from a development perspective. As much as developers should know what the expected type of specific inputs is and how they should be checked, the developers also know about how the application works and what for example the tightest Content-Security-Policy can be. A WAF is instead often deployed by a different team which does not have deep knowledge of the application and therefore cannot easily set the security headers to the tightest values acceptable by the application.

Therefore it should only be set in the WAF if it cannot be set in the application itself, which might be the case with third-party applications. As an additional line of defense, though, a WAF may still be used to ensure that the headers are there and sufficiently strict, since it might be that the developers forgot to set them.


Encrypting short identifiers? I am developing a webapp that does not reveal record count, because it hides the primary key. I am looking for a better way to do this.

My favorite idea is to encrypt the ID itself with a block cipher, because that would require not additional tracking tables, and if the block size is equal to the key size, it should work fine.

However, I don't want a 128 bit block size, because it would take awhile to type example.com/records/MTZjaHJzRm9yMTI4Yml0cw (Base 64 representation)

The ideal block size would be fully adjustable. I want to be able to make an 8 digit ID input that results in an 8 digit output, that is collision free by using a permanently stored random key. The input would be the real primary key, and the output would be the identifier shown to the public. I may decide to change the digit length, or to switch to Base64 identifiers, and I would like for the algorithm to be flexible enough to accomodate this?

Can you recommend an encryption routine for such short data and outputs? I don't care whether the key is short or not, only the data and output has to be.

What you want is format-preserving encryption. There is unfortunately no ready-to-use standard for that, but some reasonable constructions are known. I would recommend the Thorp shuffle which is an extremely unbalanced Feistel scheme; given enough rounds, this can implement a permutation which is close to the optimal (except that a Feistel scheme is necessarily an even permutation).

Be aware that implementing your own cryptographic algorithm is fraught with perils. If you are not comfortable with the article quoted above, find someone else who is. (Fortunately, in your specific scenario, if you use a weak cipher the penalty is limited: attackers may guess the number of records or predict the next primary key value.)


Can a biometric device serve as a user based entropy source? I am wondering if a biometric device can be used to generate some entropy or key material that would be stable across each authentication.

The contrary would be for biometric devices to act like an oracle, with a simple YES/NO answer to any authentication request.

What I am thinking about would be to gather the results of a biometric authentication and always come up with the same "number", which would be unique for any given biometric input.

For example, Alice biometric ouput would always be 64489c85dc2fe0787b85cd87214b3810, without having that number stored in advance somewhere, like I would generate a key from a password to decrypt something, without having store the password or key anywhere in advance.

I'm not interested (yet) in any standards or API for this, or in implementation details like the fact that all fingers from a same person would have a different (but stable) output. My question relates to the biometric authentication process inside the device.

No,

If a device sequenced the user's genome from a skin cell, the results would be the same each time. Assuming the skin cells have replicated without errors.  But it seems what you are asking is impossible, since you have to have a database somewhere that stores the answer to your key.


Why is subject verification an effective means to detect MitM attacks in TLS? Say, an attacker fakes an original server certificate by a trusted CA using a another certificate from the same CA in a Man-in-the-middle attack. Why can this be detected using subject verification on the client-side?

(I'm not asking about the general workings of the protocol, all it's mechanisms, but, in the framework of those mechanisms, and assuming a general knowledge of TLS, how subject verification specifically prevents a MitM attack, without the need to explain extraneous mechanics of TLS.)

Here is my attempt to answer the question, based on my research in the meantime.

The attacker may obtain another certificate from a trusted CA, but he is unable to alter this certificate in any way. The assumption is that the CA will not issue a certificate for the subject under attack to the attacker, since he cannot prove that he owns the subject (domain name).

When the attacker tries to mediate the traffic between the client and server in a MitM attack, he has to present his own certificate to the client, instead of the servers, to be able to eavesdrop on the traffic. If the client performs subject verification, he will see that the attackers certificate does not contain the correct subject, even though his certificate is coming from a trusted CA. This way subject verification can detect MitM attacks.


Does CSRF prevention also prevent reflected XSS attack? What I understand about reflected XSS is

  ... When a web application is vulnerable to this type of attack, it will
  pass unvalidated input sent through requests back to the client... [1]

Assuming that my webapp has a CSRF validation on server that checks for a valid CSRF token for all requests. It will give proper error if it receives any request not containing CSRF token (this error is a simple string, it has no attack vectors). For the sake of completeness, let's also say that I have proper security measures for preventing CSRF token from being stolen or guessed.

So is it safe to assume that CSRF tokens also prevent reflected XSS attack because both of these are true:

The server doesn't reflect anything if CSRF token is not present.
The attacker cannot have or guess CSRF token.

The answer is usually yes if the value is only reflected if a valid CSRF token is provided - the user can only "attack" themselves in this instance.

However, if there is a form generated that correctly encodes output to a page that contains a CSRF token but then that form submits to a page that does not correctly encode output then your site is still vulnerable.

e.g. Original page (a GET request, which is not normally subject to CSRF tokens due to lack of side effects - only POSTs should cause side effects):-

www.example.com/displayForm.php?name=<script>alert('xss')</script>

contains

<input type="hidden" name="csrfToken" value"123456" />
<input type="hidden" name="name" value="&lt;script&gt;alert(&#039;xss&#039;)&lt;/script&gt;" />

However, when this page is submitted by POST, name is output unencoded:

<body>

Hello <script>alert('xss')</script>.

</body>


How to secure Password and Salt on a deployed application I have a question regarding one step of protection more than salt/hash.  I work on an application that is distributed to many clients and then deployed on their networks.  If I set a password on one instance of the application and then look up the generated salt and hash in the database, what mechanism can stop me from copying a known password's salt and hash into another instance of my application?

You can add a per-instance salt as well.  This would be stored in the config for the application, and would result in different hashes for each instance, even for the same salt/password combination.

Now the question arises of why you'd want to do that.  If someone has gained read access to one database and write access to another, it seems they've already got quite a bit of access.  Why would they copy a salt & password over rather than (say) just inserting a new account?


Authenticate that I am the poster of a certain anonymous message I'm a programmer, and I've made a nifty script that scours a certain internal forum site. Messages posted on the forum are all anonymous, so I'm wondering how exactly I can get my script to realize which of those messages are mine. I have a basic understanding of encryption, and was planning on encrypting my messages with a pre-generated public key, and store a private key in my script.

Unfortunately, in recent light of events, I've realized that the private key can be obtained from the source code, which in turn could be used to generate an equivalent public key, and then used to impersonate me.

How does my open-source script authenticate that a message that was posted, was posted by me?

Constraints: 1) All messages that I post is visible to others, so no secrets can be transmitted to my script. 2) The source code of my script will be open.

If you want to publish your script, then you should do it the other way around: Put the public key into your script and keep the private key to yourself.

Sign your messages with your private key. The script can then be used to verify that those signatures come from you.


How safe/secure are banking applications on Android phones? I have a mobile banking application installed on my phone which allows me to pay for things, transfer money using my phone from my account to another etc.

How safe or unsafe is this application?  For example, what are the chances that I could get malware/virus/spyware/keylogger on my phone which could somehow record my bank details, or worse, steal my money and send my money to some foreign countries bank account?

Is such a thing possible, or is this impossible, i.e. are all android applications sand-boxed or something, which makes it impossible for malware/virus/spyware/keyloggers to tap into another application on the same phone, i.e. the banking application?

I am specifically talking about banking applications on android phones.

Interesting question. In short I would say it is safe at least as your laptop/desktop are safe.

Explanation: mobile OS are far more advanced in their security architecture than your good old windows OS is.

Having said that it really depends on your device, OS and how you use it.

For example devices I would consider safe without any hesitation are unrooted iOS devices and Android Nexus devices. I would say most of these are much safer than most PC's are.

If you root/jailbreak your device you are greatly increasing the risk since you are breaking the defense mechanisms of the OS.

If you allow installation of applications from untrusted sources you are increasing the risk

If your device is not a high end device which gets updates on a timely manner you are at bigger risk (this is why Nexus devices are the safest among android devices)

If you connect to open public WiFi networks you are increasing your risk.

Additionally I would recommend to use the default keyboard and not some 3rd party keyboard. Not because I think 3rd party keyboard on the market are malicious (Apple and Google perform security audits on their markets) but because they might be logging your input for "good" purpose like word completion - but you cannot be sure they are doing it in a secure manner which will prevent your passwords from leaking who knows where...


Remote access to my home PC - minimizing the risk I use TightVNC behind my home LAN, but am open to alternative (free) suggestions.

Many's the time that I have wished that I could have remote access to my home PC (which must run Windows, for business reasons), generally   just for a few minutes. Until now, I have avoided doing so, but it would be nice to have occasionally.

How could I reduce the attack vector?

I was thinking of coding a little Python script to run on the machine and react to a specially titled email, or the appearance & disappearance of a specially named (blank) file on a website, to start/stop the Tight VNC server. Of course, there is no guarantee of immediate, or even timely, delivery of email, and I don’t want to be permanently polling a website, but I could live with access after a few minutes of my action.

Would that be a good mechanism?
Is there something more secure?
Any general hints & tips on reducing the attack vector on having a VNC server running, even if only for a few minutes, on my home PC (which probably allows access to everything behind the router if compromised)?

I prefer free solutions to paid, and off-the shelf to homebrew, but as a  software developer I am not averse to rolling my own if needs must.

Obviously, I don’t want to take a security through obscurity approach.

A typical solution is to use a VPN. A VPN makes it possible to connect to your home network (and subsequently to TightVNC) and VPN authentication is often sufficiently hardened to expose to the internet.

Another option is to use a SSH server, which can act as a poor man's VPN. This is also TightVNC's own advice:

  In the mean time, if you need real security, we recommend installing an SSH server, and using SSH tunneling for all TightVNC connections from untrusted networks.


Where can I learn cryptography/cryptanalysis the hard way, without going to school ? Any good book? I'm not so bad at mathematics:

I know what are p-list and p-combinations, I know matrix algebra, I know what a XOR is, I know how to tell if number is a prime, etc: I'm not the programmer who hates math because he is bad at it, but I don't have a PhD eitherway.

I'm not bad a computer sciences either, well at least in term of general computer science culture:

I know C, C++ (both learned at school), python, some haskell,  what text encoding are out there, how UNICODE works, I know how a file can be compressed or encrypted, what common algorithms are out there (diffie-hellman, the LZMA algorithm, DES, AES, Serpent, Blowfish, SHA, MD5...). I got a lot interested in cryptography on wikipedia or other websites, but I don't think wikipedia can teach me cryptography without detailing algorithms or without practice; for example I know what is synchronous cryptography and what is asynchronous (public/private key).

I'd like to learn how to properly and securely implement the most popular algorithms, and how to make them reliable: a book or good tutorials or courses. I've quickly searched on Khan Academy, but this subject is not trivial and requires both knowledge in math, computer sciences and/or electronics.

I don't want to read pages and pages of just theory about the basic things I might already know or might be not really relevant to today's cryptography, like a paper written by a researcher, just something practical, with problems, and cryptanalysis problems, for students.

I have currently much free time, I'm only 26, and I'm sure I can learn this stuff, not only for the pay increase it can bring me but also because I've always been fascinated by cryptography without actually understanding it, I just can't find any good material.

(LZMA is a compression algorithm, not cryptographic.)

For the purpose of implementing cryptographic algorithms, the generic method is getting the relevant descriptive standard, grabbing your keyboard, and trying. Most standards include "test vectors", i.e. sample values which let you know whether your implementation returns the correct answers. At that point, things differ, depending on what kind of algorithm you are considering.

Symmetric cryptography:

Symmetric algorithms cover symmetric encryption, hash functions, and message authentication codes (MAC). You do not need to know much mathematics to handle these; most of it is about additions of 32-bit and 64-bit integers (that's modular arithmetic, with 232 or 264 as modulus) and bitwise operations (XOR, AND...).

Such code is usually done in C. Good performance is achieved by having some notions on how the C compiler will understand and translate the code into instructions for the CPU; knowledge of assembly is not strictly mandatory, but quite useful. An important parameter is cache memory: loop unrolling is usually a good tool, but if you overdo it, performance drops sharply.

I suggest beginning by implementing the classical hash functions (the SHA family, described in FIPS 180-3) and trying to make them fast. As a comparison point, get OpenSSL and use the command-line tool openssl speed to see what kind of performance can be obtained (this tool is already included in any decent Linux distribution, and it works on Windows and MacOS too). For instance, on my PC:

$ openssl speed sha256
Doing sha256 for 3s on 16 size blocks: 4842590 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 2820288 sha256's in 2.99s
Doing sha256 for 3s on 256 size blocks: 1262067 sha256's in 2.99s
Doing sha256 for 3s on 1024 size blocks: 395563 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 53564 sha256's in 3.00s
OpenSSL 0.9.8o 01 Jun 2010
built on: Wed Feb 23 00:47:27 UTC 2011
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           25827.15k    60367.37k   108056.57k   135018.84k   146265.43k

which means that OpenSSL includes a SHA-256 implementation hand-optimized in assembly, which achieves 146 MB/s when processing 8 kB messages. On the same machine, a pure C implementation ought to get to at least 130 MB/s.

For an example of how hash functions are implemented in C and Java, and how hashing speed can be measured in a meaningful way, see sphlib.

Afterwards, you can try symmetric encryption, in particular the AES (FIPS 197). It helps a bit to know what a finite field of characteristic 2 is, but the standard is clear enough to guide you through a perfunctory implementation. Then, try to optimize things. OpenSSL can serve as a comparison point, and get inspiration from the AES implementations of Brian Gladman. As for security, there has been some concern about what key-dependent information could be leaked through use of look-up tables in the implementation (try to search for "AES cache timing attack"); trying to reproduce that kind of attack is a very good exercise (mind you, it is not easy, but if you succeed in demonstrating it in lab conditions then you will have learned a good deal on how cryptographic implementations work).

Asymmetric cryptography:

Asymmetric cryptography is about the algorithms which involve more than one party. This includes asymmetric encryption (RSA, ElGamal), key exchange (Diffie-Hellman) and digital signatures (RSA again, DSA...). The maths contents are much bigger there, and optimization is a much broader subject than for symmetric cryptography, because there are several ways to implement each algorithm, instead of a single "obvious" implementation path.

A good reference is the Guide to Elliptic Curve Cryptography. Although it is mainly about elliptic curves, it includes a general treatment of the implementation of operations in finite fields, and it so happens that this is the sample chapter which can be downloaded for free at the URL linked to above. So get it and read it now. Another indispensable reference is the Handbook of Applied Cryptography, which can be freely downloaded; chapter 14, in particular, is about efficient implementation.

RSA is simple enough, and is adequately described in PKCS#1. There are possible timing attacks on RSA, which are countered by masking (yes, this is a paper "written by a researcher", but in the subject of cryptography, researchers are the people who understand what is going on). If you get the hang of modular arithmetic, you can try to implement DSA (FIPS 186-3). Diffie-Hellman is mathematically simple (it needs nothing more than is needed to implement DSA) but its describing standard (ANSI X9.42) is not downloadable for free.

Elliptic curves are a popular future replacement for modular arithmetic; EC variants of DSA and Diffie-Hellman are faster and believed more secure with shorter public keys. But that's more mathematics. There again, the Guide to Elliptic Curve Cryptography is the must-have reference.

There are other kinds of asymmetric cryptography algorithms, e.g. the McEliece cryptosystem (asymmetric encryption; there is a variant for signatures described by Niederreiter) and algorithms based on lattice reduction. But they do not (yet) benefit from published standards which take care of the implementation details, and there are not so many existing implementations to compare with. You'd better begin with RSA and DSA.

Cryptanalysis:

Cryptanalysis uses a much higher dose of mathematics than implementation.

For symmetric cryptography, the two main tools are differential and linear cryptanalysis; see this tutorial.

My own path to cryptography began by implementing DES, and then implementing Matsui's linear cryptanalysis on a reduced version of DES (8 rounds instead of 16). DES is described in FIPS 46-3, which is officially withdrawn, but still available. From DES can be defined Triple-DES (three DES instances, with three distinct keys, the middle one being use in "decryption" direction) and there are published test vectors for Triple-DES (also known as "TDES", "3DES", or sometimes "DES", which is arguably confusing).

For asymmetric algorithms, cryptanalysis mostly involves working on the mathematical structure of the keys, e.g. by trying to factor big non-prime integers in order to break RSA variants. Mathematics here range from the non-trivial to the totally unimaginable, so this might be too steep a learning curve to begin cryptography by trying to break RSA...


Windows' default certificate store for intermediate vs trusted root certificates - my self signed root CA cert goes to 'intermediate' by default? Is it possible to create self-signed root CA certificate that Windows will import to Trusted Root by default instead of Intemediate certificate store ? Obviously, it won't do it without the big giant nag window asking if you're really sure - but it would be nice to not have to go the extra step of specifying which certificate store it goes in.

Currently, both our root CA and intermediate certificates by default (if you just right click > install) go into the intermediate certificate store. If I tell it to install to trusted root store for the root cert, then everything works as expected (trust chain etc). However, ideally we shouldn't have to set this and instead have it assume it should go there (it would still display the are-you-sure dialog). Is this possible?

We have built (and are still fine tuning) a CA using phpseclib. As an example here is a root CA I generated (with sanitized details):

-----BEGIN CERTIFICATE-----
MIID7zCCAtmgAwIBAgIBITALBgkqhkiG9w0BAQUwgYYxCzAJBgNVBAsMAklUMREw
DwYDVQQKDAhUZXN0IE9yZzEPMA0GA1UEBwwGRGFsbGFzMQswCQYDVQQIDAJUWDEL
MAkGA1UEBgwCVVMxHzAdBgkqhkiG9w0BCQEMEHRlc3RAZXhhbXBsZS5jb20xGDAW
BgNVBAMMD1Rlc3RpbmcgUm9vdCBDQTAiGA8yMDEzMDcxMjA1MDAwMFoYDzIwMTQw
NzEyMDUwMDAwWjCBhjELMAkGA1UECwwCSVQxETAPBgNVBAoMCFRlc3QgT3JnMQ8w
DQYDVQQHDAZEYWxsYXMxCzAJBgNVBAgMAlRYMQswCQYDVQQGDAJVUzEfMB0GCSqG
SIb3DQEJAQwQdGVzdEBleGFtcGxlLmNvbTEYMBYGA1UEAwwPVGVzdGluZyBSb290
IENBMIIBIDALBgkqhkiG9w0BAQEDggEPADCCAQoCggEBANKeGI3lqA2GXEZj/PJc
wxENmoXH3xgHyu21/tXIMQCTPytg68Zo3g/A3YpUJrRA/atnwIe4efBRGOJPEL2e
YHcswVKaD0dowgaPCGhhHb7gJNZLW0bFDO3RnKaWN27cPDmJ1g0vFomUOq9aEiGu
glDolVWEjwmd4jhlndzBap5kiBYuS5LsG0R0j+5V/M+okEozNU3ZFY9JJQj3ktMi
CwBfnL+wGznCrOysu/QBtfnifk1U2Ai/fB+UMbQ/Y7pVAc/gG4aQHDBnS6G8FCsq
zlZ5yVVxqtueSO13E1pdTZCnnjurfGS01Q66HAV88ytO77637NUZ7S4LmjNasZnr
qJ0CAwEAAaNoMGYwCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O
BBYEFMs7EewverdoXjgsYVkfyh7IixciMCcGA1UdJQQgMB4GCCsGAQUFBwMCBggr
BgEFBQcDAQYIKwYBBQUHAwQwCwYJKoZIhvcNAQEFA4IBAQCfVm1cwB5rWp43vjbv
vYrWnAeYtgnusFzho+jizbR8Rm3Ue3ahlrARDY4m7h9blAXJXTTo8clDrBaIwE3h
T8laWJSNreBsCsjm1kKNYmAALiHAKSrKsn9ha52bw1SDaPMEXa9Gjr2OsteUyfWh
J0MHIjmVHymNaJFNQP9wE3osD6DR3YSENLgVBwq400dikZYHbjWbiwGtiiUl5UiS
iPWgXtj2NQa7RbXIPZQOvCECvqaB8NNeI0W/IyN3S5PHr6t9XkPPq9aq3VaFwF7w
BrddqctgjKdpFQpsb/YOfxwk51Wg8arPajmrItKMenaA3k85U8kCIPhGs1fUioNm
iep5
-----END CERTIFICATE-----

Are we doing something wrong, setting or not setting an extension? Perhaps it needs to be in pfx or other format instead of PEM? Or will Windows always default to intermediate, and nothing to be done about it?

Windows applies some not-really-documented heuristics to know where your certificate should go. Apparently, these heuristics have changed: when I import your certificate on a Windows XP system, it defaults to the root store (with the big warning), but when I try on a Windows 2008R2 system, it goes to the intermediate CA store.

One way to side-step the issue is that root CA are very sensitive objects, and should not be imported "automatically". A rogue root CA can be used to deal considerable damage on the victim and I am not sure a single popup is really enough as a protection measure. The popup is not even red and scary-looking; it is more like a boring wall of text:

It is like license agreements: who really reads them, honestly ?

Under these conditions, I cannot really blame Microsoft for directing by default certificate imports to an intermediate CA store.

Now for your specific question, if I were to hazard a guess about what makes some Windows versions consider your certificate as "probably not a root CA", I would point at the short lifetime. Root CA certificates usually last longer than one year. I suggest trying to make that certificate valid for 20 years or so. This may or may not solve your problem, but if it does, so much the better.

Note: a certificate which is both self-issued (subject DN and issuer DN are equal) and self-signed is not necessarily a root; as per X.509, a CA may emit such things if it wants to handle a smooth transition when trying to change some characteristic in its certificate. The path validation algorithm includes a lot of provisions for such self-issued intermediate CA certificates.


Can someone using (the Join Me) screen sharing software use it to access my PC's files? When using Join Me, can a file on a desktop be stolen by those viewing?  I was using Join Me and another person was communicating with me to set up log in and access to My Vault, when I noticed a folder went missing from my desktop for about 15 minutes and then reappeared in a different location then where I put it.  Was that person taking my personal file folder information?

While we frequently say that people "steal" your files, we really mean that they copy them. So, if the remote desktop user wanted to just get your data, they wouldn't have copied then deleted your files, they just would have copied them.

Furthermore, join.me does not allow for simple copy-and-paste file copying. Copying files is an interactive process that requires you to initiate the process.

What I suspect happened is that you or the remote desktop user accidentally dragged your folder across the desktop. This happens frequently in Windows. When you noticed that the folder wasn't where it was, you thought it disappeared. Later you found where it was on your desktop (this place may have been covered by a window making it impossible to see) and thought it had reappeared. The same thing has happened to me many times.

So, unless the remote user knows of some still unpublished, critical vulnerability in join.me, I think you're just fine.


Solution for Enterprise SW Eng. with Github and NPM Can anyone share an architecture or framework that supports the use of Open Source software in enterprise software development environments?

I'm seeking solutions to manage and mitigate the risk of compromised libraries and dependencies in CRAN and NPM.

I'm seeking reference architectures to satisfy IT Security pros, while enabling developers to exploit the power of public repos and package managers (with their dependency resolution).

While I acknowledge this is yet another attack vector I'm seeking practical solutions/examples/tools that help strike a reasonable balance.

I've heard mention of Internal repo Mirrors; Sandboxes for security testing, prior to promoting to production; Continuous Integration Platforms etc.

What is the state of the current thinking among the security community and are there any best practices?

Thanks

The answer is that a lot of organisations and enterprises make use of public repositories (e.g. npm, rubygems, NuGet) but I don't think there are a lot of well defined solutions for the risk that the use of unaudited 3rd party code introduces.

A couple of options to reduce the risk might be

Internal mirrors.  Your organisation hosts it's own repository and carefully selects what packages and versions are available on it.
Security Review Key libraries.  If you rely on key open source libraries you could have your organisation review their security either internally or have it done by a third party consultancy

There's some more details on some of the risks and potential solutions here in a talk I did for OWASP AppSecEU


Why do outgoing rules have priority over incoming rules? I've been spending the morning playing with my routers and I've checked one thing:

All of them come by default with an implicit deny configuration for incoming traffic, that is all packets should be rejected unless otherwise specified. Outgoing is either as implicit accept or does not have any rule at all.

With that default setup, I can browse without any problem. But I do not understand why. The connection starts because outgoing traffic is allowed, however when the response comes, it should be dropped because incoming traffic is implicit denied.

I'm trying to figure out why is this happening, and the only idea with sense that comes to my mind is that outgoing rules must have priority over incoming rules. Is there any other explanation?

Your firewall configuration on the router is a stateful one.

When an outbound connection is established, the router/firewall keeps track of the connection and allows any response over the same connection through the firewall.


What are the risks of removing ISATAP from the default global block list? The process of installing Microsofts pseudo VPN called Direct Access requires me to remove the ISATAP name from the default global block list by running this command:

dnscmd /config /globalqueryblocklist wpad

What are the implications of running this command and what are the benefits of leaving ISATAP blocked?

Microsoft Dynamic DNS allows hosts to request a specific host name they would like to use. (That's what the dynamic means!)

As you'd expect, you can't use this feature to steal an existing host's name, but there's a related attack where you steal the name of a host that doesn't exist, but that clients look for as part of an autodiscovery protocol.

For example, when Internet Explorer starts up, it tries to discover if there is a proxy server it should be using. One of the ways it does this is to try to connect to a server called wpad and download a Web Proxy Automatic Discovery configuration file.

Similarly, if you have an IPv4 network, and a client application that wants to send IPv6 traffic to somewhere, the client needs to find an Intra-site Automatic Tunnel Addressing Protocol (ISATAP) router - the client then wraps the IPV6 traffic in an IPV4 packet and sends it to the ISATAP router, which unwraps the traffic and sends it on. You guessed it: one of the ways the client finds a suitable router is to try connecting to a server called isatap and downloading a list.

So if you don't have hosts called wpad and isatap, you need to make sure that a malicious client can't register these names, as otherwise they can deliver fake configuration files to clients and steal traffic.

You'd think you'd just tell the DNS server not to hand out those names, but that would be too easy. Instead, you use the global block list, which is a list of names that the DNS server will never resolve, whether it has records for them or not. By default this list has two entries, wpad and isatap.

This means, then, that if things change and you set up a real wpad/istap host, you need to remove their names from the block list before it will work.

In your specific situation, Direct Access is IPV6 based, and the hosts your clients connect to must all use IPV6. So, if they are on an IPV4-only network, you have to deploy ISATAP for it to work, and hence you have to remove ISATAP from the global blocked list.

Doing this shouldn't introduce a security problem, because once Direct Access is in place you'll have a real host called isatap and malicious clients will not be able to register that name.

One last note for those wondering why you say dnscmd /config /globalqueryblocklist wpad when it's isatap you're enabling, not wpad. This command sets the block list to the specified value.  i.e. by default the block list reads "wpad isatap" and the command changes it to just be "wpad".


one-time JWT token with JWT ID claim I'm trying to figure out how to issue a one-time use JWT token for password reset feature and still keeping it stateless. Came across Single-Use Tokens w/ JWT which basically suggests to include hash of current password which in turn gets invalidated once the password is changed successfully.

I don't feel comfortable including the password hash in JWT so I researched a bit and found JWT ID specification but that requires to store the ID somewhere so it can be checked on token validation.

So my question is, what are the security concerns if I include the current password hash in the password reset link token which is sent over email?

Is it better to use a JWT ID and add that as a column somewhere in the database instead of using the password?

I hesitate to roll my own security, but just for the fun of it here is an idea.

Instead of including the password hash, follow this process when generating the JWT:

Obtain the password hash
Obtain a server-side secret key (256 bits entropy should do it)
Compute an expiration timestamp, say an hour from the current time
Create a new hash over 1 + 2 + 3
Include the hash and the expiration timestamp in the JWT

To validate a password reset request:

Obtain the password hash
Obtain the server-side secret key
Read (and check) the expiration timestamp from the JWT
Compute a new hash over 1 + 2 +3
Compare to the hash in the JWT

This way you don't expose the password hash, and it cannot be brute-forced without also brute-forcing the secret key (which would take millions of years).  And you also preclude the hash from reuse by embedding the timestamp in it.


Storing private keys for updates to remote device I'm reading up on how to perform signed updates for remote hardware devices. I need to check if the new software has been generated by a "trusted" source, ie me.
Based on my understanding of asymmetric cryptography I understand that I can embed a public key on all my devices and then any new software that needs to be updated on the device, needs to have a signed hash in a header that I could check against. I'm all onboard until this part, and it sounds great for secure updates, but I'm wondering how one would securely store the private key. Say I built 1M units. All have the public key programmed on them. If my private key is lost for whatever reason, I lose the ability to update any of these devices. It sounds like the jugular vein. Should I accept storing private keys very safely as a cost of doing business, or is there a better way to handle this case?

I need to check if the new software has been generated by a "trusted"
source, ie me.

This means you need a single key - your key. You embed your public key into each device. When later on you upload an update to each device, you sign the upload package with your private key. Each device verifies your signature using your public key that you have embedded into the device.

If my private key is lost for whatever reason, I lose the ability to
update any of these devices.

Correct. I would suggest you to proceed like CAs do. Often the end-consumer certificates are issued not by the "top level" CA, but by some "intermediate" CA.
So you can create a "top level" key pair and corresponding certificate, and embed public key (or certificate) into each device. You should keep this private key in a very secure place.
Then let say every 3 months you do following: You generate a new intermediate key pair, create a certificate which expires in 3 months. You sign this certificate with the top level key. You use this intermediate private key to sign any updates in the next 3 months.
Since you want to sign 1M units, it may happen that you lose the private key. In such case you just generate a new intermediate key pair (without waiting 3 months), sign it with the top level key, and use this new intermediate key to sign updates from now on.
Each device should verify the packages as follows:

Check if signature matches the certificate attached to the update.

Check that certificate is issued by the top level key, which is embedded into device.

Check certificate expiration date.

Of course, if you lose the top level key, you will be blocked. But since the top level key will be used rarely and kept much more securely than a key used for 1M signatures, the chance to lose it essentially lower.
I'd suggest that you consider also revocation of the keys. It can be needed if a key used to sign updates is stolen, or if you just suppose it is stolen. You may want to prevent the attacker from uploading malicious updates signed with your stolen private key. In such case you can have a CRL (certificate revocation list) on each device. In case you want to declare some key as untrusted, you generate certificate revocation info for the compromised key and push to all devices. Then generate a new intermediate key pair. In case the device obtains a package signed by a stolen key and finds this key in its CRL list, it should not trust such signature and should reject such update package.


Strong password qualification I'm not sure where to ask this, but I feel this may be the correct place. I have an assignment where I need to construct a password policy and I've been looking online for certain password policies that big organizations have.

I have found a password policy that states "Strong passwords only: Cannot contain a dot character '.' immediately preceding the '@' symbol"

Why is this a password policy? Does it have something to do with how the password gets hashed?

Rather than answer a question about a specific policy that may be in place to prevent a very specific problem, I'd point you at http://passwordresearch.com/ as a good resource site for helping you get your task done.

When you come up with a solution, be prepared to justify each restriction you place on it. Think about why you might choose to set a minimum length, and what that minimum should be. Do you need a maximum length? Why would you limit it? Are you trying to prevent SQL injection attacks? What would be the purpose for requiring a digit? Every aspect of a policy should be grounded in logic.


MFA for multiple accounts? We are thinking about enabling 2FA with Google Authenficator for all our services.

But the only concern for me now is that users will have to have a dedicated Authenticator's account for every service, let's say:

Github
AWS
Gmail
Jenkins

Maybe there is a better approach?

Something like using a self-hosted TOTP service? Although this, I guess, will require SSO to be enabled between all accounts as well, but SSO is out of the scope of current tasks.

Although there are lots of open standards for authentication, and separating the authentication service from the application service, there are surprisingly few application providers willing to let you use your authentication service. i.e. its simply not possible to to impose your MFA solution on external providers.

That doesn't mean that you can't enforce MFA access on these services though. You just need to provide some proxy capability which can inject credentials into a session and put the MFA login on that proxy service; the users of the service never get to see the token (password, ssh key, certificate, passphrase...). This is catered for by most privileged access management solutions. I work with CyberArk which is very good at this - but also very expensive. There are other options available, but the cost of implementing any of them is likely to be orders of magnitude greater than rolling out your own google auth service.


What makes it difficult to have a hardware antivirus? Posting systems are vulnerable to virus and worms and having an antivirus is almost necessary. How is it possible that hardware antiviruses don't exist?

The idea sounds pretty good, if the antivirus resides on reprogrammable chips similar to the one that hosts the BIOS, then it would be immune to attacks yet still upgradeable. Also it would have higher privileges and that would solve the problem of being unable to repair in-use system files.

Is there something I am not thinking of that makes this impossible to implement?

If the chip is writable from within the OS, the malware can write to it too, so it wouldn't help there.

Also, anti-malware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the anti-malware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the OS. If we can write to the chip from the OS, so can the malware.

In order to make a secure hardware anti-malware you first have to change the main task of the program. Anti-malware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time.
If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of OK programs. You'd either have to have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you'd have to have an enormous list of any programs that anyone would ever want to run.

To generate that list, the easiest would be to add every possible program, and remove all the bad ones, which is equivalent to what anti-malware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for anti-malware companies trying to sell subscription services.

As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.


Is there any asymmetric scheme provides signature with length of 30 bytes? I want to send short messages to cell phones.Commonly a short message is no longer than 70 bytes. I need 20 bytes or more holding information and the rest bytes are for signature provided by asymmetric schemes from server. It is because short messages can be easily faked with faked radio towers.

My app will get public key through https channel from the server.After getting public key, the phone may always be offline.When the server wants to contact a phone, it sends a short message to it and sign by private key.So the phone can trust the message and do the orders on the message.The public key will be refreshed every month and has a expired time of several month.

I've read some papers introducing RSA,DSA and BLS.The shortest RSA has a 128 bytes sign, while a DSA sign with readable charset like BASE64 is 64 bytes.Is there any shorter signature scheme? I saw BLS but it's not a international standard now and no jvm implementation found.

We assume the raw text is visible since attackers can read client code and know what happens to it.So is it still secure using a short signature with 30 bytes(others being redundancy)?

sum

sign length is around 30 bytes
expired time is several months
asymmetric scheme so messages cannot be mock
raw text is some how visible

AFAIK you should check elliptic curves. Since BitCoin "account number" is a public key itself, I would suggest:

http://blog.ezyang.com/2011/06/the-cryptography-of-bitcoin/

You should be even able to find an implementation in a BitCoin client.

However, I don't see a reason to use asymmetric cryptography in your case. Your application can just obtain a shared secret from the server and then use just HMAC to authenticate. Why not?


Is it safe to use a SSH server keys for a SSH client? Let me explain my question. I am working on an Internet Appliance device (IOT). The device currently runs an SSH server rather nicely. You can SSH to it and configure it, look at stats, etc. I now need to add a feature in which the device periodically uploads its logs via SFTP to a server that does not allow password logins/authentication, just public key.

For reasons that I won't bore you with here, it would be much more convenient if I could use the same public/private key pair for the SFTP session. Generating and storing a new key safely on this device is rather complicated. It is not Linux based device but rather runs a proprietary RTOS.

I cannot think of any security risks, but I thought I would ask. Is there something that I have overlooked? Is there a reason not to do this?

Only the public key is disclosed in either case.

Using the same private key for more than one purpose is usually a bad idea, because of the risk that you might be tricked into signing something in the first capacity, that might be used to impersonate you in the second capacity.

More precisely, is there a risk that a client connecting to your server, might trick your server into generating a signature that could be used to authenticate you to the SFTP server?

The SSH Public Key Authentication protocol does however appear to be sufficiently inconsistent with the SSH Key Agreement protocol to rule out that attack vector.

The SSH Security Considerations do not explicitly cover this question.


Share or not share public key for servers? In order to encrypt communications from our (custom) client to our (custom) servers our current scheme is a bit like this:

Client uses the bundled public key A to encrypt some random key material.
Lobby server decrypts it with the private key, uses the encrypted key material to set up an encrypted channel with symmetric encryption.
Client gets another public key B1 from the lobby server for login to game server 1, over the encrypted channel. (Game Server 2 would have public key B2 etc, each of these are generated at server restart)
Client connects to game server and follows same scheme as 1-2 to secure communications.

Leaving aside how how the key material is generated and used, would there be any change in security we change it to:

Client uses bundled public key A to encrypt key material
Lobby server decrypts with private key, uses the encrypted key material to set up an encrypted channel with symmetric encryption.
Client connects to game server and follows same scheme as 1-2 to secure communications with THE SAME PUBLIC KEY "A" the lobby used (so both lobby and game servers use the same private key)

In other words, do we get any enhanced security from only using the bundled public key for the lobby login?

A final alternative would be with a separate login server:

We create a login server which the client connects to in the manner of 1-2
The client is then awarded a new symmetric key C and an identifying number D
The client connects to the lobby server, presents the number D in plain-text.
The lobby and client now continues communication using the key (assume C is in a shared db or similar) C
The client connects to the game server, again follows 3-4 to set up an encrypted channel.

Are any of these schemes significantly worse or better than the other? I can't see any huge difference.

One potentially significant advantage of not using the same private key for both the lobby and the game servers is that, even if one or more of the game server keys is compromised, the lobby server key (whose public half is bundled with the client, making it hard to change) is still safe.
Presumably, the game servers present a significantly larger (and more frequently changing) attack surface than a dedicated lobby server, so it makes sense to design your system to be able to recover from an attack on the game servers, while making the lobby server as hard to compromise as possible.
Your third alternative also shares this advantage, since only the login server needs to know the private half of the bundled key.  Indeed, depending what else besides authentication the "lobby" server is doing, separating the critical authentication functions onto a dedicated server may be a good idea.
Also, your third alternative guarantees that clients will not be able to bypass the lobby/login server even if they somehow manage to acquire a copy of the game server public keys (e.g. from another, compromised, client).  (The client could still bypass the login server if they somehow acquired another client's symmetric key, but since those keys are tied to client IDs, your servers should be able to detect it.)  Depending on your use case, this may or may not be an advantage, but at least it shouldn't hurt.

BTW, I feel like I really should amend this old answer to note that there's a more secure (and practical) option than any of those described above:

Don't bundle any of the game or lobby server public keys in the client.  Instead, bundle the public half of a "root" digital signature key, while keeping the private half somewhere safe (i.e. not on any publicly accessible servers).

Use the private root key to sign the public keys of your game and lobby servers.

When a client connects to a server, the server first presents (over an insecure channel) a "certificate" containing its signed public key.  The client first verifies the signature using its bundled public root key, and then establishes a secure channel to the server using the verified public key.

You will also need some mechanism of revoking compromised server keys.  The simplest way is to attach an expiration timestamp to the public server key before signing it, and have the client refuse to use an expired key.  Of course, this means that you'll have to change (or at least re-sign) the server keys at regular intervals before they expire, which is something you'll want to automate.
You can also include in your protocol an option for e.g. the auth/lobby server to send the client a list of revoked server keys that the client should not trust even if they otherwise look valid.  This will at least allow quick revocation of game server keys, without having to wait for them to expire.  This can be useful e.g. if some game servers are run by third parties who cannot easily receive automated key updates, making it inconvenient to use a very short expiration time for their keys.
Of course, another option could be to give such third-party game server operators their own "branch" signing key, itself signed by the root key, so that they can generate and sign their own server keys.  Of course, the client then needs to be able to follow such chains of signed keys all the way up to the bundled root key.  And the branch keys need to carry some (signed) metadata indicating which servers they're valid for, so that the third party can't e.g. just generate and sign their own lobby/auth server keys.
The nice thing, though, is that you don't really have to implement any of those features yourself, since they're all part of the public key infrastructure model used in TLS (and DTLS), which is the protocol that e.g. your web browser uses to connect securely to Stack Exchange (and to any other HTTPS website).  While TLS is a very complex protocol (party due to historical accumulation of features) that you really don't want to implement yourself, there are plenty of TLS libraries that you can use.  Nowadays, it's more than likely that your language runtime even has one bundled in.  (If it can fetch data from an https:// URL, it does, or uses one bundled with your OS.)
Of course, you'll still need to learn how to configure your TLS library to suit your needs (e.g. to only trust your own root certificate and to disable any legacy features you don't want) and how to generate and sign TLS keys, which can be a non-trivial task in itself.  But it's certainly a lot easier than implementing a secure communications protocol all by yourself from scratch.


Key Management: storing encrypted key in database and decrypted key in session variable Edit:
Rephrased title to hopefully get some interest on what I would have thought was a common issue ?

I am developing a website using php/mySQL to store non-commercial data and it will be clearly labelled as not for sensitive information. The site is to be hosted on a shared internet server.

As i am using a shared server I have already accepted that this website will be very limited in terms of absolute data security but I wish to at least offer the option of a credible solution to the risks of any server admin simply being able to read the plain text fields in the database directly or via a backup and similarly should the server be hacked and the database be accessed. There is no perceived threat from determined hackers as the data would have little value.

My concerns are mainly connected with key management: storing the encrypted secret key in the database and storing the decrypted secret key in a Session variable.
All comments would be welcome.

My proposal is as follows:

use symmetric encrypt/decrypt with php mcrypt_encrypt(MCRYPT_RIJNDAEL_256)
Store the symmetric secret key encrypted on the database using a hash of a secret phrase
the secret phrase would be given to the organsation where there might be upto 10 people who need to use it
After a user logs in with their unique username and password they are asked for the secret phrase : if it is entered correctly the text data is decrypted and displayed. If they do not enter the correct phrase it is not sent to the web browser.
the secret key is stored in a Session variable , which is destroyed when the user logs out or after a session timeout.
the site is also protected using apache htaccess as it is not for public use
the php is incorporating methods to defend against xss, injection etc

I was thinking about doing a similar thing.  I came across this answer while searching which seems to imply that this is an acceptable practice as long as you aren't using passwords or password hashes in the key.  https://security.stackexchange.com/a/18998/39545


Calculate time taken to break AES key A 256 bit AES key is required to be broken using the brute force method on a 2GHz computer.
How long would it take to break the key in the best case and in the worst case situations? Assume that 1000 clock cycles are required to check a single AES key.

One of my favourite gems on encryption is from Bruce Schneier in his book Applied Cryptography.

  One of the consequences of the second law of thermodynamics is that a
  certain amount of energy is necessary to represent information. To
  record a single bit by changing the state of a system requires an
  amount of energy no less than kT, where T is the absolute temperature
  of the system and k is the Boltzman constant. (Stick with me; the
  physics lesson is almost over.)

  Given that k = 1.38×10-16 erg/K, and that the ambient
  temperature of the universe is 3.2 K, an ideal computer running
  at 3.2 K would consume 4.4×10-16 ergs every time it set or cleared a
  bit. To run a computer any colder than the cosmic background radiation
  would require extra energy to run a heat pump.

  Now, the annual energy output of our Sun is about 1.21×1041 ergs. This
  is enough to power about 2.7×1056 single bit changes on our ideal
  computer; enough state changes to put a 187-bit counter through all
  its values. If we built a Dyson sphere around the sun and captured all
  its energy for 32 years, without any loss, we could power a computer
  to count up to 2192. Of course, it wouldn't have the energy left over
  to perform any useful calculations with this counter.

  But that's just one star, and a measly one at that. A typical
  supernova releases something like 1051 ergs. (About a hundred times as
  much energy would be released in the form of neutrinos, but let them
  go for now.) If all of this energy could be channeled into a single
  orgy of computation, a 219-bit counter could be cycled through all of
  its states.

  These numbers have nothing to do with the technology of the devices;
  they are the maximums that thermodynamics will allow. And they
  strongly imply that brute-force attacks against 256-bit keys will be
  infeasible until computers are built from something other than matter
  and occupy something other than space.

See also https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html


Best approach for restricting remote ssh session Using the following files, I have attempted to restrict the SSH remote login. Having lack of knowledge in linux environment, I don't know the drawbacks and vulnerabilities between the following ways. So I want to know the internal works between these files and process.

Experts please share your experience with me.

SSHD_CONFIG
   I found this file ssh_config in the /etc/ssh/ folder. If I have added the following line. I could restrict the root user remote access as well as I could allow the user I want to access with the max session I wanted.

vim /etc/ssh/ssh_config
PermitRootLogin no
AllowUsers jack joe
MaxSessions 5

HostDeny File

Just appended the user IP in the following file.

vim /etc/hosts.deny

192.168.5.*

PAM Folder :
In the PAM folder, I have added the user who are all not allowed to authenticate to access remote ssh.

vi /etc/pam.d/ssh

auth required pam_listfile.so item=user sense=deny file=/etc/sshd/sshd.deny onerr=succeed

vi /etc/sshd/sshd.deny

PermitRootLogin no
AllowUsers jack joe
MaxSessions 5

The first 2 lines of that configuration seem just fine to me. The third one is not such necessary as if someone breaks into your system, it's enough to have 1 shell to do all the evil.

In this context, you're allowing just two users to connect, that means that those users will have to use a secure enough password to not break in (at least not easily).

There are some more things you can do:

If you're using a restricted range of IPs from whom you connect to your machine, restrict port 22 just to these ranges. Drop/reject the rest.
If not, you might use GeoIP with iptables to reject all countries from whom you don't expect connections (or said differently, only allow the ones that you expect).
There are some other tools that might help you: Fail2Ban is one of them. This will make that upon X configurable attempts with bad password into your system, the IP will be banned by iptables for an amount of time (also configurable).
There are hundreds of similar tools but this would be a good enough approach to have a basically consistent configuration.


Is the OpenPGP implementation of the YubiKey 4 Open Source? Although previous versions of the YubiKey (eg Neo and Neo-N) used an Open Source Java applet to handle OpenPGP signing, encryption and authentication, it is unclear from the yubico website / documentation if this is also true for the newer YubiKey 4.

No, the Yubikey 4 is not Open Source:

The implementation is not open source, that is correct. We have both internal and external review of our code to ensure that it is secure. It's important to remember that open source code is no guarantee that bugs/vulnerabilities will be detected as the bug you've linked to demonstrates quite well. The bug was inherited from the upstream project which ykneo-openpgp is based on, and was NOT detected by any audit of the source code. It was interaction with the device itself which lead to it's discovery.
We're all for open source, and we try to open source as much of our code as possible when and where it makes sense, but in this case it was determined not to be so. One reason is that on the YubiKey NEO, each applet runs in its own sandbox, isolated from the rest of the system and can be audited/reasoned about on its own. This is not the case on the YubiKey 4, where each part of the system interacts with several others. Another reason that ykneo-openpgp was implemented as an open source project (aside from being able to leverage an existing project) was that it was useful for others, as it can run on a variety of devices. Again, this is not the case for the implementation running on the YubiKey 4.

Although older devices such as the Yubikey NEO used an Open Source applet, the newer Yubikey 4 devices quietly switched to a proprietary, closed-source implementation.


My S/MIME certificate (created with OpenSSL) does not match my email address I created a certificate with OpenSSL and following commands:

openssl req   -x509 -nodes -days 365   -subj '/C=DE/ST=state/L=city/CN=hostname'   -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

openssl pkcs12 -export   -out mycert.pfx -in mycert.pem   -name "My Certificate"

And installed it with my Windows 7 machine. Then I tried to send an encrypted email and I got a message that there is no certificate matching my email address

What am I missing?

Edit 1

Thank you for those insights, Thomas.  I added the email address but the message still pops up :-( I also read about a root certificate, do I need such thing?

A certificate binds a public key to an identity. The notion of identity that S/MIME uses is email addresses. Namely, for your certificate to be usable with S/MIME, it should contain your email address.

The email address can be added in the subject name (simple but officially deprecated), like this:

openssl req -x509 -nodes -days 365 -subj '/C=DE/ST=state/L=city/CN=Sven/emailAddress=sven@svenisgreat.com' -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

or (the "normal solution", but more complex) as part of a "Subject Alt Name" extension (with OpenSSL, this requires using the -extensions flag and a configuration file; see the documentation).


Precauations for web application security audit We have planned to give our web application to a third party vendor,what were the precautionary measures which we need to take care before giving our application to third party vendor?

As the vendor have source access of our web application in order to carry out penetration test there might be application level exploits which might be carried out later by the tested vendor,other than that what were the pre checks which we need to be carried out while handing our web application to security audit ?

If you're contracting with a company to pen test and audit your app, you will be wise to scope out exactly what is in the limits of said test, what will be tested and how (it appears you are giving them source to be able to white-box test as well). They will likely work with you to establish the legal agreements that indemnifies them. It should also spell out the expected outputs, the timeframes and methods they will communicate the results to you. All of these things are just ways to make sure you are getting exactly what you expect from them. This is in their best interest too; they want happy customers as well.

Aside from the legal/contractual matters you would be wise to give them an environment as close to or the same as your production one so that the findings are accurate and also if you can perform your own testing ahead of time to remove the "low hanging fruit"- that is, anything that is easy for them to find. Consider code reviews and system design reviews ahead of time to give them what you think is your best. That way you are getting your money's worth.


How can I implement a whitelist based on packet content? At the moment I am looking for some way on Linux to have packet filter whitelisting done but based on fine-grained parameters such as packet content rather than more general parameters such as protocol type or IP source.

A security critical application running on the firewalled host must not be able to see or parse the data sent until it passes a firewall filter that only allows packets with certain predefined data (hardcoded text string commands) through.

In essence its a "seccomp-like" mechanism I'm looking for except the data source is a potentially malicious/untrusted application running on another machine.

Things I've looked but failed to understand if applicable to my use case:

seccomp
libpcap
Linux Socket Filtering aka Berkeley Packet Filter (BPF)
Snort

http://www.lowth.com/howto/iptables-treasures.php

And what a treasure it is. IPTables itself has a string module that can do this by looking for strings defined in the ruleset and passing them on.

http://linux.blogs.com.np/2008/03/11/iptables-string-matching/

  Kernels from 2.6 include support for matching strings present in IP packets, inspecting the entire packet data. Earlier kernels supported matching at the IP header level only, which was a limitation as the rules can only be formed based on header values like IP addresses, ports, packet state etc. The netfilter iptables firewall system has undergone great advancements in the latest kernels, with the modified string matching option being more interesting among them for server administrators. The rules, based on string matching functions, are very easy to implement.