Theoretical - Password salting with concatenation vs. salting with HMAC

The four methods you listed are essentially equivalently secure for the purpose of hashing passwords.

The HMAC construction of H(k1 ++ H(k2 ++ m)) (where ++ is concatenation)  is designed specifically to prevent attacks against MACs being used to authenticate messages as being written by someone possessing the secret key (k1, k2; where k1 = K ⊕ opad, k2 = K ⊕ ipad, where opad=0x5c5c...5c and ipad=0x3636...36).  Due to common hash functions like md5, sha1, sha2 being vulnerable to length extension attacks, you can't use a construction like H(k ++ m) as a MAC, since an eavesdropper who observed a signed message m could use a length-extension attack to make a valid MAC for a message m' = m ++ tampered_msg.  Similarly, the construction H(m ++ k) is also insecure if an attacker could generate a collision (find two messages H(m1) = H(m2) where m1 and m2 lined up on a block) and then if he can trick someone into creating a MAC for m1, he can use that as a valid MAC for m2.

However, being susceptible to length-extension or pre-collision attacks is not relevant for the use of storing and validating user passwords.  All that is relevant is the length of the returned hash, the fact the salt is unique for every stored password in your system (so multiple passwords are not attacked in parallel, the time to calculate the hash (intrinsically slow hashes are more secure against brute force), and the strength of the password.

If I use H(random_salt ++ password) with a hash that's vulnerable to length-extension attacks, there's no equivalent vulnerability.  Who cares if someone who doesn't know my password but has seen the hash could potentially calculate H(random_salt ++ password ++ tampered_pw) for whatever tampered_pw they want to add onto my password without figuring out what the password is?

That said, the HMAC construction may be a tad safer in that it calls the hash function twice, so theoretically should take double the time to brute force; though typically when you perform multiple rounds of hashing you do many thousands of rounds of hashing (that makes brute forcing many thousands of times harder) instead of just 2 rounds of hashing.


Single-packet connect request at an extremely slow rate

It simply means to do something like try a single connection attempt to a single port with a lot of time between.

But what "slow" means and how much time is not defined. 1/hr? 1/day? It depends on how stealthy the person wants to be and what their goals are.

nmap has many config options to do this (read the manual: https://nmap.org/book/man-performance.html)

For instance: T0 sends a single connection attempt to one port at a time with 5 minutes in between. There are numerous finer config options where you can define exactly what you want to do.

I challenge the statement that noisy network scans are not performed by advanced hackers. It really depends on the situation. There is no reason to go slow on a public IP. Internal IPs, once you are inside and re-enumerating, would need this, but this is not something that only advanced attackers would do. It's just a response to the reality that noisy scans would be discovered and so would the attacker. Typically, the attacker would listen to traffic or do other enumerations to get a sense of what servers are available and what they serve.


How can I access a website without it being able to identify me as a previous visitor?

What you expect can be done, but will not be convenient.
It's not needed to create a new fingerprint for every connection, but have one fingerprint that are so generic it cannot be linked to you.
You can buy a popular phone - a cheap Samsung (for example) running the stock ROM (not rooted), and access the site using your provider. For the next access, factory reset, access the site using a WiFi connection. Even if the device is the same, the factory reset will delete every identifier linked to the device, and more than a dozen popular Android devices running the stock firmware will have accessed the site, so neither access can be linked to you.
That's why Tor browser recommends you to not change the browser resolution and not used it maximized, so every user will have the same settings and same resolution.


How to tell if encryption has been enabled for my gmail email account when connecting via mac Mail / iOS Mail /

For the connection: Check to see what ports you're connecting to the IMAP server on. Typically 993 is the encrypted inbound port (imap) and 465 is the encrypted outbound port (smtp).

Note: 143 (in) / 25 (out) would be the unencrypted counterparts.

P.S. For the truly paranoid: Run wireshark while fetching new mail.


What is the correct way to assess and compare Certicom's products to the alternatives?

Certicom holds patents on certain primitives/protocols related to elliptic curve cryptography (MQV for example), which you will not be able to use from a freely distributable library. I can't enumerate everything they hold or if they are significant (textbook MQV is generally no longer used).

I have also heard, somewhat ironically, that they have the fastest RSA implementation and some companies use their libraries just for it. That may be an urban legend though.

In general, if you are going to use elliptic curve cryptography (which I recommend as it is fast), the Certicom library will be excellent but not irreplaceable. And for specialized purposes, there are probably faster EC implementations: e.g., NIST P-224 in OpenSSL, RELIC, Curve25519, etc.

If your priority is unity across platforms and you aren't doing heavy crypto, then using a general library instead of the Certicom one should be fine.


PIV/CAC for FedRAMP Manatory requirements

"Can the system fully support user authentication via Agency Common
  Access Card (CAC) or Personal Identity Verification (PIV)
  credentials?"

  We make software, and specifically mobile applications. Our
  application would never need a CAC or PIV for end users. Further, we
  have two factor auth setup for our login to our cloud platform (AWS)
  but I can't see how/why we'd use PIV or CACs.

The answer to the "why" question is: You will do it because it is mandated. ;)

As for the "how" question: If your "system" already supports some forms of two-factor authentication, you probably don't have too far to go to support PIV/CAC, in principle. In fact, any old desktop computer can use a PIV/CAC card reader, right? If I remember correctly you can also fit a mobile phone with a CAC card readers as well...


Why is it not recommend to use permanent validity of certificate for public key

Just to be precise, an X.509 certificate has a non-optional end of validity date, so you cannot make a standard-compliant "permanent" certificate. However, that date can be encoded as a GeneralizedTime which can encode instants up to the end of year 9999, which is far enough in the future to be considered "forever".

Note that there is a binary equivalent to the Y2K problem, called the Year 2038 problem, so a certificate whose end-of-validity is beyond January 19th, 2038, may incur interoperability issues. Usually, Windows systems do not have any trouble with such dates (because they use 64-bit integers for their internal time representation), but application that use old libraries from the Unix world (in particular OpenSSL), and use them poorly, may have difficulty handling such a certificate. It is thus recommended, for now, to avoid setting the end-of-validity date beyond 2037.

Anyway, the official reason for having an end-of-validity date is to support revocation. When a certificate is revoked, its serial number is added to a list called the CRL, periodically published by the CA. The serial number will need to be kept as part of the CRL as long as the certificate is "valid" (with regards to its end-of-validity date). Thus, the end-of-validity is there to allow pruning old entries from CRL; if certificates were permanent, then CRL would grow indefinitely, which could be a problem since they are supposed to be generated and re-downloaded frequently.

In an ideal world, or at least a better world, we would not use CRL but OCSP. An OCSP response is like a CRL that talks about a unique certificate. In a pure-OCSP revocation system, permanent certificates would not be an issue at all.

The less-official reason of the end-of-validity date is that it works as renewal fee due date. When a commercial CA sells certificates, the CA really loves it when customers must come back buy a renewal every year.


Limiting redirect parameter to specific domain

Your example is trivially bypassable:

http://yoursite.com/page.php?redirect=/www.google.com

results in a redirect of:

//www.google.com

Which is a valid URL.

You should parse the URL using a function like parse_url then reconstruct a sanitized URL with the path components you want.  For example, you could use just the path and query fragments to build a URL that redirects only within the current protocol, port, and host.


Does an admin need legitimaly to access his own logs generated by auditd?

There is no reason not to allow Read access to his logs. He may be able to notice and handle breach of his own account or just chceck what he did if he forgets/mistypes.

They should NOT have write access to any logs. Especially if you want to be able to do forensics on the logs, the logs should not be tampered with.


Is there an actual use for OpenPGP authentication keys?

There is an informational RFC for use of OpenPGP keys in SSL/TLS; as the RFC says:

The term "OpenPGP key" is used in this document as in the OpenPGP
specification [RFC4880].  We use the term "OpenPGP certificate" to
refer to OpenPGP keys that are enabled for authentication.

That's what these keys are for: usages as part of authentication protocols which may technically look like signatures, but are not meant to fulfil "non repudiation" requirements.

I never saw a working implementation of RFC 6091, though. I don't think it gets much used anywhere.


How to know if somebody has logged in and when to my win 10?

Yes. If someone administers your computer (especially in a work environment and your question sounds like one) they:

know your user name
can learn your password by installing keylogger on your machine
can login to your machine with their credentials and access all data (with minor exceptions)
can change your password, access the data, restore the system to the previous state, so that the old password remains active
can delete the logs showing their access (although likely forensic analysis would prove the tampering)


What are the security implications of my credit card number being known by someone else?

An excerpt from another answer:

  You don't actually need the CVV to perform transactions, they're just required by most retailers as a means of verifying that you have the physical card in your possession.

  From Wikipedia (unsourced):

    It is not mandatory for a merchant to require the security code for
    making a transaction, hence the card is still prone to fraud even if
    only its number is known to phishers.

  On most EFTPOS systems, it's possible to manually enter the card details. When a field is not present, the operator simply presses enter to skip, which is common with cards that don't carry a start date. On these systems, it is trivial to charge a card without the CVV. When I worked in retail, we would frequently do this when the chip on a card wasn't working and the CVV had rubbed off. In such cases, all that was needed was the card number and expiry date, with a signature on the receipt for verification.

In other words:

You could use that number to make payments or purchases in some systems. But if they have also your CVV from the back of the card your card is fully compromised and can be used for all kind of payments.

Recommendation:

Contact your credit card bank or issuer. They can provide you a new credit card. Also CC are something pre-internet they don't have an amazing security and every bank in this world actually prefer to be like that because they can follow the money transaction and they can find who is the responsible for a CC fraud.


isn't it a security hole that locked tablet/PC lets you change WiFi settings without warning the user?

Yes, this is a valid security concern. There might be anything going on on the network while the device is locked, and an attacker could get access to all that traffic even if you get notified after login. This would definitely enable MITM attacks, but of course there's other layers of security that can tackle the most: this is not a critical security issue.

In order to keep the possibility to reset password but prevent unauthorized change of network settings, I would suggest a sort of safe mode network: if network was changed while locked, firewall would block all other connections but the one required for password reset synchronization. When unlocked, the OS would prompt for a permission to remove this firewall policy. This would work for both wireless and wired network changes.


How can I execute shell in this CTF exercise?

Make strcmp to be 0

Assuming a correct implementation of strcmp, this means argv[1] must match the contents of level08.pass exactly for 63 bytes or until the first newline/null byte.

Since we don't know the contents of the file, our only option would be to manipulate argv[1] to point to an address in memory containing the correct string (e.g. buf). The absence of any argc checks made me wonder about this, but it isn't possible the way argv is handled.

  Somehow suppress signals

Have a look at the process signal mask.

There are a couple of key points in this paragraph from the docs:

  The collection of signals that are currently blocked is called the
  signal mask. Each process has its own signal mask. When you create a
  new process (see Creating a Process), it inherits its parent’s mask.
  You can block or unblock signals with total flexibility by modifying
  the signal mask.


My machine is hacked by someone and used to attack others via ssh, how to stop it?

You can start by blocking all the outgoing ssh traffic form your server using iptables :

#iptables -A OUTPUT -p tcp –dport 22 -j DROP


how block all subdomains for a particular domain

There are a few options for a home office:

upgrade the router to one with the desired features (high monetary cost)
run your own DNS server internally (high labour cost)
upgrade your existing router to DD-WRT/OpenWRT or alternate firmware (moderate labour cost)
offload the issue to a 3rd party, like a DNS provider, such as OpenDNS (small labour cost to configure your router, free for home use)

Can you prevent direct IP connection? That's another problem entirely. Short answer is 'no'. Long answer is 'yes', but then you are looking at more equipment, technology, and configurations/costs. None of the options here are reasonable for home use.


How can Windows 10 not have the password in memory?

A quick search turned up the link below.  They created a new technology called CredentialGuard, which isolates secrets in virtualized secure environments rather than storing everything in LSA like they used to.  Mimikatz can no longer just dump lsass.exe process memory and parse the contents.  They're still in some memory, strictly speaking, but not memory that we can access easily.

More: https://technet.microsoft.com/itpro/windows/keep-secure/credential-guard


How does Linux know if a new password is a "wrapped" version of a old one?

The answer is cracklib.
CrackLib will take the new password and modify it in a lot of ways to see if the modification is the same as the current password, that you had to type before changing the password.
So if your old password is
acbEFGH123321 and the new is acbdEFGH123321, and Linux complains, it means cracklib took the new password, added/dropped chars on each position, and discovered that you added one single letter. And that's bad.
Performance penalty on this is negligible. Linux have both the old and the new passwords, and a simple compare between strings can detect differences.


Why do some companies ask last 4 digits of my SSN or a scan of my ID? What are my risks?

I live outside the US so I'm not sure exactly how SSNs are normally used, but it sounds like they're using these details as a key to look you up in an external identity verification service.

This isn't too uncommon in relation to property rentals seeing as most physical rental agencies want scans of your ID, etc. any way.

  1) Why do some companies want last 4 digits of my SSN?

  2) How do they supposedly use it? How do last 4 digits of SSN help
  check my identity? How does it work?

It's very unlikely that anyone else has the same first and last name, plus the same last 4 digits in their SSN.

Therefore I can imagine this combination being used as a key to look up your record in an external database. Once they have your record the are asking you questions against that information to prove you are indeed that person.

  3) What can a hacker do if they somehow steal this information (my
  name, date of birth, address, last 4 digits of SSN)? How can this
  information be used against me?

To some extent it's protecting you. It wouldn't be too difficult for an attacker to obtain the information you mention, however it would be much more difficult for them to answer questions like "Which state did you live in 2005?".

Therefore if they tried to use your details to rent a property under your name (eg. to run a meth lab) they'd hopefully be prevented by not being able to answer the additional questions.

Having said that, there is of course the threat that an attacker might be able to access your records via the identity authentication service. Hopefully the identity verification service would require sufficient controls to protect your data before providing access.

It's a trade-off between convenience, protecting you against the company as a threat to your privacy, and protecting you and the company against fraudulent renters.

  4) Do you think they could get those personal questions and answers
  just based on my name, address & date of birth, or they could get that
  information somehow only after I entered last 4 digits of my SSN?

Probably, I imagine credit providers (eg. your bank) would at least have a history of your postal address and they'd be able to uniquely identify your record from this information.

From a practical standpoint, I'm not sure the specifics of how they might provide that information to an identity verification service. It seems reasonably likely it could happen though.

  5) What can a hacker do if they somehow steal a photo of my ID?

  6) What do you think is safer: sending last 4 digits of SSN or a photo
  of ID card?

There's a lot of factors to consider, but I'd say sending SSN is safer assuming there's no additional verification (ie. no extra questions) when you upload your photo ID.

The reason being is that an attacker could just resubmit your photo ID every time and pass verification. However, if they only had your SSN they'd have to answer those questions too (which hopefully change every time).


Do I need to password protect [web] services that are only accessible internally?

By having mo auth you are opening up more attack vectors. Couple of examples I can thin of:

Network is compromised and the attacker manages to get one of the IPs from VPN range
VPN is compromised and attacker gets access to the network that way
Another service on the server is compromised and attacker makes the requests from server (127.0.0.1)

All these attack vectors would give the attacker full access to the service you have described. Having auth on the service would fix that.


A portable executable (PE) file can describe a number of different types of object, including EXE files, DLLs, screensavers, and drivers. All PE files have a set of headers, followed by a set of sections.

The headers and tables describe the type of executable, the functionality it supports, the APIs it calls, etc. The sections tell the PE loader how to map file data into memory.

There are three main headers and two main tables:

DOS Header - Contains the magic number (MZ), the DOS stub, and some very low-level information about the executable. This is largely legacy now, and is only included for historical purposes.
Common Object File Format (COFF) Header - Contains machine type (e.g. i386 or Intel64) and some basic flags about the type of executable that this file is.
Portable Executable (PE) Header - Contains information about the runtime of the process, e.g. entry point address, code and data sizes, base addresses, the Windows subsystem to run in (e.g. GUI, console, driver, EFI, etc.), the characteristics of the module (e.g. is it NX / ASLR compatible?), the initial stack and heap sizes, etc.
Data Directory Table - A set of pointers (RVAs) and sizes for sixteen "special" segments of the file data, e.g. the import / export directories, the debug directory, .NET metadata, security directory, relocation table, TLS directories, etc
Section Table - A table that represents various sections within the executable. Sections contain the data that constitutes the actual program, e.g. the instructions.

When the OS loads a PE file, it creates blocks of virtual memory for each section, with the addresses, sizes, and flags specified in the section table, and copies the data from the file into these memory sections. There are two special sections: code and data. The code and data sections are identified by the BaseOfCode and BaseOfData fields in the PE header, and are assigned to the CS and DS segment registers respectively. The eip register (or rip in 64-bit) is then set to the value as specified in the AddressOfEntryPoint field in the PE header, and the program begins.

The PE format was not designed to be resistant against modification. There are many vectors to code injection at the file level:

Add a new section to the section table, mark it as code, then change AddressOfEntryPoint to point to your new section. You can now execute code and return back to the original entry point (OEP). This is easy for AVs to detect because the EP points to outside the code section.
Inject code into the "slack" space at the end of the original code section, then modify the entry point and jump back to OEP at the end of your injected code. This slack space is usually limited in size, so it's not always this simple. It may also be possible to use dead code as slack space.
Expand the original code section, shift the data down, inject your code at OEP, re-map the entire section table, re-map any fixups, and rebuild the imports and exports directories. This is difficult, and essentially involved re-building the entire file, but is difficult for AVs to detect.
Add a new data directory that contains instructions (often encrypted), then inject a small stub into the program (through any of the above methods) that allocates a new executable memory block and copies the data into it. If encryption is used, the stub decrypts the instructions. This new code block can then be jumped to directly.
Add TLS callback entries that include an initialisation callback to some code you have injected into the file (e.g. via a new section).
Modify known functions to do something different entirely.
Modify call tables to point to alternative (patched) code.
Many more...

As you can see, if an adversary has write access to a PE file, they can inject their code pretty easily. The best protection against this is digital signatures, which are managed inside the security directory of the PE file. A digital signature is essentially a certificate that is signed by a trusted provider, or by a provider whose certificate authority you trust. This certificate is then embedded in the PE file, and matches the data exactly. If you modify the PE file, or modify the signature, the PE loader will reject the file. Of course, it is also possible to simply strip the signature from the file, so that it runs without any certificate. This can be prevented via local policy, in which you can set a flag that requires all executables to be signed.

Unfortunately, this isn't the only way to inject code. The alternative is to inject memory into a process at runtime, then start a remote thread inside that process. This is relatively trivial in Windows:

Call OpenProcess on the target process, with PROCESS_VM_WRITE, PROCESS_VM_OPERATION, and PROCESS_CREATE_THREAD privileges.
Call VirtualAllocEx to allocate a block of executable memory in the remote process.
Use WriteProcessMemory to write code into that memory.
Call CreateRemoteThread to start a new thread in the process, using the base of the allocated memory as the thread entry point.

This causes code to run in the context of the target process. However, this is only possible when step 1 succeeds, and this is reliant on the malicious process having access to the other process. A low-privilege user cannot open such a handle to a high-privilege (e.g. administrator) user's process. However, if the malicious process is running with high privileges, all bets are off.

There is very little that can be done to protect you from these attacks once a malicious application is running with write access to processes and executable files.


Using sqlmap --crawl without asking questions

Try this out:

 --answers="follow=Y" --batch

From SQLmap wiki:

  Act in non-interactive mode Switch: --batch

  If you want sqlmap to run as a batch tool, without any user's
  interaction when sqlmap requires it, you can force that by using
  switch --batch. This will leave sqlmap to go with a default behaviour
  whenever user's input would be required.

  Set answers for questions Option: --answers

  In case that user wants to automatically set up answers for questions,
  even if --batch is used, using this option he can do it by providing
  any part of question together with answer after an equal sign. Also,
  answers for different question can be split with delimiter character
  ,.

Everything is here


Is it possible to transfer one-time credit card info to a physical mag stripe card?

No, this is not possible.  Among other things, the value provided for CVV online (such as a one-time use credit card number) is a CVV2 value, similar to what's printed on the back of a Visa/Mastercard.  (And is generally used for any "Card not present" transactions.)

On the other hand "card present" transactions require the CVV1 value, which is encoded on magnetic track.  A one-time-use card on the site wouldn't provide that value, so it wouldn't be possible to build the whole magnetic stripe.


XTS vs AES-CBC with ESSIV for file-based filesystem encryption

The criticisms about XTS make sense in a context when attackers can observe successive versions of the encrypted disk (i.e. the attacker steals your laptop, makes an image of the whole disk, then puts the laptop back in your bag, and you did not notice anything; and he does it again tomorrow, and the day after tomorrow, and so on...). With XTS, every 16-byte block gets encrypted by itself, so the attacker may notice when two successive versions of the same encrypted block (the same 16-byte block within the same sector of the harddisk) contain the same data. This potentially allows for traffic analysis. If the attacker goes active, then he can put back an old version of any block, and can do so for all blocks independently.

With CBC+ESSIV, each sector has its own IV, so our recurring attacker can notice when a new version of a sector begins with the same sequence of blocks as a previous version. CBC is such that if two plaintext blocks differ at some point in a sector, the remaining blocks in that sector will diverge. In that sense, compared to XTS, the attacker's abilities for traffic analysis of CBC+ESSIV are reduced. For instance, if two versions of a given sector use the same plaintext value for the 13th block, this will be apparent with XTS, not so with CBC (unless the versions for the 12 previous sectors are also unchanged).

On the other hand, an active attacker is often happier with CBC, because he can alter bits at will within a block (provided that he does not mind replacing the previous block with uncontrollable random junk).

So no, dm-crypt does not have the exact same vulnerabilities as TrueCrypt. The envisioned scenarios (repeated eavesdropping of the same disk, hostile alterations...) are not the primary goal of full-disk encryption; really, FDE was meant for the "stolen laptop" situation, in which you don't get it back, ever. Neither solution behaves well against a more industrious attacker, but they don't fail in exactly the same ways.


Why is the SHA-1 hash of certificate sent in TLS "Client Certificate URL" extension?

From my understanding your problem is that an active man in the middle can make a server S access a URL at host U and this URL is specified by the attacker. And the problem with this is not that the attacker might get to the contents behind this URL (he can't) but that just accessing this URL might trigger a bug at the server U.

Thus to make this attack working the following conditions must apply:

There must be a bug in server U which can be triggered just by accessing the specific URL.
The attacker can do an active man in the middle attack.
The attacker is either not willing or not able to access server U directly so it needs to use server S to access this URL.
Server S does implement the feature to get the clients certificate from a URL.
Server S does no filtering which kind of URL's it can access or server U is allowed by this filter.

If all this applies it can be used to attack server U. But in most cases there are far easier ways to make somebody access URL, like accessing the URL directly, including it in some <img src... tag at some web site to be accessed by somebody else or similar.

  Then, why is 20-byte SHA1 hash of URL included with this message?

While I do not find any explicit explanation in the RFC my guess is that it is only to make sure that the server U actually provided the expected content and not something else which makes a bit sense in cases where the client itself has no real control over changes done at server U. This is not to prohibit attacks against server U.

Of course if the content served by U does not contain the expected client certificate it will be noticed during the handshake anyway because the private key used by the client does not match the client certificate. Thus it is questionable if this hash is really helpful or if it is just another useless feature which nevertheless made in in the standard: Remember the TLS heartbeat extension where the server for no real reason had to send the contents of the clients request payload back?


Public access to IIS Web server inside company network, for one specific service

I would personally use a VPN and make the service accessible from the local network (VPN connections would appear to be local).

When using a VPN connection everything is encrypted and you require credentials to use the VPN. These credentials could change on a weekly, monthly basis, etc, etc.

Very short answer but it is very black and white.


This is probably an issue with the co-existance' of multiple realtime AV software. One will suspect the other one's activities as malicious.

Avast is trying to scan your router/default gateway and Norton flags it as malicious here. You should uninstall any of the two as soon as possible.

Running multiple AV's on the machine can have effects like low performance, instead of increasing security, it decreases the security level, more false positives etc. Instead of running multiple AVs you can supplement your favorite ONE with Anti-Malware tools like Malwarebytes antimalware or Hitman Pro and observe safe internet usage practices.

Also, when uninstalling any, be sure to use the removal tool provided by vendor.
For Norton : Norton Removal Tool

  Using more than one anti-virus program is not advisable. Why? The
  primary concern with doing so is due to Windows resource management
  and significant conflicts that can arise especially when they are
  running in real-time protection mode simultaneously. Even if one of
  them is disabled for use as a stand-alone on demand scanner, it can
  affect the other and cause conflicts. Anti-virus software components
  insert themselves deep into the operating systems core where they
  install kernel mode drivers that load at boot-up regardless of whether
  real-time protection is enabled or not. Thus, using multiple
  anti-virus solutions can result in kernel mode conflicts causing
  system instability, catastrophic crashes, slow performance and waste
  vital system resources. When actively running in the background while
  connected to the Internet, each anti-virus may try to update their
  definition databases at the same time. As the programs compete for
  resources required to download the necessary files this often can
  result in sluggish system performance or unresponsive behavior.

  When scanning engines are initiated, each anti-virus may interpret the
  activity of the other as suspicious behavior and there is a greater
  chance of them alerting you to a "false positive". If one finds a
  virus or a suspicious file and then the other also finds the same,
  both programs will be competing over exclusive rights on dealing with
  that threat. Each anti-virus may attempt to remove the offending file
  and quarantine it at the same time resulting in a resource management
  issue as to which program gets permission to act first. If one
  anit-virus finds and quarantines the file before the other one does,
  then you may encounter the problem of both wanting to scan each
  other's zipped or archived and update files and each reporting the
  other's quarantined contents. This can lead to a repetitive cycle of
  endless alerts that continually warn you that a threat has been found
  after it has already been neutralized.

  Anti-virus scanners use virus definitions to check for malware and
  these can include a fragment of the virus code which may be recognized
  by other anti-virus programs as the virus itself. Because of this,
  many anti-virus vendors encrypt their definitions so that they do not
  trigger a false alarm when scanned by other security programs. Other
  vendors do not encrypt their definitions and they can trigger false
  alarms when detected by the resident anti-virus. Further, dual
  installation is not always possible because most of the newer
  anti-virus programs will detect the presence of another and may insist
  that it be removed prior to installation. If the installation does
  complete with another anti-virus already installed, you may encounter
  issues like system freezing, unresponsiveness or similar symptoms as
  described above while trying to use it. In some cases, one of the
  anti-virus programs may even get disabled by the other.

To avoid these problems, use only one anti-virus solution.


if Noscript is secure is that possible our system still compromise by crypto?

Cryptographic algorithms are not interpreters for a Turing-equivalent language. As such, they cannot be meaningfully compared with scripting support, which Noscript deactivates.

Implementations of cryptographic algorithms are rarely afflicted with buffer overflows, but may leak some highly sensitive data (such as cryptographic keys) if inexpertly implemented. A more usual source of vulnerabilities is the handling of X.509 certificates (e.g. see this for OpenSSL), because decoding of certificates can be a daunting task due to its (ab)use of all the intricacies of ASN.1.


Possible Vulnerability in the following Php/JS code

Both codes are vulnerable, but neither is exploitable with most modern browsers.

In the first example, could exploit the echoing of REQUEST_URI. Exploitability depends on the browser not automatically encoding values before sending the request (see XSS via REQUEST_URI). Host Header Injection may also be possible.

In the second example, the code is accepting input from the user via document.URL. This is called DOM based XSS (but modern browsers will most likely URL-encode the URL, so exploitation may not be possible).


If I am able to generate the same public key as someone else, do I also get the same private key?

Breaking any key from a set by random guessing is indeed 'easier' than breaking a specific key, but not enough to make a difference.

How many known keys there are depends on who does the knowing, but if consider available from public servers on the Internet, several projects have collected more or less all SSL/TLS and/or SSH keys on public Internet servers for various kinds of investigations; see https://www.factorable.net for one good example. This takes some work and a bit of time, but is quite possible. They reported 12 million in 2012; adding a generous allowance for growth and rounding up, call it about 32 million (2^25). This is not large at all for modern database systems and computers, although e.g. storing it on paper cards in an old-style library catalog would be costly.

As per the link in Crypt32's answer, the chance that a randomly generated RSA 4096 key matches a particular target is about 1 in 2^4070; with 2^25 targets, it improves to about 1 in 2^4045. Both of these are astronomically unlikely -- literally so; if you used all the energy in the universe the chance of hitting any target is still much less than the chance of your house being hit by dozens of independent asteroids within one second.

Even for RSA 2048, which is much more common today, you improve from 1/2^1005 to 1/2^980 -- still not enough to matter.

ECC, on the other hand, is much smaller because it isn't subject to math-structure attacks like RSA. For the commonly used ~256-bit curves (secp256r1, secp256k1, X25519/Ed25519) the universe does contain enough energy to break some reasonable number of keys, though the Earth doesn't. And for Bitcoin addresses, which run the secp256k1 key through a (net) 160-bit hash, it is quite possible someone will find a duplicate within not too many millenia, though probably not within your lifetime (or mine).


Clarification of relationship between CORS and CSRF

Bit of a rambling question, so bit of a rambling answer also.

CSRF can also be defended by including a custom header on XHR requests, and with same site cookies.

CORS is not variously defined; it is a W3C standard. What sometimes causes confusion is that CORS is not really a security mechanism.

Cross-origin data leaking is an area of active research and requires defences both built-in to the browser, and in both server-side and client-side application code.

Q1) The main other cross-origin attack is cross-site scripting. Defences needed in both server-side and client-side application code. Clickjacking is another one. There are probably some more although I can't think just now.

Q2) I've found most uses of CORS are for reads. Some REST APIs have permissive CORS settings but require a security token in requests. This lets third-party domains access the API, once the user has authorized them, e.g using OAuth.

Q3) That's right, CORS is not a security mechanism and doesn't in itself defend against anything. It does sometimes stop people using insecure alternatives like JSONP so it can help security.


Any reason why SHA-3 isn't yet present in GnuPG?

Are there any development plans for supporting SHA3 or BLAKE?

These algorithms are already included in the Libgcrypt library. It is only a matter of getting them incorporated into the OpenPGP standard for GnuPG to make use of them.
The GnuPG developers are working towards getting the OpenPGP Message Format updated from RFC 4880. The current work-in-progress for the new standard can be seen here. SHA3-256 and SHA3-512 are included in the draft, but not BLAKE.


Yes, you can use the Firefox Developer Edition as your main browser but it has slightly different privacy and security properties.

Most notably, Firefox Dev comes with additional development and debugging tools, some of them still experimental. That means more responsibility for the user and potentially a bigger attack surface since fresh features can be more likely to be vulnerable.

  We'll include experimental tools that aren't yet ready to ride the trains to release.

You are also using the new features of the Aurora build (pre-beta).

  By using the Developer Edition, you gain access to tools and platform features at least 12 weeks before they reach the main Firefox release channel.

Because of the developer-centric design, it's easier to make insecure settings. For example, in Firefox Dev you can disable signature enforcement which would result in the browser accepting unsigned extensions.

  What are my options if I want to install unsigned extensions in Firefox?
  The Developer Edition and Nightly versions of Firefox will have a setting to disable signature enforcement.

Firefox Dev collects usage statistics ("Telemetry") by default which impacts your privacy.

  Usage statistics or "Telemetry" is a feature in Firefox that sends
  Mozilla usage, performance, and responsiveness statistics about user
  interface features, memory, and hardware configuration.
  [...] This feature is turned on by default in Nightly, Developer Edition (Aurora), and Beta builds of Firefox to help those users provide feedback to Mozilla. In the general release version of Firefox, this feature is turned off by default.

If you're concerned about these points, you could also just use the default build and install additional developer extensions later when you need them.


two websites with same signing cert but google chrome says CA is invalid for one of them and not the other?

StartCom certificates are no longer trusted by Chrome, due to a number of irregularities found in WoSign (the parent company of StartCom) and StartCom's certificate issuance practices.   There is a blanket policy of distrusting all certificates issued by WoSign or StartCom after October 21st, 2016, but due to a requirement for certificate transparency and other unspecified technical reasons, certificates issues before this date may not be trusted either.   Since the certificates for both of the sites you referenced were issued before this date, it appears that one of them meets Google's criteria to remain trusted, while the other does not, for indeterminate reasons.

You can read more about Google's decision to stop trusting certs signed by these roots here.


While it is a bad idea to still keep the server running such old and unsupported systems are actually often found in industrial environments where they are used to run some software only supported on such older OS or which is tied to specific hardware.

The way to limit the risk in such cases is to minimize the attack surface as much as possible. This means removing or at least disabling any software and services which are not actually needed, harden any passwords in use on the system and put a firewall in front of it. The firewall should restrict access to only the applications which need to be actually accessible from outside and only for specific IP addresses. The firewall should also limit what traffic can leave the system so that a successful attacker will at least not be able to infect other systems from the compromised one. Of course you should not rely on the builtin-in firewall for this since the attacker might change this.

This way you at least reduced the risk of the system getting compromised and that it can be used to attack other systems after a successful compromise. Once this is done you should also look for a long term strategy to deal with the system, since what you did for now was only to limit the impact of the worst problems. Long term strategy might involve to declare the service you offer as officially obsolete so you can switch off the system after a while. Or you might rebuild everything in a more secure way on a supported platform and migrate customers to the new system.


Do javascript: URLs starting with // allow XSS?

Yes, it allows XSS.  You can inject a newline after the // if you use the right trick.  The // makes the line a comment, but the newline is (as whitespace) not allowed in a URL, htmlencoded or not. Simply urlencode it, like this:

XSS


Intel Management Engine vulnerabilities in CPUs without vPro

Intel vPro is not a single thing, but is actually a group of several Intel technologies working together to provide a certain set of services. The Intel vPro reference guide lists those technologies (emphasize is mine):

  Intel vPro technology is a collection of platform capabilities that
  support enhanced manageability, security, virtualization, and power
  efficiency.  The key platform capabilities include the following Intel
  technologies:

  Intel Turbo Boost Technology for increased performance and power efficiency
  Intel Virtualization Technology (Intel VT) for Dynamic Virtual Client support and other operating system or application streaming
  techniques using virtualization
  Intel Hyper-Threading Technology (Intel HT) for higher performance
  Intel Active Management Technology (Intel AMT) for greater manageability
  Intel Anti  -Theft Technology (Intel AT) for greater security
  Intel Trusted Execution Technology (Intel TXT) for greater security
  Intel Identity Protection Technology (Intel IPT) for enhanced web security

Among these various technologies is the Intel Active Management Technology, which allows system administrator to remotely manage companies computers independently of their location and their state: even computers turned off or computer where the operating system fails to boot can still be managed using this technology.

What happened is that a security researcher found an vulnerability allowing a remote, unprivileged user to take control of this management feature.

As stated in Intel's Security Advisory (emphasize is mine):

  There is an escalation of privilege vulnerability in Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology versions firmware versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 that can allow an unprivileged attacker to gain control of the manageability features provided by these products.  This vulnerability does not exist on Intel-based consumer PCs with consumer firmware, Intel servers utilizing Intel® Server Platform Services (Intel® SPS), or Intel® Xeon® Processor E3 and Intel® Xeon® Processor E5 workstations utilizing Intel® SPS firmware.

AMT is part of the Intel's vPro offering and is not available on non-vPro devices like "consumer PCs with consumer firmware" and "Intel servers utilizing Intel® Server Platform Services (Intel® SPS)".

Intel CPUs without vPro support therefore do not seem vulnerable to this attack as they lack the vulnerable firmware.


Domains getting mapped to localhost is common when you want to route traffic destined to an external domain to the local machine first for proxying/inspecting/modification.

There are valid reasons for doing so, but it is also a method used by malware for malicious purposes.


All subdomains blocked by Google SafeBrowsing

Solved. One of the subdomains had been hacked and contained several javascript injections.

Some interesting facts:

it's rather surprising that google blacklisted all the other subdomains, I wonder if it's a systematic behavior or not.
the example harmful URLs list given in the WebmasterTools is empty for the other subdomains, but when you ask for a review, which fails, the View Examples button in the mail does list some problematic URLs from the hacked site even if it is not the one you asked the review for.

As a conclusion, while I'm grateful to Google for having detected and filtered the injection, I regret a bit that the blacklisting algorithm exhibits a domain-wide behavior, and that the Webmaster Tools interface is unable to explain that a specific subdomain has been blacklisted because of a problem in another subdomain.


How do I switch appearances with Tor when onion routing is disabled?

If you do not use Tor with Tor Browser, then you will be one of the very few people who have the generally homogenous fingerprint of that browser, but without Tor. While simply restarting the browser is sufficient to destroy all traditional persistent fingerprinting vectors (cookies and "supercookies" and the like), the fact is that you will still likely be the only user a website ever sees which is using Tor Browser without Tor.

Tor Browser can only provide you with anonymity if you have a large anonymity set. That is, everything about your connection applies to millions of other people. Changing any one thing, whether it's the use of your friend's IP instead of Tor or the addition of new browser addons, will reduce the anonymity set considerably and will make you far easier to identify across different sessions. Do not disable Tor.

The New Identity button is functionally equivalent to closing and opening the browser.


User Key pairs and Man-in-the-middle issues

There is already an infrastructure to manage trust and it's called "Public Key Infrastructure". This is the basis of all the SSL/TLS protocols used over the internet and websites.

The main idea is to designate a Trusted Third Party (TTP) which is recognised by all the parties involved. These TTP issues their public key and they are shipped by default in all major browsers (we have to assume there is no tampering before this point, or the all thing fails). Once you have that public key that you trust with no doubt, any server can ask the TTP (which is called a Certificate Authority) to deliver them a certificate. The certificate includes a public key and the identity of the certificate requester and the certificate issuer. When the CA verified the identity of the requester, the certificate is signed by the private key of the CA.

Anyone who gets this signed certificate can verify the CA signature. If it's ok, you deduce that the certificate (therefore the public key) belongs to the entity mentioned in the certificate. You can then use it to encrypt message to this person without fear of it being intercepted by someone else.

If someone where to make a MitM attack on the system he would need to :

get a forged certificate for a domain name he does not own
get the victim to accept a new/fake CA certificate on which he has control (and then generate forged certificate)
break the public key (very unlikely)

Otherwise, the certificate signature would not be verified and therefore the authenticity of the public key would not be proven.


Let's Encrypt can only issue certificates for valid DNS names. So if your intranet uses a made-up domain name like intranet.mycompany.local then it won't work.

If you have a real DNS name like intranet.mycompany.com (even if it doesn't resolve externally to your intranet), then you can use Let's Encrypt to issue certificates for it. If the domain does resolve externally to a server that can respond on port 80 (which need not actually be part of your intranet, if you have split-horizon DNS), you can use the http-01 challenge.

Alternatively, you can use the dns-01 challenge (fully supported in Certbot 0.10.0 and later, as well as other clients such as dehydrated, getssl and acme.sh). Since this challenge works by provisioning DNS TXT records, you don't ever need to point an A record at a public IP address.

So your intranet does not need to be reachable from the Internet, but your domain name does need to exist in the public DNS under your control.

Let's Encrypt - and publicly trusted certificate authorities in general, due to Chrome's requirements - submit all issued certificates to public certificate transparency logs. As such, you should not expect your intranet (sub)domain name to remain secret if you obtain a certificate for it. Your intranet's security shouldn't be dependent on keeping its domain name secret anyway.


If the NSA forced every US Cert Authority to hand over their keys what would be the threat?

This is similar to what is going on in the UK right now with the Investigatory Powers Act, which gives the UK government the power to effectively perform man-in-the-middle attacks against every UK citizen. A Security Stack user @Matthew gives a great answer here explaining how something like this would occur. Although, in the UK it is more likely they would force citizens to install their certificate rather than force companies to hand over theirs.

That being said, it would be highly unlikely that the NSA could do this, CA's aren't all located under the jurisdiction of the US government.

If this ever happened they could essentially perform man-in-the-middle attacks/intercept and decrypt any HTTPS traffic of their choosing (if they got every CA to comply). They would be able to read all your HTTPS traffic. So your conversations, your banking information, anything and everything would be theirs as much as it is yours. As @John Deters mentioned in the comments, "All Bad Things could happen".

Unless it were mandated by law, there would be ways to ensure that your traffic isn't snooped on or modified, even though they hold all the keys. VPN's are one way, which could encrypt your traffic with a key they do not hold. But, this would not guarantee safety in a world where the NSA has this sort of power.


Is there value in slowing down retries on a fingerprint lock?

Any delay would be a security benefit. One way to look at it is that everything can be cracked, it is just a matter of time. By adding delays, one is increasing the amount of time it takes to break the security. You want the time it takes to crack to be longer than the time the item needs to be secure.

In the case of fingerprints, the fingerprint gets turned into a number. Numbers can be brute-forced.


What are the best practices for anti-virus / anti-malware when using containers?

The general insistence of some security standards on anti-malware software running on every host, without exception, is a bit... dubious in a lot of cases (IMO).

That said, if it's a standard you need to comply with you need to either have a control or a well thought through mitigating control if you can't comply fully.

Here there's two aspects to the issue.  First is scanning the images themselves, second is scanning data placed into the images (for example user uploads).

The second case is actually easier to handle.  as containers are ephemeral you'll be mounting volumes from outside the container for any data you need to be persistent.  So you can just enable anti-malware on your external data stores (if you have any) and that addresses the issue here.

For the files from the container images themselves, I'd say that scanning running images (which would have a performance hit) can be avoided reasonably with some mitigating controls :-

Images should be scanned in the registry on build and periodically after that to ensure that they're not running outdated, vulnerable packages
As images are meant to be ephemeral, they should be able to be mounted with a read only root file system (via readOnlyRootFilesystem: true in the security context for the containers).  With this configuration the attacker can't write files inside the running container, so there's no real need for A-V scanning.


Using ex.: Ubuntu or Windows: Can I see the memory of a process that I am running?

Yes, you can read the memory of processes you own.

On Windows you need to open a handle to the process with PROCESS_VM_READ rights, and you can use ReadProcessMemory to read that process's memory (unsurprisingly). You must be running under a context with the appropriate security token to match a rule in the DACL (access control list) of the process, or be granted a privilege which allows global process access (e.g. SeDebugPrivilege).

On Linux you can read /proc/$pid/mem if you are the owner of that process or root.

This is entirely by design. The processes exist under your security context, so therefore you have access to them. If you run malicious code under that same security context, it has access to everything you do.

There is, however, a saving grace from such a scenario under a modern Windows system - integrity levels. Processes can be split into different integrity levels describing their trustworthiness. A low integrity process is restricted from a lot of operations, including interprocess access to high integrity processes. The boundary between low integrity and high integrity is often managed via User Access Control (UAC) elevation prompts and the secure desktop. KeePass, for example, utilises this so that a browser exploit gaining code execution in a low integrity process cannot gain direct access to the KeePass process. While UAC itself is not considered a security boundary, integrity levels are.

Many password managers also attempt to make master key and password decryption from memory dumps difficult. On Windows the CryptProtectMemory API can be used to encrypt data in memory using a key stored in the Local Security Authority subsystem (LSASS) which is protected by the operating system, thus requiring administrative privileges (SYSTEM, in fact) to discover the key.

Linux with the grsecurity patches has some restrictions on access to /proc which may also provide some security benefits in these types of scenarios, although I am not well versed enough in the grsec options or Linux internals to know exactly how these work and what exactly they prevent.


Browser password manager vs third party password manager

There are three main areas of difference.

First, password management is a feature for browser developers, while it is the entire product for the third parties. So typically, the browser managers only offer basic core features. The 3rd parties add lots of useful stuff on top to differentiate their product. For example:

Storing other information apart from web page logins.
More sophisticated password generation features.
Checking sites against lists of breaches and warning you to change your password

Second, because 3rd party managers are not tied to the browser, there are some situations in which they are more flexible. for example:

You can have one password store that works with multiple browsers on your machine
The browser managers typically only use the browser's services for backup and sync. For example, Chrome only uses Google Sync Services, Safari only uses iCloud. If you want to use Dropbox, you have to go third party.
The portable/mobile versions of 3rd party managers will show you the password if required, so you can type it in on a temporary machine without having to configure the browser to sync all your passwords over and then remove them later.

Lastly, third party managers are usually targeted at the security-conscious and so usually better document their security practices and have security as higher on their list of priorities.


Isn't RBAC just an implementation of MAC?

Think of the two models as accomplishing similar objectives, but through a different perspective. What's even more confusing is that in practice they may be combined.

Think of MAC like a simplified version of the US Government classification system -- you have Confidential, Secret, Top Secret for example.  If one only has a Confidential clearance, they may not access secret or top secret, but when one has a Top Secret clearance they may receive access to documents on all levels.  One key element of MAC though is that it's handled centrally and enforced by the computer system -- so users, sysadmins etc cannot escalate privileges on their own without approval by the central authority of the organization.

In contrast, a role-based access control would be more granular.  For example, if using role-based access control, someone working for the US Government in Human Relations would have access to memos, dossiers and other information on employees as their position requires.  However, they wouldn't have access to other information at the same classification level that is outside of their scope of work -- like, financials for equipment purchases.  So, role-based access control limits the scope of information.

The systems can be combined in practice, and many systems may have a combination of role-based and mandatory-access controls.  However, RBAC is seen as usually more suited for commercial environments while MAC is more associated with sensitive environments such as defense.

That said, in terms of the video you identify, the question is tricky.  However, the fact it contains both sensitivity level and department means it's RBAC -- as department is involved (that's a role).  Because sensitivity level is involved, then it's not DAC (discretionary access control) but rather MAC being implemented in an RBAC fashion.


XSS is the ability to execute javascript code (i.e. alert(1)). HTML injection is the ability to execute HTML (such as <p>, like you said).
Often they go hand in hand.

When <script> tags are deleted by a filter of the web app, attackers can often still achieve to execute javascript (XSS) by leveraging HTML injection through:

<img src='x' onerror=alert(1);>


A filesystem with chunks hidden all over the internet?

The need for such a distributed file store is largely filled by Freenet.   Freenet is a distributed hash table where by various chunks of a file is obtained anonymously from various nodes in the network.

The addition of stenography upon Freenet would add a level of secrecy in that only people who know where to look can find the information.


Is the standard scheme of RSA CCA and CPA secure?

Your "basic RSA" is probably not standard RSA as specified in PKCS#1, but the so-called "textbook RSA", which is insecure because it is reduced to the core modular exponentiation and does not include the padding, which is essential.

In "textbook RSA", public key consists in n (modulus) and e (public exponent). Private key is d (private exponent). Plaintexts are integers modulo n. The encryption of m is me mod n; decryption is obtained by raising to the power d because (me)d = m mod n for all integers m in the 0 to n-1 range.

Indeed, textbook RSA is not secure against Chosen Ciphertext Attacks because of the following: for the modulus n and all messages m and m', you have:

(mm')e = (me)(m'e) mod n

In other words, the encryption of a product is the product of the encryptions. In the CCA setup:

There is a message m and its ciphertext c = me mod n. Attacker knows c and wants to find m.
Attacker is allowed to obtain the decryption of ciphertexts that he chooses, as long as none of them is equal to c.
Attacker generates a random m' (modulo n) and computes c' = m'e mod n.
Attacker asks for the decryption of cc' mod n: this is an integer modulo n, distinct from c, so the attacker gets a response.
The response is necessarily equals to mm' mod n. Attacker knows m' (he chose it himself) so he computed m easily.

As for Chosen Plaintext Attacks: asymmetric encryption is necessarily secure against CPA, if it is to offer any security at all. Indeed, encryption uses the public key, which is public, thus known to everybody, including the attacker. If the attacker wants to encrypt some messages of his choosing, then he... just does it. He does not need any help from the private key owner, since encryption uses only public elements.

If textbook RSA was not secure against CPA, then standard RSA, with the padding, would be weak too: using his breaking method, the attacker would recover the padded message, from which he would obtain the non-padded message.

Now this does not mean that textbook RSA is secure against attackers who cannot obtain the decryption of custom ciphertexts. Textbook RSA has (at least) the following very serious issues:

As noted above, it is insecure against CCA.
If the message is a small integer, then the RSA problem may become very easy. For instance, if m is a 200-bit integer and the public exponent is e = 3, then me is a 600-bit integer, while the modulus is normally larger (at least 1024 bits). This implies that m can be recovered with a simple, non-modular cube root (which is easy).
Textbook RSA is deterministic; thus, if the message itself is amenable to brute force (e.g. it is a password), then it can be recovered by trying potential message values until a match is found.

Standard padding, as specified in PKCS#1, solves these issues: the padding ensures that the padded integer is large enough; padding includes random bytes. The old-style PKCS#1 padding (dubbed "v1.5") is actually not very strong against CCA, although it still is tolerably good when employed properly, as in SSL (it requires that the SSL server does not complain when the decryption of what the client sends does not have a syntactically valid padding). The new-style PKCS#1 padding (dubbed "OAEP") is strong (and even "proven strong" for an appropriate meaning of "proven").


Is snail mail or HTTPS webmail safer for sensitive information?

In terms of how likely it is that your message will be intercepted, webmail is definitely more vulnerable. Not for any special reason necessarily, just that the number of potential adversaries is higher. It's difficult for a malicious person on the opposite side of the world to reach into your local post office and pluck your correspondence out, but it's not hard to spy on e-mail traffic if you know where it's originating.

In absolute terms, however, the chance of any single message being intercepted is low. I can't speak for the rest of the world, but the United States mail processes ~554 million mail pieces per day. It is unlikely that a random malicious person will randomly latch onto your message.

E-mail is rather more prolific. A 2010 estimate had world e-mail production at ~90 trillion per year. Cutting out 90 percent of that as spam still leaves ~9 trillion a year. Even allowing for a large percentage of that to be internal communication that never sees the Internet, that is a large number of messages to sift through.

In the end, you really can't be sure, however. Security is HARD, and once something is out of your physical control, it's gone.


Is FAR (False Accept Rate) a property of algorithm or a property of the system?

First you should define whether your system uses identification or authentication. Identification finds a biometric scan in a database (e.g. to find a criminal in a crowd), while authentication compares a biometric scan with a single database entry (e.g. to grant access after a user scanned his RFID card).

According to my CISSP guide, FAR is a property of the system and it is calculated on a single comparison.

Assuming that each impostor is only allowed one scan, if your biometric system is used for authorization then the average probability that one impostor enters is

100 impostors x 0.001% FAR x 1 database entry = 0.1% = 1 impostor every 1000 days

If your biometric system is used for identification as the sole access control system, then the average probability that an impostor enters is

100 impostors x 0.001% FAR x 1000 database entries = 100% = 1 impostor every day

Unless there are specific business needs, biometrics is better suited for authentication.


Is there any way to block LD_PRELOAD and LD_LIBRARY_PATH on Linux?

Essentially, you need to control the execution environment of the apps. There's no magic about it. A couple of solutions that come to mind:

You could somehow set all the binaries that worry you as setuid/setgid (that does not mean they must be owned by root, as far as I know). Linux normally prevents attaching to a setuid/setgid process. Please do verify if it does so for non-root-owned setuid though!
You could use a secure loader to run your apps instead of ld, which refuses to acknowledge LD_PRELOADs. This may break some existing apps. See Mathias Payer's work for more, though I doubt there is any off-the-shelf tool you can just apply.
You could rebuild your binaries with a libc that disables LD_PRELOAD and dlsym. I've heard musl can do that if passing the right options, but can't refind information on how right now.
And finally, you could sandbox your apps and prevent apps from directly launching other processes with a custom environment or from modifying the user's home directory. There is no ready-made tool for this either (it's very much work in progress and nothing is yet deployable).

There probably are limits to the above solutions and other candidate solutions depending on what apps you need to run, who the users are and what the threat model is. If you can make your question more accurate I'll try and improve that answer accordingly.

Edit: keep in mind that a malicious user can only modify their own execution environment (unless they can escalate privileges to root with some exploit but then you have other issues to handle). So, a user would usually not use LD_PRELOAD injections because they can already run code with the same privileges. Attacks make sense for a few scenarios:

breaking security-related checks on the client side of client-server software (typically cheats in video games, or making a client app bypass some validation step with its distributor's server)
installing permanent malware when you take over a user's session or process (either because they forgot to log out and you have physical access to the device or because you exploited one of their apps with crafted content)


What does "in-house hash function" mean?

From the explanation of in-house in the Cambridge Directory: "Something that is done in-house is done within an organization or business by its employees rather than by other people".

Here it means developing your own hash algorithm  instead of using a public one.  Usually that means that it is developed by only a few people with only limited expertise in the problem area and without any public input. Thus it is very likely that the self-developed one gets eventually broken once more experts in cryptography take a look at it.

See also Why shouldn't we roll our own? and How valuable is secrecy of an algorithm?.


Short Version

The number of iterations that gives at least 250 ms to compute

Long Version

When BCrypt was first published, in 1999, they listed their implementation's default cost factors:

normal user: 6
super user: 8

A bcrypt cost of 6 means 64 rounds (26 = 64).

They also note:

  Of course, whatever cost people choose should be reevaluated
  from time to time

At the time of deployment in 1976, crypt could hash fewer than 4 passwords per second. (250 ms per password)
In 1977, on a VAX-11/780, crypt (MD5) could be evaluated about 3.6 times per second.   (277 ms per password)

That gives you a flavor of the kind of delays that the original implementers were considering when they wrote it:

~250 ms for normal users
~1 second for super users.

But, of course, the longer you can stand, the better. Every BCrypt implementation I've seen used 10 as the default cost. And my implementation used that. I believe it is time for me to to increase the default cost to 12.

We've decided we want to target no less than 250ms per hash.

My desktop PC is an Intel Core i7-2700K CPU @ 3.50 GHz. I originally benchmarked a BCrypt implementation on 1/23/2014:

1/23/2014  Intel Core i7-2700K CPU @ 3.50 GHz

| Cost | Iterations        |    Duration |
|------|-------------------|-------------|
|  8   |    256 iterations |     38.2 ms | <-- minimum allowed by BCrypt
|  9   |    512 iterations |     74.8 ms |
| 10   |  1,024 iterations |    152.4 ms | <-- current default (BCRYPT_COST=10)
| 11   |  2,048 iterations |    296.6 ms |
| 12   |  4,096 iterations |    594.3 ms |
| 13   |  8,192 iterations |  1,169.5 ms |
| 14   | 16,384 iterations |  2,338.8 ms |
| 15   | 32,768 iterations |  4,656.0 ms |
| 16   | 65,536 iterations |  9,302.2 ms |

Future Proofing

Rather than having a fixed constant, it should be a fixed minimum.

Rather than having your password hash function be:

String HashPassword(String password)
{
   return BCrypt.HashPassword(password, BCRYPT_DEFAULT_COST);
}

it should be something like:

String HashPassword(String password)
{
   /*
     Rather than using a fixed default cost, run a micro-benchmark
     to figure out how fast the CPU is.
     Use that to make sure that it takes **at least** 250ms to calculate
     the hash
   */
   Int32 costFactor = this.CalculateIdealCost();
   //Never use a cost lower than the default hard-coded cost
   if (costFactor < BCRYPT_DEFAULT_COST)
      costFactor = BCRYPT_DEFAULT_COST;

   return BCrypt.HashPassword(password, costFactor);
}

Int32 CalculateIdealCost()
{
    //Benchmark using a cost of 5 (the second-lowest allowed)
    Int32 cost = 5;

    var sw = new Stopwatch();
    sw.Start();
    this.HashPassword("microbenchmark", cost);
    sw.Stop();

    Double durationMS = sw.Elapsed.TotalMilliseconds;

    //Increasing cost by 1 would double the run time.
    //Keep increasing cost until the estimated duration is over 250 ms
    while (durationMS < 250)
    {
       cost += 1;
       durationMS *= 2;
    }

    return cost;
}

And ideally this would be part of everyone's BCrypt library, so rather than relying on users of the library to periodically increase the cost, the cost periodically increases itself.


OCSP invalidation of intermediate CA using OCSP_SIGNING

I happened to have some experience in implementing an OCSP responder.
You might see "signer certificate not found" error if you didn't add the OCSP signing certificate, X, into the BasicOCSPResponse.
BasicOCSPResponse ::= SEQUENCE {
  tbsResponseData          ResponseData,
  signatureAlgorithm       AlgorithmIdentifier,
  signature                BIT STRING,
  certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }


Securing a secondary login page for inputting a multi-factor auth token

Use a Session Cookie to track users throughout the authentication process, just as you would after authentication.

Make sure that your cookie's length and complexity are sufficient to withstand brute-force and spoofing attacks.  Use the secure and httponly attributes to prevent the bad guys from capturing and using it.

Use one cookie for first-auth-through-verification, and then renew the session id after the second step, which is a Privilege Change.

This is one of those things where the problems have been plumbed and the best practices exist to prescribe what you should do - just read, understand, and follow the OWASP Session Management Cheat Sheet.


Public Key Transfer between two Applications

For #1 the usual answer would be to the store the key in an HSM (hardware security module). This is the only truly secure way to store a private key, as any keys simply stored on the hard drive will be compromised if your machine is compromised.

Question #2 is what is usually solved by a PKI (public key infrastructure). Others have said that there is no need to securely transfer a public key, but this is not entirely true; if someone were to perform a man-in-the-middle attack and insert their public key instead, then they would be able to decrypt all future communication. The key itself is not sensitive, and doesn't need to be secured, but you do need some way of ensuring that it is authentic. Confidentiality is not required but authenticity is.

When you use a PKI, the public key is signed by another key higher up the hierarchy to produce a certificate, and this signature verifies that the key is authentic. Of course, then you have the issue of distributing the public key of the next key up the hierarchy and so on. Generally this is solved by distributing the root public key along with your application, as a trusted root CA (certificate authority), then this can be used to verify the authenticity of any certificate chains with this CA at their root.

Question #3 is again something that can be achieved if you are using an HSM to secure your keys.


Got requests to unpublished services. Am I being spied on?

There is are multiple reasons why this can happen. As some poeple stated in the comment, its possible that a misconfiguration in the nginx lead a request to end up in your virtual hosts, simply, because of how the requests are processed. It's hard to tell without the config and detailed logs.

An other thing might be that you are leaking information, somehow. For example, error message of if your defualt_server coudl leak a hostname or a redirect (to a canonical site or the standard http to https redirect) can also be a s possible leak of your actual site name.


What countries are at highest risk of espionage on personal devices?

Assuming you have a basic level of Cyber Security measures e.g. ecrypted hard drives, decent user name and password rules, encrypted VPN tunnels etc. I would say there are a number of issues to consider.

Content on the laptops - is this commercially sensitive,
nationally sensitive, any export controls applicable. Effectively who would be interested in the data and what skills / resources do they have at their disposal?
Your business - what it is you do and how that can be seen in
different cultures - are you at risk of industrial, national espionage or from hacktivism.
The legality of your "standard" IT Security Solution in the country of destination - I believe some countries (especially middle east) have a big problem with encryption and prohibit any encrypted communications.
Your level of risk acceptance based on the country of destination. E.g. do you mind if the US authorities exercise their right of search of your device and would you be happy to provide any decryption codes to the border staff before the laptop is taken away for investigation?

A multinational company I work closely with all laptops have HDDs which are high level encrypted and where remote access is authorized it is via VPN but only with RSA tokens has a list of "home" countries where standard laptops  can be taken, this is essentially all the countries the company has a major presence (except USA). Outside of that the user "should" contact IT and obtain a loan laptop there are 2 levels "amber" and "red" based on Security advice on the country of destination.

"Amber" is for relatively friendly countries where for business purposes a clean laptop is taken (so a fresh internal build) with only files needed for the business trip are taken, these can connect via vpn back home and essentially work similar to the traveler's normal laptop. The issue here is to minimize risks from data loss, export offenses etc, whilst maintaining a good level of access

"Red" is for particularly risky countries where data intercept is to be expected these include China, Russia or where encrypted VPNs are banned in law. These laptops are very basic with fresh installs of base windows with basic office software, public email, internet access and only approved files may be loaded on to them (e.g. pre-cleared presentations), these "red" devices have no way of 'phoning home' and will be wiped on return and once being marked as a "red" laptop they will remain "red" until they are finally shredded (literally).

I have heard some organizations which have a process in place to counter the risk of border security searches e.g. in the US by having a process where the device is encrypted before travel and critically the user does not know the decryption code so is unable to login. That is only disclosed once the traveler gets through immigration the process is printed and the traveler can show that to immigration staff and apparently that gets round the right to search non US citizens, but not being a lawyer I'm not sure how true this is.


ensuring that compiled (and signed) packages don't contain malicious code

If you compile the package yourself - and use the same compiler and settings - then you will get identical binaries to the distribution binaries. The theory is that in a large community like Debian, some people will periodically do this, and would detect any changes introduced by the package maintainer. The maintainer is in a highly trusted position, and we can't really avoid that, but at least there is some oversight by the wider community.

The source code is open for public inspection, so the theory is that some people in the community will review this. Anyone with write access to the source code is again in a highly trusted position, but again, there is some community oversight.

Compare this to closed source software where there is very little oversight at all. When you pick up a Windows DVD, what confidence do you have that there is not an NSA backdoor on the disc?


Bypass NTFS Encryption via Password Change (Encrypting File System)

Under normal circumstances, changing the user password from an administrator account will result in the user's EFS encrypted files being lost. If the original password can be set back and the user's key is not changed, then the files can be decrypted again. This is true whether the user is an AD user or a local user, and the password is changed by using an AD/local administrator account.
For domains, it is possible to set up a Data Recovery Agent (DRA). This allows for the recovery of the decryption key if the original key becomes unusable. The DRA can be used to decrypt the files, so it's not necessary for an admin to change passwords to get to the data; they can just use the DRA's certificate to decrypt them.
The DRA could potentially be used to attack systems with automated password reset features. In the linked DRA page, there's a section on automated recovery of the encryption keys (for Azure Active Directory accounts). If an attacker can force a password reset to a known or chosen password, then they may be able to login with the new password and automatically recover the decryption key from Active Directory.


The general advice (to inject an event handler in the image tag) from @MarkBuffalo in the comment is correct, but onload isn't a great choice of event handler for images. The better option is usually onerror, which is very easy to reliably trigger; just set the source to be something you know won't exist (or at least won't be an image), like src="qq" onerror="alert('XSS!')".

The specific exception I like is SVG tags, where <svg onload="…" /> is a nice short string (as short as <script>…</script>, and usable in places that try stupid tricks like filtering <script>).


HMACs that have the same key and message

I know that people often suggest slow functions like - PBKDF2, Scrypt etc..

Listen to them. Use scrypt, bcrypt or PBKDF2. These functions are designed for hashing password. See How to securely hash passwords? for details. This is the recommended approach to hashing passwords.

but is using HMACSHA256 safe too?

It's fast => brute-force is cheaper => it's weaker than a slow hash.
A fast hash is only acceptable if you know that only strong passwords (say 80+ bits of entropy) will be used. In practice this means that you don't allow user chosen passwords and generate them using a computer. At this point they're closer to keys than to typical passwords.

do keys have to be unique in HMACSHA256?

When used as a MAC, keys don't need to be unique. You're using it as a password hash, so there is no secret key. Salts should be unique to prevent multi target attacks, but occasional collisions don't hurt much.

// salt is a guid we store separately, it's the id of the user

This means that the salt will be reused when the user changes their password. Not ideal, but not a big deal either.

HMAC(password, salt + password)

This is silly but harmless. 1) It uses a variable length value as key. HMAC has some weird properties when doing that. 2) Why input the password twice?
If you use HMAC(salt, password) for hashing passwords, I'd use the password as message and the salt as key. This matches HKDF-Extract.

Hmm, should we do something about it?, to make it a constant length value(any recommendations)?

If you use the salt as key and the password as message, the key has fixed length. But since these properties don't have much practical impact, don't worry too much if it's variable length either.

I thought the hash(salt+password) is always better than hash(password) // the sole purpose of salting?
but from what I see from your answer, HMACSHA256 does similar thing using the key supplied?

Since HMAC already combines key and message, you don't need to include the password in both.

but, in our case salt is the userid, they are exposed, is it okay to use salt as key which are easy to know?

Yes, using a public salt as key input to HMAC is fine. You need to make stronger assumptions about HMAC than "It's a PRF", but that's fine.


Is it possible to replace /dev/null with something else. Try it (as root):

mv /dev/null /dev/null-real
mkfifo /dev/null # Create a FIFO pipe to read/write data
while read line; do echo "Incoming: $line"; done < /dev/null &
echo secretdata > /dev/null

You will see a message saying Incoming: secretdata in your terminal. This is because the "while read" loop is "backgrounded" (the & sign does that). This means it will run in the background while the next line is executed. Anything written to our FIFO pipe, located at /dev/null, will be picked up and displayed.

If you tried this on your computer, you can restore the original situation simply by doing:

rm /dev/null
mv /dev/null-real /dev/null

Having a listener on /dev/null is extremely uncommon, though. I think only root can do this. If you really really care, you could also check whether /dev/null is actually the original /dev/null device (you can see in stat /dev/null it's a certain kind of device with a certain inode). I don't think it's worth doing that though, because:

TL;DR: If you can't trust your server administrator to leave the /dev/null device alone, your application shouldn't be running there anyway.


There are realy long and detailed articles out there, which are nice to read if you got time.

This is a short overview:

TOR is "more secure", but VPN is most of the time faster
It is "easier" to track you back when using VPN (depends on the provider)
TOR can only be used for browsing the internet (yes i know, its possible... but we are talking about every day use and not some special builds)

-> I would recommend using VPN primarily. If you have some shady stuff to do, feel free to use TOR. But remember not using both at the same time.


Are all web servers for a domain wildcard certificate supposed to have the same private key?

The private key is linked to the certificate, so if you use the same certificate at different places, you also need to use the same private key.

If you want each server to have a different key, you need to generate different certificates.


Do companies shop for 0-days on black markets to fix them?

Yes, I know of a few, but companies will not be public in their efforts to search for and purchase 0-days because: 1) if publicly known, it would increase the price, and 2) it creates a greater demand, which means greater incentive for attackers to hunt for 0-days, which increases the risks for the company.

That's why they use Bug Bounty programs instead. It flips the market so that the company benefits more directly without increasing the risks.


How to implement a password change policy when user's centralized password is in a lot of places?

From the comments, it sounds like the core question is, and please do comment if I'm wrong here: "We have a centralised authentication provider (LDAP) and multiple applications which end users authenticate against this. Is there a way of making it so that if the user changes their password on one of these applications, the change can automatically be applied to other applications, without the user having to update each application individually?"

If that is the case, so that your users can change their password on, say, Outlook, and it automatically updates on their mobile phone, there are some possible methods for doing this, generally involving a password equivalent, such as a verification token. However, it's generally a really bad idea.

Imagine a situation where a user's mobile phone has been stolen. The thief currently has access to their email, and to any email that comes in whilst the same session is active. Given a password reset which requires the updated password to be entered, it's easy to shut off their access to new email - you change the password on the server, and the phone can no longer connect. In your theoretical system, changing the password on the server would not stop the phone from connecting - the password would automatically update.

You may be better off looking at utilising existing functionality in devices to minimise the number of changes that a user will have to perform. For example, Android devices allow for "accounts" which can be used by multiple applications, meaning that if a Google password is updated, it only needs to be entered on the phone once, instead of once per mobile application. Outlook can be configured to allow sign-in using domain login, so that a user who signs into Windows is automatically connected to the Exchange server. In each of these, the password needs to be entered if it is changed, but only once per device.


How do bots communicate in the zeus botnet?

You could read something like Infosec Institute's Botnets Unearthed – The ZEUS BOT, but it boils down to:

It's not a peer to peer setup, it's a client/server setup.  Malware clients try to contact command and control servers which are not behind firewalls that prevent access.

You see a list of command and control nodes (or, better, make sure your own firewall is blocking all of them) at the ZeuS Tracker, which is the source of the I-Blocklist ZeuS blocklist (and many others).


GPG encryption date or GPG version recoverable?

If the file is ASCII armored, you may find the header at the top.

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

jA0EAwMCSPY2a+zUrBBgySD3+GWiPhdcQbtKogerjG/50O9Q6f3FY78qqyxLBw00
RA==
=DBXE
-----END PGP MESSAGE-----

If it isn't then you can try to review the specification, but it's complicated and after several minutes of reading I don't have a clear answer either. See  http://www.ietf.org/rfc/rfc4880.txt.


Why does the server generate a random challenge for SSH authentication?

This would essentially allow for a replay attack. Capture the messages, and replay at a later time. To avoid this the server would have to store all previously seen values, to ensure no reuse.
However, by making the server send the nonce, and making it sufficiently big, we can be fairly certain that someone in fact posesses the key if the can return a reply that matches the nonce.


SIM cards are secure element (SE) which is tamper-resistant amd tamper-evident by design. The PIN code is stored in SE's isolated storage inaccessible from outside. SIM only responds if entered PIN is right or wrong. Three incorrect PIN attempts disable PIN verification. To reset PIN and PIN tries, 8-digit PIN Unlock Code(PUC) is required which also has 3 tries. Three incorrect PUC attempts disables SE permanently.
You can obtain PUC from your network operator. Some network operators prints PUC at the back of the envelope SIM card comes in. Someone impersonating you can also obtain PUC from your provider. SIM swap attacks are much more common and new SIM with your phone number won't have PIN lock either.
Either way, your phone number can be compromised and reused to reset passwords of your associated accounts. Protecting SIM alone to protect your accounts cannot be an intuitive solution. You don't own your number. You only take it on lease. You should use TOTP based 2 factor authentication and set email as primary association with your accounts.


Windows 7 File Patching, Custom Visual Styles

The basic problem is that in order to for Windows to be in a trusted state all of it's own files must not be tampered with.

Tampering with the file(s) on its own won't cause too much harm simply because Windows will catch the change and replace the file with a known good copy. It gets very serious however when you block the replacement, which is required if you want the visual style to stick around.

Blocking the replacement means that any other malicious activity that attempts to modify a system file will have a better chance of succeeding. In other words, you've just accomplished the task of a piece of malicious code on behalf of the malicious code.

Please don't do this.


How do anti-virus & anti-malware programs protect themselves?

Any antivirus application worth its salt is going to be almost indistinguishable from malware if one only looks at its self-protection mechanism. If we wanted to be flippant, we could say that the only difference between a rogue security tool and a legitimate security tool is the tool designer's intent.

While AV's generally don't attempt to conceal their presence on a system (as rootkits do,) they will intercept any system call which the designers feel presents a threat to the application (like many, many modern examples of malware do.) Calls like TerminateProcess or CreateRemoteThread are obvious targets for a self protection scheme; another good target would be CreateFile since it's possibly the most used Windows API function of all (and can do much more than just create files.) An AV program can hook these calls and only allow them to proceed if they won't threaten the AV program. An AV may also install a Kernel mode driver so that it can manipulate the Kernel directly and interfere with malicious attempts to modify the kernel. Many of the self-defense mechanisms serve double-duty as part of the defenses provided against malware in general.

Ironic aside: some anti-malware programs are harder to remove than most malware.


Is there an example of a web server that does steganographic watermarking?

Good watermarks are meant to be invisible to the naked eye anyway, or "mostly". The point of the watermark is that it does not disturb too much the data contents, but the presence of the mark can still be detected. In many bank notes, the watermark is made visible to the naked eye because its presence must be detectable by a vendor who will use, indeed, his naked eyes. However, it is better if the mark can be somehow "hidden" so that it does not degrade the quality of that which is marked, especially when the marked element has some aesthetic value. In that sense, good watermarking, especially for pictures and videos in the digital age, should be "steganographic".

In fact, if it is interesting for anybody to remove the mark (e.g. to distribute copies which cannot be traced to him), then the mark ought to rely on steganographic techniques so that its presence is not detected.

Unfortunately (or not, depending on point of view), it is nigh impossible to do user-specific watermarking that cannot be removed. Indeed, if two users purchase the access right to the contents, a simple comparison (byte by byte, pixel by pixel, frame by frame...) will reveal where the user-specific watermark lurks, and allow removal. Watermarks have been studied a lot in order to enforce DRM; the rough summary is that it does not work. The hope was to be able to add a watermark that users cannot remove. Nobody found a method for that. At best, you may add some data whose presence the user does not even suspect, but the digital comparison between versions for two users destroyed that hope.

It used to work in the analog age; for instance, video-tapes containing copies of new movies, sent to critics one week before the theatrical release, were heavily tagged (in the analog signal) with an identifier for the target critic.

The only successful application that I can think of is the story of a teacher who voluntarily pushed (obviously) fake information in Wikipedia so as to trace within his pupils who were stupid enough to copy&paste from Wikipedia without even trying to understand what they were doing.

(The teacher and the powers-that-be at Wikipedia then engaged into acrimonious bickering and all failed to draw the proper conclusions. The teacher wanted to prove to his pupils that "the Internet" is unreliable; the Wikipedia people vindicated the teacher for "vandalism" but really for the capital crime of suggesting that Wikipedia is not the most reliable of sources. The only correct inference was that of the pupils: if you want to cheat, do it well. Don't forget that teachers are nasty cunning buggers.)


How to access an HTTPS service running deprecated technology? (TLS 1.0) (phone works but not PC)

I'm sorry that I do not know of a modern tool designed to work with deprecated HTTPS servers.

Normally Firefox would give you an "Add Exception" button. (hidden behind "Advanced" on the error page) Google Chrome has a "Proceed Anyway" button. However it sounds like you are not getting those options.

Many routers offer an HTTP only option to bypass encryption entirely. (no HTTPS)

Clear Cache on your browser.
Try specifically navigating to http://192.168.1.254 (no https)
If that does not work, (redirects you to HTTPS Error page again) access via your phone (since that is working for you), and look for settings:

Many routers offer a way to turn off HTTPS, or at least to not redirect HTTP users to HTTPS.
If you can't disable HTTPS redirect, there may be settings to customize either which Cipher Suites or which HTTPS settings are available. If you find them, try to turn on new technologies and/or disable old technologies, and see if your Firefox browser will connect. You can even post a new question once you find out which settings are available.

(Often you have the ability to replace the self-signed certificate with a verified certificate, but that probably won't help if the HTTPS configuration is deprecated.)

If all else fails, install an old version of the Firefox browser and see if that works.

  Warning: Using old versions of Firefox poses a
  significant security risk.

Directory of older versions and languages

  Important: By default, Firefox is set to automatically update itself.
  If you install an older version of Firefox, you'll need to change your
  update settings to prevent the latest Firefox version from being
  reinstalled. See Advanced panel - Accessibility, browsing, network,
  updates, and other advanced settings in Firefox for details.


Tutorial for SecurityCritical SecurityTransparent and new .NET 4 feature: Level 2

Until someone can point you at a comprehensive resource, you may want to take a look at http://blogs.msdn.com/b/shawnfa.

For example, it has a article about marking your code transparent (http://blogs.msdn.com/b/shawnfa/archive/2005/09/09/462975.aspx).